ComputerSurge/bind9
3
0
Fork 0
Code Pull Requests 1 Activity

added new RFCs

Browse Source
This commit is contained in:
Andreas Gustafsson
2000-09-20 14:05:08 +00:00
parent 0e07026a21
commit 5bb229d213
3 changed files with 2137 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

675
doc/rfc/rfc2929.txt Normal file
View File

@@ -0,0 +1,675 @@
Network Working Group D. Eastlake, 3rd
Request for Comments: 2929 Motorola
BCP: 42 E. Brunner-Williams
Category: Best Current Practice Engage
B. Manning
ISI
September 2000
Domain Name System (DNS) IANA Considerations
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
Internet Assigned Number Authority (IANA) parameter assignment
considerations are given for the allocation of Domain Name System
(DNS) classes, Resource Record (RR) types, operation codes, error
codes, etc.
Table of Contents
1. Introduction................................................. 2
2. DNS Query/Response Headers................................... 2
2.1 One Spare Bit?.............................................. 3
2.2 Opcode Assignment........................................... 3
2.3 RCODE Assignment............................................ 4
3. DNS Resource Records......................................... 5
3.1 RR TYPE IANA Considerations................................. 6
3.1.1 Special Note on the OPT RR................................ 7
3.2 RR CLASS IANA Considerations................................ 7
3.3 RR NAME Considerations...................................... 8
4. Security Considerations...................................... 9
References...................................................... 9
Authors' Addresses.............................................. 11
Full Copyright Statement........................................ 12
Eastlake, et al. Best Current Practice [Page 1]
RFC 2929 DNS IANA Considerations September 2000
1. Introduction
The Domain Name System (DNS) provides replicated distributed secure
hierarchical databases which hierarchically store "resource records"
(RRs) under domain names.
This data is structured into CLASSes and zones which can be
independently maintained. See [RFC 1034, 1035, 2136, 2181, 2535]
familiarity with which is assumed.
This document covers, either directly or by reference, general IANA
parameter assignment considerations applying across DNS query and
response headers and all RRs. There may be additional IANA
considerations that apply to only a particular RR type or
query/response opcode. See the specific RFC defining that RR type or
query/response opcode for such considerations if they have been
defined.
IANA currently maintains a web page of DNS parameters. See
<http://www.iana.org/numbers.htm>.
"IETF Standards Action", "IETF Consensus", "Specification Required",
and "Private Use" are as defined in [RFC 2434].
2. DNS Query/Response Headers
The header for DNS queries and responses contains field/bits in the
following diagram taken from [RFC 2136, 2535]:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT/ZOCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT/PRCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT/UPCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The ID field identifies the query and is echoed in the response so
they can be matched.
Eastlake, et al. Best Current Practice [Page 2]
RFC 2929 DNS IANA Considerations September 2000
The QR bit indicates whether the header is for a query or a response.
The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
only in queries or only in responses, depending on the bit. However,
many DNS implementations copy the query header as the initial value
of the response header without clearing bits. Thus any attempt to
use a "query" bit with a different meaning in a response or to define
a query meaning for a "response" bit is dangerous given existing
implementation. Such meanings may only be assigned by an IETF
Standards Action.
The unsigned fields query count (QDCOUNT), answer count (ANCOUNT),
authority count (NSCOUNT), and additional information count (ARCOUNT)
express the number of records in each section for all opcodes except
Update. These fields have the same structure and data type for
Update but are instead the counts for the zone (ZOCOUNT),
prerequisite (PRCOUNT), update (UPCOUNT), and additional information
(ARCOUNT) sections.
2.1 One Spare Bit?
There have been ancient DNS implementations for which the Z bit being
on in a query meant that only a response from the primary server for
a zone is acceptable. It is believed that current DNS
implementations ignore this bit.
Assigning a meaning to the Z bit requires an IETF Standards Action.
2.2 Opcode Assignment
New OpCode assignments require an IETF Standards Action.
Currently DNS OpCodes are assigned as follows:
OpCode Name Reference
0 Query [RFC 1035]
1 IQuery (Inverse Query) [RFC 1035]
2 Status [RFC 1035]
3 available for assignment
4 Notify [RFC 1996]
5 Update [RFC 2136]
6-15 available for assignment
Eastlake, et al. Best Current Practice [Page 3]
RFC 2929 DNS IANA Considerations September 2000
2.3 RCODE Assignment
It would appear from the DNS header above that only four bits of
RCODE, or response/error code are available. However, RCODEs can
appear not only at the top level of a DNS response but also inside
OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930].
The OPT RR provides an eight bit extension resulting in a 12 bit
RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field.
Error codes appearing in the DNS header and in these three RR types
all refer to the same error code space with the single exception of
error code 16 which has a different meaning in the OPT RR from its
meaning in other contexts. See table below.
RCODE Name Description Reference
Decimal
Hexadecimal
0 NoError No Error [RFC 1035]
1 FormErr Format Error [RFC 1035]
2 ServFail Server Failure [RFC 1035]
3 NXDomain Non-Existent Domain [RFC 1035]
4 NotImp Not Implemented [RFC 1035]
5 Refused Query Refused [RFC 1035]
6 YXDomain Name Exists when it should not [RFC 2136]
7 YXRRSet RR Set Exists when it should not [RFC 2136]
8 NXRRSet RR Set that should exist does not [RFC 2136]
9 NotAuth Server Not Authoritative for zone [RFC 2136]
10 NotZone Name not contained in zone [RFC 2136]
11-15 available for assignment
16 BADVERS Bad OPT Version [RFC 2671]
16 BADSIG TSIG Signature Failure [RFC 2845]
17 BADKEY Key not recognized [RFC 2845]
18 BADTIME Signature out of time window [RFC 2845]
19 BADMODE Bad TKEY Mode [RFC 2930]
20 BADNAME Duplicate key name [RFC 2930]
21 BADALG Algorithm not supported [RFC 2930]
22-3840 available for assignment
0x0016-0x0F00
3841-4095 Private Use
0x0F01-0x0FFF
4096-65535 available for assignment
0x1000-0xFFFF
Since it is important that RCODEs be understood for interoperability,
assignment of new RCODE listed above as "available for assignment"
requires an IETF Consensus.
Eastlake, et al. Best Current Practice [Page 4]
RFC 2929 DNS IANA Considerations September 2000
3. DNS Resource Records
All RRs have the same top level format shown in the figure below
taken from [RFC 1035]:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NAME is an owner name, i.e., the name of the node to which this
resource record pertains. NAMEs are specific to a CLASS as described
in section 3.2. NAMEs consist of an ordered sequence of one or more
labels each of which has a label type [RFC 1035, 2671].
TYPE is a two octet unsigned integer containing one of the RR TYPE
codes. See section 3.1.
CLASS is a two octet unsigned integer containing one of the RR CLASS
codes. See section 3.2.
TTL is a four octet (32 bit) bit unsigned integer that specifies the
number of seconds that the resource record may be cached before the
source of the information should again be consulted. Zero is
interpreted to mean that the RR can only be used for the transaction
in progress.
RDLENGTH is an unsigned 16 bit integer that specifies the length in
octets of the RDATA field.
Eastlake, et al. Best Current Practice [Page 5]
RFC 2929 DNS IANA Considerations September 2000
RDATA is a variable length string of octets that constitutes the
resource. The format of this information varies according to the
TYPE and in some cases the CLASS of the resource record.
3.1 RR TYPE IANA Considerations
There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
and MetaTYPEs.
Data TYPEs are the primary means of storing data. QTYPES can only be
used in queries. Meta-TYPEs designate transient data associated with
an particular DNS message and in some cases can also be used in
queries. Thus far, data TYPEs have been assigned from 1 upwards plus
the block from 100 through 103 while Q and Meta Types have been
assigned from 255 downwards (except for the OPT Meta-RR which is
assigned TYPE 41). There have been DNS implementations which made
caching decisions based on the top bit of the bottom byte of the RR
TYPE.
There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG
[RFC 2845], and TKEY [RFC 2930].
There are currently five QTYPEs assigned: * (all), MAILA, MAILB,
AXFR, and IXFR.
Considerations for the allocation of new RR TYPEs are as follows:
Decimal
Hexadecimal
0
0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
2535] and in other circumstances and must never be allocated
for ordinary use.
1 - 127
0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
TYPEs by IETF Consensus.
128 - 255
0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
Meta TYPEs by IETF Consensus.
256 - 32767
0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by IETF
Consensus.
Eastlake, et al. Best Current Practice [Page 6]
RFC 2929 DNS IANA Considerations September 2000
32768 - 65279
0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
65280 - 65535
0xFF00 - 0xFFFF - Private Use.
3.1.1 Special Note on the OPT RR
The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its
primary purpose is to extend the effective field size of various DNS
fields including RCODE, label type, flag bits, and RDATA size. In
particular, for resolvers and servers that recognize it, it extends
the RCODE field from 4 to 12 bits.
3.2 RR CLASS IANA Considerations
DNS CLASSes have been little used but constitute another dimension of
the DNS distributed database. In particular, there is no necessary
relationship between the name space or root servers for one CLASS and
those for another CLASS. The same name can have completely different
meanings in different CLASSes although the label types are the same
and the null label is usable only as root in every CLASS. However,
as global networking and DNS have evolved, the IN, or Internet, CLASS
has dominated DNS use.
There are two subcategories of DNS CLASSes: normal data containing
classes and QCLASSes that are only meaningful in queries or updates.
The current CLASS assignments and considerations for future
assignments are as follows:
Decimal
Hexadecimal
0
0x0000 - assignment requires an IETF Standards Action.
1
0x0001 - Internet (IN).
2
0x0002 - available for assignment by IETF Consensus as a data CLASS.
3
0x0003 - Chaos (CH) [Moon 1981].
4
0x0004 - Hesiod (HS) [Dyer 1987].
Eastlake, et al. Best Current Practice [Page 7]
RFC 2929 DNS IANA Considerations September 2000
5 - 127
0x0005 - 0x007F - available for assignment by IETF Consensus as data
CLASSes only.
128 - 253
0x0080 - 0x00FD - available for assignment by IETF Consensus as
QCLASSes only.
254
0x00FE - QCLASS None [RFC 2136].
255
0x00FF - QCLASS Any [RFC 1035].
256 - 32767
0x0100 - 0x7FFF - assigned by IETF Consensus.
32768 - 65280
0x8000 - 0xFEFF - assigned based on Specification Required as defined
in [RFC 2434].
65280 - 65534
0xFF00 - 0xFFFE - Private Use.
65535
0xFFFF - can only be assigned by an IETF Standards Action.
3.3 RR NAME Considerations
DNS NAMEs are sequences of labels [RFC 1035]. The last label in each
NAME is "ROOT" which is the zero length label. By definition, the
null or ROOT label can not be used for any other NAME purpose.
At the present time, there are two categories of label types, data
labels and compression labels. Compression labels are pointers to
data labels elsewhere within an RR or DNS message and are intended to
shorten the wire encoding of NAMEs. The two existing data label
types are sometimes referred to as Text and Binary. Text labels can,
in fact, include any octet value including zero octets but most
current uses involve only [US-ASCII]. For retrieval, Text labels are
defined to treat ASCII upper and lower case letter codes as matching.
Binary labels are bit sequences [RFC 2673].
IANA considerations for label types are given in [RFC 2671].
Eastlake, et al. Best Current Practice [Page 8]
RFC 2929 DNS IANA Considerations September 2000
NAMEs are local to a CLASS. The Hesiod [Dyer 1987] and Chaos [Moon
1981] CLASSes are essentially for local use. The IN or Internet
CLASS is thus the only DNS CLASS in global use on the Internet at
this time.
A somewhat dated description of name allocation in the IN Class is
given in [RFC 1591]. Some information on reserved top level domain
names is in Best Current Practice 32 [RFC 2606].
4. Security Considerations
This document addresses IANA considerations in the allocation of
general DNS parameters, not security. See [RFC 2535] for secure DNS
considerations.
References
[Dyer 1987] Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical
Plan - Name Service, April 1987,
[Moon 1981] D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
Institute of Technology Artificial Intelligence
Laboratory, June 1981.
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, November 1987.
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and
Specifications", STD 13, RFC 1035, November 1987.
[RFC 1591] Postel, J., "Domain Name System Structure and
Delegation", RFC 1591, March 1994.
[RFC 1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC 2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
Eastlake, et al. Best Current Practice [Page 9]
RFC 2929 DNS IANA Considerations September 2000
[RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC 2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", RFC 2606, June 1999.
[RFC 2671] Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
[RFC 2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
2672, August 1999.
[RFC 2673] Crawford, M., "Binary Labels in the Domain Name System",
RFC 2673, August 1999.
[RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
Wellington, "Secret Key Transaction Authentication for
DNS (TSIG)", RFC 2845, May 2000.
[RFC 2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, September 2000.
[US-ASCII] ANSI, "USA Standard Code for Information Interchange",
X3.4, American National Standards Institute: New York,
1968.
Eastlake, et al. Best Current Practice [Page 10]
RFC 2929 DNS IANA Considerations September 2000
Authors' Addresses
Donald E. Eastlake 3rd
Motorola
140 Forest Avenue
Hudson, MA 01749 USA
Phone: +1-978-562-2827 (h)
+1-508-261-5434 (w)
Fax: +1-508-261-4447 (w)
EMail: Donald.Eastlake@motorola.com
Eric Brunner-Williams
Engage
100 Brickstone Square, 2nd Floor
Andover, MA 01810
Phone: +1-207-797-0525 (h)
+1-978-684-7796 (w)
Fax: +1-978-684-3118
EMail: brunner@engage.com
Bill Manning
USC/ISI
4676 Admiralty Way, #1001
Marina del Rey, CA 90292 USA
Phone: +1-310-822-1511
EMail: bmanning@isi.edu
Eastlake, et al. Best Current Practice [Page 11]
RFC 2929 DNS IANA Considerations September 2000
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Eastlake, et al. Best Current Practice [Page 12]

899
doc/rfc/rfc2930.txt Normal file
View File

@@ -0,0 +1,899 @@
Network Working Group D. Eastlake, 3rd
Request for Comments: 2930 Motorola
Category: Standards Track September 2000
Secret Key Establishment for DNS (TKEY RR)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
[RFC 2845] provides a means of authenticating Domain Name System
(DNS) queries and responses using shared secret keys via the
Transaction Signature (TSIG) resource record (RR). However, it
provides no mechanism for setting up such keys other than manual
exchange. This document describes a Transaction Key (TKEY) RR that
can be used in a number of different modes to establish shared secret
keys between a DNS resolver and server.
Acknowledgments
The comments and ideas of the following persons (listed in alphabetic
order) have been incorporated herein and are gratefully acknowledged:
Olafur Gudmundsson (TIS)
Stuart Kwan (Microsoft)
Ed Lewis (TIS)
Erik Nordmark (SUN)
Brian Wellington (Nominum)
Eastlake Standards Track [Page 1]
RFC 2930 The DNS TKEY RR September 2000
Table of Contents
1. Introduction............................................... 2
1.1 Overview of Contents...................................... 3
2. The TKEY Resource Record................................... 4
2.1 The Name Field............................................ 4
2.2 The TTL Field............................................. 5
2.3 The Algorithm Field....................................... 5
2.4 The Inception and Expiration Fields....................... 5
2.5 The Mode Field............................................ 5
2.6 The Error Field........................................... 6
2.7 The Key Size and Data Fields.............................. 6
2.8 The Other Size and Data Fields............................ 6
3. General TKEY Considerations................................ 7
4. Exchange via Resolver Query................................ 8
4.1 Query for Diffie-Hellman Exchanged Keying................. 8
4.2 Query for TKEY Deletion................................... 9
4.3 Query for GSS-API Establishment........................... 10
4.4 Query for Server Assigned Keying.......................... 10
4.5 Query for Resolver Assigned Keying........................ 11
5. Spontaneous Server Inclusion............................... 12
5.1 Spontaneous Server Key Deletion........................... 12
6. Methods of Encryption...................................... 12
7. IANA Considerations........................................ 13
8. Security Considerations.................................... 13
References.................................................... 14
Author's Address.............................................. 15
Full Copyright Statement...................................... 16
1. Introduction
The Domain Name System (DNS) is a hierarchical, distributed, highly
available database used for bi-directional mapping between domain
names and addresses, for email routing, and for other information
[RFC 1034, 1035]. It has been extended to provide for public key
security and dynamic update [RFC 2535, RFC 2136]. Familiarity with
these RFCs is assumed.
[RFC 2845] provides a means of efficiently authenticating DNS
messages using shared secret keys via the TSIG resource record (RR)
but provides no mechanism for setting up such keys other than manual
exchange. This document specifies a TKEY RR that can be used in a
number of different modes to establish and delete such shared secret
keys between a DNS resolver and server.
Eastlake Standards Track [Page 2]
RFC 2930 The DNS TKEY RR September 2000
Note that TKEY established keying material and TSIGs that use it are
associated with DNS servers or resolvers. They are not associated
with zones. They may be used to authenticate queries and responses
but they do not provide zone based DNS data origin or denial
authentication [RFC 2535].
Certain modes of TKEY perform encryption which may affect their
export or import status for some countries. The affected modes
specified in this document are the server assigned mode and the
resolver assigned mode.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
In all cases herein, the term "resolver" includes that part of a
server which may make full and incremental [RFC 1995] zone transfer
queries, forwards recursive queries, etc.
1.1 Overview of Contents
Section 2 below specifies the TKEY RR and provides a description of
and considerations for its constituent fields.
Section 3 describes general principles of operations with TKEY.
Section 4 discusses key agreement and deletion via DNS requests with
the Query opcode for RR type TKEY. This method is applicable to all
currently defined TKEY modes, although in some cases it is not what
would intuitively be called a "query".
Section 5 discusses spontaneous inclusion of TKEY RRs in responses by
servers which is currently used only for key deletion.
Section 6 describes encryption methods for transmitting secret key
information. In this document these are used only for the server
assigned mode and the resolver assigned mode.
Section 7 covers IANA considerations in assignment of TKEY modes.
Finally, Section 8 provides the required security considerations
section.
Eastlake Standards Track [Page 3]
RFC 2930 The DNS TKEY RR September 2000
2. The TKEY Resource Record
The TKEY resource record (RR) has the structure given below. Its RR
type code is 249.
Field Type Comment
----- ---- -------
NAME domain see description below
TTYPE u_int16_t TKEY = 249
CLASS u_int16_t ignored, SHOULD be 255 (ANY)
TTL u_int32_t ignored, SHOULD be zero
RDLEN u_int16_t size of RDATA
RDATA:
Algorithm: domain
Inception: u_int32_t
Expiration: u_int32_t
Mode: u_int16_t
Error: u_int16_t
Key Size: u_int16_t
Key Data: octet-stream
Other Size: u_int16_t
Other Data: octet-stream undefined by this specification
2.1 The Name Field
The Name field relates to naming keys. Its meaning differs somewhat
with mode and context as explained in subsequent sections.
At any DNS server or resolver only one octet string of keying
material may be in place for any particular key name. An attempt to
establish another set of keying material at a server for an existing
name returns a BADNAME error.
For a TKEY with a non-root name appearing in a query, the TKEY RR
name SHOULD be a domain locally unique at the resolver, less than 128
octets long in wire encoding, and meaningful to the resolver to
assist in distinguishing keys and/or key agreement sessions. For
TKEY(s) appearing in a response to a query, the TKEY RR name SHOULD
be a globally unique server assigned domain.
A reasonable key naming strategy is as follows:
If the key is generated as the result of a query with root as its
owner name, then the server SHOULD create a globally unique domain
name, to be the key name, by suffixing a pseudo-random [RFC 1750]
label with a domain name of the server. For example
89n3mDgX072pp.server1.example.com. If generation of a new
Eastlake Standards Track [Page 4]
RFC 2930 The DNS TKEY RR September 2000
pseudo-random name in each case is an excessive computation load
or entropy drain, a serial number prefix can be added to a fixed
pseudo-random name generated an DNS server start time, such as
1001.89n3mDgX072pp.server1.example.com.
If the key is generated as the result of a query with a non-root
name, say 789.resolver.example.net, then use the concatenation of
that with a name of the server. For example
789.resolver.example.net.server1.example.com.
2.2 The TTL Field
The TTL field is meaningless in TKEY RRs. It SHOULD always be zero to
be sure that older DNS implementations do not cache TKEY RRs.
2.3 The Algorithm Field
The algorithm name is in the form of a domain name with the same
meaning as in [RFC 2845]. The algorithm determines how the secret
keying material agreed to using the TKEY RR is actually used to
derive the algorithm specific key.
2.4 The Inception and Expiration Fields
The inception time and expiration times are in number of seconds
since the beginning of 1 January 1970 GMT ignoring leap seconds
treated as modulo 2**32 using ring arithmetic [RFC 1982]. In messages
between a DNS resolver and a DNS server where these fields are
meaningful, they are either the requested validity interval for the
keying material asked for or specify the validity interval of keying
material provided.
To avoid different interpretations of the inception and expiration
times in TKEY RRs, resolvers and servers exchanging them must have
the same idea of what time it is. One way of doing this is with the
NTP protocol [RFC 2030] but that or any other time synchronization
used for this purpose MUST be done securely.
2.5 The Mode Field
The mode field specifies the general scheme for key agreement or the
purpose of the TKEY DNS message. Servers and resolvers supporting
this specification MUST implement the Diffie-Hellman key agreement
mode and the key deletion mode for queries. All other modes are
OPTIONAL. A server supporting TKEY that receives a TKEY request with
a mode it does not support returns the BADMODE error. The following
values of the Mode octet are defined, available, or reserved:
Eastlake Standards Track [Page 5]
RFC 2930 The DNS TKEY RR September 2000
Value Description
----- -----------
0 - reserved, see section 7
1 server assignment
2 Diffie-Hellman exchange
3 GSS-API negotiation
4 resolver assignment
5 key deletion
6-65534 - available, see section 7
65535 - reserved, see section 7
2.6 The Error Field
The error code field is an extended RCODE. The following values are
defined:
Value Description
----- -----------
0 - no error
1-15 a non-extended RCODE
16 BADSIG (TSIG)
17 BADKEY (TSIG)
18 BADTIME (TSIG)
19 BADMODE
20 BADNAME
21 BADALG
When the TKEY Error Field is non-zero in a response to a TKEY query,
the DNS header RCODE field indicates no error. However, it is
possible if a TKEY is spontaneously included in a response the TKEY
RR and DNS header error field could have unrelated non-zero error
codes.
2.7 The Key Size and Data Fields
The key data size field is an unsigned 16 bit integer in network
order which specifies the size of the key exchange data field in
octets. The meaning of this data depends on the mode.
2.8 The Other Size and Data Fields
The Other Size and Other Data fields are not used in this
specification but may be used in future extensions. The RDLEN field
MUST equal the length of the RDATA section through the end of Other
Data or the RR is to be considered malformed and rejected.
Eastlake Standards Track [Page 6]
RFC 2930 The DNS TKEY RR September 2000
3. General TKEY Considerations
TKEY is a meta-RR that is not stored or cached in the DNS and does
not appear in zone files. It supports a variety of modes for the
establishment and deletion of shared secret keys information between
DNS resolvers and servers. The establishment of such a shared key
requires that state be maintained at both ends and the allocation of
the resources to maintain such state may require mutual agreement. In
the absence of willingness to provide such state, servers MUST return
errors such as NOTIMP or REFUSED for an attempt to use TKEY and
resolvers are free to ignore any TKEY RRs they receive.
The shared secret keying material developed by using TKEY is a plain
octet sequence. The means by which this shared secret keying
material, exchanged via TKEY, is actually used in any particular TSIG
algorithm is algorithm dependent and is defined in connection with
that algorithm. For example, see [RFC 2104] for how TKEY agreed
shared secret keying material is used in the HMAC-MD5 algorithm or
other HMAC algorithms.
There MUST NOT be more than one TKEY RR in a DNS query or response.
Except for GSS-API mode, TKEY responses MUST always have DNS
transaction authentication to protect the integrity of any keying
data, error codes, etc. This authentication MUST use a previously
established secret (TSIG) or public (SIG(0) [RFC 2931]) key and MUST
NOT use any key that the response to be verified is itself providing.
TKEY queries MUST be authenticated for all modes except GSS-API and,
under some circumstances, server assignment mode. In particular, if
the query for a server assigned key is for a key to assert some
privilege, such as update authority, then the query must be
authenticated to avoid spoofing. However, if the key is just to be
used for transaction security, then spoofing will lead at worst to
denial of service. Query authentication SHOULD use an established
secret (TSIG) key authenticator if available. Otherwise, it must use
a public (SIG(0)) key signature. It MUST NOT use any key that the
query is itself providing.
In the absence of required TKEY authentication, a NOTAUTH error MUST
be returned.
To avoid replay attacks, it is necessary that a TKEY response or
query not be valid if replayed on the order of 2**32 second (about
136 years), or a multiple thereof, later. To accomplish this, the
keying material used in any TSIG or SIG(0) RR that authenticates a
TKEY message MUST NOT have a lifetime of more then 2**31 - 1 seconds
Eastlake Standards Track [Page 7]
RFC 2930 The DNS TKEY RR September 2000
(about 68 years). Thus, on attempted replay, the authenticating TSIG
or SIG(0) RR will not be verifiable due to key expiration and the
replay will fail.
4. Exchange via Resolver Query
One method for a resolver and a server to agree about shared secret
keying material for use in TSIG is through DNS requests from the
resolver which are syntactically DNS queries for type TKEY. Such
queries MUST be accompanied by a TKEY RR in the additional
information section to indicate the mode in use and accompanied by
other information where required.
Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY
ignore the recursive header bit in TKEY queries they receive.
4.1 Query for Diffie-Hellman Exchanged Keying
Diffie-Hellman (DH) key exchange is a means whereby two parties can
derive some shared secret information without requiring any secrecy
of the messages they exchange [Schneier]. Provisions have been made
for the storage of DH public keys in the DNS [RFC 2539].
A resolver sends a query for type TKEY accompanied by a TKEY RR in
the additional information section specifying the Diffie-Hellman mode
and accompanied by a KEY RR also in the additional information
section specifying a resolver Diffie-Hellman key. The TKEY RR
algorithm field is set to the authentication algorithm the resolver
plans to use. The "key data" provided in the TKEY is used as a random
[RFC 1750] nonce to avoid always deriving the same keying material
for the same pair of DH KEYs.
The server response contains a TKEY in its answer section with the
Diffie-Hellman mode. The "key data" provided in this TKEY is used as
an additional nonce to avoid always deriving the same keying material
for the same pair of DH KEYs. If the TKEY error field is non-zero,
the query failed for the reason given. FORMERR is given if the query
included no DH KEY and BADKEY is given if the query included an
incompatible DH KEY.
If the TKEY error field is zero, the resolver supplied Diffie-Hellman
KEY RR SHOULD be echoed in the additional information section and a
server Diffie-Hellman KEY RR will also be present in the answer
section of the response. Both parties can then calculate the same
shared secret quantity from the pair of Diffie-Hellman (DH) keys used
[Schneier] (provided these DH keys use the same generator and
modulus) and the data in the TKEY RRs. The TKEY RR data is mixed
with the DH result as follows:
Eastlake Standards Track [Page 8]
RFC 2930 The DNS TKEY RR September 2000
keying material =
XOR ( DH value, MD5 ( query data | DH value ) |
MD5 ( server data | DH value ) )
Where XOR is an exclusive-OR operation and "|" is byte-stream
concatenation. The shorter of the two operands to XOR is byte-wise
left justified and padded with zero-valued bytes to match the length
of the other operand. "DH value" is the Diffie-Hellman value derived
from the KEY RRs. Query data and server data are the values sent in
the TKEY RR data fields. These "query data" and "server data" nonces
are suffixed by the DH value, digested by MD5, the results
concatenated, and then XORed with the DH value.
The inception and expiry times in the query TKEY RR are those
requested for the keying material. The inception and expiry times in
the response TKEY RR are the maximum period the server will consider
the keying material valid. Servers may pre-expire keys so this is
not a guarantee.
4.2 Query for TKEY Deletion
Keys established via TKEY can be treated as soft state. Since DNS
transactions are originated by the resolver, the resolver can simply
toss keys, although it may have to go through another key exchange if
it later needs one. Similarly, the server can discard keys although
that will result in an error on receiving a query with a TSIG using
the discarded key.
To avoid attempted reliance in requests on keys no longer in effect,
servers MUST implement key deletion whereby the server "discards" a
key on receipt from a resolver of an authenticated delete request for
a TKEY RR with the key's name. If the server has no record of a key
with that name, it returns BADNAME.
Key deletion TKEY queries MUST be authenticated. This authentication
MAY be a TSIG RR using the key to be deleted.
For querier assigned and Diffie-Hellman keys, the server MUST truly
"discard" all active state associated with the key. For server
assigned keys, the server MAY simply mark the key as no longer
retained by the client and may re-send it in response to a future
query for server assigned keying material.
Eastlake Standards Track [Page 9]
RFC 2930 The DNS TKEY RR September 2000
4.3 Query for GSS-API Establishment
This mode is described in a separate document under preparation which
should be seen for the full description. Basically the resolver and
server can exchange queries and responses for type TKEY with a TKEY
RR specifying the GSS-API mode in the additional information section
and a GSS-API token in the key data portion of the TKEY RR.
Any issues of possible encryption of parts the GSS-API token data
being transmitted are handled by the GSS-API level. In addition, the
GSS-API level provides its own authentication so that this mode of
TKEY query and response MAY be, but do not need to be, authenticated
with TSIG RR or SIG(0) RR [RFC 2931].
The inception and expiry times in a GSS-API mode TKEY RR are ignored.
4.4 Query for Server Assigned Keying
Optionally, the server can assign keying for the resolver. It is
sent to the resolver encrypted under a resolver public key. See
section 6 for description of encryption methods.
A resolver sends a query for type TKEY accompanied by a TKEY RR
specifying the "server assignment" mode and a resolver KEY RR to be
used in encrypting the response, both in the additional information
section. The TKEY algorithm field is set to the authentication
algorithm the resolver plans to use. It is RECOMMENDED that any "key
data" provided in the query TKEY RR by the resolver be strongly mixed
by the server with server generated randomness [RFC 1750] to derive
the keying material to be used. The KEY RR that appears in the query
need not be accompanied by a SIG(KEY) RR. If the query is
authenticated by the resolver with a TSIG RR [RFC 2845] or SIG(0) RR
and that authentication is verified, then any SIG(KEY) provided in
the query SHOULD be ignored. The KEY RR in such a query SHOULD have
a name that corresponds to the resolver but it is only essential that
it be a public key for which the resolver has the corresponding
private key so it can decrypt the response data.
The server response contains a TKEY RR in its answer section with the
server assigned mode and echoes the KEY RR provided in the query in
its additional information section.
If the response TKEY error field is zero, the key data portion of the
response TKEY RR will be the server assigned keying data encrypted
under the public key in the resolver provided KEY RR. In this case,
the owner name of the answer TKEY RR will be the server assigned name
of the key.
Eastlake Standards Track [Page 10]
RFC 2930 The DNS TKEY RR September 2000
If the error field of the response TKEY is non-zero, the query failed
for the reason given. FORMERR is given if the query specified no
encryption key.
The inception and expiry times in the query TKEY RR are those
requested for the keying material. The inception and expiry times in
the response TKEY are the maximum period the server will consider the
keying material valid. Servers may pre-expire keys so this is not a
guarantee.
The resolver KEY RR MUST be authenticated, through the authentication
of this query with a TSIG or SIG(0) or the signing of the resolver
KEY with a SIG(KEY). Otherwise, an attacker can forge a resolver KEY
for which they know the private key, and thereby the attacker could
obtain a valid shared secret key from the server.
4.5 Query for Resolver Assigned Keying
Optionally, a server can accept resolver assigned keys. The keying
material MUST be encrypted under a server key for protection in
transmission as described in Section 6.
The resolver sends a TKEY query with a TKEY RR that specifies the
encrypted keying material and a KEY RR specifying the server public
key used to encrypt the data, both in the additional information
section. The name of the key and the keying data are completely
controlled by the sending resolver so a globally unique key name
SHOULD be used. The KEY RR used MUST be one for which the server has
the corresponding private key, or it will not be able to decrypt the
keying material and will return a FORMERR. It is also important that
no untrusted party (preferably no other party than the server) has
the private key corresponding to the KEY RR because, if they do, they
can capture the messages to the server, learn the shared secret, and
spoof valid TSIGs.
The query TKEY RR inception and expiry give the time period the
querier intends to consider the keying material valid. The server
can return a lesser time interval to advise that it will not maintain
state for that long and can pre-expire keys in any case.
This mode of query MUST be authenticated with a TSIG or SIG(0).
Otherwise, an attacker can forge a resolver assigned TKEY query, and
thereby the attacker could specify a shared secret key that would be
accepted, used, and honored by the server.
Eastlake Standards Track [Page 11]
RFC 2930 The DNS TKEY RR September 2000
5. Spontaneous Server Inclusion
A DNS server may include a TKEY RR spontaneously as additional
information in responses. This SHOULD only be done if the server
knows the querier understands TKEY and has this option implemented.
This technique can be used to delete a key and may be specified for
modes defined in the future. A disadvantage of this technique is
that there is no way for the server to get any error or success
indication back and, in the case of UDP, no way to even know if the
DNS response reached the resolver.
5.1 Spontaneous Server Key Deletion
A server can optionally tell a client that it has deleted a secret
key by spontaneously including a TKEY RR in the additional
information section of a response with the key's name and specifying
the key deletion mode. Such a response SHOULD be authenticated. If
authenticated, it "deletes" the key with the given name. The
inception and expiry times of the delete TKEY RR are ignored. Failure
by a client to receive or properly process such additional
information in a response would mean that the client might use a key
that the server had discarded and would then get an error indication.
For server assigned and Diffie-Hellman keys, the client MUST
"discard" active state associated with the key. For querier assigned
keys, the querier MAY simply mark the key as no longer retained by
the server and may re-send it in a future query specifying querier
assigned keying material.
6. Methods of Encryption
For the server assigned and resolver assigned key agreement modes,
the keying material is sent within the key data field of a TKEY RR
encrypted under the public key in an accompanying KEY RR [RFC 2535].
This KEY RR MUST be for a public key algorithm where the public and
private keys can be used for encryption and the corresponding
decryption which recovers the originally encrypted data. The KEY RR
SHOULD correspond to a name for the decrypting resolver/server such
that the decrypting process has access to the corresponding private
key to decrypt the data. The secret keying material being sent will
generally be fairly short, usually less than 256 bits, because that
is adequate for very strong protection with modern keyed hash or
symmetric algorithms.
If the KEY RR specifies the RSA algorithm, then the keying material
is encrypted as per the description of RSAES-PKCS1-v1_5 encryption in
PKCS#1 [RFC 2437]. (Note, the secret keying material being sent is
directly RSA encrypted in PKCS#1 format. It is not "enveloped" under
Eastlake Standards Track [Page 12]
RFC 2930 The DNS TKEY RR September 2000
some other symmetric algorithm.) In the unlikely event that the
keying material will not fit within one RSA modulus of the chosen
public key, additional RSA encryption blocks are included. The
length of each block is clear from the public RSA key specified and
the RSAES-PKCS1-v1_5 padding makes it clear what part of the
encrypted data is actually keying material and what part is
formatting or the required at least eight bytes of random [RFC 1750]
padding.
7. IANA Considerations
This section is to be interpreted as provided in [RFC 2434].
Mode field values 0x0000 and 0xFFFF are reserved.
Mode field values 0x0001 through 0x00FF, and 0XFF00 through 0XFFFE
can only be assigned by an IETF Standards Action.
Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF
are allocated by IESG approval or IETF consensus.
Mode field values 0x1000 through 0xEFFF are allocated based on
Specification Required as defined in [RFC 2434].
Mode values should not be changed when the status of their use
changes. For example, a mode value assigned based just on providing
a specification should not be changed later just because that use's
status is changed to standards track.
The following assignments are documented herein:
RR Type 249 for TKEY.
TKEY Modes 1 through 5 as listed in section 2.5.
Extended RCODE Error values of 19, 20, and 21 as listed in section
2.6.
8. Security Considerations
The entirety of this specification is concerned with the secure
establishment of a shared secret between DNS clients and servers in
support of TSIG [RFC 2845].
Protection against denial of service via the use of TKEY is not
provided.
Eastlake Standards Track [Page 13]
RFC 2930 The DNS TKEY RR September 2000
References
[Schneier] Bruce Schneier, "Applied Cryptography: Protocols,
Algorithms, and Source Code in C", 1996, John Wiley and
Sons
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and
Specifications", STD 13, RFC 1035, November 1987.
[RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
September 1996.
[RFC 1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
August 1996.
[RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
[RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
Specifications Version 2.0", RFC 2437, October 1998.
[RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC 2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
Domain Name System (DNS)", RFC 2539, March 1999.
Eastlake Standards Track [Page 14]
RFC 2930 The DNS TKEY RR September 2000
[RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.
[RFC 2931] Eastlake, D., "DNS Request and Transaction Signatures
(SIG(0)s )", RFC 2931, September 2000.
Author's Address
Donald E. Eastlake 3rd
Motorola
140 Forest Avenue
Hudson, MA 01749 USA
Phone: +1 978-562-2827 (h)
+1 508-261-5434 (w)
Fax: +1 508-261-4447 (w)
EMail: Donald.Eastlake@motorola.com
Eastlake Standards Track [Page 15]
RFC 2930 The DNS TKEY RR September 2000
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Eastlake Standards Track [Page 16]

563
doc/rfc/rfc2931.txt Normal file
View File

@@ -0,0 +1,563 @@
Network Working Group D. Eastlake 3rd
Request for Comments: 2931 Motorola
Updates: 2535 September 2000
Category: Standards Track
DNS Request and Transaction Signatures ( SIG(0)s )
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
Extensions to the Domain Name System (DNS) are described in [RFC
2535] that can provide data origin and transaction integrity and
authentication to security aware resolvers and applications through
the use of cryptographic digital signatures.
Implementation experience has indicated the need for minor but non-
interoperable changes in Request and Transaction signature resource
records ( SIG(0)s ). These changes are documented herein.
Acknowledgments
The contributions and suggestions of the following persons (in
alphabetic order) to this memo are gratefully acknowledged:
Olafur Gudmundsson
Ed Lewis
Erik Nordmark
Brian Wellington
Eastlake Standards Track [Page 1]
RFC 2931 DNS SIG(0) September 2000
Table of Contents
1. Introduction................................................. 2
2. SIG(0) Design Rationale...................................... 3
2.1 Transaction Authentication.................................. 3
2.2 Request Authentication...................................... 3
2.3 Keying...................................................... 3
2.4 Differences Between TSIG and SIG(0)......................... 4
3. The SIG(0) Resource Record................................... 4
3.1 Calculating Request and Transaction SIGs.................... 5
3.2 Processing Responses and SIG(0) RRs......................... 6
3.3 SIG(0) Lifetime and Expiration.............................. 7
4. Security Considerations...................................... 7
5. IANA Considerations.......................................... 7
References...................................................... 7
Author's Address................................................ 8
Appendix: SIG(0) Changes from RFC 2535.......................... 9
Full Copyright Statement........................................ 10
1. Introduction
This document makes minor but non-interoperable changes to part of
[RFC 2535], familiarity with which is assumed, and includes
additional explanatory text. These changes concern SIG Resource
Records (RRs) that are used to digitally sign DNS requests and
transactions / responses. Such a resource record, because it has a
type covered field of zero, is frequently called a SIG(0). The
changes are based on implementation and attempted implementation
experience with TSIG [RFC 2845] and the [RFC 2535] specification for
SIG(0).
Sections of [RFC 2535] updated are all of 4.1.8.1 and parts of 4.2
and 4.3. No changes are made herein related to the KEY or NXT RRs or
to the processing involved with data origin and denial authentication
for DNS data.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
Eastlake Standards Track [Page 2]
RFC 2931 DNS SIG(0) September 2000
2. SIG(0) Design Rationale
SIG(0) provides protection for DNS transactions and requests that is
not provided by the regular SIG, KEY, and NXT RRs specified in [RFC
2535]. The authenticated data origin services of secure DNS either
provide protected data resource records (RRs) or authenticatably deny
their nonexistence. These services provide no protection for glue
records, DNS requests, no protection for message headers on requests
or responses, and no protection of the overall integrity of a
response.
2.1 Transaction Authentication
Transaction authentication means that a requester can be sure it is
at least getting the messages from the server it queried and that the
received messages are in response to the query it sent. This is
accomplished by optionally adding either a TSIG RR [RFC 2845] or, as
described herein, a SIG(0) resource record at the end of the response
which digitally signs the concatenation of the server's response and
the corresponding resolver query.
2.2 Request Authentication
Requests can also be authenticated by including a TSIG or, as
described herein, a special SIG(0) RR at the end of the request.
Authenticating requests serves no function in DNS servers that
predate the specification of dynamic update. Requests with a non-
empty additional information section produce error returns or may
even be ignored by a few such older DNS servers. However, this syntax
for signing requests is defined for authenticating dynamic update
requests [RFC 2136], TKEY requests [RFC 2930], or future requests
requiring authentication.
2.3 Keying
The private keys used in transaction security belong to the host
composing the DNS response message, not to the zone involved.
Request authentication may also involve the private key of the host
or other entity composing the request or of a zone to be affected by
the request or other private keys depending on the request authority
it is sought to establish. The corresponding public key(s) are
normally stored in and retrieved from the DNS for verification as KEY
RRs with a protocol byte of 3 (DNSSEC) or 255 (ANY).
Because requests and replies are highly variable, message
authentication SIGs can not be pre-calculated. Thus it will be
necessary to keep the private key on-line, for example in software or
in a directly connected piece of hardware.
Eastlake Standards Track [Page 3]
RFC 2931 DNS SIG(0) September 2000
2.4 Differences Between TSIG and SIG(0)
There are significant differences between TSIG and SIG(0).
Because TSIG involves secret keys installed at both the requester and
server the presence of such a key implies that the other party
understands TSIG and very likely has the same key installed.
Furthermore, TSIG uses keyed hash authentication codes which are
relatively inexpensive to compute. Thus it is common to authenticate
requests with TSIG and responses are authenticated with TSIG if the
corresponding request is authenticated.
SIG(0) on the other hand, uses public key authentication, where the
public keys are stored in DNS as KEY RRs and a private key is stored
at the signer. Existence of such a KEY RR does not necessarily imply
implementation of SIG(0). In addition, SIG(0) involves relatively
expensive public key cryptographic operations that should be
minimized and the verification of a SIG(0) involves obtaining and
verifying the corresponding KEY which can be an expensive and lengthy
operation. Indeed, a policy of using SIG(0) on all requests and
verifying it before responding would, for some configurations, lead
to a deadly embrace with the attempt to obtain and verify the KEY
needed to authenticate the request SIG(0) resulting in additional
requests accompanied by a SIG(0) leading to further requests
accompanied by a SIG(0), etc. Furthermore, omitting SIG(0)s when not
required on requests halves the number of public key operations
required by the transaction.
For these reasons, SIG(0)s SHOULD only be used on requests when
necessary to authenticate that the requester has some required
privilege or identity. SIG(0)s on replies are defined in such a way
as to not require a SIG(0) on the corresponding request and still
provide transaction protection. For other replies, whether they are
authenticated by the server or required to be authenticated by the
requester SHOULD be a local configuration option.
3. The SIG(0) Resource Record
The structure of and type number of SIG resource records (RRs) is
given in [RFC 2535] Section 4.1. However all of Section 4.1.8.1 and
the parts of Sections 4.2 and 4.3 related to SIG(0) should be
considered replaced by the material below. Any conflict between [RFC
2535] and this document concerning SIG(0) RRs should be resolved in
favor of this document.
For all transaction SIG(0)s, the signer field MUST be a name of the
originating host and there MUST be a KEY RR at that name with the
public key corresponding to the private key used to calculate the
Eastlake Standards Track [Page 4]
RFC 2931 DNS SIG(0) September 2000
signature. (The host domain name used may be the inverse IP address
mapping name for an IP address of the host if the relevant KEY is
stored there.)
For all SIG(0) RRs, the owner name, class, TTL, and original TTL, are
meaningless. The TTL fields SHOULD be zero and the CLASS field
SHOULD be ANY. To conserve space, the owner name SHOULD be root (a
single zero octet). When SIG(0) authentication on a response is
desired, that SIG RR MUST be considered the highest priority of any
additional information for inclusion in the response. If the SIG(0)
RR cannot be added without causing the message to be truncated, the
server MUST alter the response so that a SIG(0) can be included.
This response consists of only the question and a SIG(0) record, and
has the TC bit set and RCODE 0 (NOERROR). The client should at this
point retry the request using TCP.
3.1 Calculating Request and Transaction SIGs
A DNS request may be optionally signed by including one SIG(0)s at
the end of the query additional information section. Such a SIG is
identified by having a "type covered" field of zero. It signs the
preceding DNS request message including DNS header but not including
the UDP/IP header and before the request RR counts have been adjusted
for the inclusions of the request SIG(0).
It is calculated by using a "data" (see [RFC 2535], Section 4.1.8) of
(1) the SIG's RDATA section entirely omitting (not just zeroing) the
signature subfield itself, (2) the DNS query messages, including DNS
header, but not the UDP/IP header and before the reply RR counts have
been adjusted for the inclusion of the SIG(0). That is
data = RDATA | request - SIG(0)
where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
calculated less the signature itself.
Similarly, a SIG(0) can be used to secure a response and the request
that produced it. Such transaction signatures are calculated by
using a "data" of (1) the SIG's RDATA section omitting the signature
itself, (2) the entire DNS query message that produced this response,
including the query's DNS header but not its UDP/IP header, and (3)
the entire DNS response message, including DNS header but not the
UDP/IP header and before the response RR counts have been adjusted
for the inclusion of the SIG(0).
Eastlake Standards Track [Page 5]
RFC 2931 DNS SIG(0) September 2000
That is
data = RDATA | full query | response - SIG(0)
where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
calculated less the signature itself.
Verification of a response SIG(0) (which is signed by the server host
key, not the zone key) by the requesting resolver shows that the
query and response were not tampered with in transit, that the
response corresponds to the intended query, and that the response
comes from the queried server.
In the case of a DNS message via TCP, a SIG(0) on the first data
packet is calculated with "data" as above and for each subsequent
packet, it is calculated as follows:
data = RDATA | DNS payload - SIG(0) | previous packet
where "|" is concatenations, RDATA is as above, and previous packet
is the previous DNS payload including DNS header and the SIG(0) but
not the TCP/IP header. Support of SIG(0) for TCP is OPTIONAL. As an
alternative, TSIG may be used after, if necessary, setting up a key
with TKEY [RFC 2930].
Except where needed to authenticate an update, TKEY, or similar
privileged request, servers are not required to check a request
SIG(0).
Note: requests and responses can either have a single TSIG or one
SIG(0) but not both a TSIG and a SIG(0).
3.2 Processing Responses and SIG(0) RRs
If a SIG RR is at the end of the additional information section of a
response and has a type covered of zero, it is a transaction
signature covering the response and the query that produced the
response. For TKEY responses, it MUST be checked and the message
rejected if the checks fail unless otherwise specified for the TKEY
mode in use. For all other responses, it MAY be checked and the
message rejected if the checks fail.
If a response's SIG(0) check succeed, such a transaction
authentication SIG does NOT directly authenticate the validity any
data-RRs in the message. However, it authenticates that they were
sent by the queried server and have not been diddled. (Only a proper
SIG(0) RR signed by the zone or a key tracing its authority to the
zone or to static resolver configuration can directly authenticate
Eastlake Standards Track [Page 6]
RFC 2931 DNS SIG(0) September 2000
data-RRs, depending on resolver policy.) If a resolver or server does
not implement transaction and/or request SIGs, it MUST ignore them
without error where they are optional and treat them as failing where
they are required.
3.3 SIG(0) Lifetime and Expiration
The inception and expiration times in SIG(0)s are for the purpose of
resisting replay attacks. They should be set to form a time bracket
such that messages outside that bracket can be ignored. In IP
networks, this time bracket should not normally extend further than 5
minutes into the past and 5 minutes into the future.
4. Security Considerations
No additional considerations beyond those in [RFC 2535].
The inclusion of the SIG(0) inception and expiration time under the
signature improves resistance to replay attacks.
5. IANA Considerations
No new parameters are created or parameter values assigned by this
document.
References
[RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
September 1996.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
[RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
Wellington, "Secret Key Transaction Signatures for DNS
(TSIG)", RFC 2845, May 2000.
[RFC 2930] Eastlake, D., "Secret Key Establishment for DNS (RR)", RFC
2930, September 2000.
Eastlake Standards Track [Page 7]
RFC 2931 DNS SIG(0) September 2000
Author's Address
Donald E. Eastlake 3rd
Motorola
140 Forest Avenue
Hudson, MA 01749 USA
Phone: +1-978-562-2827(h)
+1-508-261-5434(w)
Fax: +1 978-567-7941(h)
+1-508-261-4447(w)
EMail: Donald.Eastlake@motorola.com
Eastlake Standards Track [Page 8]
RFC 2931 DNS SIG(0) September 2000
Appendix: SIG(0) Changes from RFC 2535
Add explanatory text concerning the differences between TSIG and
SIG(0).
Change the data over which SIG(0) is calculated to include the SIG(0)
RDATA other than the signature itself so as to secure the signature
inception and expiration times and resist replay attacks. Specify
SIG(0) for TCP.
Add discussion of appropriate inception and expiration times for
SIG(0).
Add wording to indicate that either a TSIG or one or more SIG(0)s may
be present but not both.
Reword some areas for clarity.
Eastlake Standards Track [Page 9]
RFC 2931 DNS SIG(0) September 2000
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Eastlake Standards Track [Page 10]