diff --git a/doc/draft/draft-ietf-dnsext-nsec-rdata-00.txt b/doc/draft/draft-ietf-dnsext-nsec-rdata-01.txt similarity index 70% rename from doc/draft/draft-ietf-dnsext-nsec-rdata-00.txt rename to doc/draft/draft-ietf-dnsext-nsec-rdata-01.txt index 701ffcb0fb..0a7a564710 100644 --- a/doc/draft/draft-ietf-dnsext-nsec-rdata-00.txt +++ b/doc/draft/draft-ietf-dnsext-nsec-rdata-01.txt @@ -1,11 +1,14 @@ + + DNS Extensions Working Group J. Schlyter, Ed. -Internet-Draft November 26, 2003 -Updates: RFC 2535, RFC TCR (if approved) -Expires: May 26, 2004 +Internet-Draft December 4, 2003 +Updates: RFC 2535, RFC TCR (if +approved) +Expires: June 3, 2004 DNSSEC NSEC RDATA Format - draft-ietf-dnsext-nsec-rdata-00.txt + draft-ietf-dnsext-nsec-rdata-01.txt Status of this Memo @@ -27,7 +30,7 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on May 26, 2004. + This Internet-Draft will expire on June 3, 2004. Copyright Notice @@ -49,9 +52,9 @@ Abstract -Schlyter Expires May 26, 2004 [Page 1] +Schlyter Expires June 3, 2004 [Page 1] -Internet-Draft DNSSEC NSEC RDATA Format November 2003 +Internet-Draft DNSSEC NSEC RDATA Format December 2003 Table of Contents @@ -67,8 +70,8 @@ Table of Contents 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . 6 Normative References . . . . . . . . . . . . . . . . . . . . 6 - Informational References . . . . . . . . . . . . . . . . . . 6 - Author's Address . . . . . . . . . . . . . . . . . . . . . . 6 + Informational References . . . . . . . . . . . . . . . . . . 7 + Author's Address . . . . . . . . . . . . . . . . . . . . . . 7 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . 8 @@ -105,14 +108,14 @@ Table of Contents -Schlyter Expires May 26, 2004 [Page 2] +Schlyter Expires June 3, 2004 [Page 2] -Internet-Draft DNSSEC NSEC RDATA Format November 2003 +Internet-Draft DNSSEC NSEC RDATA Format December 2003 1. Introduction - The NSEC [3] Resource Record (RR) is used for authenticated proof of + The NSEC [5] Resource Record (RR) is used for authenticated proof of the non-existence of DNS owner names and types. The RDATA format for the NSEC RR, as described in RFC 2535 [2], had a limitation in that, without using a yet undefined extension mechanism, the the RDATA @@ -136,13 +139,13 @@ Internet-Draft DNSSEC NSEC RDATA Format November 2003 For convenience and completeness this document presents the syntax and semantics for the NSEC RR based on the specification in RFC 2535 - [2] and as updated by RFC TCR [3], thereby not introducing changes + [2] and as updated by RFC TCR [5], thereby not introducing changes except for the syntax of the type bit map. [Editors note: this is the text that is to be copied into draft-ietf-dnssec-dnssec-records] - This document updates RFC 2535 [2] and RFC TCR [3]. + This document updates RFC 2535 [2] and RFC TCR [5]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this @@ -161,14 +164,15 @@ Internet-Draft DNSSEC NSEC RDATA Format November 2003 -Schlyter Expires May 26, 2004 [Page 3] +Schlyter Expires June 3, 2004 [Page 3] -Internet-Draft DNSSEC NSEC RDATA Format November 2003 +Internet-Draft DNSSEC NSEC RDATA Format December 2003 The type value for the NSEC RR is 47. - The NSEC RR is class independent. + The NSEC RR RDATA format is class independent and defined for all + classes. The NSEC RR has no special TTL requirements. @@ -192,50 +196,50 @@ Internet-Draft DNSSEC NSEC RDATA Format November 2003 of the Next Domain Name field in the last NSEC record in the zone is the name of the zone apex (the owner name of the zone's SOA RR). - A sender MUST NOT use DNS name compression on the Next Domain Name - field when transmitting an NSEC RR. A receiver which receives an - NSEC RR containing a compressed Next Domain Name field SHOULD - decompress the field value. - - Owner names of RRsets not authoritative for the given zone (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. - 2.1.2 The List of Type Bit Map(s) Field - The List of Type Bit Map(s) Field identifies the RRset types which - exist at the NSEC RR's owner name and uses a simple windowed bitmap - encoding. It is a logical extension to the encoding used by NXT [2] - and is designed to be both efficient and easy to implement without - errors. + The RR type space is split into 256 window blocks, each representing + the low-order 8 bits of the 16-bit RR type space. Each block that has + at least one active RR type is encoded using a single octet window + number (from 0 to 255), a single octet bitmap length (from 1 to 32) + indicating the number of octets used for the window block's bitmap, + and up to 32 octets (256 bits) of bitmap. - The type space is split into into 256 window blocks. Each block that - has at least one active type is encoded using a window octet (from 0 - to 255), a bitmap length octet (from 1 to 32) and a bitmap (covering - up to 256 type codes) in network bit order (similar to NXT). Blocks - with no types present MUST NOT be included. Trailing zero octets in + Blocks are present in the NSEC RR RDATA in increasing numerical + order. + + "|" denotes concatenation + + Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) + + + Each bitmap encodes the low-order 8 bits of RR types within the + window block, in network bit order. The first bit is bit 0. For + window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds + to RR type 2 (NS), and so forth. For window block 1, bit 1 + corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to -Schlyter Expires May 26, 2004 [Page 4] +Schlyter Expires June 3, 2004 [Page 4] -Internet-Draft DNSSEC NSEC RDATA Format November 2003 +Internet-Draft DNSSEC NSEC RDATA Format December 2003 - the bitmap MUST be removed. Blocks is presented in increasing - numerical order. + 1, it indicates that an RRset of that type is present for the NSEC + RR's owner name. If a bit is set to 0, it indicates that no RRset of + that type is present for the NSEC RR's owner name. + Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [3] + (section 3.1) or within the range reserved for assignment only to + QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in + zone data. If encountered, they must be ignored upon reading. - "|" denotes concatenation - - NSEC RDATA = ( Window Block # | Bitmap Length | Bitmap ) + - - A zone MUST NOT generate an NSEC RR for any domain name that only - holds glue records. - - Bits representing pseudo-RR types MUST be set to 0, since they do not - appear in zone data. If encountered, they must be ignored upon - reading. + Blocks with no types present MUST NOT be included. Trailing zero + octets in the bitmap MUST be omitted. The length of each block's + bitmap is determined by the type code with the largest numerical + value, within that block, among the set of RR types present at the + NSEC RR's owner name. Trailing zero octets not specified MUST be + interpretted as zero octets. 2.1.3 Inclusion of Wildcard Names in NSEC RDATA @@ -252,9 +256,9 @@ Internet-Draft DNSSEC NSEC RDATA Format November 2003 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. + The List of Type Bit Map(s) Field is represented as a sequence of RR + type mnemonics. When the mnemonic is not known, the TYPE + representation as described in RFC 3597 [4] (section 5) MUST be used. 2.3 NSEC RR Example @@ -262,21 +266,31 @@ Internet-Draft DNSSEC NSEC RDATA Format November 2003 alfa.example.com. and identifies the next authoritative name after alfa.example.com. - alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC + alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC TYPE1234 The first four text fields specify the name, TTL, Class, and RR type (NSEC). The entry host.example.com. is the next authoritative name after alfa.example.com. in canonical order. The A, MX, RRSIG and NSEC - mnemonics indicate there are A, MX, RRSIG and NSEC RRsets associated - with the name alfa.example.com. + mnemonics indicate there are A, MX, RRSIG, NSEC and TYPE1234 RRsets + associated with the name alfa.example.com. +Schlyter Expires June 3, 2004 [Page 5] -Schlyter Expires May 26, 2004 [Page 5] +Internet-Draft DNSSEC NSEC RDATA Format December 2003 -Internet-Draft DNSSEC NSEC RDATA Format November 2003 + The RDATA section of the NSEC RR above would be encoded as: + + 0x04 'h' 'o' 's' 't' + 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' + 0x03 'c' 'o' 'm' 0x00 + 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 + 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x20 Assuming that the resolver can authenticate this NSEC record, it could be used to prove that beta.example.com does not exist, or could @@ -288,7 +302,7 @@ Internet-Draft DNSSEC NSEC RDATA Format November 2003 This document introduces no new IANA considerations, because all of the protocol parameters used in this document have already been - assigned by RFC TCR [3]. + assigned by RFC TCR [5]. 4. Security Considerations @@ -303,16 +317,30 @@ Normative References [2] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. - [3] Weiler, S., "Legacy Resolver Compatibility for Delegation + [3] Eastlake, D., Brunner-Williams, E. and B. Manning, "Domain Name + System (DNS) IANA Considerations", BCP 42, RFC 2929, September + 2000. + + [4] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) + Types", RFC 3597, September 2003. + + [5] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work in progress), October 2003. Informational References - [4] Mockapetris, P., "Domain names - concepts and facilities", STD + + +Schlyter Expires June 3, 2004 [Page 6] + +Internet-Draft DNSSEC NSEC RDATA Format December 2003 + + + [6] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. - [5] Mockapetris, P., "Domain names - implementation and + [7] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. @@ -325,15 +353,6 @@ Author's Address EMail: jakob@schlyter.se - - - - -Schlyter Expires May 26, 2004 [Page 6] - -Internet-Draft DNSSEC NSEC RDATA Format November 2003 - - Appendix A. Acknowledgements The encoding described in this document was initially proposed by @@ -369,25 +388,9 @@ Appendix A. Acknowledgements +Schlyter Expires June 3, 2004 [Page 7] - - - - - - - - - - - - - - - -Schlyter Expires May 26, 2004 [Page 7] - -Internet-Draft DNSSEC NSEC RDATA Format November 2003 +Internet-Draft DNSSEC NSEC RDATA Format December 2003 Intellectual Property Statement @@ -441,9 +444,9 @@ Full Copyright Statement -Schlyter Expires May 26, 2004 [Page 8] +Schlyter Expires June 3, 2004 [Page 8] -Internet-Draft DNSSEC NSEC RDATA Format November 2003 +Internet-Draft DNSSEC NSEC RDATA Format December 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF @@ -497,5 +500,5 @@ Acknowledgment -Schlyter Expires May 26, 2004 [Page 9] +Schlyter Expires June 3, 2004 [Page 9]