idnits 2.17.1 draft-ietf-dnsext-nsec-rdata-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 34 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2535, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC2535, updated by this document, for RFC5378 checks: 1997-07-24) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 10, 2004) is 7262 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '6' is defined on line 263, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 266, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2535 (ref. '2') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2929 (ref. '3') (Obsoleted by RFC 5395) == Outdated reference: A later version (-06) exists of draft-ietf-dnsext-dnssec-2535typecode-change-05 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Extensions Working Group J. Schlyter, Ed. 3 Internet-Draft May 10, 2004 4 Updates: RFC 2535, RFC TCR (if approved) 5 Expires: November 8, 2004 7 DNSSEC NSEC RDATA Format 8 draft-ietf-dnsext-nsec-rdata-06.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on November 8, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 This document redefines the wire format of the "Type Bit Map" field 39 in the NSEC resource record RDATA format to cover the full RR type 40 space. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 3 46 2.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . . 4 47 2.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 4 48 2.1.2 The List of Type Bit Map(s) Field . . . . . . . . . . . . . 4 49 2.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . . . . 5 50 2.2 The NSEC RR Presentation Format . . . . . . . . . . . . . . 5 51 2.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . . 5 52 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6 53 4. Security Considerations . . . . . . . . . . . . . . . . . . 6 54 Normative References . . . . . . . . . . . . . . . . . . . . 6 55 Informational References . . . . . . . . . . . . . . . . . . 7 56 Author's Address . . . . . . . . . . . . . . . . . . . . . . 7 57 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 58 Intellectual Property and Copyright Statements . . . . . . . 8 60 1. Introduction 62 The NSEC [5] Resource Record (RR) is used for authenticated proof of 63 the non-existence of DNS owner names and types. The NSEC RR is based 64 on the NXT RR as described in RFC 2535 [2], and is similar except for 65 the name and typecode. The RDATA format for the NXT RR has the 66 limitation in that the RDATA could only carry information about the 67 existence of the first 127 types. RFC 2535 did reserve a bit to 68 specify an extension mechanism, but the mechanism was never actually 69 defined. 71 In order to avoid the need to develop an extension mechanism into a 72 deployed base of DNSSEC aware servers and resolvers once the first 73 127 type codes are allocated, this document redefines the wire format 74 of the "Type Bit Map" field in the NSEC RDATA to cover the full RR 75 type space. 77 This document introduces a new format for the type bit map. The 78 properties of the type bit map format are that it can cover the full 79 possible range of typecodes, that it is relatively economical in the 80 amount of space it uses for the common case of a few types with an 81 owner name, that it can represent owner names with all possible types 82 present in packets of approximately 8.5 kilobytes and that the 83 representation is simple to implement. Efficient searching of the 84 type bitmap for the presence of certain types is not a requirement. 86 For convenience and completeness this document presents the syntax 87 and semantics for the NSEC RR based on the specification in RFC 2535 88 [2] and as updated by RFC TCR [5], thereby not introducing changes 89 except for the syntax of the type bit map. 91 This document updates RFC 2535 [2] and RFC TCR [5]. 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [1]. 97 2. The NSEC Resource Record 99 The NSEC resource record lists two separate things: the owner name of 100 the next RRset in the canonical ordering of the zone, and the set of 101 RR types present at the NSEC RR's owner name. The complete set of 102 NSEC RRs in a zone both indicate which RRsets exist in a zone and 103 also form a chain of owner names in the zone. This information is 104 used to provide authenticated denial of existence for DNS data, as 105 described in RFC 2535 [2]. 107 The type value for the NSEC RR is 47. 109 The NSEC RR RDATA format is class independent and defined for all 110 classes. 112 The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL 113 field. This is in the spirit of negative caching [8]. 115 2.1 NSEC RDATA Wire Format 117 The RDATA of the NSEC RR is as shown below: 119 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 120 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 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 / Next Domain Name / 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 / List of Type Bit Map(s) / 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 2.1.1 The Next Domain Name Field 129 The Next Domain Name field contains the owner name of the next RR in 130 the canonical ordering of the zone. The value of the Next Domain 131 Name field in the last NSEC record in the zone is the name of the 132 zone apex (the owner name of the zone's SOA RR). 134 A sender MUST NOT use DNS name compression on the Next Domain Name 135 field when transmitting an NSEC RR. 137 Owner names of RRsets not authoritative for the given zone (such as 138 glue records) MUST NOT be listed in the Next Domain Name unless at 139 least one authoritative RRset exists at the same owner name. 141 2.1.2 The List of Type Bit Map(s) Field 143 The RR type space is split into 256 window blocks, each representing 144 the low-order 8 bits of the 16-bit RR type space. Each block that has 145 at least one active RR type is encoded using a single octet window 146 number (from 0 to 255), a single octet bitmap length (from 1 to 32) 147 indicating the number of octets used for the window block's bitmap, 148 and up to 32 octets (256 bits) of bitmap. 150 Window blocks are present in the NSEC RR RDATA in increasing 151 numerical order. 153 "|" denotes concatenation 155 Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) + 156 Each bitmap encodes the low-order 8 bits of RR types within the 157 window block, in network bit order. The first bit is bit 0. For 158 window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds 159 to RR type 2 (NS), and so forth. For window block 1, bit 1 160 corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to 161 1, it indicates that an RRset of that type is present for the NSEC 162 RR's owner name. If a bit is set to 0, it indicates that no RRset of 163 that type is present for the NSEC RR's owner name. 165 Since bit 0 in window block 0 refers to the non-existing RR type 0, 166 it MUST be set to 0. After verification, the validator MUST ignore 167 the value of bit 0 in window block 0. 169 Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [3] 170 (section 3.1) or within the range reserved for assignment only to 171 QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in 172 zone data. If encountered, they must be ignored upon reading. 174 Blocks with no types present MUST NOT be included. Trailing zero 175 octets in the bitmap MUST be omitted. The length of each block's 176 bitmap is determined by the type code with the largest numerical 177 value, within that block, among the set of RR types present at the 178 NSEC RR's owner name. Trailing zero octets not specified MUST be 179 interpretted as zero octets. 181 2.1.3 Inclusion of Wildcard Names in NSEC RDATA 183 If a wildcard owner name appears in a zone, the wildcard label ("*") 184 is treated as a literal symbol and is treated the same as any other 185 owner name for purposes of generating NSEC RRs. Wildcard owner names 186 appear in the Next Domain Name field without any wildcard expansion. 187 RFC 2535 [2] describes the impact of wildcards on authenticated 188 denial of existence. 190 2.2 The NSEC RR Presentation Format 192 The presentation format of the RDATA portion is as follows: 194 The Next Domain Name field is represented as a domain name. 196 The List of Type Bit Map(s) Field is represented as a sequence of RR 197 type mnemonics. When the mnemonic is not known, the TYPE 198 representation as described in RFC 3597 [4] (section 5) MUST be used. 200 2.3 NSEC RR Example 202 The following NSEC RR identifies the RRsets associated with 203 alfa.example.com. and identifies the next authoritative name after 204 alfa.example.com. 206 alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC TYPE1234 208 The first four text fields specify the name, TTL, Class, and RR type 209 (NSEC). The entry host.example.com. is the next authoritative name 210 after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC 211 and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC and 212 TYPE1234 RRsets associated with the name alfa.example.com. 214 The RDATA section of the NSEC RR above would be encoded as: 216 0x04 'h' 'o' 's' 't' 217 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' 218 0x03 'c' 'o' 'm' 0x00 219 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 220 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 221 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 222 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 223 0x00 0x00 0x00 0x00 0x20 225 Assuming that the resolver can authenticate this NSEC record, it 226 could be used to prove that beta.example.com does not exist, or could 227 be used to prove there is no AAAA record associated with 228 alfa.example.com. Authenticated denial of existence is discussed in 229 RFC 2535 [2]. 231 3. IANA Considerations 233 This document introduces no new IANA considerations, because all of 234 the protocol parameters used in this document have already been 235 assigned by RFC TCR [5]. 237 4. Security Considerations 239 The update of the RDATA format and encoding does not affect the 240 security of the use of NSEC RRs. 242 Normative References 244 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 245 Levels", BCP 14, RFC 2119, March 1997. 247 [2] Eastlake, D., "Domain Name System Security Extensions", RFC 248 2535, March 1999. 250 [3] Eastlake, D., Brunner-Williams, E. and B. Manning, "Domain Name 251 System (DNS) IANA Considerations", BCP 42, RFC 2929, September 252 2000. 254 [4] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) 255 Types", RFC 3597, September 2003. 257 [5] Weiler, S., "Legacy Resolver Compatibility for Delegation 258 Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work 259 in progress), October 2003. 261 Informational References 263 [6] Mockapetris, P., "Domain names - concepts and facilities", STD 264 13, RFC 1034, November 1987. 266 [7] Mockapetris, P., "Domain names - implementation and 267 specification", STD 13, RFC 1035, November 1987. 269 [8] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 270 2308, March 1998. 272 Author's Address 274 Jakob Schlyter (editor) 275 Karl Gustavsgatan 15 276 Goteborg SE-411 25 277 Sweden 279 EMail: jakob@schlyter.se 281 Appendix A. Acknowledgements 283 The encoding described in this document was initially proposed by 284 Mark Andrews. Other encodings where proposed by David Blacka and 285 Michael Graff. 287 Intellectual Property Statement 289 The IETF takes no position regarding the validity or scope of any 290 intellectual property or other rights that might be claimed to 291 pertain to the implementation or use of the technology described in 292 this document or the extent to which any license under such rights 293 might or might not be available; neither does it represent that it 294 has made any effort to identify any such rights. Information on the 295 IETF's procedures with respect to rights in standards-track and 296 standards-related documentation can be found in BCP-11. Copies of 297 claims of rights made available for publication and any assurances of 298 licenses to be made available, or the result of an attempt made to 299 obtain a general license or permission for the use of such 300 proprietary rights by implementors or users of this specification can 301 be obtained from the IETF Secretariat. 303 The IETF invites any interested party to bring to its attention any 304 copyrights, patents or patent applications, or other proprietary 305 rights which may cover technology that may be required to practice 306 this standard. Please address the information to the IETF Executive 307 Director. 309 Full Copyright Statement 311 Copyright (C) The Internet Society (2004). All Rights Reserved. 313 This document and translations of it may be copied and furnished to 314 others, and derivative works that comment on or otherwise explain it 315 or assist in its implementation may be prepared, copied, published 316 and distributed, in whole or in part, without restriction of any 317 kind, provided that the above copyright notice and this paragraph are 318 included on all such copies and derivative works. However, this 319 document itself may not be modified in any way, such as by removing 320 the copyright notice or references to the Internet Society or other 321 Internet organizations, except as needed for the purpose of 322 developing Internet standards in which case the procedures for 323 copyrights defined in the Internet Standards process must be 324 followed, or as required to translate it into languages other than 325 English. 327 The limited permissions granted above are perpetual and will not be 328 revoked by the Internet Society or its successors or assignees. 330 This document and the information contained herein is provided on an 331 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 332 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 333 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 334 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 335 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 337 Acknowledgment 339 Funding for the RFC Editor function is currently provided by the 340 Internet Society.