+++ /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
