diff --git a/doc/draft/draft-ietf-dnsext-dnssec-records-02.txt b/doc/draft/draft-ietf-dnsext-dnssec-records-02.txt deleted file mode 100644 index 83c3b9feb3..0000000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-records-02.txt +++ /dev/null @@ -1,1794 +0,0 @@ - - -Network Working Group R. Arends -Internet-Draft -Expires: April 29, 2003 M. Larson - VeriSign - D. Massey - USC/ISI - S. Rose - NIST - October 29, 2002 - - - Resource Records for the DNS Security Extensions - draft-ietf-dnsext-dnssec-records-02 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on April 29, 2003. - -Copyright Notice - - Copyright (C) The Internet Society (2002). All Rights Reserved. - -Abstract - - This document is part of a family of documents that describe the DNS - Security Extensions (DNSSEC). The DNS Security Extensions are a - collection of resource records and protocol modifications that - provide source authentication for the DNS. This document defines the - KEY, DS, SIG, and NXT resource records. The purpose and format of - each resource record is descibed in detail and an example of each - - - -Arends, et al. Expires April 29, 2003 [Page 1] - -Internet-Draft DNSSEC Resource Records October 2002 - - - resource record is given. - - This document obsoletes RFC 2535 and incorporates changes from all - updates to RFC 2535. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Background and Related Documents . . . . . . . . . . . . . 4 - 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3 Editors Notes . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . 4 - 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . 4 - 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . 5 - 2. The KEY Resource Record . . . . . . . . . . . . . . . . . 6 - 2.1 KEY RDATA Wire Format . . . . . . . . . . . . . . . . . . 6 - 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . 6 - 2.1.2 The Protocol Octet Field . . . . . . . . . . . . . . . . . 7 - 2.1.3 The Algorithm and Public Key Fields . . . . . . . . . . . 7 - 2.1.4 Notes on KEY RDATA Design . . . . . . . . . . . . . . . . 7 - 2.2 The KEY RR Presentation Format . . . . . . . . . . . . . . 7 - 2.3 KEY RR Example . . . . . . . . . . . . . . . . . . . . . . 7 - 3. The SIG Resource Record . . . . . . . . . . . . . . . . . 9 - 3.1 The SIG RDATA . . . . . . . . . . . . . . . . . . . . . . 9 - 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . . . 10 - 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . . . 10 - 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . . . 10 - 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . . . 10 - 3.1.5 Signature Expiration and Inception Fields . . . . . . . . 11 - 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . 11 - 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . 11 - 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . 11 - 3.2 Calculating A Signature . . . . . . . . . . . . . . . . . 12 - 3.2.1 Calculating An RRset Signature . . . . . . . . . . . . . . 12 - 3.2.2 Calculating An Transaction Signature . . . . . . . . . . . 12 - 3.3 The SIG RR Presentation Format . . . . . . . . . . . . . . 13 - 3.4 Example of a SIG RR . . . . . . . . . . . . . . . . . . . 13 - 4. The NXT Resource Record . . . . . . . . . . . . . . . . . 15 - 4.1 NXT RDATA Wire Format . . . . . . . . . . . . . . . . . . 15 - 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . 15 - 4.1.2 The Type Bit Map Field . . . . . . . . . . . . . . . . . . 16 - 4.1.2.1 Alternate Formats for the Type Bit Map Field . . . . . . . 16 - 4.1.3 Inclusion of Wildcard Names in NXT RDATA . . . . . . . . . 16 - 4.2 The NXT RR Presentation Format . . . . . . . . . . . . . . 16 - 4.3 NXT RR Example . . . . . . . . . . . . . . . . . . . . . . 17 - 5. The DS Resource Record . . . . . . . . . . . . . . . . . . 18 - 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 18 - 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . 18 - - - -Arends, et al. Expires April 29, 2003 [Page 2] - -Internet-Draft DNSSEC Resource Records October 2002 - - - 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . 19 - 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . 19 - 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . 19 - 5.2 The DS RR Presentation Format . . . . . . . . . . . . . . 19 - 5.3 DS Record Example . . . . . . . . . . . . . . . . . . . . 20 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 21 - 7. Security Considerations . . . . . . . . . . . . . . . . . 22 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 23 - References . . . . . . . . . . . . . . . . . . . . . . . . 24 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . 25 - A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . 26 - A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . 26 - A.1.1 Indiret and Private Algorithm Types . . . . . . . . . . . 26 - A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . 27 - B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 28 - B.1 Key Tag for Algorithm 1 - RSA/MD5 . . . . . . . . . . . . 29 - C. Canonical Form and Order of Resource Records . . . . . . 30 - C.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . 30 - C.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . 30 - C.3 Canonical RR Ordering Within An RRset . . . . . . . . . . 31 - C.4 Canonical Ordering of RR Types . . . . . . . . . . . . . . 31 - Full Copyright Statement . . . . . . . . . . . . . . . . . 32 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 29, 2003 [Page 3] - -Internet-Draft DNSSEC Resource Records October 2002 - - -1. Introduction - - The DNS Security Extensions (DNSSEC) introduce four resource records: - the KEY, SIG, NXT, and DS resource records. This document defines - the purpose of each resource record (RR), the RR's RDATA format, and - its ASCII representation. An example of each RR type is also given. - -1.1 Background and Related Documents - - This document is part of a family of documents that define the DNS - security extensions. The DNS security extensions (DNSSEC) are a - collection of resource records and DNS protocol modifications that - add source authentication the Domain Name System (DNS). An - introduction to DNSSEC and definition of common terms can be found in - [13]. A description of DNS protocol modifications can be found in - [14]. This document defines the DNSSEC resource records. - - The reader to assumed to be familiar with the basic DNS concepts - described in RFC1034 [1] and RFC1035 [2] and should also be familiar - with common DNSSEC terminology as defined in [13]. - -1.2 Reserved Words - - 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 [4]. - -1.3 Editors Notes - -1.3.1 Open Technical Issues - - The NXT section (Section 4) requires input from the working group. - Since the opt-in issue is not resolved, this text describes the NXT - record as it was defined in RFC 2535. This section may need to be - updated, depending on the outcome of the opt-in discussion. - - The cryptographic algorithm types (Appendix A) requires input from - the working group. The DSA algorithm was moved to OPTIONAL. This - had strong consensus in workshops and various discussions and a - seperate internet draft solely to move DSA from MANDATORY to OPTIONAL - seemed excessive. This draft solicts input on that proposed change. - - The indirect and private algorithms types (Appendix A) are also worth - noting. See the text in that section. - -1.3.2 Technical Changes or Corrections - - Please report technical corrections to dnssec-editors@east.isi.edu. - - - -Arends, et al. Expires April 29, 2003 [Page 4] - -Internet-Draft DNSSEC Resource Records October 2002 - - - To assist the editors, please indicate the text in error and point - out the RFC that defines the correct behavior. For a technical - change where there is no RFC that defines the correct behavior (or - RFCs provide conflicting answers), please post the issue to - namedroppers. - - An example correction to dnssec-editors might be: Page X says - "DNSSEC RRs SHOULD be automatically returned in responses." This was - true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the - DNSSEC RR types MUST NOT be included in responses unless the resolver - indicated support for DNSSEC. - -1.3.3 Typos and Minor Corrections - - Please report any typos corrections to dnssec-editors@east.isi.edu. - To assist the editors, please provide enough context for us to - quickly find the incorrect text. - - An example message to dnssec-editors might be: page X says "the - DNSSEC standard has been in development for over 1 years". It - should read "over 10 years". - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 29, 2003 [Page 5] - -Internet-Draft DNSSEC Resource Records October 2002 - - -2. The KEY Resource Record - - DNSSEC uses public key cryptogrpahy to sign and authenticate DNS - resource record sets (RRsets). The public keys are stored in KEY - resource records and are used in the DNSSEC authentication process - described in [14]. In a typical example, a zone signs its - authorititave RRsets using a private key and stores the corresponding - public key in a KEY RR. A resolver can then use these signatures to - authenticate RRsets from the zone. - - The KEY RR is also used to store public keys associated with other - DNS operations, such as SIG(0) [14] and TKEY [9]. In all cases, the - KEY RR plays a special role in secure DNS resolution and DNS message - processing. The KEY RR is not intended as a record for storing - arbitrary public keys. The KEY RR MUST NOT be used to store - certificates or public keys that do not directly relate to the DNS - infrastructure. Examples of certificates and public keys that MUST - NOT be stored in the KEY RR include X.509 certificates, IPSEC public - keys, and SSH public keys. - - The type number for the KEY RR is 25. - - The KEY RR is class independent. - - There are no special TTL requirements on the KEY record. DNSSEC best - practices documents are encouraged to provide TTL recommendations. - -2.1 KEY RDATA Wire Format - - The RDATA for a KEY RR consists of a 2 octet Flags Fields, a Protocol - Octet, a one octet Algorithm Number, and the Public Key. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Flags | Protocol | Algorithm | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | / - / Public Key / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - - -2.1.1 The Flags Field - - Bit 7 of the Flags field is the Zone Key flag. If bit 7 is 1, then - the KEY record holds a DNS zone key and the KEY's owner name MUST be - the name of a zone. If bit 7 is 0, then the KEY record holds some - - - -Arends, et al. Expires April 29, 2003 [Page 6] - -Internet-Draft DNSSEC Resource Records October 2002 - - - other type of DNS public key, such as a public key used by SIG(0) or - TKEY. - - Bits 0-6 and 8-15 are reserved for future use and MUST be zero. - -2.1.2 The Protocol Octet Field - - The Protocol Octet field MUST be 3. - -2.1.3 The Algorithm and Public Key Fields - - The Algorithm field identifies the public key's cryptographic - algorithm and determines the format of the Public Key field. A list - of DNSSEC algorithm types can be found in Appendix A.1 - -2.1.4 Notes on KEY RDATA Design - - Although the Protocol Octet field is always 3, it is retained for - backwards compatibility with an earlier version of the KEY record. - The use of bit 7 as the Zone Key Flag is also due to backwards - compatiblity issues. - -2.2 The KEY RR Presentation Format - - A KEY RR may appear as a single line or multiple lines separated with - newline characters if those lines are contained with parantheses. - The presentation format of the RDATA portion is as follows: - - The Flag field is represented as an unsigned integer. - - The Protocol Octet field is represented as the unsigned integer 3. - - The Algorithm field is represented as an unsigned integer or as an - algorithm mnemonic specified in Appendix A.1. - - The Public Key field is a Base 64 encoding of the Public Key Field. - -2.3 KEY RR Example - - The following KEY RR stores a DNS zone key for isi.edu. - - isi.edu. 86400 IN KEY 256 3 5 ( AQPT0sh3WjVeRY3WqpBjtf - - xxDw==) - - The first four fields specify the owner name, TTL, Class, and RR type - (KEY). 256 indicates the Flags field has the zone key bit is set. 3 - is the fixed Protocol Octet value. 5 indicates the public key - - - -Arends, et al. Expires April 29, 2003 [Page 7] - -Internet-Draft DNSSEC Resource Records October 2002 - - - algorithm. Appendix A.1 identifies algorithm type 5 as RSA/SHA1 and - indicates that the format of the RSA/SHA1 public key field is defined - in [12]. The remaining text is a base 64 encoding of the public key. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 29, 2003 [Page 8] - -Internet-Draft DNSSEC Resource Records October 2002 - - -3. The SIG Resource Record - - DNSSEC uses public key cryptogrpahy to sign and authenticate DNS - resource record sets (RRsets). The signatures are stored in SIG - resource records and are used in the DNSSEC authentication process - described in [14]. In a typical example, a zone signs its - authorititave RRsets using a private key and stores the corresponding - signatures in SIG RRs. A resolver can then use these signatures to - authenticate RRsets from the zone. - - A SIG record contains the signature for an RRset with a particular - name, class, and type. The SIG RR is said to "cover" this RRset. - The SIG RR also specifies a validity interval for the signature and - uses an algorithm signer's name, and key tag to identify the public - key (KEY record) that can be used to verify the signature. - - The signature in SIG RR may also cover a transaction rather than an - RRset [14]. In this case, the "Type Covered" field is set to 0 and - the SIG RR is refered to as SIG(0) resource record. - - The type number for the SIG RR type is 24. - - The SIG RR is class independent, but MUST have the same class as the - RRset it covers. - - The SIG RR TTL SHOULD match the TTL of the RRset it covers. - -3.1 The SIG RDATA - - The RDATA portion of a SIG RR is shown below: - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | type covered | algorithm | labels | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | original TTL | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | signature expiration | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | signature inception | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | key tag | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name + - | / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ - / / - / signature / - - - -Arends, et al. Expires April 29, 2003 [Page 9] - -Internet-Draft DNSSEC Resource Records October 2002 - - - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -3.1.1 The Type Covered Field - - The Type Covered field identifies the RRset type covered by the SIG - record. - - If Type Covered field is set to 0, the record is referred to as a - SIG(0) RR and its signature covers a transaction rather than a - specific RRset. [14] descirbes how to sign transactions using SIG(0) - resource records. - -3.1.2 The Algorithm Number Field - - The Algorithm Number field identies the cryptographic algorithm used - to create the signature. A list of DNSSEC algorithm types can be - found in Appendix A.1 - -3.1.3 The Labels Field - - The Labels field specifies the number of labels in the original SIG - RR owner name. It is included to handle signatures associated with - wildcard owner names. - - To validate the signature, a resolver requires the original owner - name that was used when the signature was created. In most cases, - the owner name used when the signature was created is identical to - the owner name sent in any response. However, a wildcard owner name - will be expanded during the query/response process and [14] describes - how the label count is used to reconstruct the original (unexpanded) - owner name. - - The Labels field does not count null labels for root and does not - count any initial "*" in a wildcard name. The Labels field MUST be - less than or equal to the number of labels in the SIG owner name. - For example, "www.example.com." has a label count of 3 and - "*.example.com." has a label count of 2. - -3.1.4 Original TTL Field - - The Original TTL field specifies the original TTL of the covered - RRset. - - To validate the signature, a resolver requires the original TTL used - when the signature was created. However, caching servers will - decrement the TTL and [14] describes how the Original TTL field count - - - -Arends, et al. Expires April 29, 2003 [Page 10] - -Internet-Draft DNSSEC Resource Records October 2002 - - - is used to reconstruct the original (undecremented) TTL. - - If the Type Covered field is non-zero, the Original TTL value MUST be - greater than or equal to the TTL of the SIG record itself. If the - Type Covered field is 0 (i.e. a SIG(0) RR), the Original TTL field - SHOULD be zero. - -3.1.5 Signature Expiration and Inception Fields - - The Signature Inception and Signature Expiration fields specify a - validity period for the signature. The SIG record MUST NOT be used - for authentication prior to the inception date and MUST NOT be used - for authentication after the expiratiation date. - - Inception and expiration dates are given as 32-bit unsigned numbers - of seconds since the start of 1 January 1970 GMT, ignoring leap - seconds. Ring arithmetic [3] to handle 32-bit wrap around. As - result, these times can never be more than 68 years in the past or - the future and the times are ambiguous modulo ~136 years. A SIG RR - can have an expiration time numerically smaller than the inception - time if the expiration time is near the 32-bit wrap around point and/ - or the signature is long lived. - -3.1.6 The Key Tag Field - - The Key Tag field contains the key tag of the public key (KEY RR) - used to authenticate this signature. The process of calculating a - key tag is given in Appendix B. - -3.1.7 The Signer's Name Field - - The Signer's Name field identifies the name of the KEY RR used to - authenticate this signature. If the Type Covered field is non-zero, - the Signer's Name MUST contain the name of the zone containing the - covered RRset and the SIG. The signer's name MAY be compressed with - standard DNS name compression when being transmitted over the - network. - - If the Type Covered field is 0 (i.e. a SIG(0) RR), the signer's name - MUST be the name of the host originating the DNS message as described - in [10]. - -3.1.8 The Signature Field - - The Signature field contains the cryptographic signature. If the - Type Covered field is non-zero, the signature covers the SIG RDATA - (excluding the Signature field) and the RRset specified by the SIG - owner name, SIG class, and SIG Type Covered field. - - - -Arends, et al. Expires April 29, 2003 [Page 11] - -Internet-Draft DNSSEC Resource Records October 2002 - - -3.2 Calculating A Signature - - A signature covers either an RRset or a transaction. RRset - signatures and transaction signatures are distinguished by the Type - Covered field. RRset signatures have a non-zero Type Covered field. - SIG RRs SHOULD NOT be generated for any "meta-type" such as ANY or - AXFR. - -3.2.1 Calculating An RRset Signature - - A signature covers the SIG RDATA (excluding the Signature Field - itself) and covers the RRset specified by the SIG owner name, SIG - class, and SIG Type Covered field. The RRset is in cannonical form - (see Appendix C) and the set RR(1),...RR(n) is signed as follows: - - signature = sign(SIG_RDATA | RR(1) | RR(2)... ) where - - "|" denotes append - - SIG_RDATA is the wire format of the SIG RDATA fields with - the Signer's Name field in cannonical form. - the Signature field excluded. - - RR(i) = fqdn | class | type | TTL | RDATA length | RDATA - - fqdn is the Fully Qualified Domain Name in canonical - form. - - All RR(i) MUST have the same fqdn as the SIG RR. - - All RR(i) MUST have the same class as the SIG RR. - - All RR(i) MUST have the RR type listed in SIG RR's - Type Covered field. - - All RR(i) MUST have the TTL listed in the SIG Original - TTL Field - - All names in the RDATA field are in canonical form - - The set of all RR(i) is sorted into cannonical order. - - -3.2.2 Calculating An Transaction Signature - - - - - - - -Arends, et al. Expires April 29, 2003 [Page 12] - -Internet-Draft DNSSEC Resource Records October 2002 - - -3.3 The SIG RR Presentation Format - - A SIG RR may appear as a single logical line. The presentation - format of the RDATA portion is as follows: - - The Type Covered field is represented by either an unsigned integer - or the mnemonic for the RR type. - - The Algorithm field is represented as an unsigned integer or as an - algorithm mnemonic specified in Appendix A.1. - - The Labels field is represented as an unsigned integer. - - The Original TTL field is represented as an unsigned integer. It MAY - be omitted if it is equal the TTL of the SIG RR. - - The Signature Inception Time and Expiration Time fields are - represented in the form YYYYMMDDHHmmSS, where: - - YYYY is the year - - MM is the month number (01-12) - - DD is the day of the month (01-31) - - HH is the hour in 24 hours notation (00-23) - - mm is the minute (00-59) - - SS is the second (00-59) - - The Key Tag field is represented as an unsigned integer. - - The Signer's Name field is represented as a domain name. - - The Signature field is a Base 64 encoding of the signature. - -3.4 Example of a SIG RR - - The following a SIG RR stores the signature for the the A RRset of - host.example.com: - - host.example.com. 30 IN SIG A 3 3 30 20011231120000 ( - 20011108100000 65531 example.com - CGr0uS55C4l/2RRc2NrMJbRt4oP+xVxwgMkC - rJFXXDsybfEDdwoajAY= ) - - The first four fields specify the owner name, TTL, Class, and RR type - - - -Arends, et al. Expires April 29, 2003 [Page 13] - -Internet-Draft DNSSEC Resource Records October 2002 - - - (SIG). The "A" represents the Type Covered field. is the algorithm - used to create this signature. The first 3 identifies the Algorithm - used to create the signature. The second 3 is the number of Labels - in the original owner name and the 30 is the Original TTL for this - SIG RR and the covered A RRset. The two dates are the expiration and - inception dates. 65531 is the Key Tag and example.com. is the - Signer's Name. The remaining text is a base 64 encoding of the - signature. - - Note that combination of SIG RR owner name, class, and and Type - Covered indicate this SIG covers the "host.example.com" A RRset. The - Label value of 3 indicates no wildcard expansion was used. The - Algorithm, Signer's Name, and Key Tag indicate this signature can be - authenticated using an example.com zone KEY RR whose algorithm is 3 - and key tag is 65531. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 29, 2003 [Page 14] - -Internet-Draft DNSSEC Resource Records October 2002 - - -4. The NXT Resource Record - - The NXT resource record lists the RR types present at the NXT's owner - name and lists the next canonical name in the zone. The collection - of NXT or "next" resource records indicate what RRsets exist in a - zone and provide a chain of all authoritative owner names in that - zone. This information can be used for authenticated denial of - existence, as desribed in [14]. - - Note that although a zone may contain non-authoritiative glue address - records, these non-authoritative glue records MUST NOT be used when - contructing the NXT resource record chain. - - The type number for the NXT RR is 30. - - The NXT RR is class independent. - - The NXT RR TTL SHOULD NOT exceed the minimum TTL in the zone's SOA - RR. - -4.1 NXT RDATA Wire Format - - The RDATA of the NXT RR is as shown below: - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / next domain name / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / type bit map / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -4.1.1 The Next Domain Name Field - - The Next Domain Name field contains the next authoritive owner name - in canonical order, where canonical order is defined in Appendix C.1. - For the last owner name in the zone, the Next Domain Name field - contains the zone apex name. - - The Next Domain Name field allows message compression. - - Note that non-authoritative glue address record names may exist in a - zone, but these non-authoritative glue records MUST NOT be listed in - the Next Domain Name. Any non-authoritative glue records are ignored - (treated as though they were never present) when constructing an NXT. - - - - - -Arends, et al. Expires April 29, 2003 [Page 15] - -Internet-Draft DNSSEC Resource Records October 2002 - - -4.1.2 The Type Bit Map Field - - The Type Bit Map field identifies the RRset types that exist at the - NXT's owner name. - - Each bit in the Type Bit Map field corresponds to an RR type. Bit - one corresponds to RR type 1 (A), bit 2 corresponds to RR type 2 - (NS), and so forth. If a bit is set to 1, it indicates that an RRset - of that type exists for the NXT's owner name. If a bit is set to - zero, it indicates that no RRset of that type exists for the NXT's - owner name. - - Trailing zero octets MUST be omitted. Thus the length of the Type - Bit Map field varies and is dependent on the largest RR type present - for the NXT's owner name. Trailing zero octets not specified MUST be - interpreted as zero octets. - - Non-authoritative glue address record types MUST NOT be used when - constructing the type bit map field. The OPT RR [8] type (41) also - MUST NOT be used when constructing the type bit map field since it is - not part of the zone data. In other words, the OPT RR type bit (bit - 41) MUST be zero. - -4.1.2.1 Alternate Formats for the Type Bit Map Field - - The above Type Bit Map format MUST NOT be used when an RR type number - greater than 127 is in use. - - Bit 0 in the Type Bit Map Field is used to indicate an alternate - format for the Type Bit Map field. If bit 0 is set to 1, it - indicates some other format is being used for this field. No - alternate formats are defined as of this writing. - -4.1.3 Inclusion of Wildcard Names in NXT RDATA - - If a wildcard owner name appears in a zone, the wildcard is treated - as a literal symbol and is treated the same as any other owner name. - Wildcard owner names appear (unexpanded) in the Next Domain Name - field without any wildcard expansion. [14] describes the impact of - wildcards on authetnicated denial of existence. - -4.2 The NXT RR Presentation Format - - A NXT RR may appear as a single line. The presentation format of the - RDATA portion is as follows: - - The Next Domain Name field is represented as a domain name. - - - - -Arends, et al. Expires April 29, 2003 [Page 16] - -Internet-Draft DNSSEC Resource Records October 2002 - - - The Type Bit Map field is represented as a sequence of RR type - mnemonics or as a sequence of unsigned integers denoting the RR - types. - -4.3 NXT RR Example - - The following NXT RR identifies the RRsets associated with - a.example.com and identifies the next authoritative name after - a.example.com. - - a.example.com. 86400 IN NXT c.example.com. A MX NXT - - The first four fields specify the name, TTL, Class, and RR type - (NXT). The entry c.example.com is the next authoritative name after - a.example.com (in cannonical order). The A MX and NXT nnemonics - indicate there are A, MX, and NXT RRsets associated with the name - a.example.com. - - Note the NXT record can be used for authenticted denial of existence. - If the example NXT record were authenticed, it could be used to prove - that b.example.com does not exist or could be used to prove there is - no AAAA record assoicated with a.example.com. Authenticated denial - of existence is discussed in [14] - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 29, 2003 [Page 17] - -Internet-Draft DNSSEC Resource Records October 2002 - - -5. The DS Resource Record - - The DS Resource Record points to a KEY RR and is used in the DNS KEY - authentication process. A DS RR points to a KEY RR by storing the - key tag, algorithm number, and a digest of KEY RR. Note that while - the digest should be sufficient to identify key, storing the key tag - and key algorithm helps make the identification process more - efficient and more secure. By authenticating the DS record, a - resolver can authenticate the KEY RR pointed to by the DS record. - The key authentication proces is described in [14]. - - The DS RR and its corresponding KEY RR both have the same owner name, - but they are stored in different locations. The DS RR is the first - resource record that appears only on the upper side of a delegation. - In other words, the DS RR for "example.com" is stored in "com" (the - upper side of the delegation). The corresponding KEY RR is stored in - the "example.com" zone (the lower side of the delegation). This - simplifies DNS zone management and zone signing, but introduces - special response processing requirements that are described in [14]. - - The type number for the DS record is 43. - - The DS resource record is class independent. - - There are no special TTL requirements on the DS resource record. - DNSSEC best practices documents are encouraged to provide TTL - recommendations. - -5.1 DS RDATA Wire Format - - The RDATA for a DS RR consists of 2 octet Key Tag, a one octet - Algorithm Number, a one octet Digest Type, and a Digest. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | key tag | algorithm | Digest type | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Digest / - / / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -5.1.1 The Key Tag Field - - The Key Tag field lists the key tag of the KEY RR pointed to by the - DS record. The KEY RR MUST be a a zone key. In other words, the KEY - - - -Arends, et al. Expires April 29, 2003 [Page 18] - -Internet-Draft DNSSEC Resource Records October 2002 - - - RR Flags must have Flags bit 7 set to 1. - - The key tag used by the DS RR is identical to the key tag used by the - SIG RR and Appendix B describes how to compute a key tag. - -5.1.2 The Algorithm Field - - The Algorithm field lists the algorithm number of the KEY RR pointed - to by the DS record. - - The algorithm number used by the DS RR is identical to the algorithm - number used by the SIG RR and KEY RR. Appendix A.1 lists the - algorithm number types. - -5.1.3 The Digest Type Field - - The DS RR points to a KEY RR by including a digest of that KEY RR. - The Digest Type field identifes the algorithm used to construct the - digest and Appendix A.2 lists the possible digest algorithm types. - -5.1.4 The Digest Field - - The DS record points to a KEY RR by including a digest of that KEY - RR. The Digest field hold the digest. - - For a given KEY RR, the digest is calculated by appending the KEY - RR's cannonical fully qualified owner name with the KEY RDATA and - then applying the digest algorithm. - - digest = digest_algorithm( cannonical FQDN of KEY RR | KEY_RR_rdata) - - "|" denotes append - - KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key - - - The size of the digest can vary depending on the digest algorithm and - KEY RR size. However, the only currently defined digest algorithm is - SHA-1 and it always produces a 24 byte digest regardless of KEY RR - size. - -5.2 The DS RR Presentation Format - - A DS RR may appear as a single line or multiple lines separated with - newline characters if those lines are contained within parantheses. - The presentation format of the RDATA portion is as follows: - - The Key Tag field is represented as an unsigned integer. - - - -Arends, et al. Expires April 29, 2003 [Page 19] - -Internet-Draft DNSSEC Resource Records October 2002 - - - The Algorithm field is represented as an unsigned integer or as an - algorithm mnemonic specified in Appendix A.1. - - The Digest Type field is represented as an unsigned integer. - - The Digest is presented in hexadecimal. - -5.3 DS Record Example - - The following example shows a KEY RR and its corresponding DS RR. - - dskey.example. 86400 IN KEY 256 3 1 ( AQPwHb4UL1U9RHaU8qP+Ts5bVOU - 1s7fYbj2b3CCbzNdj4+/ECd18yKiy - UQqKqQFWW5T3iVc8SJOKnueJHt/Jb - /wt) ; key tag = 28668 - dskey.example. 3600 IN DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE - - The first four fields specify the name, TTL, Class, and RR type (DS). - 28668 is the key tag for the corresponding "dskey.example." KEY RR - and 1 algorithm used by this "dskey.example." KEY RR. The second 1 - is the algorithm used to construct the digest and the final string is - the digest in hex. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 29, 2003 [Page 20] - -Internet-Draft DNSSEC Resource Records October 2002 - - -6. IANA Considerations - - This document introduces no new IANA considerations. - - This document only clarifies the use of existing DNS resource - records. However for completeness, the IANA considerations from - these previous documents are summarized below. No IANA changes are - made by this document. - - RFC 2535 updated the IANA registry for DNS Resource Record Types and - assigned types 24,25, and 30 to the SIG, KEY, and NXT (respectively). - [DS RFC] assigned DNS Resource Record Type 43 to DS. - - RFC 2535 created an IANA registry for DNSSEC Resource Record - Algorithm Numbers. Values to 1-4, and 252-255 were assigned by RFC - 2535. Value 5 was assigned by RFC 3110. - - [DS RFC] created an IANA registry for DNSSEC DS Digest Types and - assigned value 0 to reserved and value 1 to RSA/SHA-1. - - RFC 2535 created an IANA Registry to KEY Protocol Octet Values, but - [KeyRestrict RFC] set all assigned values other than 3 to reserved - and closed this IANA registry. The registry remains closed and all - KEY records are required to have Protocol Octet value of 3. - - The Flag bits in the KEY RR are not assigned by IANA and there is no - IANA registry for these flags. All changes to the meaning of the KEY - RR Flag bits require a standards action. - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 29, 2003 [Page 21] - -Internet-Draft DNSSEC Resource Records October 2002 - - -7. Security Considerations - - This document describes the format of four DNS resource records used - by the DNS security extensions and presents an algorithm for - calculating a key tag for a public key. Other than the items - desribed below, the resource records themselves introduce no security - considerations. The use of these records is specified in a seperate - document and security considerations related to the use these - resource records are discussed in that document. - - The DS record points to a KEY RR using a cryptographic digest, the - key algorithm type and a key tag. The DS record is intended to - identify an existing KEY RR, but it is theoretically possibile for an - attacker to generate a KEY that matches all the DS fields. The - probability of constructing such a matching KEY depends on the type - of digest algorithm in use and the only currently defined digest - algorithm is SHA1. It is considered very difficult to constuct a - public key that matches the algorithm, key tag, and SHA1 digest given - in a DS record. - - The key tag is used to help efficiently select KEY resource records, - but it does not uniquely identify a KEY resource record. It is - possible that two distinct KEY RRs could have the same owner name, - same algorithm type and same key tag. An implementation that used - only the key tag to select a KEY RR may select the wrong public key - for a given scenario. Implementations MUST NOT assume the key tag is - unique public key identifier and this is clearly stated in the text. - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 29, 2003 [Page 22] - -Internet-Draft DNSSEC Resource Records October 2002 - - -8. Acknowledgements - - This document was created from the input and ideas of several members - of the DNS Extensions Working Group and working group mailing list. - The co-authors of this draft would like to express their thanks for - the comments and suggestions received during the revision of these - security extension specifications. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 29, 2003 [Page 23] - -Internet-Draft DNSSEC Resource Records October 2002 - - -References - - [1] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. - - [2] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [3] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, - August 1996. - - [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [5] Elz, R. and R. Bush, "Clarifications to the DNS Specification", - RFC 2181, July 1997. - - [6] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [7] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System - (DNS)", RFC 2536, March 1999. - - [8] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, - August 1999. - - [9] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC - 2930, September 2000. - - [10] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - [12] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name - System (DNS)", RFC 3110, May 2001. - - [13] Arends, R., Larson, M., Massey, D. and S. Rose, "DNSSEC Intro", - October 2002. - - [14] Arends, R., Larson, M., Massey, D. and S. Rose, "DNSSEC - Protocol", October 2002. - - [15] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource - Record", draft-ietf-dnsext-restrict-key-for-dnssec-02 (work in - progress), March 2002. - - - - -Arends, et al. Expires April 29, 2003 [Page 24] - -Internet-Draft DNSSEC Resource Records October 2002 - - -Authors' Addresses - - Roy Arends - Bankastraat 41-E - 1094 EB Amsterdam - NL - - EMail: roy@logmess.com - - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - Dan Massey - USC Information Sciences Institute - 3811 N. Fairfax Drive - Arlington, VA 22203 - USA - - EMail: masseyd@isi.edu - - - Scott Rose - National Institute for Standards and Technology - 100 Bureau Drive - Gaithersburg, MD 20899-8920 - USA - - EMail: scott.rose@nist.gov - - - - - - - - - - - - - - - - -Arends, et al. Expires April 29, 2003 [Page 25] - -Internet-Draft DNSSEC Resource Records October 2002 - - -Appendix A. DNSSEC Algorithm and Digest Types - - The DNS security exstentions are designed to be independent of the - underlying cryptographic algorithms. The KEY, SIG, and DS resource - records all use a DNSSEC Algorithm Number to identify the - crytographic algorithm in use by the resource record. The DS - resource record also specifies a Digest Algorithm Number to identify - the digest algorithm used to construct the DS record. The currently - defined Algorithm and Digest Types are listed below. Additional - Algorithm or Digest Types could be added as advances in cryptography - warrant. - - A DNSSEC aware resolver or name server MUST implement all MANDATORY - algorithms. - -A.1 DNSSEC Algorithm Types - - An "Algorithm Number" field in the KEY, SIG, and DS resource record - types identifies the cryptographic algorithm used by the resource - record. Algorithm specific formats are described in separate - documents. The following table lists the currently defined algorithm - types and provides references to their supporting documents: - - VALUE Algorithm RFC STATUS - 0 Reserved - - - 1 RSA/MD5 RFC 2537 NOT RECOMMENDED - 2 Diffie-Hellman RFC 2539 OPTIONAL - 3 DSA RFC 2536 OPTIONAL - 4 elliptic curve TBA OPTIONAL - 5 RSA/SHA1 RFC 3110 MANDATORY - 6-251 available for assignment - - 252 indirect see below OPTIONAL - 253 private see below OPTIONAL - 254 private see below OPTIONAL - 255 reserved - - - - -A.1.1 Indiret and Private Algorithm Types - - RFC 2535 describes Algorithm number 252 as an indirect key format - where the actual key material is elsewhere. This format was to be - defined in a separate document. In the years between RFC 2535 and - this document, no indirect key document has been prodcued. - - Algorithm number 253 is reserved for private use and will never be - assigned to a specific algorithm. The public key area in the KEY RR - and the signature area in the SIG RR begin with a wire encoded domain - name. Only local domain name compression is permitted. The domain - - - -Arends, et al. Expires April 29, 2003 [Page 26] - -Internet-Draft DNSSEC Resource Records October 2002 - - - name indicates the private algorithm to use and the remainder of the - public key area is determined by that algorithm. Entities should - only use domain names they control to designate their private - algorithms. - - Algorithm number 254 is reserved for private use and will never be - assigned to a specific algorithm. The public key area in the KEY RR - and the signature area in the SIG RR begin with an unsigned length - byte followed by a BER encoded Object Identifier (ISO OID) of that - length. The OID indicates the private algorithm in use and the - remainder of the area is whatever is required by that algorithm. - Entities should only use OIDs they control to designate their private - algorithms. - - Editors Note: There is currently no use of or operational experience - with these algorithms. The editors (at least Dan!) recommend that - these algorithm types be eliminated. We don't need this in the base - spec and every other algorithm type requires a seperate document to - describe it in detail. Note eliminating these from the base spec - would not elminate any future functionality since there are 200+ - available algorithm numbers. Anyone who feels they need this type of - algorithm (or a similar algorithm) can write the document clearly - describing it. - -A.2 DNSSEC Digest Types - - A "Digest Type" field in the DS resource record types identifies the - cryptographic digest algorithm used by the resource record. The - following table lists the currently defined digest algorithm types. - - VALUE Algorithm STATUS - 0 Reserved - - 1 RSA/SHA-1 MANDATORY - 2-255 Unassigned - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 29, 2003 [Page 27] - -Internet-Draft DNSSEC Resource Records October 2002 - - -Appendix B. Key Tag Calculation - - The key tag field provides a mechanism for efficiently selecting a - public key. In most cases, a combination of owner name, algorithm, - and key tag can efficiently identify a KEY record. For example, - both the SIG and DS resource records have corresponding KEY records. - A Key Tag field in the SIG and DS records can be used to help - efficiently select the corresponding KEY RR when there is more than - one candidate KEY RR available. - - However, it is essential to note that the key tag is not a unique - identifier. It is theoretically possible for two distinct KEY RRs to - have the same owner name, same algorithm, and same key tag. The key - tag is used to efficiently limit the possible candidate keys but it - does not uniquely identify a KEY record. Implementations MUST NOT - assume the key tag uniquely idenifies a KEY RR. - - The following ANSI C reference implementation is provided for - calculating a Key Tag. This reference implementation applies to all - algorithm types except algorithm 1 (see Appendix B.1). The input is - the public key material in base 64, not the entire RDATA of the KEY - record that contains the public key. The code is written for - clarity, not efficiency. - - /* assumes int is at least 16 bits - first byte of the key tag is the most significant byte of return - value - second byte of the key tag is the least significant byte of - return value - */ - - int keytag ( - - unsigned char key[], /* the RDATA part of the KEY RR */ - unsigned int keysize, /* the RDLENGTH */ - ) - { - long int ac; /* assumed to be 32 bits or larger */ - - for ( ac = 0, i = 0; i < keysize; ++i ) - ac += (i&1) ? key[i] : key[i]<<8; - ac += (ac>>16) & 0xFFFF; - return ac & 0xFFFF; - } - - - - - - - -Arends, et al. Expires April 29, 2003 [Page 28] - -Internet-Draft DNSSEC Resource Records October 2002 - - -B.1 Key Tag for Algorithm 1 - RSA/MD5 - - Algorithm 1 - RSA/MD5 key tag is the only algoritm that does not use - the key tag defined above. For a KEY RR with algorithm 1, the key - tag is the most signifigant 16 bits of the least signifigant 24 bits - in the public key modulus. In others, the 4th to last and 3rd to - last octets in the key modulus. Note that Algorithm 1 is NOT - RECOMMENDED. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 29, 2003 [Page 29] - -Internet-Draft DNSSEC Resource Records October 2002 - - -Appendix C. Canonical Form and Order of Resource Records - - This section defines a canonical form for resource records (RRs) and - defines a name order and overall order. A canonical name order is - required to construct the NXT name chain. A canonical RR form and - ordering within an RRset is required to construct and verify SIG RRs. - -C.1 Canonical DNS Name Order - - For purposes of DNS security, owner names are sorted by treating - individual labels as unsigned left justified octet strings. The - absence of a octet sorts before a zero value octet and upper case - letters are treated as lower case letters. - - To sort names in a zone, first sort all names based on only the - highest level label. Next if multiple names appear within a level, - sort based on the next highest level label. Repeat until all names - have been sorted down to leaf node labels. - - For example, the following names are sorted in canonical DNS name - order. The highest label is label level is foo.example. At this - level, foo.example sorts first, followed by all names ending in - a.foo.example and then all names ending z.foo.example. The names - withing the a.foo.example level and z.foo.example level are sorted. - - foo.example - a.foo.example - yljkjljk.a.foo.example - Z.a.foo.example - zABC.a.FOO.EXAMPLE - z.foo.example - *.z.foo.example - \200.z.foo.example - - -C.2 Canonical RR Form - - For purposes of DNS security, the canonical form for an RR is the - wire format of the RR with - - (1) all domain names fully expanded - (no name compression via pointers) - (2) all domain name letters set to lower case - (3) any owner name wild cards in master file form - (no substitution made for *) - (4) the original TTL substituted for the current TTL. - - - - - -Arends, et al. Expires April 29, 2003 [Page 30] - -Internet-Draft DNSSEC Resource Records October 2002 - - -C.3 Canonical RR Ordering Within An RRset - - For purposes of DNS security, RRs with same owner name and same type - are sorted by treating the RDATA as a left justified unsigned octet - sequence. The absence of an octet sorts before the zero octet. - -C.4 Canonical Ordering of RR Types - - RRs with the same owner name but different types are sorted based on - the RR type number. The exception to this rule are SIG RRs, which - are placed immediately after the type they cover. - - For example, an A record would be put before an MX record because - type 1 (A) and is lower than type 15 (MX). If the A and MX records - were both signed, the order would be A < SIG(A) < MX < SIG(MX). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 29, 2003 [Page 31] - -Internet-Draft DNSSEC Resource Records October 2002 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2002). 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. - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires April 29, 2003 [Page 32] - - - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-records-03.txt b/doc/draft/draft-ietf-dnsext-dnssec-records-03.txt new file mode 100644 index 0000000000..23475b80c0 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-records-03.txt @@ -0,0 +1,1848 @@ + + +DNS Extensions R. Arends +Internet-Draft Telematica Instituut +Expires: August 26, 2003 R. Austein + ISC + M. Larson + VeriSign + D. Massey + USC/ISI + S. Rose + NIST + February 25, 2003 + + + Resource Records for the DNS Security Extensions + draft-ietf-dnsext-dnssec-records-03 + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on August 26, 2003. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document is part of a family of documents that describes the DNS + Security Extensions (DNSSEC). The DNS Security Extensions are a + collection of resource records and protocol modifications that + provide source authentication for the DNS. This document defines the + + + +Arends, et al. Expires August 26, 2003 [Page 1] + +Internet-Draft DNSSEC Resource Records February 2003 + + + KEY, DS, SIG, and NXT resource records. The purpose and format of + each resource record is described in detail and an example of each + resource record is given. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 Background and Related Documents . . . . . . . . . . . . . . 4 + 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3 Editors Notes . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4 + 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4 + 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5 + 2. The KEY Resource Record . . . . . . . . . . . . . . . . . . 6 + 2.1 KEY RDATA Wire Format . . . . . . . . . . . . . . . . . . . 6 + 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . . 6 + 2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . . . . 7 + 2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 7 + 2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . . . . 7 + 2.1.5 Notes on KEY RDATA Design . . . . . . . . . . . . . . . . . 7 + 2.2 The KEY RR Presentation Format . . . . . . . . . . . . . . . 7 + 2.3 KEY RR Example . . . . . . . . . . . . . . . . . . . . . . . 7 + 3. The SIG Resource Record . . . . . . . . . . . . . . . . . . 9 + 3.1 SIG RDATA Wire Format . . . . . . . . . . . . . . . . . . . 9 + 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . . . . 10 + 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . . . . 10 + 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . . . . 10 + 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . . . . 11 + 3.1.5 Signature Expiration and Inception Fields . . . . . . . . . 11 + 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 11 + 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . . 11 + 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . . 12 + 3.2 The SIG RR Presentation Format . . . . . . . . . . . . . . . 12 + 3.3 SIG RR Example . . . . . . . . . . . . . . . . . . . . . . . 13 + 4. The NXT Resource Record . . . . . . . . . . . . . . . . . . 15 + 4.1 NXT RDATA Wire Format . . . . . . . . . . . . . . . . . . . 15 + 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 15 + 4.1.2 The Type Bit Map Field . . . . . . . . . . . . . . . . . . . 15 + 4.1.3 Inclusion of Wildcard Names in NXT RDATA . . . . . . . . . . 16 + 4.2 The NXT RR Presentation Format . . . . . . . . . . . . . . . 16 + 4.3 NXT RR Example . . . . . . . . . . . . . . . . . . . . . . . 16 + 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 18 + 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . . 18 + 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 18 + 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 19 + 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . . 19 + 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . . 19 + 5.2 The DS RR Presentation Format . . . . . . . . . . . . . . . 19 + + + +Arends, et al. Expires August 26, 2003 [Page 2] + +Internet-Draft DNSSEC Resource Records February 2003 + + + 5.3 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 20 + 6. Canonical Form and Order of Resource Records . . . . . . . . 21 + 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . . 21 + 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . . 21 + 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . . 22 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23 + 8. Security Considerations . . . . . . . . . . . . . . . . . . 24 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25 + Normative References . . . . . . . . . . . . . . . . . . . . 26 + Informative References . . . . . . . . . . . . . . . . . . . 27 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27 + A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . 29 + A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . . 29 + A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . . . . 29 + A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . . 30 + B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . 31 + B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . . 32 + Full Copyright Statement . . . . . . . . . . . . . . . . . . 33 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 3] + +Internet-Draft DNSSEC Resource Records February 2003 + + +1. Introduction + + The DNS Security Extensions (DNSSEC) introduce four new DNS resource + record types: KEY, SIG, NXT, and DS. This document defines the + purpose of each resource record (RR), the RR's RDATA format, and its + ASCII representation. + +1.1 Background and Related Documents + + The reader is assumed to be familiar with the basic DNS concepts + described in RFC1034 [1] and RFC1035 [2]. + + This document is part of a family of documents that define the DNS + security extensions. The DNS security extensions (DNSSEC) are a + collection of resource records and DNS protocol modifications that + add source authentication the Domain Name System (DNS). An + introduction to DNSSEC and definition of common terms can be found in + [10]. A description of DNS protocol modifications can be found in + [11]. This document defines the DNSSEC resource records. + +1.2 Reserved Words + + 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 [5]. + +1.3 Editors Notes + +1.3.1 Open Technical Issues + + The NXT section (Section 4) may be updated in the next version if + DNSSEC-Opt-In [13] becomes part of DNSSEC. + + The cryptographic algorithm types (Appendix A) requires input from + the working group. The DSA algorithm was moved to OPTIONAL. This + had strong consensus in workshops and various discussions and a + separate internet draft solely to move DSA from MANDATORY to OPTIONAL + seemed excessive. This draft solicits input on that proposed change. + +1.3.2 Technical Changes or Corrections + + Please report technical corrections to dnssec-editors@east.isi.edu. + To assist the editors, please indicate the text in error and point + out the RFC that defines the correct behavior. For a technical + change where no RFC that defines the correct behavior, or if there's + more than one applicable RFC and the definitions conflict, please + post the issue to namedroppers. + + + + +Arends, et al. Expires August 26, 2003 [Page 4] + +Internet-Draft DNSSEC Resource Records February 2003 + + + An example correction to dnssec-editors might be: Page X says + "DNSSEC RRs SHOULD be automatically returned in responses." This was + true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the + DNSSEC RR types MUST NOT be included in responses unless the resolver + indicated support for DNSSEC. + +1.3.3 Typos and Minor Corrections + + Please report any typos corrections to dnssec-editors@east.isi.edu. + To assist the editors, please provide enough context for us to find + the incorrect text quickly. + + An example message to dnssec-editors might be: page X says "the + DNSSEC standard has been in development for over 1 years". It + should read "over 10 years". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 5] + +Internet-Draft DNSSEC Resource Records February 2003 + + +2. The KEY Resource Record + + DNSSEC uses public key cryptography to sign and authenticate DNS + resource record sets (RRsets). The public keys are stored in KEY + resource records and are used in the DNSSEC authentication process + described in [11]. In a typical example, a zone signs its + authoritative RRsets using a private key and stores the corresponding + public key in a KEY RR. A resolver can then use these signatures to + authenticate RRsets from the zone. + + The KEY RR may also be used to store public keys associated with + other DNS operations such as TKEY [15]. In all cases, the KEY RR + plays a special role in secure DNS resolution and DNS message + processing. The KEY RR is not intended as a record for storing + arbitrary public keys. The KEY RR MUST NOT be used to store + certificates or public keys that do not directly relate to the DNS + infrastructure. Examples of certificates and public keys that MUST + NOT be stored in the KEY RR include X.509 certificates, IPSEC public + keys, and SSH public keys. + + The Type value for the KEY RR type is 25. + + The KEY RR is class independent. + + There are no special TTL requirements on the KEY record. + +2.1 KEY RDATA Wire Format + + The RDATA for a KEY RR consists of a 2 octet Flags Field, a 1 octet + Protocol Field, a 1 octet Algorithm Field , and the Public Key Field. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | Protocol | Algorithm | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Public Key / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +2.1.1 The Flags Field + + Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1, + then the KEY record holds a DNS zone key and the KEY's owner name + MUST be the name of a zone. If bit 7 has value 0, then the KEY + record holds some other type of DNS public key, such as a public key + + + +Arends, et al. Expires August 26, 2003 [Page 6] + +Internet-Draft DNSSEC Resource Records February 2003 + + + used by TKEY. + + Bits 0-6 and 8-15 are reserved and MUST have value 0 upon creation of + the KEY RR, and MUST be ignored upon reception. + + Editors' Note: draft-ietf-dnsext-keyrr-key-signing-flag changes this + by allocating bit 15 as the KSK bit. + +2.1.2 The Protocol Field + + The Protocol Field MUST have value 3. + +2.1.3 The Algorithm Field + + The Algorithm field identifies the public key's cryptographic + algorithm and determines the format of the Public Key field. A list + of DNSSEC algorithm types can be found in Appendix A.1 + +2.1.4 The Public Key Field + + The Public Key Field holds the public key material. + +2.1.5 Notes on KEY RDATA Design + + Although the Protocol Field always has value 3, it is retained for + backward compatibility with an earlier version of the KEY record. + +2.2 The KEY RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Flag field is represented as an unsigned decimal integer with a + value of either 0 or 256. + + The Protocol Field is represented as an unsigned decimal integer with + a value of 3. + + The Algorithm field is represented either as an unsigned decimal + integer or as an algorithm mnemonic as specified in Appendix A.1. + + The Public Key field is represented as a Base64 encoding of the + Public Key. Whitespace is allowed within the Base64 text. For a + definition of Base64 encoding, see [3] Section 5.2. + +2.3 KEY RR Example + + The following KEY RR stores a DNS zone key for example.com. + + + + +Arends, et al. Expires August 26, 2003 [Page 7] + +Internet-Draft DNSSEC Resource Records February 2003 + + + example.com. 86400 IN KEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3Cbl + +BBZH4b/0PY1kxkmvHjcZc8nokfzj31 + GajIQKY+5CptLr3buXA10hWqTkF7H6R + foRqXQeogmMHfpftf6zMv1LyBUgia7z + a6ZEzOJBOztyvhjL742iU/TpPSEDhm2 + SNKLijfUppn1UaNvv4w== ) + + The first four text fields specify the owner name, TTL, Class, and RR + type (KEY). Value 256 indicates that the Zone Key bit (bit 7) in the + Flags field has value 1. Value 3 is the fixed Protocol value. Value + 5 indicates the public key algorithm. Appendix A.1 identifies + algorithm type 5 as RSA/SHA1 and indicates that the format of the + RSA/SHA1 public key field is defined in [8]. The remaining text is a + base 64 encoding of the public key. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 8] + +Internet-Draft DNSSEC Resource Records February 2003 + + +3. The SIG Resource Record + + DNSSEC uses public key cryptography to sign and authenticate DNS + resource record sets (RRsets). Signatures are stored in SIG resource + records and are used in the DNSSEC authentication process described + in [11]. In a typical example, a zone signs its authoritative RRsets + using a private key and stores the corresponding signatures in SIG + RRs. A resolver can then use these SIG RRs to authenticate RRsets + from the zone. + + A SIG record contains the signature for an RRset with a particular + name, class, and type. The SIG RR specifies a validity interval for + the signature and uses the Algorithm, the Signer's Name, and the Key + Tag to identify the public key (KEY RR) that can be used to verify + the signature. + + The SIG RR may cover a transaction instead of an RRset. In this + case, the "Type Covered" field value is 0, the SIG RR MUST NOT appear + in any zone, and its use and processing are outside the scope of this + document. Please see [7] for further details. + + The Type value for the SIG RR type is 24. + + The SIG RR MUST have the same class as the RRset it covers. + + The SIG RR TTL value SHOULD match the TTL value of the RRset it + covers. + +3.1 SIG RDATA Wire Format + + The RDATA for a SIG RR consists of a 2 octet Type Covered field, a 1 + octet Algorithm field, a 1 octet Labels field, a 4 octet Original TTL + field, a 4 octet Signature Expiration field, a 4 octet Signature + Inception field, a 2 octet Key tag, the Signer's Name field, and the + Signature field. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type Covered | Algorithm | Labels | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Original TTL | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Signature Expiration | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Signature Inception | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Tag | / + + + +Arends, et al. Expires August 26, 2003 [Page 9] + +Internet-Draft DNSSEC Resource Records February 2003 + + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Signature / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +3.1.1 The Type Covered Field + + The Type Covered field identifies the type of the RRset which is + covered by this SIG record. + + If Type Covered field has a value of 0, the record is referred to as + a transaction signature; please see [7] for further details. + +3.1.2 The Algorithm Number Field + + The Algorithm Number field identifies the cryptographic algorithm + used to create the signature. A list of DNSSEC algorithm types can + be found in Appendix A.1 + +3.1.3 The Labels Field + + The Labels field specifies the number of labels in the original SIG + RR owner name. It is included to handle signatures associated with + wildcard owner names. + + To validate a signature, the validator requires the original owner + name that was used when the signature was created. If the original + owner name contains a wildcard label ("*"), the owner name may have + been expanded by the server during the response process, in which + case the validator will need to reconstruct the original owner name + in order to validate the signature. [11] describes how to use the + Labels field to reconstruct the original owner name. + + The value of the Label field MUST NOT count either the null (root) + label that terminates the owner name or the wildcard label (if + present). The value of the Label field MUST be less than or equal to + the number of labels in the SIG owner name. For example, + "www.example.com." has a Label field value of 3, and "*.example.com." + has a Label field value of 2. Root (".") has a Label field value of + 0. + + Note that, although the wildcard label is not included in the count + stored in the Label field of the SIG RR, the wildcard label is part + of the RRset's owner name when generating or verifying the signature. + + + +Arends, et al. Expires August 26, 2003 [Page 10] + +Internet-Draft DNSSEC Resource Records February 2003 + + +3.1.4 Original TTL Field + + The Original TTL field specifies the TTL of the covered RRset as it + appears in the authoritative zone. + + The Original TTL field is necessary because a caching resolver + decrements the TTL value of a cached RRset. In order to validate a + signature, a resolver requires the original TTL. [11] describes how + to use the Original TTL field value to reconstruct the original TTL. + + The Original TTL value MUST be greater than or equal to the TTL value + of the SIG record itself. + +3.1.5 Signature Expiration and Inception Fields + + The Signature Expiration and Inception fields specify a validity + period for the signature. The SIG record MUST NOT be used for + authentication prior to the inception date and MUST NOT be used for + authentication after the expiration date. + + Signature Expiration and Inception field values are in POSIX.1 time + format, a 32-bit unsigned number of seconds elapsed since 1 January + 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The + longest interval which can be expressed by this format without + wrapping is approximately 136 years. A SIG RR can have an Expiration + field value which is numerically smaller than the Inception field + value if the expiration field value is near the 32-bit wrap-around + point or if the signature is long lived. Because of this, all + comparisons involving these fields MUST use "Serial number + arithmetic" as defined in [4]. As a direct consequence, the values + contained in these fields cannot refer to dates more than 68 years in + either the past or the future. + +3.1.6 The Key Tag Field + + The Key Tag field contains the key tag value of the KEY RR that + validates this signature. The process of calculating the Key Tag + value is given in Appendix B. + +3.1.7 The Signer's Name Field + + The Signer's Name field value identifies the owner name of the KEY RR + used to authenticate this signature. The Signer's Name field MUST + contain the name of the zone of the covered RRset, unless the Type + Covered field value is 0. A sender MUST NOT use DNS name compression + on the Signer's Name field when transmitting a SIG RR. A receiver + which receives a SIG RR containing a compressed Signer's Name field + SHOULD decompress the field value. + + + +Arends, et al. Expires August 26, 2003 [Page 11] + +Internet-Draft DNSSEC Resource Records February 2003 + + +3.1.8 The Signature Field + + The Signature field contains the cryptographic signature which covers + the SIG RDATA (excluding the Signature field) and the RRset specified + by the SIG owner name, SIG class, and SIG Type Covered field. + +3.1.8.1 Signature Calculation + + A signature covers the SIG RDATA (excluding the Signature Field) and + covers the RRset specified by the SIG owner name, SIG class, and SIG + Type Covered field. The RRset is in canonical form (see Section 6) + and the set RR(1),...RR(n) is signed as follows: + + signature = sign(SIG_RDATA | RR(1) | RR(2)... ) where + + "|" denotes concatenation; + + SIG_RDATA is the wire format of the SIG RDATA fields with + the Signer's Name field in canonical form and + the Signature field excluded; + + RR(i) = owner | class | type | TTL | RDATA length | RDATA; + + "owner" is the fully qualified owner name of the RRset in + canonical form (for RRs with wildcard owner names, the + wildcard label is included in the owner name); + + Each RR MUST have the same owner name as the SIG RR; + + Each RR MUST have the same class as the SIG RR; + + Each RR in the RRset MUST have the RR type listed in the + SIG RR's Type Covered field; + + Each RR in the RRset MUST have the TTL listed in the SIG + Original TTL Field; + + Any DNS names in the RDATA field of each RR MUST be in + canonical form; and + + The RRset MUST be sorted in canonical order. + + +3.2 The SIG RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Type Covered field value is represented either as an unsigned + + + +Arends, et al. Expires August 26, 2003 [Page 12] + +Internet-Draft DNSSEC Resource Records February 2003 + + + decimal integer or as the mnemonic for the covered RR type. + + The Algorithm field value is represented either as an unsigned + decimal integer or as an algorithm mnemonic as specified in Appendix + A.1. + + The Labels field value is represented as an unsigned decimal integer. + + The Original TTL field value is represented as an unsigned decimal + integer. + + The Signature Inception Time and Expiration Time field values are + represented in the form YYYYMMDDHHmmSS in UTC, where: + + YYYY is the year (0000-9999, but see Section 3.1.5); + + MM is the month number (01-12); + + DD is the day of the month (01-31); + + HH is the hour in 24 hours notation (00-23); + + mm is the minute (00-59); + + SS is the second (00-59). + + The Key Tag field is represented as an unsigned decimal integer. + + The Signer's Name field value is represented as a fully qualified + domain name. + + The Signature field is represented as a Base64 encoding of the + signature. Whitespace is allowed within the Base64 text. For a + definition of Base64 encoding see [3] Section 5.2. + +3.3 SIG RR Example + + The following a SIG RR stores the signature for the A RRset of + host.example.com: + + host.example.com. 86400 IN SIG A 5 3 86400 20030322173103 ( + 20030220173103 2642 example.com. + oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr + PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o + B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t + GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG + J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) + + + + +Arends, et al. Expires August 26, 2003 [Page 13] + +Internet-Draft DNSSEC Resource Records February 2003 + + + The first four fields specify the owner name, TTL, Class, and RR type + (SIG). The "A" represents the Type Covered field. The value 5 + identifies the Algorithm used (RSA-SHA1) to create the signature. + The value 3 is the number of Labels in the original owner name. The + value 86400 in the SIG RDATA is the Original TTL for the covered A + RRset. 20030322173103 and 20030220173103 are the expiration and + inception dates, respectively. 2642 is the Key Tag, and example.com. + is the Signer's Name. The remaining text is a Base64 encoding of the + signature. + + Note that combination of SIG RR owner name, class, and Type Covered + indicate that this SIG covers the "host.example.com" A RRset. The + Label value of 3 indicates that no wildcard expansion was used. The + Algorithm, Signer's Name, and Key Tag indicate this signature can be + authenticated using an example.com zone KEY RR whose algorithm is 5 + and key tag is 2642. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 14] + +Internet-Draft DNSSEC Resource Records February 2003 + + +4. The NXT Resource Record + + The NXT resource record lists two separate things: the owner name of + the next authoritative RRset in the canonical ordering of the zone, + and the set of RR types present at the NXT RR's owner name. The + complete set of NXT RRs in a zone both indicate which authoritative + RRsets exist in a zone and also form a chain of authoritative owner + names in the zone. This information is used to provide authenticated + denial of existence for DNS data, as described in [11]. + + The type value for the NXT RR is 30. + + The NXT RR is class independent. + +4.1 NXT RDATA Wire Format + + The RDATA of the NXT RR is as shown below: + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Next Domain Name / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Type Bit Map / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +4.1.1 The Next Domain Name Field + + The Next Domain Name field contains the owner name of the next + authoritative RRset in the canonical ordering of the zone; see + Section 6.1 for an explanation of canonical ordering. The value of + the Next Domain Name field in the last NXT record in the zone is the + name of the zone apex (the owner name name of the zone's SOA RR). + + A sender MUST NOT use DNS name compression on the Next Domain Name + field when transmitting an NXT RR. A receiver which receives an NXT + RR containing a compressed Next Domain Name field SHOULD decompress + the field value. + + Owner names of non-authoritative RRsets (such as glue records) MUST + NOT be listed in the Next Domain Name unless at least one + authoritative RRset exists at the same owner name. + +4.1.2 The Type Bit Map Field + + The Type Bit Map field identifies the RRset types which exist at the + NXT RR's owner name. + + + +Arends, et al. Expires August 26, 2003 [Page 15] + +Internet-Draft DNSSEC Resource Records February 2003 + + + Each bit in the Type Bit Map field corresponds to an RR type. Bit 1 + corresponds to RR type 1 (A), bit 2 corresponds to RR type 2 (NS), + and so forth. If a bit is set to 1, it indicates that an RRset of + that type is present for the NXT's owner name. If a bit is set to 0, + it indicates that no RRset of that type present for the NXT's owner + name. + + Bit 1 MUST NOT indicate glue address records. + + Bit 41 MUST have the value of 0, since the OPT pseudo-RR [6] can + never appear in zone data. + + Trailing zero octets MUST be omitted. The length of the Type Bit Map + field varies, and is determined by the type code with the largest + numerical value among the set of RR types present at the NXT RR's + owner name. Trailing zero octets not specified MUST be interpreted + as zero octets. + + The above Type Bit Map format MUST NOT be used when an RR type code + with numerical value greater than 127 is present. + + Bit 0 in the Type Bit Map field indicates the Type Bit Map format. A + value of 0 in bit 0 denotes the format described above, therefore bit + 0 MUST have a value of 0. The format and meaning of a Type Bit Map + with a value of 1 in bit 0 is undefined. + +4.1.3 Inclusion of Wildcard Names in NXT RDATA + + If a wildcard owner name appears in a zone, the wildcard label ("*") + is treated as a literal symbol and is treated the same as any other + owner name for purposes of generating NXT RRs. Wildcard owner names + appear in the Next Domain Name field without any wildcard expansion. + [11] describes the impact of wildcards on authenticated denial of + existence. + +4.2 The NXT RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Next Domain Name field is represented as a domain name. + + The Type Bit Map field is represented either as a sequence of RR type + mnemonics or as a sequence of unsigned decimal integers denoting the + RR type codes. + +4.3 NXT RR Example + + The following NXT RR identifies the RRsets associated with + + + +Arends, et al. Expires August 26, 2003 [Page 16] + +Internet-Draft DNSSEC Resource Records February 2003 + + + alfa.example.com. and identifies the next authoritative name after + alfa.example.com. + + alfa.example.com. 86400 IN NXT host.example.com. A MX SIG NXT + + The first four text fields specify the name, TTL, Class, and RR type + (NXT). The entry host.example.com. is the next authoritative name + after alfa.example.com. (in canonical order). The A, MX, SIG and + NXT mnemonics indicate there are A, MX, SIG and NXT RRsets associated + with the name alfa.example.com. + + Note the NXT record can be used for authenticated denial of + existence. If the example NXT record were authenticated, it could be + used to prove that beta.example.com. does not exist, or could be + used to prove there is no AAAA record associated with + alfa.example.com. Authenticated denial of existence is discussed in + [11] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 17] + +Internet-Draft DNSSEC Resource Records February 2003 + + +5. The DS Resource Record + + The DS Resource Record refers to a KEY RR and is used in the DNS KEY + authentication process. A DS RR refers to a KEY RR by storing the + key tag, algorithm number, and a digest of KEY RR. Note that while + the digest should be sufficient to identify the key, storing the key + tag and key algorithm helps make the identification process more + efficient. By authenticating the DS record, a resolver can + authenticate the KEY RR to which the DS record points. The key + authentication process is described in [11]. + + The DS RR and its corresponding KEY RR have the same owner name, but + they are stored in different locations. The DS RR appears only on + the upper (parental) side of a delegation, and is authoritative data + in the parent zone. For example, the DS RR for "example.com" is + stored in the "com" zone (the parent zone) rather than in the + "example.com" zone (the child zone). The corresponding KEY RR is + stored in the "example.com" zone (the child zone). This simplifies + DNS zone management and zone signing, but introduces special response + processing requirements for the DS RR; these are described in [11]. + + The type number for the DS record is 43. + + The DS resource record is class independent. + + There are no special TTL requirements on the DS resource record. + +5.1 DS RDATA Wire Format + + The RDATA for a DS RR consists of 2 octet Key Tag field, a one octet + Algorithm field, a one octet Digest Type field, and a Digest field. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Tag | Algorithm | Digest Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Digest / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +5.1.1 The Key Tag Field + + The Key Tag field lists the key tag of the KEY RR referred to by the + DS record. The KEY RR MUST be a zone key. The KEY RR Flags MUST + have Flags bit 7 set to value 1. + + + +Arends, et al. Expires August 26, 2003 [Page 18] + +Internet-Draft DNSSEC Resource Records February 2003 + + + The Key Tag used by the DS RR is identical to the Key Tag used by the + SIG RR and Appendix B describes how to compute a Key Tag. + +5.1.2 The Algorithm Field + + The Algorithm field lists the algorithm number of the KEY RR referred + to by the DS record. + + The algorithm number used by the DS RR is identical to the algorithm + number used by the SIG RR and KEY RR. Appendix A.1 lists the + algorithm number types. + +5.1.3 The Digest Type Field + + The DS RR refers to a KEY RR by including a digest of that KEY RR. + The Digest Type field identifies the algorithm used to construct the + digest and Appendix A.2 lists the possible digest algorithm types. + +5.1.4 The Digest Field + + The DS record refers to a KEY RR by including a digest of that KEY + RR. The Digest field holds the digest. + + The digest is calculated by concatenating the canonical form of the + fully qualified owner name of the KEY RR (abbreviated below as "key + RR name") with the KEY RDATA, and then applying the digest algorithm. + + digest = digest_algorithm( KEY RR name | KEY RDATA); + + "|" denotes concatenation + + KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key. + + + The size of the digest may vary depending on the digest algorithm and + KEY RR size. Currently, the defined digest algorithm is SHA-1, which + produces a 20 octet digest. + +5.2 The DS RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Key Tag field is represented as an unsigned decimal integer. + + The Algorithm field is represented either as an unsigned decimal + integer or as an algorithm mnemonic specified in Appendix A.1. + + The Digest Type field is represented as an unsigned decimal integer. + + + +Arends, et al. Expires August 26, 2003 [Page 19] + +Internet-Draft DNSSEC Resource Records February 2003 + + + The Digest is represented as a sequence of case-insensitive + hexadecimal digits. Whitespace is allowed within the hexadecimal + text. + +5.3 DS RR Example + + The following example shows a KEY RR and its corresponding DS RR. + + dskey.example.com. 86400 IN KEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz + fwJr1AYtsmx3TGkJaNXVbfi/ + 2pHm822aJ5iI9BMzNXxeYCmZ + DRD99WYwYqUSdjMmmAphXdvx + egXd/M5+X7OrzKBaMbCVdFLU + Uh6DhweJBjEVv5f2wwjM9Xzc + nOf+EPbtG9DMBmADjFDc2w/r + ljwvFw== + ) ; key id = 60485 + + dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A + 98631FAD1A292118 ) + + + The first four text fields specify the name, TTL, Class, and RR type + (DS). Value 60485 is the key tag for the corresponding + "dskey.example.com." KEY RR, and value 5 denotes the algorithm used + by this "dskey.example.com." KEY RR. The value 1 is the algorithm + used to construct the digest, and the rest of the RDATA text is the + digest in hexadecimal. + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 20] + +Internet-Draft DNSSEC Resource Records February 2003 + + +6. Canonical Form and Order of Resource Records + + This section defines a canonical form for resource records, a + canonical ordering of DNS names, and a canonical ordering of resource + records within an RRset. A canonical name order is required to + construct the NXT name chain. A canonical RR form and ordering + within an RRset are required to construct and verify SIG RRs. + +6.1 Canonical DNS Name Order + + For purposes of DNS security, owner names are ordered by treating + individual labels as unsigned left-justified octet strings. The + absence of a octet sorts before a zero value octet, and upper case + US-ASCII letters are treated as if they were lower case US-ASCII + letters. + + To compute the canonical ordering of a set of DNS names, start by + sorting the names according to their most significant (rightmost) + labels. For names in which the most significant label is identical, + continue sorting according to their next most significant label, and + so forth. + + For example, the following names are sorted in canonical DNS name + order. The most significant label is "example". At this level, + "example" sorts first, followed by names ending in "a.example", then + names ending "z.example". The names within each level are sorted in + the same way. + + example + a.example + yljkjljk.a.example + Z.a.example + zABC.a.EXAMPLE + z.example + \001.z.example + *.z.example + \200.z.example + + +6.2 Canonical RR Form + + For purposes of DNS security, the canonical form of an RR is the wire + format of the RR where: + + 1. Every domain name in the RR is fully expanded (no DNS name + compression) and fully qualified; + + 2. All uppercase US-ASCII letters in the owner name of the RR are + + + +Arends, et al. Expires August 26, 2003 [Page 21] + +Internet-Draft DNSSEC Resource Records February 2003 + + + replaced by the corresponding lowercase US-ASCII letters; + + 3. If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, + HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, + SRV, DNAME, or A6, all uppercase US-ASCII letters in the DNS + names within the RDATA of the RR are replaced by the + corresponding lowercase US-ASCII letters; + + 4. If the owner name of the RR is a wildcard name, the owner name is + in its original unexpanded form, including the "*" label (no + wildcard substitution); and + + 5. The RR's TTL is set to its original value as it appears in the + authoritative zone containing the RR or the Original TTL field of + the covering SIG RR. + + Editors' Note: the above definition sacrifices readability for an + attempt at precision. Please send better text! + +6.3 Canonical RR Ordering Within An RRset + + For purposes of DNS security, RRs with same owner name, same class, + and same type are sorted by sorting the canonical forms of the RRs + while treating the RDATA portion of the canonical form of each RR as + a left justified unsigned octet sequence. The absence of an octet + sorts before the zero octet. + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 22] + +Internet-Draft DNSSEC Resource Records February 2003 + + +7. IANA Considerations + + This document introduces one new IANA consideration. RFC 2535 [14] + created an IANA registry for DNS Security Algorithm Numbers. This + document re-assigns DNS Security Algorithm Number 252 to be + "reserved". This value is no longer available for assignment by + IANA. + + This document clarifies the use of existing DNS resource records. + For completeness, the IANA considerations from the previous documents + which defined these resource records are summarized below. No IANA + changes are made by this document other than the one change described + in the first paragraph of this section. + + [14] updated the IANA registry for DNS Resource Record Types, and + assigned types 24,25, and 30 to the SIG, KEY, and NXT RRs, + respectively. [9] assigned DNS Resource Record Type 43 to DS. + + [14] created an IANA registry for DNSSEC Resource Record Algorithm + Numbers. Values to 1-4, and 252-255 were assigned by [14]. Value 5 + was assigned by [8]. Value 252 is re-assigned by this document, as + noted above. + + [9] created an IANA registry for DNSSEC DS Digest Types, and assigned + value 0 to reserved and value 1 to SHA-1. + + [14] created an IANA Registry for KEY Protocol Values, but [16] re- + assigned all assigned values other than 3 to reserved and closed this + IANA registry. The registry remains closed, and all KEY records are + required to have Protocol Octet value of 3. + + The Flag bits in the KEY RR are not assigned by IANA, and there is no + IANA registry for these flags. All changes to the meaning of the KEY + RR Flag bits require a standards action. + + The meaning of a value of 1 in bit zero of the Type Bit Map of an NXT + RR can only be assigned by a standards action. + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 23] + +Internet-Draft DNSSEC Resource Records February 2003 + + +8. Security Considerations + + This document describes the format of four DNS resource records used + by the DNS security extensions, and presents an algorithm for + calculating a key tag for a public key. Other than the items + described below, the resource records themselves introduce no + security considerations. The use of these records is specified in a + separate document, and security considerations related to the use + these resource records are discussed in that document. + + The DS record points to a KEY RR using a cryptographic digest, the + key algorithm type and a key tag. The DS record is intended to + identify an existing KEY RR, but it is theoretically possible for an + attacker to generate a KEY that matches all the DS fields. The + probability of constructing such a matching KEY depends on the type + of digest algorithm in use. The only currently defined digest + algorithm is SHA-1, and the working group believes that constructing + a public key which would match the algorithm, key tag, and SHA-1 + digest given in a DS record would be a sufficiently difficult problem + that such an attack is not a serious threat at this time. + + The key tag is used to help select KEY resource records efficiently, + but it does not uniquely identify a single KEY resource record. It + is possible for two distinct KEY RRs to have the same owner name, the + same algorithm type, and the same key tag. An implementation which + used only the key tag to select a KEY RR might select the wrong + public key in some circumstances. Implementations MUST NOT assume + the key tag is unique public key identifier; this is clearly stated + in Appendix B. + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 24] + +Internet-Draft DNSSEC Resource Records February 2003 + + +9. Acknowledgments + + This document was created from the input and ideas of several members + of the DNS Extensions Working Group and working group mailing list. + The co-authors of this draft would like to express their thanks for + the comments and suggestions received during the revision of these + security extension specifications. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 25] + +Internet-Draft DNSSEC Resource Records February 2003 + + +Normative References + + [1] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [2] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [3] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail + Extensions) Part One: Mechanisms for Specifying and Describing + the Format of Internet Message Bodies", RFC 1521, September + 1993. + + [4] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, + August 1996. + + [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [6] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, + August 1999. + + [7] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + [8] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name + System (DNS)", RFC 3110, May 2001. + + [9] Gudmundsson, O., "Delegation Signer Resource Record", draft- + ietf-dnsext-delegation-signer-12 (work in progress), December + 2002. + + [10] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, + "DNS Security Introduction and Requirements", draft-ietf- + dnsext-dnssec-intro-05 (work in progress), February 2003. + + [11] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, + "Protocol Modifications for the DNS Security Extensions", + draft-ietf-dnsext-dnssec-protocol-00 (work in progress), + Februari 2003. + + [12] Gustafsson, A., "Handling of Unknown DNS RR Types", draft-ietf- + dnsext-unknown-rrs-04 (work in progress), September 2002. + + [13] Kosters, M., Blacka, D. and R. Arends, "DNSSEC Opt-in", draft- + ietf-dnsext-dnssec-opt-in-04 (work in progress), February 2003. + + + + + +Arends, et al. Expires August 26, 2003 [Page 26] + +Internet-Draft DNSSEC Resource Records February 2003 + + +Informative References + + [14] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [15] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC + 2930, September 2000. + + [16] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource + Record (RR)", RFC 3445, December 2002. + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede + NL + + EMail: roy.arends@telin.nl + + + Rob Austein + Internet Software Consortium + 40 Gavin Circle + Reading, MA 01867 + USA + + EMail: sra@isc.org + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Dan Massey + USC Information Sciences Institute + 3811 N. Fairfax Drive + Arlington, VA 22203 + USA + + EMail: masseyd@isi.edu + + + +Arends, et al. Expires August 26, 2003 [Page 27] + +Internet-Draft DNSSEC Resource Records February 2003 + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-8920 + USA + + EMail: scott.rose@nist.gov + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 28] + +Internet-Draft DNSSEC Resource Records February 2003 + + +Appendix A. DNSSEC Algorithm and Digest Types + + The DNS security extensions are designed to be independent of the + underlying cryptographic algorithms. The KEY, SIG, and DS resource + records all use a DNSSEC Algorithm Number to identify the + cryptographic algorithm in use by the resource record. The DS + resource record also specifies a Digest Algorithm Number to identify + the digest algorithm used to construct the DS record. The currently + defined Algorithm and Digest Types are listed below. Additional + Algorithm or Digest Types could be added as advances in cryptography + warrant. + + A DNSSEC aware resolver or name server MUST implement all MANDATORY + algorithms. + +A.1 DNSSEC Algorithm Types + + An "Algorithm Number" field in the KEY, SIG, and DS resource record + types identifies the cryptographic algorithm used by the resource + record. Algorithm specific formats are described in separate + documents. The following table lists the currently defined algorithm + types and provides references to their supporting documents: + + VALUE Algorithm RFC STATUS + 0 Reserved - - + 1 RSA/MD5 RFC 2537 NOT RECOMMENDED + 2 Diffie-Hellman RFC 2539 OPTIONAL + 3 DSA RFC 2536 OPTIONAL + 4 elliptic curve TBA OPTIONAL + 5 RSA/SHA1 RFC 3110 MANDATORY + 6-251 available for assignment - + 252 reserved - + 253 private see below OPTIONAL + 254 private see below OPTIONAL + 255 reserved - - + + +A.1.1 Private Algorithm Types + + Algorithm number 253 is reserved for private use and will never be + assigned to a specific algorithm. The public key area in the KEY RR + and the signature area in the SIG RR begin with a wire encoded domain + name. Only local domain name compression is permitted. The domain + name indicates the private algorithm to use and the remainder of the + public key area is determined by that algorithm. Entities should + only use domain names they control to designate their private + algorithms. + + + + +Arends, et al. Expires August 26, 2003 [Page 29] + +Internet-Draft DNSSEC Resource Records February 2003 + + + Algorithm number 254 is reserved for private use and will never be + assigned to a specific algorithm. The public key area in the KEY RR + and the signature area in the SIG RR begin with an unsigned length + byte followed by a BER encoded Object Identifier (ISO OID) of that + length. The OID indicates the private algorithm in use and the + remainder of the area is whatever is required by that algorithm. + Entities should only use OIDs they control to designate their private + algorithms. + +A.2 DNSSEC Digest Types + + A "Digest Type" field in the DS resource record types identifies the + cryptographic digest algorithm used by the resource record. The + following table lists the currently defined digest algorithm types. + + VALUE Algorithm STATUS + 0 Reserved - + 1 SHA-1 MANDATORY + 2-255 Unassigned - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 30] + +Internet-Draft DNSSEC Resource Records February 2003 + + +Appendix B. Key Tag Calculation + + The Key Tag field in the SIG and DS resource record types provides a + mechanism for selecting a public key efficiently. In most cases, a + combination of owner name, algorithm, and key tag can efficiently + identify a KEY record. Both the SIG and DS resource records have + corresponding KEY records. The Key Tag field in the SIG and DS + records can be used to help select the corresponding KEY RR + efficiently when more than one candidate KEY RR is available. + + However, it is essential to note that the key tag is not a unique + identifier. It is theoretically possible for two distinct KEY RRs to + have the same owner name, the same algorithm, and the same key tag. + The key tag is used to limit the possible candidate keys, but it does + not uniquely identify a KEY record. Implementations MUST NOT assume + that the key tag uniquely identifies a KEY RR. + + The key tag is the same for all KEY algorithm types except algorithm + 1 (please see Appendix B.1 for the definition of the key tag for + algorithm 1). For all algorithms other than algorithm 1, the key tag + is defined to be the output which would be generated by running the + ANSI C function shown below with the RDATA portion of the KEY RR as + input. It is not necessary to use the following reference code + verbatim, but the numerical value of the Key Tag MUST be identical to + what the reference implementation would generate for the same input. + + Please note that the algorithm for calculating the Key Tag is almost + but not completely identical to the familiar ones complement checksum + used in many other Internet protocols. Key Tags MUST be calculated + using the algorithm described below rather than the ones complement + checksum. + + The following ANSI C reference implementation calculates the value of + a Key Tag. This reference implementation applies to all algorithm + types except algorithm 1 (see Appendix B.1). The input is the wire + format of the RDATA portion of the KEY RR. The code is written for + clarity, not efficiency. + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 31] + +Internet-Draft DNSSEC Resource Records February 2003 + + + /* + * Assumes that int is at least 16 bits. + * First octet of the key tag is the most significant 8 bits of the + * return value; + * Second octet of the key tag is the least significant 8 bits of the + * return value. + */ + + unsigned int + keytag ( + unsigned char key[], /* the RDATA part of the KEY RR */ + unsigned int keysize /* the RDLENGTH */ + ) + { + unsigned long ac; /* assumed to be 32 bits or larger */ + int i; /* loop index */ + + for ( ac = 0, i = 0; i < keysize; ++i ) + ac += (i & 1) ? key[i] : key[i] << 8; + ac += (ac >> 16) & 0xFFFF; + return ac & 0xFFFF; + } + + +B.1 Key Tag for Algorithm 1 (RSA/MD5) + + The key tag for algorithm 1 (RSA/MD5) is defined differently than the + key tag for all other algorithms, for historical reasons. For a KEY + RR with algorithm 1, the key tag is defined to be the most + significant 16 bits of the least significant 24 bits in the public + key modulus (in other words, the 4th to last and 3rd to last octets + of the public key modulus). + + Please note that Algorithm 1 is NOT RECOMMENDED. + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 32] + +Internet-Draft DNSSEC Resource Records February 2003 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). 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. + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 33] + diff --git a/doc/draft/draft-ietf-dnsext-mdns-13.txt b/doc/draft/draft-ietf-dnsext-mdns-14.txt similarity index 63% rename from doc/draft/draft-ietf-dnsext-mdns-13.txt rename to doc/draft/draft-ietf-dnsext-mdns-14.txt index 4a3186a6c6..c23eedf89e 100644 --- a/doc/draft/draft-ietf-dnsext-mdns-13.txt +++ b/doc/draft/draft-ietf-dnsext-mdns-14.txt @@ -7,8 +7,8 @@ DNSEXT Working Group Levon Esibov INTERNET-DRAFT Bernard Aboba Category: Standards Track Dave Thaler - Microsoft -4 November 2002 + Microsoft +22 March 2003 Linklocal Multicast Name Resolution (LLMNR) @@ -33,7 +33,7 @@ http://www.ietf.org/shadow.html. Copyright Notice -Copyright (C) The Internet Society (2002). All Rights Reserved. +Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract @@ -61,40 +61,40 @@ Esibov, Aboba & Thaler Standards Track [Page 1] -INTERNET-DRAFT LLMNR 4 November 2002 +INTERNET-DRAFT LLMNR 22 March 2003 Table of Contents 1. Introduction .......................................... 3 - 1.1 Requirements .................................... 3 - 1.2 Terminology ..................................... 3 + 1.1 Requirements .................................... 4 + 1.2 Terminology ..................................... 4 2. Name resolution using LLMNR ........................... 4 - 2.1 Sender behavior ................................. 4 + 2.1 Sender behavior ................................. 5 2.2 Responder behavior .............................. 5 - 2.3 Addressing ...................................... 7 - 2.4 TTL ............................................. 7 - 2.5 No/multiple responses ........................... 7 + 2.3 Unicast queries ................................. 7 + 2.4 Addressing ...................................... 7 + 2.5 TTL ............................................. 7 + 2.6 Retransmissions ................................. 8 + 2.7 DNS TTL ......................................... 8 3. Usage model ........................................... 8 - 3.1 LLMNR configuration ............................. 9 -4. Sequence of events .................................... 10 -5. Conflict resolution ................................... 10 - 5.1 Considerations for multiple interfaces .......... 12 - 5.2 API issues ...................................... 14 -6. Security considerations ............................... 14 - 6.1 Scope restriction ............................... 14 - 6.2 Usage restriction ............................... 15 - 6.3 Cache and port separation ....................... 16 - 6.4 Authentication .................................. 16 -7. IANA considerations ................................... 16 -8. Normative References .................................. 16 -9. Informative References ................................ 17 + 3.1 Unqualified names ............................... 9 + 3.2 LLMNR configuration ............................. 9 +4. Conflict resolution ................................... 11 + 4.1 Considerations for multiple interfaces .......... 13 + 4.2 API issues ...................................... 14 +5. Security considerations ............................... 14 + 5.1 Scope restriction ............................... 15 + 5.2 Usage restriction ............................... 15 + 5.3 Cache and port separation ....................... 16 + 5.4 Authentication .................................. 16 +6. IANA considerations ................................... 17 +7. Normative References .................................. 17 +8. Informative References ................................ 17 Acknowledgments .............................................. 18 -Authors' Addresses ........................................... 18 +Authors' Addresses ........................................... 19 Intellectual Property Statement .............................. 19 -Full Copyright Statement ..................................... 19 - - +Full Copyright Statement ..................................... 20 @@ -121,7 +121,7 @@ Esibov, Aboba & Thaler Standards Track [Page 2] -INTERNET-DRAFT LLMNR 4 November 2002 +INTERNET-DRAFT LLMNR 22 March 2003 1. Introduction @@ -129,76 +129,26 @@ INTERNET-DRAFT LLMNR 4 November 2002 This document discusses Link-Local Multicast Name Resolution (LLMNR), which operates on a separate port from DNS, with a distinct resolver cache, but does not change the format of DNS packets. LLMNR supports all -current and future DNS formats, types and classes. +current and future DNS formats, types and classes. However, since LLMNR +only operates on the local link, it cannot be considered a substitute +for DNS. The goal of LLMNR is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. These include scenarios in which hosts are not configured with the address of a DNS server, where configured DNS servers do not reply to a query, or where -they respond with RCODE set to NXRRSET. - -Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is -possible for a dual stack host to be configured with the address of a -DNS server over IPv4, while remaining unconfigured with a DNS server -suitable for use over IPv6. In these situations, a dual stack host will -send AAAA queries to the configured DNS server over IPv4. However, an -IPv6-only host will not be able to resolve names. - -Since automatic IPv6 DNS configuration mechanisms such as [DHCPv6DNS] -and [DNSDisc] are not yet widely deployed, and not all DNS servers -support IPv6, "partial configuration" may be common in the short term, -and LLMNR may prove useful in enabling linklocal name resolution over -IPv6. However, in the long term, IPv6 DNS configuration, and DNS support -over IPv6 will become more common so that LLMNR usage will typically be -restricted to adhoc networks in which neither IPv4 nor IPv6 DNS servers -are configured, situations in which DNS servers do not respond to -queries, or where they respond with RCODE set to NXRRSET. - -Service discovery in general, as well as discovery of DNS servers using -LLMNR in particular is outside of the scope of this document, as is name -resolution over non-multicast capable media. - -1.1. Requirements - -In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", -"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as -described in [RFC2119]. - -1.2. Terminology - -Responder A host that listens to LLMNR queries, and responds to - those for which it is authoritative is called - "responder". - -Sender A host that sends an LLMNR query. Typically a host is - configured as both a sender and a responder, but a host - - - -Esibov, Aboba & Thaler Standards Track [Page 3] - - - - - -INTERNET-DRAFT LLMNR 4 November 2002 - - - may be configured as a "sender", but not a "responder" or - a "responder" but not a "sender". - -2. Name resolution using LLMNR - -While operating on a different port with a distinct resolver cache, -LLMNR makes no change to the current format of DNS packets. +they respond with errors, as described in Section 3. LLMNR queries are sent to and received on port TBD using a LINKLOCAL address as specified in "Administratively Scoped IP Multicast" [RFC2365] -for IPv4 and the "solicited name" LINKLOCAL multicast addresses for -IPv6, and using a unicast addresses in a few scenarios described below -in Section 3. The LLMNR LINKLOCAL address to be used for IPv4 is -224.0.0.251. LINKLOCAL addresses are used to prevent propagation of -LLMNR traffic across routers, potentially flooding the network. +for IPv4. The LLMNR LINKLOCAL address to be used for IPv4 is +224.0.0.251. For IPv6, the "solicited name" LINKLOCAL multicast +addresses are used for A/AAAA queries, and a separate multicast address +TBD for all other queries. LINKLOCAL multicast addresses are used to +prevent propagation of LLMNR traffic across routers, potentially +flooding the network; for details, see Section 2.4. In circumstances +described in Section 2.3, LLMNR queries can also be sent to a unicast +address. Propagation of LLMNR packets on the local link is considered sufficient to enable name resolution in small networks. The assumption is that if a @@ -222,16 +172,66 @@ incorrect, and multicast routing becomes ubiquitous. For example, it is not clear that this assumption will be valid in large adhoc networking scenarios. + + + +Esibov, Aboba & Thaler Standards Track [Page 3] + + + + + +INTERNET-DRAFT LLMNR 22 March 2003 + + Once we have experience in LLMNR deployment in terms of administrative issues, usability and impact on the network it will be possible reevaluate which multicast scopes are appropriate for use with multicast name resolution mechanisms. -2.1. Sender behavior +Service discovery in general, as well as discovery of DNS servers using +LLMNR in particular is outside of the scope of this document, as is name +resolution over non-multicast capable media. -A sender sends an LLMNR query for any legal Type of resource record -(e.g. A, PTR, etc.) to the LINKLOCAL address. Notice that in some -scenarios described below in Section 3 a sender may also send a unicast +1.1. Requirements + +In this document, several words are used to signify the requirements of +the specification. These words are often capitalized. 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 [RFC2119]. + +1.2. Terminology + +Responder A host that listens to LLMNR queries, and responds to + those for which it is authoritative. + +Sender A host that sends an LLMNR query. Typically a host is + configured as both a sender and a responder. However, a + host may be configured as a sender, but not a responder + or as a responder, but not a sender. + +Routable address + An address other than a linklocal address. This includes + site local and globally routable addresses, as well as + private addresses. + +2. Name resolution using LLMNR + +The sequence of events for LLMNR usage is as follows: + +[1] If a sender needs to resolve a query for a name "host.example.com", + then it sends a LLMNR query to the LINKLOCAL multicast address. + +[2] A responder responds to this query only if it is authoritative + for the domain name "host.example.com". The responder sends + a response to the sender via unicast over UDP. + +[3] Upon the reception of the response, the sender verifies that the Hop + Limit field in IPv6 header or TTL field in IPv4 header (depending on + the protocol used) of the response is set to 255. The sender then + verifies compliance with the addressing requirements for IPv4, + described in [IPV4Link], and IPv6, described in [RFC2373]. If these @@ -241,57 +241,57 @@ Esibov, Aboba & Thaler Standards Track [Page 4] -INTERNET-DRAFT LLMNR 4 November 2002 +INTERNET-DRAFT LLMNR 22 March 2003 -query. The RD (Recursion Desired) bit MUST NOT be set. If a responder -receives a query with the header containing RD set bit, the responder -MUST ignore the RD bit. + conditions are met, then the sender uses and caches the returned + response. If not, then the sender ignores the response and continues + waiting for the response. -The IPv6 LINKLOCAL address a given responder listens to, and to which a -sender sends, is a link-local multicast address formed as follows: The -name of the resource record in question is expressed in its canonical -form (see [RFC2535], section 8.1), which is uncompressed with all -alphabetic characters in lower case. The first label of the FQDN in the -query is then hashed using the MD5 algorithm, described in [RFC1321]. -The first 32 bits of the resultant 128-bit hash is then appended to the -prefix FF02:0:0:0:0:2::/96 to yield the 128-bit "solicited name -multicast address". (Note: this procedure is intended to be the same as -that specified in section 3 of "IPv6 Node Information Queries" -[NodeInfo]). A responder that listens for queries for multiple names -will necessarily listen to multiple of these solicited name multicast -addresses. +Further details of sender and responder behavior are provided in the +sections that follow. -If the LLMNR query is not resolved during a limited amount of time -(LLMNR_TIMEOUT), then a sender MAY repeat the transmission of a query in -order to assure themselves that the query has been received by a host -capable of responding to the query. The default value for LLMNR_TIMEOUT -is 1 second. Since a sender cannot know beforehand whether it will -receive no response, one response, or more than one response to a query, -it SHOULD wait for LLMNR_TIMEOUT in order to collect all possible -responses, rather than considering the query answered after the first -response is received. +2.1. Sender behavior -Repetition MUST NOT be attempted more than 3 times and SHOULD NOT be -repeated more often than once per second to reduce unnecessary network -traffic. The delay between attempts should be randomized so as to avoid -synchronization effects. +A sender sends an LLMNR query for any legal Type of resource record +(e.g. A, PTR, etc.) to the LINKLOCAL multicast address. An LLMNR sender +MAY send requests for any name. + +Under conditions described in Section 2.3, a sender may also send a +unicast query. The RD (Recursion Desired) bit MUST NOT be set. If a +responder receives a query with the header containing RD set bit, the +responder MUST ignore the RD bit. + +The sender MUST anticipate receiving no replies to some LLMNR queries, +in the event that no responders are available within the linklocal +multicast scope, or in the event that no positive non-null responses +exist for the transmitted query. If no positive response is received, a +resolver treats it as a response that no records of the specified type +and class for the specified name exist (that is, it is treated the same +as a response with RCODE=0 and an empty answer section). 2.2. Responder behavior -A responder listens on port TBD on the LINKLOCAL address and on the -unicast address(es) that could be set as the source address(es) when the -responder responds to the LLMNR query. The host configured as a -"responder" MUST act as a sender by using LLMNR dynamic update requests -to verify the uniqueness of names as described in Section 5. +A responder listens on port TBD on the LINKLOCAL multicast address(es) +and on the unicast address(es) that could be set as the source +address(es) when the responder responds to the LLMNR query. The host +configured as a responder MUST act as a sender to verify the uniqueness +of names as described in Section 4. Responders MUST NOT respond to LLMNR queries for names they are not authoritative for. Responders SHOULD respond to LLMNR queries for names and addresses they are authoritative for. This applies to both forward and reverse lookups. -As an example, assume that computer "host.example.com." is authoritative -for the domain "host.example.com.". On receiving a LLMNR A resource +As an example, a computer "host.example.com." configured to respond to +the LLMNR queries is authoritative for the name "host.example.com.". On +receiving an LLMNR A/AAAA resource record query for the name +"host.example.com." the host authoritatively responds with A/AAAA +record(s) that contain IP address(es) in the RDATA of the resource +record. + +If a responder is authoritative for a name, it MAY respond with RCODE=0 +and an empty answer section, if the type of query does not match a RR @@ -301,12 +301,17 @@ Esibov, Aboba & Thaler Standards Track [Page 5] -INTERNET-DRAFT LLMNR 4 November 2002 +INTERNET-DRAFT LLMNR 22 March 2003 -record query for the name "host.example.com." the host responds with A -record(s) that contain IP address(es) in the RDATA of the resource -record. +owned by the responder. For example, if the host has a AAAA RR, but no +A RR, and an A RR query is received, the host would respond with RCODE=0 +and an empty answer section. + +If a DNS server is running on a host that supports LLMNR, the DNS server +MUST respond to LLMNR queries only for the RRSets owned by the host on +which the server is running, but MUST NOT respond for other records for +which the server is authoritative. In conventional DNS terminology a DNS server authoritative for a zone is authoritative for all the domain names under the zone root except for @@ -323,33 +328,28 @@ coexistence of two or more hosts with the names representing child and parent (or grandparent) nodes in the DNS tree, for example, "host.example.com." and "child.host.example.com.". -In this example (unless this limitation is introduced) a LLMNR query for -an A record for the name "child.host.example.com." would result in two -authoritative responses: name error received from "host.example.com.", -and a requested A record - from "child.host.example.com.". To prevent -this ambiguity, LLMNR enabled hosts could perform a dynamic update of -the parent (or grandparent) zone with a delegation to a child zone. In -this example a host "child.host.example.com." would send a dynamic -update for the NS and glue A record to "host.example.com.", but this -approach significantly complicates implementation of LLMNR and would not -be acceptable for lightweight hosts. +In this example (unless this limitation is introduced) an LLMNR query +for an A record for the name "child.host.example.com." would result in +two authoritative responses: a name error received from +"host.example.com.", and a requested A record - from +"child.host.example.com.". To prevent this ambiguity, LLMNR enabled +hosts could perform a dynamic update of the parent (or grandparent) zone +with a delegation to a child zone. In this example a host +"child.host.example.com." would send a dynamic update for the NS and +glue A record to "host.example.com.", but this approach significantly +complicates implementation of LLMNR and would not be acceptable for +lightweight hosts. A response to a LLMNR query is composed in exactly the same manner as a response to the unicast DNS query as specified in [RFC1035]. Responders -MUST never respond using cached data, and the AA (Authoritative Answer) +MUST NOT respond using cached data, and the AA (Authoritative Answer) bit MUST be set. The response is sent to the sender via unicast. A response to an LLMNR query MUST have RCODE set to zero. Responses with RCODE set to zero are referred to in this document as "positively resolved". LLMNR responders may respond only to queries which they can resolve positively. -If a TC (truncation) bit is set in the response, then the sender MAY use -the response if it contains all necessary information, or the sender MAY -discard the response and resend the query over TCP or using EDNS0 with -larger window using the unicast address of the responder. The RA -(Recursion Available) bit in the header of the response MUST NOT be set. -Even if the RA bit is set in the response header, the sender MUST ignore -it. + @@ -361,97 +361,10 @@ Esibov, Aboba & Thaler Standards Track [Page 6] -INTERNET-DRAFT LLMNR 4 November 2002 +INTERNET-DRAFT LLMNR 22 March 2003 -2.3. Addressing - -For IPv4 LINKLOCAL addressing, section 2.4 of "Dynamic Configuration of -IPv4 Link-Local Addresses" [IPV4Link] lays out the rules with respect to -source address selection, TTL settings, and acceptable -source/destination address combinations. IPv6 is described in [RFC2460]; -IPv6 LINKLOCAL addressing is described in [RFC2373]. LLMNR queries and -responses MUST obey the rules laid out in these documents. - -In composing an LLMNR response, the responder MUST set the Hop Limit -field in the IPv6 header and the TTL field in IPv4 header of the LLMNR -response to 255. The sender MUST verify that the Hop Limit field in IPv6 -header and TTL field in IPv4 header of each response to the LLMNR query -is set to 255. If it is not, then sender MUST ignore the response. - - Implementation note: - - In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL socket - options are used to specify the TTL of outgoing unicast and multicast - packets. The IP_RECVTTL socket option is available on some platforms - to receive the IPv4 TTL of received packets with recvmsg(). [RFC2292] - specifies similar options for specifying and receiving the IPv6 Hop - Limit. - -2.4. TTL - -The responder should use a pre-configured TTL value in the records -returned in the LLMNR query response. Due to the TTL minimalization -necessary when caching an RRset, all TTLs in an RRset MUST be set to the -same value. In the additional and authority section of the response the -responder includes the same records as a DNS server would insert in the -response to the unicast DNS query. - -2.5. No/multiple responses - -The sender MUST anticipate receiving no replies to some LLMNR queries, -in the event that no responders are available within the linklocal -multicast scope, or in the event that no positive non-null responses -exist for the transmitted query. If no positive response is received, a -resolver treats it as a response that no records of the specified type -and class for the specified name exist (NXRRSET). - -While the responder MUST NOT respond to queries for names it is not -authoritative for, a responder MAY respond to a query for the name it is -authoritative for, even if the type of query does not match a RR owned -by the responder, with RCODE set to NXRRSET. For example, if the host -has a AAAA RR, but no A RR, and an A RR query is received, the host -would respond with an RCODE set to NXRRSET. - - - -Esibov, Aboba & Thaler Standards Track [Page 7] - - - - - -INTERNET-DRAFT LLMNR 4 November 2002 - - -The sender MUST anticipate receiving multiple replies to the same LLMNR -query, in the event that several LLMNR enabled computers receive the -query and respond with valid answers. When this occurs, the responses -MAY first be concatenated, and then treated in the same manner that -multiple RRs received from the same DNS server would, ordinarily. - -3. Usage model - -A host may be configured as a "sender", but not a "responder" or as a -"responder", but not a "sender". However, a host configured as a -"responder" MUST at least use a "sender's" capability to send LLMNR -dynamic update requests to verify the uniqueness of the names, as -described in Section 5. An LLMNR "sender" MAY multicast requests for any -name. If that name is not qualified and does not end in a trailing dot, -for the purposes of LLMNR, the implicit search order is as follows: - -[1] Request the name with the current domain appended. -[2] Request just the name. - -This is the behavior suggested by [RFC1536]. LLMNR uses this technique -to resolve unqualified host names. The same host MAY use LLMNR queries -for the resolution of unqualified host names, and conventional DNS -queries for resolution of other DNS names. - -If a DNS server is running on a host that supports LLMNR, the DNS server -MUST respond to LLMNR queries only for the RRSets owned by the host on -which the server is running, but MUST NOT respond for other records for -which the server is authoritative. +2.3. Unicast queries A sender MUST NOT send a unicast LLMNR query except when: @@ -462,16 +375,103 @@ A sender MUST NOT send a unicast LLMNR query except when: enables the sender to send a query directly to the hosts authoritative for the name in the query. -A responder with a name "host.example.com." configured to respond to the -LLMNR queries is authoritative for the name "host.example.com.". For -example, when a responder with the name "host.example.com." receives an -A type LLMNR query for the name "host.example.com." it authoritatively -responds to the query. +If a TC (truncation) bit is set in the response, then the sender MAY use +the response if it contains all necessary information, or the sender MAY +discard the response and resend the query over TCP or using EDNS0 with +larger window using the unicast address of the responder. The RA +(Recursion Available) bit in the header of the response MUST NOT be set. +If the RA bit is set in the response header, the sender MUST ignore it. -3.1. LLMNR configuration +2.4. Addressing -LLMNR usage MAY be configured manually or automatically on a per -interface basis. By default, LLMNR responders SHOULD be enabled on all +The IPv4 LINKLOCAL multicast address a given responder listens to, and +to which a sender sends all queries, is 224.0.0.251. The IPv6 LINKLOCAL +multicast address a given responder listens to, and to which a sender +sends A/AAAA queries, is formed as follows: The name of the resource +record in question is expressed in its canonical form (see [RFC2535], +section 8.1), which is uncompressed with all alphabetic characters in +lower case. + +The first label of the FQDN in the query is then hashed using the MD5 +algorithm, described in [RFC1321]. The first 32 bits of the resultant +128-bit hash is then appended to the prefix FF02:0:0:0:0:2::/96 to yield +the 128-bit "solicited name multicast address". (Note: this procedure +is intended to be the same as that specified in section 3 of "IPv6 Node +Information Queries" [NodeInfo]). A responder that listens for queries +for multiple names with different first labels will necessarily listen +to multiple of these solicited name multicast addresses. + +For IPv4 LINKLOCAL addressing, section 2.4 of "Dynamic Configuration of +IPv4 Link-Local Addresses" [IPV4Link] lays out the rules with respect to +source address selection, TTL settings, and acceptable +source/destination address combinations. IPv6 is described in [RFC2460]; +IPv6 LINKLOCAL addressing is described in [RFC2373]. LLMNR queries and +responses MUST obey the rules laid out in these documents. + +2.5. TTL + +In composing an LLMNR response, the responder MUST set the Hop Limit +field in the IPv6 header and the TTL field in IPv4 header of the LLMNR + + + +Esibov, Aboba & Thaler Standards Track [Page 7] + + + + + +INTERNET-DRAFT LLMNR 22 March 2003 + + +response to 255. The sender MUST verify that the Hop Limit field in IPv6 +header and TTL field in IPv4 header of each response to the LLMNR query +is set to 255. If it is not, then sender MUST ignore the response. + + Implementation note: + + In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL socket + options are used to set the TTL of outgoing unicast and multicast + packets. The IP_RECVTTL socket option is available on some platforms + to retrieve the IPv4 TTL of received packets with recvmsg(). + [RFC2292] specifies similar options for setting and retrieving the + IPv6 Hop Limit. + +2.6. Retransmissions + +In order to avoid synchronization, LLMNR queries and responses are +delayed by a time uniformly distributed between 0 and 200 ms. + +If the LLMNR query is not resolved within the timeout interval +(LLMNR_TIMEOUT), then a sender MAY repeat the transmission of a query in +order to assure themselves that the query has been received by a host +capable of responding to the query. Since a sender cannot know +beforehand whether it will receive no response, one response, or more +than one response to a query, it SHOULD wait for LLMNR_TIMEOUT in order +to collect all possible responses, rather than considering the query +answered after the first response is received. + +LLMNR implementations SHOULD dynamically estimate the timeout value +(LLMNR_TIMEOUT) on a per-interface basis, using the algorithms described +in [RFC2988], with a minimum timeout value of 300 ms. + +Repetition SHOULD NOT be attempted more than 3 times and SHOULD NOT be +repeated more often than once per second to reduce unnecessary network +traffic. + +2.7. DNS TTL + +The responder should use a pre-configured TTL value in the records +returned in the LLMNR query response. Due to the TTL minimalization +necessary when caching an RRset, all TTLs in an RRset MUST be set to the +same value. In the additional and authority section of the response the +responder includes the same records as a DNS server would insert in the +response to the unicast DNS query. + +3. Usage model + +LLMNR is a peer-to-peer name resolution protocol that is not intended as +a replacement for DNS. By default, LLMNR requests SHOULD be sent only @@ -481,57 +481,57 @@ Esibov, Aboba & Thaler Standards Track [Page 8] -INTERNET-DRAFT LLMNR 4 November 2002 +INTERNET-DRAFT LLMNR 22 March 2003 -interfaces, at all times. By default, LLMNR requests SHOULD be sent -only when no manual or automatic DNS configuration has been performed, -when DNS servers do not respond, or when they respond to a query with an -RCODE set to NXRRSET. +when no manual or automatic DNS configuration has been performed, when +DNS servers do not respond, or when they respond to a query with RCODE=3 +(Authoritative Name Error) or RCODE=0, and an empty answer section. -Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to -configure LLMNR on an interface. The LLMNR Enable Option, described in -[LLMNREnable], can be used to explicitly enable or disable use of LLMNR -on an interface. The LLMNR Enable Option does not determine whether or -in which order DNS itself is used for name resolution. The order in -which various name resolution mechanisms should be used can be specified -using the Name Service Search Option for DHCP, [RFC2937]. +As noted in [DNSPerf], even when DNS servers are configured, a +significant fraction of DNS queries do not receive a response, or result +in a negative responses due to missing inverse mappings or NS records +that point to nonexistent or inappropriate hosts. Given this, support +for LLMNR as a secondary name resolution mechanism has the potential to +result in a large number of inappropriate queries without the following +additional restrictions: -A home gateway may implement a DNS proxy and DHCPv4, but not DHCPv6 for -DNS configuration [DHCPv6DNS]. In such a circumstance, IPv6-only hosts -will not be configured with a DNS server. Where the DNS proxy does not -support dynamic client update over IPv6 or DHCPv6-based dynamic update -of the DNS proxy, the home gateway will not be able to dynamically -register the names of IPv6 hosts. As a result, the DNS proxy will -respond to AAAA RR queries sent over IPv4 or IPv6 with an RCODE of -NXRRSET. This prevents hosts from resolving the names of IPv6-only -hosts on the local link. In this situation, LLMNR over IPv6 can be used -for resolution of dynamic names. +[1] If a DNS query does not receive a response, prior to falling + back to LLMNR, a DNS query SHOULD be retransmitted at least + once. -3.1.1. Consistency of configuration +[2] A sender SHOULD send LLMNR queries only for names that are + either unqualified or exist within the default domain. -It is possible that DNS servers and/or DNS configuration mechanisms will -go in and out of service. In these circumstances, it is possible for -hosts within an administrative domain to be inconsistent in their DNS -configuration. +[3] A responder with both linklocal and routable addresses + MUST respond to LLMNR queries for A/AAAA RRs only with + routable address(es). This encourages use of routable + address(es) for establishment of new connections. -For example, where DHCP is used for configuring DNS servers, one or more -DHCP servers can go down. As a result, hosts configured prior to the -outage will be configured with a DNS server, while hosts configured -after the outage will not. +3.1. Unqualified names -Alternatively, it is possible for the DNS configuration mechanism to -continue functioning while configured DNS servers fail. +The same host MAY use LLMNR queries for the resolution of unqualified +host names, and conventional DNS queries for resolution of other DNS +names. -In order to minimize inconsistencies, the following practices are -recommended: +If a name is not qualified and does not end in a trailing dot, for the +purposes of LLMNR, the implicit search order is as follows: -Periodic retry - Unless unconfigured hosts periodically retry configuration, an - outage in the DNS configuration mechanism will result in hosts - continuing to prefer LLMNR even once the outage is repaired. Since - LLMNR only enables linklocal name resolution, this represents an - unnecessary degradation in capabilities. As a result, it is +[1] Request the name with the current domain appended. +[2] Request just the name. + +This is the behavior suggested by [RFC1536]. LLMNR uses this technique +to resolve unqualified host names. + +3.2. LLMNR configuration + +LLMNR usage MAY be configured manually or automatically on a per +interface basis. By default, LLMNR responders SHOULD be enabled on all +interfaces, at all times. + +Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is +possible for a dual stack host to be configured with the address of a +DNS server over IPv4, while remaining unconfigured with a DNS server @@ -541,40 +541,79 @@ Esibov, Aboba & Thaler Standards Track [Page 9] -INTERNET-DRAFT LLMNR 4 November 2002 +INTERNET-DRAFT LLMNR 22 March 2003 - recommended that hosts without a configured DNS server periodically - attempt to obtain DNS configuration. A default retry interval of - two (2) minutes is recommended. +suitable for use over IPv6. In these situations, a dual stack host will +send AAAA queries to the configured DNS server over IPv4. -DNS failover - By default, LLMNR queries are not sent unless DNS is not - configured, configured DNS servers have not responded, or respond - with an RCODE of NXRRSET. However, where all configured DNS - servers fail, LLMNR queries will be sent. +However, an IPv6-only host unconfigured with a DNS server suitable for +use over IPv6 will be unable to resolve names using DNS. Since +automatic IPv6 DNS configuration mechanisms such as [DHCPv6DNS] and +[DNSDisc] are not yet widely deployed, and not all DNS servers support +IPv6, lack of IPv6 DNS configuration may be a common problem in the +short term, and LLMNR may prove useful in enabling linklocal name +resolution over IPv6. -4. Sequence of events +For example, a home gateway may implement a DNS proxy and DHCPv4, but +not DHCPv6 for DNS configuration [DHCPv6DNS] or [DNSDisc]. In such a +circumstance, IPv6-only hosts will not be configured with a DNS server. +Where the DNS proxy does not support dynamic client update over IPv6 or +DHCPv6-based dynamic update of the DNS proxy, the home gateway will not +be able to dynamically register the names of IPv6 hosts. As a result, +the DNS proxy will respond to AAAA RR queries sent over IPv4 or IPv6 +with an authoritative name error (RCODE=3). This prevents hosts from +resolving the names of IPv6-only hosts on the local link. In this +situation, LLMNR over IPv6 can be used for resolution of dynamic names. -The sequence of events for LLMNR usage is as follows: +Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to +configure LLMNR on an interface. The LLMNR Enable Option, described in +[LLMNREnable], can be used to explicitly enable or disable use of LLMNR +on an interface. The LLMNR Enable Option does not determine whether or +in which order DNS itself is used for name resolution. The order in +which various name resolution mechanisms should be used can be specified +using the Name Service Search Option for DHCP [RFC2937]. -1. If a sender needs to resolve a query for a name "host.example.com", - then it sends a LLMNR query to the LINKLOCAL multicast address. +3.2.1. Configuration consistency -2. A responder responds to this query only if it is authoritative - for the domain name "host.example.com". The responder sends - a response to the sender via unicast over UDP. +It is possible that DNS configuration mechanisms will go in and out of +service. In these circumstances, it is possible for hosts within an +administrative domain to be inconsistent in their DNS configuration. -3. Upon the reception of the response, the sender verifies that the Hop - Limit field in IPv6 header or TTL field in IPv4 header (depending on - the protocol used) of the response is set to 255. The sender then - verifies compliance with the addressing requirements for IPv4, - described in [IPV4Link], and IPv6, described in [RFC2373]. If these - conditions are met, then the sender uses and caches the returned - response. If not, then the sender ignores the response and continues - waiting for the response. +For example, where DHCP is used for configuring DNS servers, one or more +DHCP servers can go down. As a result, hosts configured prior to the +outage will be configured with a DNS server, while hosts configured +after the outage will not. Alternatively, it is possible for the DNS +configuration mechanism to continue functioning while configured DNS +servers fail. -5. Conflict resolution +Unless unconfigured hosts periodically retry configuration, an outage in +the DNS configuration mechanism will result in hosts continuing to +prefer LLMNR even once the outage is repaired. Since LLMNR only enables +linklocal name resolution, this represents an unnecessary degradation in +capabilities. As a result, it is recommended that hosts without a + + + +Esibov, Aboba & Thaler Standards Track [Page 10] + + + + + +INTERNET-DRAFT LLMNR 22 March 2003 + + +configured DNS server periodically attempt to obtain DNS configuration. +A default retry interval of two (2) minutes is recommended. + +4. Conflict resolution + +The sender MUST anticipate receiving multiple replies to the same LLMNR +query, in the event that several LLMNR enabled computers receive the +query and respond with valid answers. When this occurs, the responses +MAY first be concatenated, and then treated in the same manner that +multiple RRs received from the same DNS server would, ordinarily. There are some scenarios when multiple responders MAY respond to the same query. There are other scenarios when only one responder may @@ -592,18 +631,6 @@ query and type of the query. For example it is expected that: Every responder that responds to a LLMNR query and/or dynamic update request AND includes a UNIQUE record in the response: - - - -Esibov, Aboba & Thaler Standards Track [Page 10] - - - - - -INTERNET-DRAFT LLMNR 4 November 2002 - - 1. MUST verify that there is no other host within the scope of the LLMNR query propagation that can return a resource record for the same name, type and class. @@ -615,17 +642,29 @@ interface, each interface should have its own independent LLMNR cache. For each UNIQUE resource record in a given interface's cache, the host MUST verify resource record uniqueness on that interface. To accomplish this, the host MUST send a dynamic LLMNR update request for each new -UNIQUE resource record. Format of the dynamic LLMNR update request is -identical to the format of the dynamic DNS update request specified in -[RFC2136]. Uniqueness verification is carried out when the host: +UNIQUE resource record. The format of the dynamic LLMNR update request +is identical that specified in [RFC2136]. By default, a host SHOULD be +configured to behave as though all RRs are UNIQUE. Uniqueness +verification is carried out when the host: - starts up or - - is configured to respond to the LLMNR queries on some interface or + - is configured to respond to the LLMNR queries on an interface or - is configured to respond to the LLMNR queries using additional UNIQUE resource records. -Below we describe the data to be specified in the dynamic update -request: + + + +Esibov, Aboba & Thaler Standards Track [Page 11] + + + + + +INTERNET-DRAFT LLMNR 22 March 2003 + + +The data to be specified in the dynamic update request is as follows: Header section contains values according to [RFC2136]. @@ -638,9 +677,9 @@ Zone section Prerequisite section This section MUST contain a record set whose semantics are - described in [RFC2136], Section 2.4.3 "RRset Does Not Exist", - requesting that RRs with the NAME and TYPE of the UNIQUE record do - not exist. + described in [RFC2136], Section 2.4.3 "RRset Does Not Exist" + (NXRRSET), requesting that RRs with the NAME and TYPE of the UNIQUE + record do not exist. Update section This section MUST be left empty. @@ -653,17 +692,6 @@ that requests that the UNIQUE resource record set does not exist, the host MUST respond via unicast with the YXRRSET error, according to the rules described in Section 3 of [RFC2136]. - - -Esibov, Aboba & Thaler Standards Track [Page 11] - - - - - -INTERNET-DRAFT LLMNR 4 November 2002 - - After the client receives an YXRRSET response to its dynamic update request stating that a UNIQUE resource record does not exist, the host MUST check whether the response arrived on another interface. If this is @@ -675,18 +703,30 @@ update requests. Note that this name conflict detection mechanism doesn't prevent name conflicts when previously partitioned segments are connected by a bridge. In such a situation, name conflicts are detected when a sender -receives more than one response to its LLMNR query. In this case, the -sender sends the first response that it received to all responders that -responded to this query except the first one, using unicast. A host that -receives a query response containing a UNIQUE resource record that it -owns, even if it didn't send such a query, MUST verify that no other -host within the LLMNR scope is authoritative for the same name, using -the dynamic LLMNR update request mechanism described above. +receives more than one response to its LLMNR query. -Based on the result, the host detects whether there is a name conflict -and acts as described above. +In this case, the sender sends the first response that it received to +all responders that responded to this query except the first one, using +unicast. A host that receives a query response containing a UNIQUE +resource record that it owns, even if it didn't send such a query, MUST +verify that no other host within the LLMNR scope is authoritative for +the same name, using the dynamic LLMNR update request mechanism +described above. Based on the result, the host detects whether there is -5.1. Considerations for Multiple Interfaces + + +Esibov, Aboba & Thaler Standards Track [Page 12] + + + + + +INTERNET-DRAFT LLMNR 22 March 2003 + + +a name conflict and acts as described above. + +4.1. Considerations for Multiple Interfaces A multi-homed host may elect to configure LLMNR on only one of its active interfaces. In many situations this will be adequate. However, @@ -696,7 +736,7 @@ Implementers who are not planning to support LLMNR on multiple interfaces simultaneously may skip this section. A multi-homed host checks the uniqueness of UNIQUE records as described -in Section 5. The situation is illustrated in figure 1 below: +in Section 4. The situation is illustrated in figure 1. ---------- ---------- | | | | @@ -711,24 +751,11 @@ respond with a host RR for "myhost" on the interface on the right (see Figure 1). The multi-homed host may, however, be configured to use the "myhost" name on the interface on the left. - - - - -Esibov, Aboba & Thaler Standards Track [Page 12] - - - - - -INTERNET-DRAFT LLMNR 4 November 2002 - - Since names are only unique per-link, hosts on different links could be using the same name. If an LLMNR client sends requests over multiple interfaces, and receives replies from more than one, the result returned to the client is defined by the implementation. The situation is -illustrated in figure 2 below. +illustrated in figure 2. ---------- ---------- | | | | @@ -745,11 +772,23 @@ both interfaces. Host myhost will then forward a response from the first responder to the second responder, who will attempt to verify the uniqueness of host RR for its name, but will not discover a conflict, since the conflicting + + + +Esibov, Aboba & Thaler Standards Track [Page 13] + + + + + +INTERNET-DRAFT LLMNR 22 March 2003 + + host resides on a different link. Therefore it will continue using its name. Indeed, host myhost cannot distinguish between the situation shown in -Figure 2, and that shown in Figure 3 where no conflict exists: +Figure 2, and that shown in Figure 3 where no conflict exists. [A] | | @@ -766,24 +805,12 @@ multi-homed host is connected to two different networks with separated name spaces. It is not the intent of this document to address the issue of uniqueness of names within DNS. -5.2. API issues +4.2. API issues [RFC2553] provides an API which can partially solve the name ambiguity problem for applications written to use this API, since the sockaddr_in6 structure exposes the scope within which each scoped address exists, and this structure can be used for both IPv4 (using v4-mapped IPv6 - - - -Esibov, Aboba & Thaler Standards Track [Page 13] - - - - - -INTERNET-DRAFT LLMNR 4 November 2002 - - addresses) and IPv6 addresses. Following the example in Figure 2, an application on 'myhost' issues the @@ -798,7 +825,7 @@ the address. Of course, to the application, Figures 2 and 3 are still indistinguishable, but this API allows the application to communicate successfully with any address in the list. -6. Security Considerations +5. Security Considerations LLMNR is by nature a peer to peer name resolution protocol. It is therefore inherently more vulnerable than DNS, since existing DNS @@ -806,6 +833,17 @@ security mechanisms are difficult to apply to LLMNR and an attacker only needs to be misconfigured to answer an LLMNR query with incorrect information. + + +Esibov, Aboba & Thaler Standards Track [Page 14] + + + + + +INTERNET-DRAFT LLMNR 22 March 2003 + + In order to address the security vulnerabilities, the following mechanisms are contemplated: @@ -819,7 +857,7 @@ mechanisms are contemplated: These techniques are described in the following sections. -6.1. Scope restriction +5.1. Scope restriction With LLMNR it is possible that hosts will allocate conflicting names for a period of time, or that attackers will attempt to deny service to @@ -832,18 +870,6 @@ senders. In all received responses, the Hop Limit field in IPv6 and the TTL field in IPv4 are verified to contain 255, the maximum legal value. Since routers decrement the Hop Limit on all packets they forward, received packets containing a Hop Limit of 255 must have originated from - - - -Esibov, Aboba & Thaler Standards Track [Page 14] - - - - - -INTERNET-DRAFT LLMNR 4 November 2002 - - a neighbor. While restricting ignoring packets received from off-link senders @@ -855,16 +881,28 @@ access to the home network, while wireless attackers may reside outside the home. Link-layer security can be of assistance against these threats if it is available. -6.2. Usage restriction +5.2. Usage restriction + +As noted in Section 3, LLMNR is intended for usage in a limited set of +scenarios. + +If an interface has been configured via any automatic configuration +mechanism which is able to supply DNS configuration information, then +LLMNR SHOULD NOT be used as the primary name resolution mechanism on +that interface, although it MAY be used as a secondary mechanism. + + + + + +Esibov, Aboba & Thaler Standards Track [Page 15] + + + + + +INTERNET-DRAFT LLMNR 22 March 2003 -As noted in Section 3.1, LLMNR is intended for usage in scenarios where -a DNS server is not configured, DNS servers do not respond to queries or -respond with RCODE set to NXRRSET. If an interface has been configured -via any automatic configuration mechanism which is able to supply DNS -configuration information, then LLMNR MUST NOT be used as the primary -name resolution mechanism on that interface, although it MAY be used as -a secondary mechanism when DNS servers do not respond to queries, or -respond with RCODE set to NXRRSET. Note: enabling LLMNR for use in situations where a DNS server has been configured will result in upgraded hosts changing their default behavior @@ -889,22 +927,7 @@ cache, once poisoned, would take precedence over the DNS cache, eliminating the benefits of cache separation. As a result, LLMNR is best thought of as a secondary name resolution mechanism. - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 15] - - - - - -INTERNET-DRAFT LLMNR 4 November 2002 - - -6.3. Cache and port separation +5.3. Cache and port separation In order to prevent responses to LLMNR queries from polluting the DNS cache, LLMNR implementations MUST use a distinct, isolated cache for @@ -916,7 +939,7 @@ decreases reliance on it. LLMNR operates on a separate port from DNS, reducing the likelihood that a DNS server will unintentionally respond to an LLMNR query. -6.4. Authentication +5.4. Authentication LLMNR does not require use of DNSSEC, and as a result, responses to LLMNR queries MAY NOT be authenticated. If authentication is desired, @@ -926,14 +949,31 @@ small network without a certificate authority, this can be most easily accomplished through configuration of a group pre-shared key for trusted hosts. -7. IANA Considerations + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 16] + + + + + +INTERNET-DRAFT LLMNR 22 March 2003 + + +6. IANA Considerations This specification does not create any new name spaces for IANA -administration. LLMNR requires allocation of a port. LLMNR utilizes a -link scope multicast IPv4 address (224.0.0.251) that has been previously -allocated to LLMNR by IANA. +administration. LLMNR requires allocation of a port for both TCP and +UDP. LLMNR utilizes a link scope multicast IPv4 address (224.0.0.251) +that has been previously allocated to LLMNR by IANA. It also requires +allocation of a link scope multicast IPv6 address, for use with queries +of types other than A/AAAA. -8. Normative References +7. Normative References [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, November 1987. @@ -951,19 +991,6 @@ allocated to LLMNR by IANA. [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998. - - - - -Esibov, Aboba & Thaler Standards Track [Page 16] - - - - - -INTERNET-DRAFT LLMNR 4 November 2002 - - [RFC2373] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", RFC 2373, July 1998. @@ -973,19 +1000,30 @@ INTERNET-DRAFT LLMNR 4 November 2002 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. -[IPV4Link] Cheshire, S., Aboba, B., "Dynamic Configuration of IPv4 - Link-Local Addresses", Internet draft (work in progress), - draft-ietf-zeroconf-ipv4-linklocal-05.txt, November 2001. +[RFC2988] Paxson, V., Allman, M., "Computing TCP's Retransmission + Timer", RFC 2988, November 2000. -[LLMNREnable] Guttman, E., "DHCP LLMNR Enable Option", Internet draft - (work in progress), draft-guttman-mdns-enable-02.txt, - April 2002. +[IPV4Link] Cheshire, S., Aboba, B.,Guttman, E., "Dynamic + Configuration of IPv4 Link-Local Addresses", Internet + draft (work in progress), draft-ietf-zeroconf- + ipv4-linklocal-07.txt, August 2002. -9. Informative References +8. Informative References [RFC1536] Kumar, A., et. al. "DNS Implementation Errors and Suggested Fixes", RFC 1536, October 1993. + + +Esibov, Aboba & Thaler Standards Track [Page 17] + + + + + +INTERNET-DRAFT LLMNR 22 March 2003 + + [RFC2292] Stevens, W., Thomas, M., "Advanced Sockets API for IPv6", RFC 2292, February 1998. @@ -1000,29 +1038,26 @@ INTERNET-DRAFT LLMNR 4 November 2002 [RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC 2937, September 2000. -[DHCPv6DNS] Droms, R., Narten, T., and Aboba, B. "Using DHCPv6 for - DNS Configuration in Hosts", draft-droms-dnsconfig- - dhcpv6-01.txt, Internet draft (work in progress), March - 2002. +[DHCPv6DNS] Droms, R., "A Guide to Implementing Stateless DHCPv6 + Service", Internet draft (work in progress), draft-droms- + dhcpv6-stateless-guide-01.txt, October 2002. -[DNSDisc] Thaler, D., Hagino, I., "IPv6 Stateless DNS Discovery", - Internet draft (work in progress), draft-ietf-ipngwg-dns- - discovery-03.txt, November 2001. +[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness + of Caching", IEEE/ACM Transactions on Networking, Volume + 10, Number 5, pp. 589, October 2002. -[NodeInfo] Crawford, Matt, "IPv6 Node Information Queries", Internet +[DNSDisc] Durand, A., Hagino, I., Thaler, D., "Well known site + local unicast addresses to communicate with recursive DNS + servers", Internet draft (work in progress), draft-ietf- + ipv6-dns-discovery-07.txt, October 2002. + +[LLMNREnable] Guttman, E., "DHCP LLMNR Enable Option", Internet draft + (work in progress), draft-guttman-mdns-enable-02.txt, + April 2002. + +[NodeInfo] Crawford, M., "IPv6 Node Information Queries", Internet draft (work in progress), draft-ietf-ipn-gwg-icmp-name- - lookups-08.txt, July 2001. - - - -Esibov, Aboba & Thaler Standards Track [Page 17] - - - - - -INTERNET-DRAFT LLMNR 4 November 2002 - + lookups-09.txt, May 2002. Acknowledgments @@ -1035,6 +1070,20 @@ Austein, James Gilroy, Olafur Gudmundsson, Erik Guttman, Myron Hattig, Thomas Narten, Erik Nordmark, Sander Van-Valkenburg, Tomohide Nagashima, Brian Zill, Keith Moore and Markku Savela. + + + + + +Esibov, Aboba & Thaler Standards Track [Page 18] + + + + + +INTERNET-DRAFT LLMNR 22 March 2003 + + Authors' Addresses Levon Esibov @@ -1060,30 +1109,6 @@ Redmond, WA 98052 Phone: +1 425 703 8835 EMail: dthaler@microsoft.com - - - - - - - - - - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 18] - - - - - -INTERNET-DRAFT LLMNR 4 November 2002 - - Intellectual Property Statement The IETF takes no position regarding the validity or scope of any @@ -1106,9 +1131,22 @@ which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. + + + + +Esibov, Aboba & Thaler Standards Track [Page 19] + + + + + +INTERNET-DRAFT LLMNR 22 March 2003 + + Full Copyright Statement -Copyright (C) The Internet Society (2002). All Rights Reserved. +Copyright (C) The Internet Society (2003). 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 @@ -1129,48 +1167,10 @@ 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." - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 19] - - - - - -INTERNET-DRAFT LLMNR 4 November 2002 - - Expiration Date -This memo is filed as , and expires May -22, 2003. - - - - - - - - - - - - - - - - - - - - - - - +This memo is filed as , and expires +October 22, 2003.