]> git.ipfire.org Git - thirdparty/bind9.git/commitdiff
new draft
authorMark Andrews <marka@isc.org>
Thu, 4 Dec 2003 22:42:48 +0000 (22:42 +0000)
committerMark Andrews <marka@isc.org>
Thu, 4 Dec 2003 22:42:48 +0000 (22:42 +0000)
doc/draft/draft-ietf-dnsext-nsec-rdata-01.txt [moved from doc/draft/draft-ietf-dnsext-nsec-rdata-00.txt with 70% similarity]

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 701ffcb0fb23464cff47347afd6db14b1a330099..0a7a56471018bd0b05bb23b1a81b3f826fc602b0 100644 (file)
@@ -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 ) +
 
-Schlyter                  Expires May 26, 2004                  [Page 4]
+   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
 
-Internet-Draft          DNSSEC NSEC RDATA Format           November 2003
 
 
-   the bitmap MUST be removed. Blocks is presented in increasing
-   numerical order.
+Schlyter                  Expires June 3, 2004                  [Page 4]
 
+Internet-Draft          DNSSEC NSEC RDATA Format           December 2003
 
-       "|" denotes concatenation
 
-       NSEC RDATA = ( Window Block # | Bitmap Length | Bitmap ) +
+   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.
 
-   A zone MUST NOT generate an NSEC RR for any domain name that only
-   holds glue records.
+   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.
 
-   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]
 
+Internet-Draft          DNSSEC NSEC RDATA Format           December 2003
 
-Schlyter                  Expires May 26, 2004                  [Page 5]
 
-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]