+++ /dev/null
-
-
-DNS Extensions Working Group J. Schlyter, Ed.
-Internet-Draft March 11, 2004
-Updates: RFC 2535, RFC TCR
-Expires: September 9, 2004
-
-
- DNSSEC NSEC RDATA Format
- draft-ietf-dnsext-nsec-rdata-05.txt
-
-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 September 9, 2004.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
- This document redefines the wire format of the "Type Bit Map" field
- in the NSEC resource record RDATA format to cover the full RR type
- space.
-
-
-
-
-
-
-
-
-
-
-
-Schlyter Expires September 9, 2004 [Page 1]
-
-Internet-Draft DNSSEC NSEC RDATA Format March 2004
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 3
- 2.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . . 4
- 2.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 4
- 2.1.2 The List of Type Bit Map(s) Field . . . . . . . . . . . . . 4
- 2.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . . . . 5
- 2.2 The NSEC RR Presentation Format . . . . . . . . . . . . . . 5
- 2.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . . 6
- 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6
- 4. Security Considerations . . . . . . . . . . . . . . . . . . 6
- Normative References . . . . . . . . . . . . . . . . . . . . 6
- Informational References . . . . . . . . . . . . . . . . . . 7
- Author's Address . . . . . . . . . . . . . . . . . . . . . . 7
- A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
- Intellectual Property and Copyright Statements . . . . . . . 8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter Expires September 9, 2004 [Page 2]
-
-Internet-Draft DNSSEC NSEC RDATA Format March 2004
-
-
-1. Introduction
-
- The NSEC [6] Resource Record (RR) is used for authenticated proof of
- the non-existence of DNS owner names and types. The NSEC RR is based
- on the NXT RR as described in RFC 2535 [3], and is similar except for
- the name and typecode. The RDATA format for the NXT RR had a
- limitation in that, without using a yet undefined extension
- mechanism, the the RDATA could only carry information about the
- existence of the first 127 types.
-
- To prevent the introduction of an extension mechanism into a deployed
- base of DNSSEC aware servers and resolvers, once the first 127 type
- codes are allocated, this document redefines the wire format of the
- "Type Bit Map" field in the NSEC RDATA to cover the full RR type
- space.
-
- This document introduces a new format for the type bit map. The
- properties of the type bit map format are that it can cover the full
- possible range of typecodes, that it is relatively economic in the
- amount of space it uses for the common case of a few types with an
- owner name, that it can represent owner names with all possible types
- present in packets of approximately 8.5 kilobytes and that the
- representation is simple to implement. Efficient searching of the
- type bitmap for the presence of certain types is not a requirement.
-
- For convenience and completeness this document presents the syntax
- and semantics for the NSEC RR based on the specification in RFC 2535
- [3] and as updated by RFC TCR [6], thereby not introducing changes
- except for the syntax of the type bit map.
-
- This document updates RFC 2535 [3] and RFC TCR [6].
-
- 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 [1].
-
-2. The NSEC Resource Record
-
- The NSEC resource record lists two separate things: the owner name of
- the next RRset in the canonical ordering of the zone, and the set of
- RR types present at the NSEC RR's owner name. The complete set of
- NSEC RRs in a zone both indicate which RRsets exist in a zone and
- also form a chain of owner names in the zone. This information is
- used to provide authenticated denial of existence for DNS data, as
- described in RFC 2535 [3].
-
- The type value for the NSEC RR is 47.
-
-
-
-
-Schlyter Expires September 9, 2004 [Page 3]
-
-Internet-Draft DNSSEC NSEC RDATA Format March 2004
-
-
- The NSEC RR RDATA format is class independent and defined for all
- classes.
-
- The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
- field. This is in the spirit of negative caching [2].
-
-2.1 NSEC RDATA Wire Format
-
- The RDATA of the NSEC 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 /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / List of Type Bit Map(s) /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-2.1.1 The Next Domain Name Field
-
- The Next Domain Name field contains the owner name of the next RR in
- the canonical ordering of the zone. The value 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 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.
-
- Blocks are present in the NSEC RR RDATA in increasing numerical
- order.
-
- "|" denotes concatenation
-
-
-
-Schlyter Expires September 9, 2004 [Page 4]
-
-Internet-Draft DNSSEC NSEC RDATA Format March 2004
-
-
- 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
- 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.
-
- Since bit 0 in window block 0 refers to the non-existing RR type 0,
- it MUST be set to 0. After verification, the validator MUST ignore
- the value of bit 0 in window block 0.
-
- Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [4]
- (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.
-
- 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
-
- 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 NSEC RRs. Wildcard owner names
- appear in the Next Domain Name field without any wildcard expansion.
- RFC 2535 [3] describes the impact of wildcards on authenticated
- denial of existence.
-
-2.2 The NSEC 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 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 [5] (section 5) MUST be used.
-
-
-
-
-
-
-Schlyter Expires September 9, 2004 [Page 5]
-
-Internet-Draft DNSSEC NSEC RDATA Format March 2004
-
-
-2.3 NSEC RR Example
-
- The following NSEC RR identifies the RRsets associated with
- 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 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, NSEC
- and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC and
- TYPE1234 RRsets associated with the name alfa.example.com.
-
- 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
- be used to prove there is no AAAA record associated with
- alfa.example.com. Authenticated denial of existence is discussed in
- RFC 2535 [3].
-
-3. IANA Considerations
-
- This document introduces no new IANA considerations, because all of
- the protocol parameters used in this document have already been
- assigned by RFC TCR [6].
-
-4. Security Considerations
-
- The update of the RDATA format and encoding does not affect the
- security of the use of NSEC RRs.
-
-Normative References
-
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [2] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
-
-
-
-Schlyter Expires September 9, 2004 [Page 6]
-
-Internet-Draft DNSSEC NSEC RDATA Format March 2004
-
-
- 2308, March 1998.
-
- [3] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [4] Eastlake, D., Brunner-Williams, E. and B. Manning, "Domain Name
- System (DNS) IANA Considerations", BCP 42, RFC 2929, September
- 2000.
-
- [5] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
- Types", RFC 3597, September 2003.
-
- [6] Weiler, S., "Legacy Resolver Compatibility for Delegation
- Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work
- in progress), October 2003.
-
-Informational References
-
- [7] Mockapetris, P., "Domain names - concepts and facilities", STD
- 13, RFC 1034, November 1987.
-
- [8] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
-
-Author's Address
-
- Jakob Schlyter (editor)
- Karl Gustavsgatan 15
- Goteborg SE-411 25
- Sweden
-
- EMail: jakob@schlyter.se
-
-Appendix A. Acknowledgements
-
- The encoding described in this document was initially proposed by
- Mark Andrews. Other encodings where proposed by David Blacka and
- Michael Graff.
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter Expires September 9, 2004 [Page 7]
-
-Internet-Draft DNSSEC NSEC RDATA Format March 2004
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2004). 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 assignees.
-
- 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
-
-
-
-Schlyter Expires September 9, 2004 [Page 8]
-
-Internet-Draft DNSSEC NSEC RDATA Format March 2004
-
-
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter Expires September 9, 2004 [Page 9]
-
--- /dev/null
+\r
+DNS Extensions Working Group J. Schlyter, Ed.\r
+Internet-Draft May 10, 2004\r
+Updates: RFC 2535, RFC TCR (if approved)\r
+Expires: November 8, 2004\r
+\r
+\r
+ DNSSEC NSEC RDATA Format\r
+ draft-ietf-dnsext-nsec-rdata-06.txt\r
+\r
+Status of this Memo\r
+\r
+ This document is an Internet-Draft and is in full conformance with\r
+ all provisions of Section 10 of RFC2026.\r
+\r
+ Internet-Drafts are working documents of the Internet Engineering\r
+ Task Force (IETF), its areas, and its working groups. Note that other\r
+ groups may also distribute working documents as Internet-Drafts.\r
+\r
+ Internet-Drafts are draft documents valid for a maximum of six months\r
+ and may be updated, replaced, or obsoleted by other documents at any\r
+ time. It is inappropriate to use Internet-Drafts as reference\r
+ material or to cite them other than as "work in progress."\r
+\r
+ The list of current Internet-Drafts can be accessed at http://\r
+ www.ietf.org/ietf/1id-abstracts.txt.\r
+\r
+ The list of Internet-Draft Shadow Directories can be accessed at\r
+ http://www.ietf.org/shadow.html.\r
+\r
+ This Internet-Draft will expire on November 8, 2004.\r
+\r
+Copyright Notice\r
+\r
+ Copyright (C) The Internet Society (2004). All Rights Reserved.\r
+\r
+Abstract\r
+\r
+ This document redefines the wire format of the "Type Bit Map" field\r
+ in the NSEC resource record RDATA format to cover the full RR type\r
+ space.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Schlyter Expires November 8, 2004 [Page 1]\r
+\r
+Internet-Draft DNSSEC NSEC RDATA Format May 2004\r
+\r
+\r
+Table of Contents\r
+\r
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3\r
+ 2. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 3\r
+ 2.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . . 4\r
+ 2.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 4\r
+ 2.1.2 The List of Type Bit Map(s) Field . . . . . . . . . . . . . 4\r
+ 2.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . . . . 5\r
+ 2.2 The NSEC RR Presentation Format . . . . . . . . . . . . . . 5\r
+ 2.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . . 5\r
+ 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6\r
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . 6\r
+ Normative References . . . . . . . . . . . . . . . . . . . . 6\r
+ Informational References . . . . . . . . . . . . . . . . . . 7\r
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . 7\r
+ A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7\r
+ Intellectual Property and Copyright Statements . . . . . . . 8\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Schlyter Expires November 8, 2004 [Page 2]\r
+\r
+Internet-Draft DNSSEC NSEC RDATA Format May 2004\r
+\r
+\r
+1. Introduction\r
+\r
+ The NSEC [5] Resource Record (RR) is used for authenticated proof of\r
+ the non-existence of DNS owner names and types. The NSEC RR is based\r
+ on the NXT RR as described in RFC 2535 [2], and is similar except for\r
+ the name and typecode. The RDATA format for the NXT RR has the\r
+ limitation in that the RDATA could only carry information about the\r
+ existence of the first 127 types. RFC 2535 did reserve a bit to\r
+ specify an extension mechanism, but the mechanism was never actually\r
+ defined.\r
+\r
+ In order to avoid the need to develop an extension mechanism into a\r
+ deployed base of DNSSEC aware servers and resolvers once the first\r
+ 127 type codes are allocated, this document redefines the wire format\r
+ of the "Type Bit Map" field in the NSEC RDATA to cover the full RR\r
+ type space.\r
+\r
+ This document introduces a new format for the type bit map. The\r
+ properties of the type bit map format are that it can cover the full\r
+ possible range of typecodes, that it is relatively economical in the\r
+ amount of space it uses for the common case of a few types with an\r
+ owner name, that it can represent owner names with all possible types\r
+ present in packets of approximately 8.5 kilobytes and that the\r
+ representation is simple to implement. Efficient searching of the\r
+ type bitmap for the presence of certain types is not a requirement.\r
+\r
+ For convenience and completeness this document presents the syntax\r
+ and semantics for the NSEC RR based on the specification in RFC 2535\r
+ [2] and as updated by RFC TCR [5], thereby not introducing changes\r
+ except for the syntax of the type bit map.\r
+\r
+ This document updates RFC 2535 [2] and RFC TCR [5].\r
+\r
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",\r
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this\r
+ document are to be interpreted as described in RFC 2119 [1].\r
+\r
+2. The NSEC Resource Record\r
+\r
+ The NSEC resource record lists two separate things: the owner name of\r
+ the next RRset in the canonical ordering of the zone, and the set of\r
+ RR types present at the NSEC RR's owner name. The complete set of\r
+ NSEC RRs in a zone both indicate which RRsets exist in a zone and\r
+ also form a chain of owner names in the zone. This information is\r
+ used to provide authenticated denial of existence for DNS data, as\r
+ described in RFC 2535 [2].\r
+\r
+ The type value for the NSEC RR is 47.\r
+\r
+\r
+\r
+Schlyter Expires November 8, 2004 [Page 3]\r
+\r
+Internet-Draft DNSSEC NSEC RDATA Format May 2004\r
+\r
+\r
+ The NSEC RR RDATA format is class independent and defined for all\r
+ classes.\r
+\r
+ The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL\r
+ field. This is in the spirit of negative caching [8].\r
+\r
+2.1 NSEC RDATA Wire Format\r
+\r
+ The RDATA of the NSEC RR is as shown below:\r
+\r
+ 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3\r
+ 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\r
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r
+ / Next Domain Name /\r
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r
+ / List of Type Bit Map(s) /\r
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r
+\r
+\r
+2.1.1 The Next Domain Name Field\r
+\r
+ The Next Domain Name field contains the owner name of the next RR in\r
+ the canonical ordering of the zone. The value of the Next Domain\r
+ Name field in the last NSEC record in the zone is the name of the\r
+ zone apex (the owner name of the zone's SOA RR).\r
+\r
+ A sender MUST NOT use DNS name compression on the Next Domain Name\r
+ field when transmitting an NSEC RR.\r
+\r
+ Owner names of RRsets not authoritative for the given zone (such as\r
+ glue records) MUST NOT be listed in the Next Domain Name unless at\r
+ least one authoritative RRset exists at the same owner name.\r
+\r
+2.1.2 The List of Type Bit Map(s) Field\r
+\r
+ The RR type space is split into 256 window blocks, each representing\r
+ the low-order 8 bits of the 16-bit RR type space. Each block that has\r
+ at least one active RR type is encoded using a single octet window\r
+ number (from 0 to 255), a single octet bitmap length (from 1 to 32)\r
+ indicating the number of octets used for the window block's bitmap,\r
+ and up to 32 octets (256 bits) of bitmap.\r
+\r
+ Window blocks are present in the NSEC RR RDATA in increasing\r
+ numerical order.\r
+\r
+ "|" denotes concatenation\r
+\r
+ Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +\r
+\r
+\r
+\r
+Schlyter Expires November 8, 2004 [Page 4]\r
+\r
+Internet-Draft DNSSEC NSEC RDATA Format May 2004\r
+\r
+\r
+ Each bitmap encodes the low-order 8 bits of RR types within the\r
+ window block, in network bit order. The first bit is bit 0. For\r
+ window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds\r
+ to RR type 2 (NS), and so forth. For window block 1, bit 1\r
+ corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to\r
+ 1, it indicates that an RRset of that type is present for the NSEC\r
+ RR's owner name. If a bit is set to 0, it indicates that no RRset of\r
+ that type is present for the NSEC RR's owner name.\r
+\r
+ Since bit 0 in window block 0 refers to the non-existing RR type 0,\r
+ it MUST be set to 0. After verification, the validator MUST ignore\r
+ the value of bit 0 in window block 0.\r
+\r
+ Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [3]\r
+ (section 3.1) or within the range reserved for assignment only to\r
+ QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in\r
+ zone data. If encountered, they must be ignored upon reading.\r
+\r
+ Blocks with no types present MUST NOT be included. Trailing zero\r
+ octets in the bitmap MUST be omitted. The length of each block's\r
+ bitmap is determined by the type code with the largest numerical\r
+ value, within that block, among the set of RR types present at the\r
+ NSEC RR's owner name. Trailing zero octets not specified MUST be\r
+ interpretted as zero octets.\r
+\r
+2.1.3 Inclusion of Wildcard Names in NSEC RDATA\r
+\r
+ If a wildcard owner name appears in a zone, the wildcard label ("*")\r
+ is treated as a literal symbol and is treated the same as any other\r
+ owner name for purposes of generating NSEC RRs. Wildcard owner names\r
+ appear in the Next Domain Name field without any wildcard expansion.\r
+ RFC 2535 [2] describes the impact of wildcards on authenticated\r
+ denial of existence.\r
+\r
+2.2 The NSEC RR Presentation Format\r
+\r
+ The presentation format of the RDATA portion is as follows:\r
+\r
+ The Next Domain Name field is represented as a domain name.\r
+\r
+ The List of Type Bit Map(s) Field is represented as a sequence of RR\r
+ type mnemonics. When the mnemonic is not known, the TYPE\r
+ representation as described in RFC 3597 [4] (section 5) MUST be used.\r
+\r
+2.3 NSEC RR Example\r
+\r
+ The following NSEC RR identifies the RRsets associated with\r
+ alfa.example.com. and identifies the next authoritative name after\r
+\r
+\r
+\r
+Schlyter Expires November 8, 2004 [Page 5]\r
+\r
+Internet-Draft DNSSEC NSEC RDATA Format May 2004\r
+\r
+\r
+ alfa.example.com.\r
+\r
+ alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC TYPE1234\r
+\r
+ The first four text fields specify the name, TTL, Class, and RR type\r
+ (NSEC). The entry host.example.com. is the next authoritative name\r
+ after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC\r
+ and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC and\r
+ TYPE1234 RRsets associated with the name alfa.example.com.\r
+\r
+ The RDATA section of the NSEC RR above would be encoded as:\r
+\r
+ 0x04 'h' 'o' 's' 't'\r
+ 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e'\r
+ 0x03 'c' 'o' 'm' 0x00\r
+ 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03\r
+ 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00\r
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00\r
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00\r
+ 0x00 0x00 0x00 0x00 0x20\r
+\r
+ Assuming that the resolver can authenticate this NSEC record, it\r
+ could be used to prove that beta.example.com does not exist, or could\r
+ be used to prove there is no AAAA record associated with\r
+ alfa.example.com. Authenticated denial of existence is discussed in\r
+ RFC 2535 [2].\r
+\r
+3. IANA Considerations\r
+\r
+ This document introduces no new IANA considerations, because all of\r
+ the protocol parameters used in this document have already been\r
+ assigned by RFC TCR [5].\r
+\r
+4. Security Considerations\r
+\r
+ The update of the RDATA format and encoding does not affect the\r
+ security of the use of NSEC RRs.\r
+\r
+Normative References\r
+\r
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement\r
+ Levels", BCP 14, RFC 2119, March 1997.\r
+\r
+ [2] Eastlake, D., "Domain Name System Security Extensions", RFC\r
+ 2535, March 1999.\r
+\r
+ [3] Eastlake, D., Brunner-Williams, E. and B. Manning, "Domain Name\r
+ System (DNS) IANA Considerations", BCP 42, RFC 2929, September\r
+\r
+\r
+\r
+Schlyter Expires November 8, 2004 [Page 6]\r
+\r
+Internet-Draft DNSSEC NSEC RDATA Format May 2004\r
+\r
+\r
+ 2000.\r
+\r
+ [4] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)\r
+ Types", RFC 3597, September 2003.\r
+\r
+ [5] Weiler, S., "Legacy Resolver Compatibility for Delegation\r
+ Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work\r
+ in progress), October 2003.\r
+\r
+Informational References\r
+\r
+ [6] Mockapetris, P., "Domain names - concepts and facilities", STD\r
+ 13, RFC 1034, November 1987.\r
+\r
+ [7] Mockapetris, P., "Domain names - implementation and\r
+ specification", STD 13, RFC 1035, November 1987.\r
+\r
+ [8] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC\r
+ 2308, March 1998.\r
+\r
+\r
+Author's Address\r
+\r
+ Jakob Schlyter (editor)\r
+ Karl Gustavsgatan 15\r
+ Goteborg SE-411 25\r
+ Sweden\r
+\r
+ EMail: jakob@schlyter.se\r
+\r
+Appendix A. Acknowledgements\r
+\r
+ The encoding described in this document was initially proposed by\r
+ Mark Andrews. Other encodings where proposed by David Blacka and\r
+ Michael Graff.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Schlyter Expires November 8, 2004 [Page 7]\r
+\r
+Internet-Draft DNSSEC NSEC RDATA Format May 2004\r
+\r
+\r
+Intellectual Property Statement\r
+\r
+ The IETF takes no position regarding the validity or scope of any\r
+ intellectual property or other rights that might be claimed to\r
+ pertain to the implementation or use of the technology described in\r
+ this document or the extent to which any license under such rights\r
+ might or might not be available; neither does it represent that it\r
+ has made any effort to identify any such rights. Information on the\r
+ IETF's procedures with respect to rights in standards-track and\r
+ standards-related documentation can be found in BCP-11. Copies of\r
+ claims of rights made available for publication and any assurances of\r
+ licenses to be made available, or the result of an attempt made to\r
+ obtain a general license or permission for the use of such\r
+ proprietary rights by implementors or users of this specification can\r
+ be obtained from the IETF Secretariat.\r
+\r
+ The IETF invites any interested party to bring to its attention any\r
+ copyrights, patents or patent applications, or other proprietary\r
+ rights which may cover technology that may be required to practice\r
+ this standard. Please address the information to the IETF Executive\r
+ Director.\r
+\r
+\r
+Full Copyright Statement\r
+\r
+ Copyright (C) The Internet Society (2004). All Rights Reserved.\r
+\r
+ This document and translations of it may be copied and furnished to\r
+ others, and derivative works that comment on or otherwise explain it\r
+ or assist in its implementation may be prepared, copied, published\r
+ and distributed, in whole or in part, without restriction of any\r
+ kind, provided that the above copyright notice and this paragraph are\r
+ included on all such copies and derivative works. However, this\r
+ document itself may not be modified in any way, such as by removing\r
+ the copyright notice or references to the Internet Society or other\r
+ Internet organizations, except as needed for the purpose of\r
+ developing Internet standards in which case the procedures for\r
+ copyrights defined in the Internet Standards process must be\r
+ followed, or as required to translate it into languages other than\r
+ English.\r
+\r
+ The limited permissions granted above are perpetual and will not be\r
+ revoked by the Internet Society or its successors or assignees.\r
+\r
+ This document and the information contained herein is provided on an\r
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING\r
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING\r
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION\r
+\r
+\r
+\r
+Schlyter Expires November 8, 2004 [Page 8]\r
+\r
+Internet-Draft DNSSEC NSEC RDATA Format May 2004\r
+\r
+\r
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF\r
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.\r
+\r
+\r
+Acknowledgment\r
+\r
+ Funding for the RFC Editor function is currently provided by the\r
+ Internet Society.\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+\r
+Schlyter Expires November 8, 2004 [Page 9]\r
+\r
+\r
+\r
projects / thirdparty / bind9.git / commitdiff
