idnits 2.17.1 draft-gieben-nsec4-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 4, 2012) is 4497 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 990, but not defined == Unused Reference: 'GiebenMekking11' is defined on line 1082, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 2672 (Obsoleted by RFC 6672) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSEXT R. Gieben 3 Internet-Draft SIDN 4 Intended status: Experimental W. Mekking 5 Expires: July 7, 2012 NLnet Labs 6 January 4, 2012 8 DNS Security (DNSSEC) Authenticated Denial of Existence 9 draft-gieben-nsec4-00 11 Abstract 13 The Domain Name System Security (DNSSEC) Extensions introduced the 14 NSEC resource record for authenticated denial of existence, and the 15 NSEC3 resource record for hashed authenticated denial of existence. 16 This document introduces an alternative resource record, NSEC4, which 17 similarly provides authenticated denial of existence. It permits 18 gradual expansion of delegation-centric zones, just like NSEC3 does. 19 With NSEC4 it is possible, but not required, to provide measures 20 against zone enumeration. 22 NSEC4 reduces the size of the denial of existence response and adds 23 Opt-Out to unhashed names. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 7, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 5 61 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 64 2. Experimental Status . . . . . . . . . . . . . . . . . . . . . 6 66 3. The NSEC4 Resource Record . . . . . . . . . . . . . . . . . . 7 67 3.1. RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 8 68 3.1.1. Hash Algorithm . . . . . . . . . . . . . . . . . . . . 8 69 3.1.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.1.2.1. Opt-Out Flag . . . . . . . . . . . . . . . . . . . 8 71 3.1.2.2. Wildcard Flag . . . . . . . . . . . . . . . . . . 8 72 3.1.3. Iterations . . . . . . . . . . . . . . . . . . . . . . 8 73 3.1.4. Salt Length . . . . . . . . . . . . . . . . . . . . . 9 74 3.1.5. Salt . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 3.1.6. Next (Hashed) Owner Name . . . . . . . . . . . . . . . 9 76 3.1.7. Type Bit Maps . . . . . . . . . . . . . . . . . . . . 9 77 3.2. NSEC4 RDATA Wire Format . . . . . . . . . . . . . . . . . 9 78 3.2.1. Type Bit Maps Encoding . . . . . . . . . . . . . . . . 10 79 3.3. Presentation Format . . . . . . . . . . . . . . . . . . . 10 80 3.3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 11 82 4. The NSEC4PARAM Resource Record . . . . . . . . . . . . . . . . 11 84 5. Opt-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 6. Authoritative Server Considerations . . . . . . . . . . . . . 12 87 6.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . 12 88 6.2. Zone Serving . . . . . . . . . . . . . . . . . . . . . . . 13 89 6.2.1. Denial of Wildcard Synthesis Proof . . . . . . . . . . 13 90 6.2.2. Closest Encloser Proof . . . . . . . . . . . . . . . . 14 91 6.2.3. Denial of Source of Synthesis Proof . . . . . . . . . 14 92 6.2.4. Name Error Responses . . . . . . . . . . . . . . . . . 14 93 6.2.5. No Data Responses . . . . . . . . . . . . . . . . . . 15 94 6.2.5.1. QTYPE is not DS . . . . . . . . . . . . . . . . . 15 95 6.2.5.2. QTYPE is DS . . . . . . . . . . . . . . . . . . . 15 96 6.2.6. Wildcard Answer Responses . . . . . . . . . . . . . . 15 97 6.2.7. Wildcard No Data Responses . . . . . . . . . . . . . . 16 98 6.2.8. Referrals to Unsigned Subzones . . . . . . . . . . . . 16 99 6.2.9. Responding to Queries for NSEC4 Only Owner Names . . . 17 100 6.2.10. Server Response to a Run-Time Collision . . . . . . . 17 101 6.3. Secondary Servers . . . . . . . . . . . . . . . . . . . . 17 102 6.4. Zones Using Unknown Hash Algorithms . . . . . . . . . . . 17 103 6.5. Dynamic Update . . . . . . . . . . . . . . . . . . . . . . 17 105 7. Validator Considerations . . . . . . . . . . . . . . . . . . . 18 106 7.1. Responses with Unknown Hash Types . . . . . . . . . . . . 18 107 7.2. Verifying NSEC4 RRs . . . . . . . . . . . . . . . . . . . 18 108 7.3. Validating Name Error Responses . . . . . . . . . . . . . 18 109 7.4. Validating No Data Responses . . . . . . . . . . . . . . . 19 110 7.5. Validating Wildcard Answer Responses . . . . . . . . . . . 19 111 7.6. Validating Wildcard No Data Responses . . . . . . . . . . 19 112 7.7. Validating Referrals to Unsigned Subzones . . . . . . . . 20 113 7.8. Validator Algorithm . . . . . . . . . . . . . . . . . . . 21 115 8. Resolver Considerations . . . . . . . . . . . . . . . . . . . 21 116 8.1. NSEC4 Resource Record Caching . . . . . . . . . . . . . . 21 117 8.2. Use of the AD Bit . . . . . . . . . . . . . . . . . . . . 21 119 9. Special Considerations . . . . . . . . . . . . . . . . . . . . 21 120 9.1. Domain Name Length Restrictions . . . . . . . . . . . . . 21 121 9.2. DNAME at the Zone Apex . . . . . . . . . . . . . . . . . . 21 122 9.3. Iterations value . . . . . . . . . . . . . . . . . . . . . 22 123 9.4. More Special Considerations . . . . . . . . . . . . . . . 22 125 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 127 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 129 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 131 13. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 24 132 13.1. 00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 134 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 135 14.1. Informative References . . . . . . . . . . . . . . . . . . 24 136 14.2. Normative References . . . . . . . . . . . . . . . . . . . 24 138 Appendix A. List of Hashed Owner Names . . . . . . . . . . . . . 25 140 Appendix B. Example Zones . . . . . . . . . . . . . . . . . . . . 26 141 B.1. Hashed Denial of Existence . . . . . . . . . . . . . . . . 26 142 B.2. Zero Hashing . . . . . . . . . . . . . . . . . . . . . . . 26 143 B.3. SHA1 Hashing . . . . . . . . . . . . . . . . . . . . . . . 27 145 Appendix C. Example Responses . . . . . . . . . . . . . . . . . . 28 146 C.1. Name Error . . . . . . . . . . . . . . . . . . . . . . . . 29 147 C.2. No Data Error . . . . . . . . . . . . . . . . . . . . . . 30 148 C.3. Referral to an Opt-Out Unsigned Zone . . . . . . . . . . . 30 149 C.4. Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 31 150 C.5. Wildcard No Data Error . . . . . . . . . . . . . . . . . . 32 152 1. Introduction 154 1.1. Rationale 156 Hashed authenticated denial of existence proofs frequently hinge on 157 the closest encloser proof (Section 7.2.1 and 8.3 of [RFC5155]). 158 When validating a hashed denial of existence response, a validator 159 must deny or assert the presence of a next closer name and a wildcard 160 name. A validator can derive these names from the closest encloser. 162 This is why most of the denial of existence responses with NSEC3 163 contain three records: 165 1. A record which matches the closest encloser; 167 2. A record which covers or matches the next closer, to deny or 168 assert the existence of the next closer name; 170 3. A record which covers or matches the wildcard, to deny or assert 171 wildcard synthesis. 173 This document presents a new record, NSEC4, that is similar to NSEC3, 174 but differs in the following ways: 176 o It provides a new way to deny the existence of the wildcard, by 177 introducing the Wildcard bit (described in Section 3.1.2.2); 179 o It allows for unhashed records, by introducing Zero hashing 180 (described in Section 3.1.1). 182 With NSEC4 you will need a maximum of two records for any denial of 183 existence response, saving one record and accompanying signature(s) 184 compared to NSEC3. 186 By defining Zero hashing, we also fold back NSEC into NSEC4 and add 187 Opt-out to unhashed names. With this change we collapse NSEC and 188 NSEC3 into one new record to leave only one form of authenticated 189 denial of existence in the DNS. 191 1.2. Requirements 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 195 document are to be interpreted as described in [RFC2119]. 197 1.3. Terminology 199 The reader is assumed to be familiar with the basic DNS and DNSSEC 200 concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034], 201 [RFC4035], and subsequent RFCs that update them: [RFC2136], 202 [RFC2181], [RFC2308] and [RFC5155]. 204 Furthermore, the same terminology is used throughout this document as 205 is described in Section 1.3 from [RFC5155], with the following 206 changes: 208 Original owner name: the owner name corresponding to a hashed owner 209 name if hashing is used. Or the owner name as-is if no hashing is 210 used. 212 Opt-Out NSEC4 RR: a NSEC4 RR that has the Opt-Out flag set to 1. 214 Wildcard NSEC4 RR: a NSEC4 RR that has the Wildcard flag set to 1. 216 Opt-Out zone: a zone with at least one Opt-Out NSEC4 RR. 218 Base32: the "Base 32 Encoding with Extended Hex Alphabet" as 219 specified in [RFC4648]. Note that trailing padding characters 220 ("=") are not used in the NSEC4 specification. 222 To cover: When a hash algorithm is defined, a NSEC4 RR is said to 223 "cover" a name if the hash of the name or next closer name falls 224 between the owner name and the next hashed owner name of the 225 NSEC4. When no hash algorithm (Zero hashing) is defined, a NSEC4 226 RR is said to "cover" a name if the name or next closer name falls 227 between the owner name and the next owner name of the NSEC4. In 228 other words, if it proves the nonexistence of the name, either 229 directly or by proving the nonexistence of an ancestor of the 230 name. 232 To match: When a hash algorithm is defined, a NSEC4 RR is said to 233 "match" a name if the owner name of the NSEC4 RR is the same as 234 the hashed owner name of that name. When no hash algorithm (Zero 235 hashing) is defined, a NSEC4 RR is said to "match" a name if the 236 name and the owner name of the NSEC4 RR are equal. 238 Zero hashing: Perform no hashing. Leave the name as-is. 240 2. Experimental Status 242 This document describes an EXPERIMENTAL extension to DNSSEC. It 243 interoperates with non-experimental DNSSEC using the technique 244 described in [RFC4955]. This experiment is identified with the 245 following private algorithm (using algorithm PRIVATEDNS): 247 o Algorithm "5.nsec4.nlnetlabs.nl.", is an alias for algorithm 5, 248 RSASHA1. 250 Servers wishing to sign and serve zones that utilize NSEC4 MUST sign 251 the zone with this private algorithm and MUST NOT use any other 252 algorithms. 254 Resolvers MUST NOT apply NSEC4 validation described in this document 255 unless a response contains RRSIGs created with this private 256 algorithm. 258 3. The NSEC4 Resource Record 260 The NSEC4 RR provides authenticated denial of existence for DNS 261 RRsets. 263 The NSEC4 RR lists RR types present at the original owner name of the 264 NSEC4 RR. It includes the next (hashed) owner name in the (hash) 265 order of the zone. The complete set of NSEC4 RRs in a zone indicates 266 which RRSets exist for the original owner name of the RR and form a 267 chain. This information is used to provide authenticated denial of 268 existence for DNS data. To provide protection against zone 269 enumeration, the owner names used in the NSEC4 RR can be 270 cryptographic hashes of the original owner name prepended as a single 271 label to the name of the zone. If hashing is used, the NSEC4 RR 272 indicates which hash function is used to construct the hash, which 273 salt is used, and how many iterations of the hash function are 274 performed over the original owner name. 276 The hashing technique is the same as with NSEC3 and is described in 277 Section 5 of [RFC5155]. NSEC3 creates hashes for empty non- 278 terminals, NSEC4 does the same, even when Zero hashing is in use. 280 (Hashed) owner names of unsigned delegations may be excluded from the 281 chain. A NSEC4 RR whose span covers an owner name or next closer 282 name of an unsigned delegation is referred to as an Opt-Out NSEC4 RR 283 and is indicated by the presence of a flag. 285 If hashing is in use, the owner name for the NSEC4 RR is the base32 286 encoding of the hashed owner name prepended as a single label to the 287 name of the zone. 289 The type value for the NSEC4 RR is [TBD]. 291 The NSEC4 RR RDATA format is class independent and is described 292 below. 294 The class MUST be the same as the class of the original owner name. 296 The NSEC4 RR SHOULD have the same TTL value as the SOA minimum TTL 297 field. This is in the spirit of negative caching [RFC2136]. 299 3.1. RDATA Fields 301 The NSEC4 RDATA has many similarities with the NSEC3 RDATA, but there 302 are differences: 304 o There is an extra flag bit reserved to indicate whether wildcard 305 synthesis is possible (e.g. does a wildcard domain name exist that 306 is immediately descending from the original owner name?); 308 o The hash length does not need to be stored, as all domain names 309 are stored as domain names, not raw hashes. 311 3.1.1. Hash Algorithm 313 [RFC5155] defines the NSEC3 hash algorithm registry. The zero hash 314 (hash algorithm 0) is reserved. For NSEC4 we define the Zero hash to 315 mean that no hashing is used (Zero hashing). 317 3.1.2. Flags 319 The Flags field is identical to the Flags field as defined in 320 [RFC5155]. This specification adds a new flag, the Wildcard Flag. 322 3.1.2.1. Opt-Out Flag 324 Like the Opt-Out Flag defined in Section 3.1.2.1 of [RFC5155]. 326 3.1.2.2. Wildcard Flag 328 The Wildcard Flag indicates whether there is wildcard synthesis 329 possible (e.g. does a wildcard domain name exist that is immediately 330 descending from the original owner name of the NSEC4?). 332 If the Wildcard flag is set, wildcard synthesis is possible. 334 If the Wildcard flag is clear, wildcard synthesis is not possible. 336 3.1.3. Iterations 338 Like the Iterations field defined in Section 3.1.3 of [RFC5155]. 340 3.1.4. Salt Length 342 Like the Salt Length field defined in Section 3.1.4 of [RFC5155]. 344 3.1.5. Salt 346 Like the Salt field defined in Section 3.1.5 of [RFC5155]. 348 3.1.6. Next (Hashed) Owner Name 350 The Next Owner Name field contains the next owner name that exists in 351 the definition of Section 2.2.3 of [RFC4592]. 353 If Zero hashing is used, the field contains the next owner name in 354 the canonical ordering of the zone, as explained in Section 6.1 of 355 [RFC4034]. 357 A sender MUST NOT use DNS name compression on the Next Owner Name 358 field when transmitting a NSEC4 RR. 360 Owner names of RRsets for which the given zone is not authoritative 361 (such as glue records) MUST NOT be listed in the Next Owner Name, 362 unless at least one authoritative RRset exists at the same owner 363 name. 365 3.1.7. Type Bit Maps 367 Like the Type Bit Maps field defined in Section 3.1.8 of [RFC5155]. 369 3.2. NSEC4 RDATA Wire Format 371 The RDATA of the NSEC4 RR is as shown below. 373 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 374 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 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Hash Alg. | Flags | Iterations | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Salt Length | Salt / 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 / Next (Hashed) Owner Name / 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 / Type Bit Maps / 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 Hash Algorithm is a single octet. If Hash Algorithm is zero (Zero 386 hashing), the Iterations field, the Salt Length field and the Salt 387 field MUST be ignored. 389 Flags field is a single octet. The following one-bit flags are 390 defined: 392 0 1 2 3 4 5 6 7 393 +-+-+-+-+-+-+-+-+ 394 | |W|O| 395 +-+-+-+-+-+-+-+-+ 397 o O - Opt-Out flag 399 o W - Wildcard flag 401 Iterations is represented as a 16-bit unsigned integer, with the most 402 significant bit first. 404 Salt Length is represented as an unsigned octet. Salt Length 405 represents the length of the Salt field in octets. If the value is 406 zero, the following Salt field is omitted. 408 Salt, if present, is encoded as a sequence of binary octets. The 409 length of this field is determined by the preceding Salt Length 410 field. 412 If Hash Algorithm is not zero, the Next (Hashed) Owner Name is a 413 base32 encoded domain name of the hashed next owner name prepended as 414 a single label to the name of the zone. If Hash Algorithm is zero it 415 is a plain domain name. 417 The Type Bit Maps encode the existing types at the original owner 418 name that matches the NSEC4 RR. 420 3.2.1. Type Bit Maps Encoding 422 The encoding of the Type Bit Maps field is the same as that used by 423 the NSEC and NSEC3 RR, described in [RFC4034], as well as in 424 [RFC5155]. 426 3.3. Presentation Format 428 The presentation format of the RDATA portion is as follows: 430 o The Hash Algorithm field is represented as an unsigned decimal 431 integer. The value has a maximum of 255. 433 o The Flags field is represented as an unsigned decimal integer. 434 The value has a maximum of 255. 436 o The Iterations field is represented as an unsigned decimal 437 integer. The value is between 0 and 65535, inclusive. 439 o The Salt Length field is not represented. 441 o The Salt field is represented as a sequence of case-insensitive 442 hexadecimal digits. Whitespace is not allowed within the 443 sequence. The Salt field is represented as "-" (without the 444 quotes) when the Salt Length field has a value of 0. 446 o The Next (Hashed) Owner Name field is represented as a domain 447 name. 449 o The Type Bit Maps field is represented as a sequence of RR type 450 mnemonics. When the mnemonic is not known, the TYPE 451 representation as described in Section 5 of [RFC3597] MUST be 452 used. 454 3.3.1. Examples 456 NSEC record: 458 example. NSEC a.example NS SOA RRSIG DNSKEY NSEC 460 They same data shown as a NSEC3 record: 462 3msev9usmd4br9s97v51r2tdvmr9iqo1.example. NSEC3 1 0 0 - ( 463 6cd522290vma0nr8lqu1ivtcofj94rga 464 NS SOA RRSIG DNSKEY NSEC3PARAM ) 466 As a NSEC4 record with Zero hashing: 468 example. NSEC4 0 0 0 - a.example. NS SOA RRSIG DNSKEY NSEC4 NSEC4PARAM 470 And as a NSEC4 record with SHA1 hashing: 472 3msev9usmd4br9s97v51r2tdvmr9iqo1.example. NSEC4 1 0 0 - ( 473 6cd522290vma0nr8lqu1ivtcofj94rga.example. 474 NS SOA RRSIG DNSKEY NSEC4PARAM ) 476 4. The NSEC4PARAM Resource Record 478 Exactly like NSEC3PARAM described in Section 5 of [RFC5155], except 479 the type code used [TBD] is that of NSEC4PARAM. 481 5. Opt-Out 483 This specification adds Opt-Out as described in Section 6 of 484 [RFC5155]. Because of Zero hashing, this allows for Opt-Out being 485 used with unhashed names. A similar method is described in 486 [RFC4956], but with NSEC4 we can reuse the Opt-Out bit from the Flags 487 field. 489 6. Authoritative Server Considerations 491 6.1. Zone Signing 493 Zones using NSEC4 must satisfy the same properties as described in 494 Section 7.1 of [RFC5155], with NSEC3 replaced by NSEC4. 496 In addition, for each original owner name that has a wildcard domain 497 name immediately descending from the original owner name, the 498 corresponding NSEC4 RR MUST have the Wildcard bit set in the Flags 499 field. 501 The following steps describe one possible method of proper 502 construction of NSEC4 RRs. 504 1. Select the hash algorithm and the values for salt and 505 iterations; 507 2. For each unique original owner name in the zone add a NSEC4 RR; 509 * If Opt-Out is being used, owner names of unsigned delegations 510 MAY be excluded; 512 * The owner name of the NSEC4 RR is either the hash of the 513 original owner name, prepended as a single label to the zone 514 name, or is equal to the original owner name if Zero hashing 515 is used; 517 * The Next Owner Name field is left blank for the moment; 519 * If Opt-Out is being used, set the Opt-Out bit to one. 521 3. For collision detection purposes, if hashing is used, optionally 522 keep track of the original owner name with the NSEC4 RR. Create 523 an additional NSEC4 RR corresponding to the original owner name 524 with the asterisk label prepended. Mark this NSEC4 RR as 525 temporary; 527 4. If the original owner name is a wildcard domain name (Section 528 2.1.1. of [RFC4592]), mark the NSEC4 to be a NSEC4 RR that is 529 matching a wildcard; 531 5. For each RRSet at the original owner name, set the corresponding 532 bit in the Type Bit Maps field; 534 6. Additional NSEC4 RRs need to be added for every empty non- 535 terminal between the apex and the original owner name. If 536 hashing is used, optionally keep track of the original owner 537 names of these NSEC4 RRs and create temporary NSEC4 RRs for 538 wildcard collisions in a similar fashion to step 3; 540 7. Sort the set of NSEC4 RRs into hash order or canonical order, 541 depending on the value of the hash algorithm; 543 8. Combine NSEC4 RRs with identical owner names by replacing them 544 with a single NSEC4 RR with the Type Bit Maps field consisting 545 of the union of the types represented by the set of NSEC4 RRs. 546 If hashing is used and the original owner name was tracked, then 547 collisions may be detected when combining, as all of the 548 matching NSEC4 RRs should have the same original owner name. If 549 a hash collision is detected, then a new salt has to be chosen, 550 and the signing process is restarted. Discard any possible 551 temporary NSEC4 RRs; 553 9. In each NSEC4 RR, insert the next (hashed) owner name by using 554 the domain name of the next NSEC4 RR in hashed (if hashing is 555 used) or canonical order (Zero hashing). The next (hashed) 556 owner name of the last NSEC4 RR in the zone contains the value 557 of the (hashed) owner name of the first NSEC4 RR in hashed or 558 canonical order. If the NSEC4 is marked to be matching a 559 wildcard, find the NSEC4 that matches the closest encloser. Set 560 the Wildcard bit in the Flags field of that NSEC4; 562 10. Finally, add a NSEC4PARAM RR with the same Hash Algorithm, 563 Iterations, and Salt fields to the zone apex. 565 6.2. Zone Serving 567 This specification modifies DNSSEC-enabled DNS responses generated by 568 authoritative servers. In particular, it replaces the use of NSEC or 569 NSEC3 RRs in such responses with NSEC4 RRs. 571 6.2.1. Denial of Wildcard Synthesis Proof 573 Instead of wasting a whole denial of existence RR to deny a wildcard, 574 we have introduced a bit in the Flags field of the NSEC4 RR that 575 indicates whether wildcard synthesis was possible because there 576 exists a wildcard domain name immediately descending from the 577 original owner name. 579 The Denial of Wildcard Synthesis proof consists of one NSEC4 RR, that 580 matches some domain name, and that has the Wildcard bit clear. 582 Note that without much knowledge of the original owner name, this 583 proof is not really useful. In particular, we don't know if this is 584 the wildcard synthesis that we are looking for. This changes if we 585 combine this proof with the closest encloser proof. 587 6.2.2. Closest Encloser Proof 589 For some NSEC4 responses a proof of the closest encloser is required. 590 This is a proof that some ancestor of the QNAME is the closest 591 encloser of QNAME. The proof is described in Section 7.2.1 of 592 [RFC5155], and is the same for NSEC4. 594 6.2.3. Denial of Source of Synthesis Proof 596 The denial of wildcard synthesis proof combined with the closest 597 encloser proof results in a denial of source of synthesis proof. The 598 source of synthesis is defined in [RFC4592] as the wildcard domain 599 name immediately descending from the closest encloser. 601 The Denial of Source of Synthesis proof consists of (up to) two NSEC4 602 RRs, the same that constructed the closest encloser proof: 604 o a NSEC4 RR that matches the closest encloser, and that has the 605 Wildcard bit clear in the Flags field; 607 o a NSEC4 RR that covers the next closer name to the closest 608 encloser. 610 The first NSEC4 RR essentially proves that the encloser exists, and 611 that no wildcard synthesis at the encloser is possible. The second 612 NSEC4 RR proves that the encloser is the closest, thus the denial of 613 the wildcard synthesis is the denial of the source of synthesis. 615 6.2.4. Name Error Responses 617 If the zone does not contain any RRsets matching QNAME either exactly 618 or via wildcard name expansion, then the name server must include 619 proof that: 621 o there is no exact match for QNAME; 623 o the zone contains no RRsets that would match QNAME via wildcard 624 name expansion. 626 With NSEC, the server includes in the response a NSEC RR that covers 627 QNAME, and a NSEC RR that covers the wildcard RR at the closest 628 encloser. 630 With NSEC3, the server includes in the response a NSEC3 RR that 631 covers the next closer, a NSEC3 RR that covers the wildcard RR at the 632 closest encloser, and a NSEC3 RR that matches the closest encloser. 634 To prove the nonexistence of QNAME with NSEC4, the server MUST 635 include a denial of source of synthesis proof. This collection of 636 (up to) two NSEC4 RRs proves both that QNAME does not exist and that 637 a wildcard that could have matched QNAME also does not exist. 639 6.2.5. No Data Responses 641 6.2.5.1. QTYPE is not DS 643 When a NODATA response needs to be returned, it is safe to say that 644 QNAME exists. Similar to NSEC and NSEC3, server MUST include the 645 NSEC4 RR that matches QNAME. This NSEC4 RR MUST NOT have the bits 646 corresponding to either the QTYPE or CNAME set in its Type Bit Maps 647 field. 649 6.2.5.2. QTYPE is DS 651 Because of Opt-Out, the response can be different when QTYPE is DS. 652 If no NSEC4 RR matches QNAME, the server MUST return a closest 653 provable encloser proof for QNAME. The NSEC4 RR that covers the next 654 closer name MUST have the Opt-Out bit set. 656 Note that we do not need to ensure the denial of source of synthesis 657 proof, because a DS RRset next to a wildcard is meaningless (Section 658 4.6, [RFC4592]). 660 6.2.6. Wildcard Answer Responses 662 If the zone does not contain any RRsets matching QNAME, but there is 663 wildcard name expansion possible then the name server must include 664 proof that the wildcard match was valid. This proof is accomplished 665 by proving that QNAME does not exist and that the closest encloser of 666 QNAME and the immediate ancestor of the wildcard are equal. 668 Both with NSEC and NSEC3, the server includes in the response a NSEC 669 RR that covers the next closer. It is not necessary to return a RR 670 that matches the closest encloser, as the existence of this closest 671 encloser is proven by the presence of the expanded wildcard in the 672 response. 674 To prove that the wildcard name expansion was valid with NSEC4, the 675 server MUST include in the response a NSEC4 RR that covers the next 676 closer. For the same reasons as with NSEC and NSEC3, it is not 677 necessary to return a RR that matches the closest encloser. 679 6.2.7. Wildcard No Data Responses 681 With NSEC, the server includes in the response a NSEC RR that matches 682 the wildcard, in addition to the NSEC RR that covers the next closer. 683 The NSEC RR does not have the bits corresponding to QTYPE or CNAME 684 set in its Type Bit Maps field. 686 Again, with NSEC3, the server includes in the response a NSEC3 RR 687 that matches the wildcard, in addition to the NSEC3 RR that covers 688 the next closer. The NSEC3 RR does not have the bits corresponding 689 to QTYPE or CNAME set in its Type Bit Maps field. Besides that, a 690 NSEC3 RR that matches the closest encloser is included, because there 691 was no expanded wildcard in the response that can be used to 692 determine the closest encloser. 694 [RFC5155] already notes that the closest encloser to QNAME must be 695 the immediate ancestor of the wildcard RR, which is also defined in 696 [RFC4592]. A closest encloser proof is not necessitated. 698 To prove the wildcard no data response with NSEC4, the server MUST 699 include in the response a NSEC4 RR that matches the wildcard, and a 700 NSEC4 RR that covers the next closer. The closest encloser can be 701 derived from the NSEC4 RR that matches the wildcard. From that, the 702 next closer can be derived. 704 6.2.8. Referrals to Unsigned Subzones 706 If there is an NSEC4 RR that matches the delegation name, then that 707 NSEC4 RR MUST be included in the response. The DS and CNAME bit in 708 the type bit maps of the NSEC4 RR must not be set (by definition). 710 If the zone is Opt-Out, then there may not be an NSEC4 RR 711 corresponding to the delegation. In this case, the closest provable 712 encloser proof MUST be included in the response. The included NSEC4 713 RR that covers the next closer name for the delegation MUST have the 714 Opt-Out flag set to one. 716 Note that with Zero hashing, the NSEC4 RR that matches the closest 717 provable encloser does not need to be included in the response, as it 718 can be derived from the NSEC4 that covers the next closer name. 720 6.2.9. Responding to Queries for NSEC4 Only Owner Names 722 When NSEC4 hashing is in effect the paradox (NSEC4 records deny their 723 own existence) described in Section 7.2.8 of [RFC5155] is back. When 724 Zero hashing is used, there is no paradox. In light of this, queries 725 for the NSEC4 resource type are handled in the same way as normal 726 queries. Resolvers initiating these queries SHOULD disregard any 727 information learned from the returned NSEC4 records. 729 6.2.10. Server Response to a Run-Time Collision 731 The same considerations as described in Section 7.2.9 of [RFC5155] 732 for NSEC3 apply to NSEC4. 734 6.3. Secondary Servers 736 The same considerations as described in Section 7.3 of [RFC5155] for 737 NSEC3 and NSEC3PARAM apply to NSEC4 and NSEC4PARAM. 739 6.4. Zones Using Unknown Hash Algorithms 741 The same considerations as described in Section 7.4 of [RFC5155] for 742 NSEC3 apply to NSEC4. 744 6.5. Dynamic Update 746 A zone signed using NSEC4 may accept dynamic updates [RFC2136]. 747 However, NSEC4 introduces some special considerations for dynamic 748 updates. 750 Adding and removing names in a zone MUST account for the creation or 751 removal of empty non-terminals, similar to [RFC5155], Section 7.5. 753 The presence of Opt-Out in a zone means that some additions or 754 removals of unsigned delegations of names will not require changes to 755 the NSEC4 RRs in a zone. The same considerations as in [RFC5155], 756 Section 7.5 for NSEC3 apply for NSEC4. 758 The presence of Opt-Out in a zone means that when adding or removing 759 NSEC4 RRs, the value of the Opt-Out flag that should be set in new or 760 modified NSEC4 RRs is ambiguous. Servers SHOULD follow the set of 761 basic rules to resolve the ambiguity, as described in [RFC5155], 762 Section 7.5. 764 Adding and removing wildcard names in a zone MUST account for the 765 setting or clearing of the Wildcard bit in the Flags field: 767 o When adding a wildcard name, the NSEC4 RR that matches the 768 immediate parent of the wildcard MUST set the Wildcard bit in the 769 Flags field; 771 o When deleting a wildcard name, the NSEC4 RR that matches the 772 immediate parent of the wildcard MUST clear the Wildcard bit in 773 the Flags field. 775 7. Validator Considerations 777 7.1. Responses with Unknown Hash Types 779 A validator MUST ignore NSEC4 RRs with unknown hash types. The 780 practical result of this is that responses containing only such NSEC4 781 RRs will generally be considered bogus. 783 7.2. Verifying NSEC4 RRs 785 A validator MUST ignore the undefined bits (0-5) in the Flags field 786 of NSEC4 RRs. 788 A validator MAY treat a response as bogus if the response contains 789 NSEC4 RRs that contain different values for hash algorithm, 790 iterations, or salt from each other for that zone. 792 7.3. Validating Name Error Responses 794 A validator MUST verify that there is a closest encloser for QNAME 795 present in the response. A validator MUST verify that the Wildcard 796 bit is clear in the Flags field of the NSEC4 RR that matches the 797 closest encloser. 799 In order to find the closest encloser, the validator MUST find the 800 longest name, X, such that X is an ancestor of QNAME that is matched 801 by a NSEC4 RR present in the response. 803 One possible algorithm for finding the closest encloser is as 804 follows: 806 1. Set SNAME=QNAME; 808 2. If there is a NSEC4 RR in the response that matches SNAME, then 809 we have found the closest encloser; 811 3. Truncate SNAME by one label from the left, go to step 2. 813 Once the closest encloser has been discovered, the validator MUST 814 check that the NSEC4 RR that has the closest encloser as the original 815 owner name is from the proper zone. The DNAME type bit MUST NOT be 816 set and the NS type bit MUST be clear if the SOA type bit is clear. 818 If this is not the case, it would be an indication that an attacker 819 is using them to falsely deny the existence of RRs for which the 820 server is not authoritative. 822 In addition, the validator MUST verify that there is a NSEC4 RR that 823 covers the next closer name. 825 7.4. Validating No Data Responses 827 If QTYPE is not DS, a validator MUST verify that a NSEC4 RR that 828 matches QNAME is present and that both the QTYPE and the CNAME type 829 are not set in its Type Bit Maps field. 831 Note that this test also covers the case where the NSEC4 RR exists 832 because it corresponds to an empty non-terminal, in which case the 833 NSEC4 RR will have an empty Type Bit Maps field. 835 If QTYPE is DS, and there is a NSEC4 RR that matches QNAME present in 836 the response, then that NSEC4 RR MUST NOT have the bits corresponding 837 to DS and CNAME set in its Type Bit Maps field. 839 If there is no such NSEC4 RR, then the validator MUST verify that 840 there is a closest provable encloser for QNAME present in the 841 response. The closest provable encloser is found in a similar way as 842 the closest encloser. In addition, the validator MUST verify that 843 there is a NSEC4 RR that covers the next closer name and has the Opt- 844 Out bit set. 846 7.5. Validating Wildcard Answer Responses 848 The verified wildcard answer RRSet in the response provides the 849 validator with a closest encloser for QNAME. The validator can do so 850 by checking the label count in the RRSIG and the number of labels in 851 the answer's owner name. 853 The validator MUST verify that there is a NSEC4 RR that covers the 854 next closer name to QNAME is present in the response. This proves 855 that QNAME itself did not exist and that the correct wildcard was 856 used to generate the response. 858 7.6. Validating Wildcard No Data Responses 860 The validator MUST verify that there is a NSEC4 RR present in the 861 response that matches the source of synthesis. 863 In order to find the source of synthesis, the validator MUST find the 864 longest name, X, such that X is an ancestor of QNAME and that *.X is 865 matched by a NSEC4 RR present in the response. 867 One possible algorithm for finding the source of synthesis is as 868 follows: 870 1. Set SNAME=QNAME; 872 2. Truncate SNAME by one label from the left. This is a candidate 873 for the closest encloser; 875 3. Set WNAME to be SNAME with the asterisk label prepended: 876 WNAME=*.SNAME; 878 4. If there is a NSEC4 RR in the response that matches WNAME, then 879 we have found the source of synthesis, with SNAME being the 880 closest encloser; 882 5. Go to step 2. 884 The validator does not need to check that the closest encloser is 885 from the proper zone. The authoritative server returned a NSEC4 that 886 matches the source of synthesis. According to [RFC2672], this proves 887 that the server did not encounter a referral (step 3b of the server 888 algorithm [RFC1035]), nor did it encounter a DNAME (step 3c of the 889 server algorithm [RFC1035]). 891 Now that the validator knows the source of synthesis and thus the 892 closest encloser, it can derive the next closer name. The validator 893 MUST verify that there is a NSEC4 RR that covers the next closer name 894 to QNAME, is present in the response. 896 Note that, because the response included a NSEC4 that matches the 897 source of synthesis, we know that there exists data in the zone below 898 the closest encloser. Therefore, the closest encloser cannot be a 899 delegation, nor can there exists a DNAME RRset at the closest 900 encloser. 902 7.7. Validating Referrals to Unsigned Subzones 904 The delegation name in a referral is the owner name of the NS RRSet 905 present in the authority section of the referral response. 907 If there is a NSEC4 RR present in the response that matches the 908 delegation name, then the validator MUST ensure that the NS bit is 909 set and that the DS bit is not set in the Type Bit Maps field of the 910 NSEC4 RR. The validator MUST also ensure that the NSEC4 RR is from 911 the correct (i.e., parent) zone. This is done by ensuring that the 912 SOA bit is not set in the Type Bit Maps field of this NSEC4 RR. 914 Note that the presence of a NS bit implies the absence of a DNAME 915 bit, so there is no need to check for the DNAME bit in the Type Bit 916 Maps field of the NSEC4 RR. 918 If there is no NSEC4 RR present that matches the delegation name, 919 then the validator MUST verify that there is a closest provable 920 encloser for the delegation name. In addition, the validator MUST 921 verify that there is a NSEC4 RR that covers the next closer name and 922 has the Opt-Out bit set. 924 7.8. Validator Algorithm 926 The following steps describe one possible method of proper validation 927 of an answer containing NSEC4 RRs. 929 [TBD] 931 8. Resolver Considerations 933 8.1. NSEC4 Resource Record Caching 935 The same considerations as described in Section 9.1 of [RFC5155] for 936 NSEC3 apply to NSEC4. 938 8.2. Use of the AD Bit 940 The same considerations as described in Section 9.2 of [RFC5155] for 941 NSEC3 apply to NSEC4. 943 9. Special Considerations 945 9.1. Domain Name Length Restrictions 947 The same considerations as described in Section 10.1 of [RFC5155] 948 apply. 950 9.2. DNAME at the Zone Apex 952 The DNAME specification in Section 3 of [RFC2672] has a 'no- 953 descendants' limitation. If a DNAME RR is present at node N, there 954 MUST be no data at any descendant of N. 956 [RFC5155] updates the DNAME specification to allow NSEC3 and RRSIG 957 types at descendants of the apex regardless of the existence of DNAME 958 at the apex. 960 This document updates the DNAME specification to also allow NSEC4 961 types at descendants of the apex regardless of the existence of DNAME 962 at the apex. 964 9.3. Iterations value 966 Like Section 10.3 in [RFC5155], but we recommend to read 967 [Schaeffer10] as it shows that a lower iterations value is also 968 acceptable. The research shows that that the half performance count 969 for validators is roughly 150 to 600, depending on the key size. For 970 authoritative servers the half performance count is around 100 971 iterations. 973 9.4. More Special Considerations 975 Appendix C of [RFC5155] clarifies specific behavior and explains more 976 special considerations for implementations, regarding salting and 977 hash collisions. These considerations for NSEC3 also apply to NSEC4. 979 10. IANA Considerations 981 Although the NSEC4 and NSEC4PARAM RR formats include a hash algorithm 982 parameter, this document does not define a particular mechanism for 983 safely transitioning from one NSEC4 hash algorithm to another. When 984 specifying a new hash algorithm for use with NSEC4, a transition 985 mechanism MUST also be defined. 987 This document updates the IANA registry "DOMAIN NAME SYSTEM 988 PARAMETERS" (http://www.iana.org/assignments/dns-parameters) in sub- 989 registry "TYPES", by defining two new types. Section 3 defines the 990 NSEC4 RR type [TBD]. Section 4 defines the NSEC4PARAM RR type [TBD]. 992 This document possibly updates the IANA registry "DNS SECURITY 993 ALGORITHM NUMBERS -- per [RFC4035]" 994 (http://www.iana.org/assignments/dns-sec-alg-numbers). 996 This document creates a new IANA registry for NSEC4 flags. This 997 registry is named "DNSSEC NSEC4 Flags". The initial contents of this 998 registry are: 1000 0 1 2 3 4 5 6 7 1001 +----+----+----+----+----+----+----+----+ 1002 | | | | | | |Wild|Opt-| 1003 | | | | | | |card|Out | 1004 +----+----+----+----+----+----+----+----+ 1006 bit 6 is the Wildcard flag. 1008 bit 7 is the Opt-Out flag. 1010 bits 0 - 5 are available for assignment. 1012 Assignment of additional NSEC4 Flags in this registry requires IETF 1013 Standards Action [RFC5226]. 1015 This document creates a new IANA registry for NSEC4PARAM flags. This 1016 registry is named "DNSSEC NSEC4PARAM Flags". The initial contents of 1017 this registry are: 1019 0 1 2 3 4 5 6 7 1020 +---+---+---+---+---+---+---+---+ 1021 | | | | | | | | 0 | 1022 +---+---+---+---+---+---+---+---+ 1024 bit 7 is reserved and must be 0. 1026 bits 0 - 6 are available for assignment. 1028 Assignment of additional NSEC4PARAM Flags in this registry requires 1029 IETF Standards Action [RFC5226]. 1031 Finally, this document creates a new IANA registry for NSEC4 hash 1032 algorithms. This registry is named "DNSSEC NSEC4 Hash Algorithms". 1033 The initial contents of this registry are: 1035 0 is Zero hashing. 1037 1 is SHA-1. 1039 2-255 Available for assignment. 1041 Assignment of additional NSEC4 hash algorithms in this registry 1042 requires IETF Standards Action [RFC5226]. 1044 11. Security Considerations 1046 This document does not introduce any new security issues beyond those 1047 already discussed in [RFC4033], [RFC4034], [RFC4035] and [RFC5155]. 1049 12. Acknowledgements 1051 This document would not be possible without the help of Ed Lewis, Roy 1052 Arends, Wouter Wijngaards, Karst Koymans, Marco Davids, Esther Makaay 1053 and Antoin Verschuren. 1055 This document was produced using the xml2rfc tool ([RFC2629]) and 1056 Pandoc2RFC ([Gieben11]). 1058 13. Changelog 1060 13.1. 00 1062 o Initial document 1064 14. References 1066 14.1. Informative References 1068 [Gieben11] Gieben, R., "Pandoc2RFC", September 2011, 1069 . 1071 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", 1072 RFC 2629, June 1999. 1074 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", 1075 RFC 2672, August 1999. 1077 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain 1078 Name System", RFC 4592, July 2006. 1080 14.2. Normative References 1082 [GiebenMekking11] Gieben, R. and W. Mekking, "Authenticated Denial 1083 of Existence in the DNS", November 2011. 1085 [RFC1034] Mockapetris, P., "Domain names - concepts and 1086 facilities", STD 13, RFC 1034, November 1987. 1088 [RFC1035] Mockapetris, P., "Domain names - implementation 1089 and specification", STD 13, RFC 1035, 1090 November 1987. 1092 [RFC2119] Bradner, S., "Key words for use in RFCs to 1093 Indicate Requirement Levels", BCP 14, RFC 2119, 1094 March 1997. 1096 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 1097 "Dynamic Updates in the Domain Name System (DNS 1098 UPDATE)", RFC 2136, April 1997. 1100 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1101 Specification", RFC 2181, July 1997. 1103 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1104 NCACHE)", RFC 2308, March 1998. 1106 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource 1107 Record (RR) Types", RFC 3597, September 2003. 1109 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., 1110 and S. Rose, "DNS Security Introduction and 1111 Requirements", RFC 4033, March 2005. 1113 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., 1114 and S. Rose, "Resource Records for the DNS 1115 Security Extensions", RFC 4034, March 2005. 1117 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., 1118 and S. Rose, "Protocol Modifications for the DNS 1119 Security Extensions", RFC 4035, March 2005. 1121 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 1122 Data Encodings", RFC 4648, October 2006. 1124 [RFC4955] Blacka, D., "DNS Security (DNSSEC) Experiments", 1125 RFC 4955, July 2007. 1127 [RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS 1128 Security (DNSSEC) Opt-In", RFC 4956, July 2007. 1130 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, 1131 "DNS Security (DNSSEC) Hashed Authenticated Denial 1132 of Existence", RFC 5155, March 2008. 1134 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for 1135 Writing an IANA Considerations Section in RFCs", 1136 BCP 26, RFC 5226, May 2008. 1138 [Schaeffer10] Schaeffer, Y., "NSEC3 Hash Performance", 1139 March 2010. 1141 Appendix A. List of Hashed Owner Names 1143 The following owner names are used in this document. The hashed 1144 names are hashed with SHA1 using an empty salt and zero iterations. 1146 +-----------------+----------------------------------+ 1147 | Original Name | Hashed Name | 1148 +-----------------+----------------------------------+ 1149 | example. | 3msev9usmd4br9s97v51r2tdvmr9iqo1 | 1150 | a.example. | 6cd522290vma0nr8lqu1ivtcofj94rga | 1151 | ns1.example. | m1o89lfdo9rrf2f8r8ss42d81d09v48m | 1152 | sd.example. | 831naajdsm14h0md3kip92563ud3saav | 1153 | ns1.sd.example. | qrsbil3cs97oa4p5fql8dedp6jo0b9a6 | 1154 | ud.example. | ub8e42kj4s2jdfve6aloo98jdoa425a9 | 1155 | ns1.ud.example. | 7cuee8ri909f5r365jqr0k6j75thndpi | 1156 | who.example. | g4s20q3kptookhpt9mgr93k8bfhjs3fd | 1157 | *.who.example. | ht6ocje68mtm96jpes8olrlbf67jjvdu | 1158 | b.who.example. | rmv5tauk8nss83vo1st0tp1ps927j71e | 1159 +-----------------+----------------------------------+ 1161 Appendix B. Example Zones 1163 B.1. Hashed Denial of Existence 1165 This is the unsigned zone we are using for the NSEC4 examples. The 1166 overall TTL and class are left out for clarity. 1168 $ORIGIN example. 1169 @ SOA ns1.example. bugs.example. 1 2 3 4 5 1170 NS ns1.example. 1171 ns1 A 192.0.2.10 1172 ;; secure delegation 1173 sd NS ns1.sd.example. 1174 DS 33694 253 2 ... 1175 ns1.sd A 192.0.2.10 1176 ;; unsecure delegation 1177 ud NS ns1.ud.example. 1178 ns1.ud A 192.0.2.10 1179 *.who TXT "Wildcard" 1181 B.2. Zero Hashing 1183 This is the same zone shown with Zero hashing. The RRSIG Signature 1184 field, the DNSKEY Public Key field and the DS Digest field are 1185 omitted. The RRSIG expiration and inception times are set to ".". 1187 $ORIGIN example. 1188 @ SOA ns1.example. bugs.example. 1 2 3 4 5 1189 RRSIG SOA 253 1 300 . . 39824 example. ... 1190 RRSIG NS 253 1 300 . . 39824 example. ... 1191 RRSIG DNSKEY 253 1 300 . . 39824 example. ... 1192 RRSIG NSEC4PARAM 253 1 3600 . . 39824 example. ... 1193 RRSIG NSEC4 253 1 5 . . 39824 example. ... 1194 NS ns1.example. 1195 DNSKEY 256 3 253 ... 1196 NSEC4PARAM 0 0 0 - 1197 NSEC4 0 1 0 - ( 1198 ns1.example. NS SOA RRSIG DNSKEY NSEC4 NSEC4PARAM ) 1199 ns1 A 192.0.2.10 1200 RRSIG A 253 2 300 . . 39824 example. ... 1201 RRSIG NSEC4 253 2 5 . . 39824 example. ... 1202 NSEC4 0 1 0 - sd.example. A RRSIG NSEC4 1203 sd NS ns1.sd.example. 1204 DS 33694 253 2 ... 1205 RRSIG DS 253 2 300 . . 39824 example. ... 1206 RRSIG NSEC4 253 2 5 . . 39824 example. ... 1207 NSEC4 0 1 0 - who.example. NS DS RRSIG NSEC4 1208 ns1.sd A 192.0.2.10 1209 ud NS ns1.ud.example. 1210 ns1.ud A 192.0.2.10 1211 who NSEC4 0 3 0 - *.who.example. 1212 RRSIG NSEC4 253 2 5 . . 39824 example. ... 1213 *.who TXT "Wildcard" 1214 RRSIG TXT 253 2 300 . . 39824 example. ... 1215 RRSIG NSEC4 253 2 5 . . 39824 example. ... 1216 NSEC4 0 1 0 - example. TXT RRSIG NSEC4 1218 B.3. SHA1 Hashing 1220 This is the same zone shown with SHA1 hashing. 1222 $ORIGIN example. 1223 @ SOA ns1.example. bugs.example. 1 2 3 4 5 1224 RRSIG SOA 253 1 300 . . 39824 example. ... 1225 RRSIG NS 253 1 300 . . 39824 example. ... 1226 RRSIG DNSKEY 253 1 300 . . 39824 example. ... 1227 RRSIG NSEC4PARAM 253 1 3600 . . 39824 example. ... 1228 NS ns1.example. 1229 DNSKEY 256 3 253 ... 1230 NSEC4PARAM 1 0 0 - 1231 3msev9usmd4br9s97v51r2tdvmr9iqo1 NSEC4 1 1 0 - ( 1232 831naajdsm14h0md3kip92563ud3saav.example. 1233 NS SOA RRSIG DNSKEY NSEC4PARAM ) 1234 RRSIG NSEC4 253 2 5 . . 39824 example. ... 1235 831naajdsm14h0md3kip92563ud3saav NSEC4 1 1 0 - ( 1236 g4s20q3kptookhpt9mgr93k8bfhjs3fd.example. 1237 NS DS RRSIG ) 1238 RRSIG NSEC4 253 2 5 . . 39824 example. ... 1239 g4s20q3kptookhpt9mgr93k8bfhjs3fd NSEC4 1 3 0 - ( 1240 ht6ocje68mtm96jpes8olrlbf67jjvdu.example. ) 1241 RRSIG NSEC4 253 2 5 . . 39824 example. ... 1242 ht6ocje68mtm96jpes8olrlbf67jjvdu NSEC4 1 1 0 - ( 1243 m1o89lfdo9rrf2f8r8ss42d81d09v48m.example. 1244 TXT RRSIG ) 1245 RRSIG NSEC4 253 2 5 . . 39824 example. ... 1246 m1o89lfdo9rrf2f8r8ss42d81d09v48m NSEC4 1 1 0 - ( 1247 3msev9usmd4br9s97v51r2tdvmr9iqo1.example. 1248 A RRSIG ) 1249 RRSIG NSEC4 253 2 5 . . 39824 example. ... 1250 ns1 A 192.0.2.10 1251 RRSIG A 253 2 300 . . 39824 example. ... 1252 sd NS ns1.sd.example. 1253 DS 33694 253 2 ... 1254 RRSIG DS 253 2 300 . . 39824 example. ... 1255 ns1.sd A 192.0.2.10 1257 ud NS ns1.ud.example. 1258 ns1.ud A 192.0.2.10 1259 *.who TXT "Wildcard" 1260 RRSIG TXT 253 2 300 . . 39824 example. ... 1262 Appendix C. Example Responses 1264 The examples in this section show response messages using the signed 1265 zone example in Appendix B.3. 1267 C.1. Name Error 1269 An authoritative name error. The NSEC4 RRs prove that the name does 1270 not exist and that there is no wildcard RR that should have been 1271 expanded. 1273 ;; Header: QR AA RD RCODE=NXDOMAIN 1274 ;; 1275 ;; Question 1276 a.example. IN A 1278 ;; Answer 1279 ;; (empty) 1281 ;; Authority 1282 ;; NSEC4 RR that matches the closest encloser (example) 1283 ;; This NSEC4 also covers the next closer name (a.example) 1284 ;; H(a.example) = 6cd522290vma0nr8lqu1ivtcofj94rga 1285 3msev9usmd4br9s97v51r2tdvmr9iqo1.example. NSEC4 1 1 0 - ( 1286 831naajdsm14h0md3kip92563ud3saav.example. 1287 NS SOA RRSIG DNSKEY NSEC4PARAM ) 1288 3msev9usmd4br9s97v51r2tdvmr9iqo1.example. RRSIG NSEC4 253 2 5 ( 1289 . . 39824 example. ... ) 1290 example. SOA ns1.example. bugs.example. 1 2 3 4 5 1291 example. RRSIG SOA 253 1 300 . . 39824 example. ... 1293 The query returns one NSEC4 RR that proves that the requested data 1294 does not exist and that no wildcard expansion applies. The negative 1295 response is authenticated by verifying the NSEC4 RR. The 1296 corresponding RRSIGs indicate that the NSEC4 RRs are signed by an 1297 "example" DNSKEY of algorithm 253 and with key tag 39824. The 1298 resolver needs the corresponding DNSKEY RR in order to authenticate 1299 this answer. 1301 In the above example, the name "example" hashes to 1302 "3msev9usmd4br9s97v51r2tdvmr9iqo1". This indicates that this might 1303 be the closest encloser. 1305 To prove that "a.example" does not exist, the name is hashed to 1306 "6cd522290vma0nr8lqu1ivtcofj94rga". The NSEC4 RR also proves that 1307 next closer name does not exist. 1309 To prove that the source of synthesis "*.example" does not exist, the 1310 Wildcard bit at the NSEC4 RR matching the closest encloser is 1311 inspected. The bit is clear and this shows that the source of 1312 synthesis does indeed not exist. 1314 C.2. No Data Error 1316 A No Data Response. The NSEC4 RR proves that the name exists and 1317 that the requested RR type does not. 1319 ;; Header: QR AA RD RCODE=NOERROR 1320 ;; 1321 ;; Question 1322 ns1.example. IN MX 1324 ;; Answer 1325 ;; (empty) 1327 ;; Authority 1328 example. SOA ns1.example. bugs.example. 1 2 3 4 5 1329 example. RRSIG SOA 253 1 300 . . 39824 example. ... 1330 ;; H(ns1.example) = m1o89lfdo9rrf2f8r8ss42d81d09v48m 1331 m1o89lfdo9rrf2f8r8ss42d81d09v48m.example. NSEC4 1 1 0 - ( 1332 3msev9usmd4br9s97v51r2tdvmr9iqo1.example. 1333 A RRSIG ) 1334 m1o89lfdo9rrf2f8r8ss42d81d09v48m.example. RRSIG NSEC4 253 2 5 ( 1335 . . 39824 example. ... ) 1337 The query returned a NSEC4 RR that proves that the requested name 1338 exists ("ns1.example" hashes to "m1o89lfdo9rrf2f8r8ss42d81d09v48m"), 1339 but the requested RR type does not exist (type MX is absent in the 1340 type code list of the NSEC4 RR), and was not a CNAME (type CNAME is 1341 also absent in the type code list of the NSEC4 RR). 1343 C.3. Referral to an Opt-Out Unsigned Zone 1345 The NSEC4 RRs prove that nothing for this delegation was signed. 1346 There is no proof that the unsigned delegation exists. 1348 ;; Header: QR RD RCODE=NOERROR 1349 ;; 1350 ;; Question 1351 a.ud.example. IN MX 1353 ;; Answer 1354 ;; (empty) 1356 ;; Authority 1357 ud.example. NS ns1.ud.example. 1359 ;; NSEC4 RR that matches the closest provable encloser (example) 1360 ;; H(example) = 3msev9usmd4br9s97v51r2tdvmr9iqo1 1361 3msev9usmd4br9s97v51r2tdvmr9iqo1.example. NSEC4 1 1 0 - ( 1362 831naajdsm14h0md3kip92563ud3saav.example. 1363 NS SOA RRSIG DNSKEY NSEC4PARAM ) 1364 3msev9usmd4br9s97v51r2tdvmr9iqo1.example. RRSIG NSEC4 253 2 5 ( 1365 . . 39824 example. ... ) 1367 ;; NSEC4 RR that covers the next closer name (ud.example) 1368 ;; H(ud.example) = ub8e42kj4s2jdfve6aloo98jdoa425a9 1369 m1o89lfdo9rrf2f8r8ss42d81d09v48m.example. NSEC4 1 1 0 - ( 1370 3msev9usmd4br9s97v51r2tdvmr9iqo1.example. 1371 A RRSIG ) 1372 m1o89lfdo9rrf2f8r8ss42d81d09v48m.example. RRSIG NSEC4 253 2 5 ( 1373 . . 39824 example. ... ) 1375 ;; Additional 1376 ns1.ud.example. A 192.0.2.10 1378 The query returned a referral to the unsigned "ud.example." zone. 1379 The response contains the closest provable encloser of "ud.example" 1380 to be "example", since the hash of "ud.example" 1381 ("ub8e42kj4s2jdfve6aloo98jdoa425a9") is covered by the first NSEC4 RR 1382 and its Opt-Out bit is set. 1384 C.4. Wildcard Expansion 1386 A query that was answered with a response containing a wildcard 1387 expansion. The label count in the RRSIG RRSet in the answer section 1388 indicates that a wildcard RRSet was expanded to produce this 1389 response, and the NSEC4 RR proves that no next closer name exists in 1390 the zone. 1392 ;; Header: QR AA RD RCODE=NOERROR 1393 ;; 1394 ;; Question 1395 a.b.who.example. IN TXT 1397 ;; Answer 1398 a.b.who.example. TXT "Wildcard" 1399 a.b.who.example. RRSIG TXT 253 2 300 ( 1400 . . 39824 example. ... ) 1402 ;; Authority 1403 ;; NSEC4 RR that covers the next closer name (b.who.example) 1404 ;; H(b.who.example) = rmv5tauk8nss83vo1st0tp1ps927j71e 1405 m1o89lfdo9rrf2f8r8ss42d81d09v48m.example. NSEC4 1 1 0 - ( 1406 3msev9usmd4br9s97v51r2tdvmr9iqo1.example. 1407 A RRSIG ) 1408 m1o89lfdo9rrf2f8r8ss42d81d09v48m.example. RRSIG NSEC4 253 2 5 ( 1409 . . 39824 example. ... ) 1410 example. NS ns1.example. 1411 example. RRSIG NS 253 1 300 . . 39824 example. ... 1413 ;; Additional 1414 ns1.example. A 192.0.2.10 1415 ns1.example. RRSIG A 253 2 300 . . 39824 example. ... 1417 The query returned an answer that was produced as a result of a 1418 wildcard expansion. The answer section contains a wildcard RRSet 1419 expanded as it would be in a traditional DNS response. The RRSIG 1420 Labels field value of 2 indicates that the answer is the result of a 1421 wildcard expansion, as the "a.b.who.example" name contains 4 labels. 1422 This also shows that "who.example" exists, so there is no need for an 1423 NSEC4 RR that matches the closest encloser. 1425 The NSEC4 RR proves that no closer match could have been used to 1426 answer this query. 1428 C.5. Wildcard No Data Error 1430 A No Data Response for a name covered by a wildcard. The NSEC4 RRs 1431 prove that the matching wildcard name does not have any RRs of the 1432 requested type and that no closer match exists in the zone. 1434 ;; Header: QR AA RD RCODE=NOERROR 1435 ;; 1436 ;; Question 1437 a.b.who.example. IN AAAA 1439 ;; Answer 1440 ;; (empty) 1442 ;; Authority 1443 ;; NSEC4 RR that covers the next closer name (b.who.example) 1444 ;; H(b.who.example) = rmv5tauk8nss83vo1st0tp1ps927j71e 1445 m1o89lfdo9rrf2f8r8ss42d81d09v48m.example. NSEC4 1 1 0 - ( 1446 3msev9usmd4br9s97v51r2tdvmr9iqo1.example. 1447 A RRSIG ) 1448 m1o89lfdo9rrf2f8r8ss42d81d09v48m.example. RRSIG NSEC4 253 2 5 ( 1449 . . 39824 example. ... ) 1450 example. SOA ns1.example. bugs.example. 1 2 3 4 5 1451 example. RRSIG SOA 253 1 300 . . 39824 example. ... 1452 ;; NSEC4 RR that matches the wildcard at closest encloser 1453 ;; H(*.who.example) = ht6ocje68mtm96jpes8olrlbf67jjvdu 1454 ht6ocje68mtm96jpes8olrlbf67jjvdu.example. NSEC4 1 1 0 - ( 1455 m1o89lfdo9rrf2f8r8ss42d81d09v48m.example. 1456 TXT RRSIG ) 1457 ht6ocje68mtm96jpes8olrlbf67jjvdu.example. RRSIG NSEC4 253 2 5 ( 1458 . . 39824 example. ... ) 1460 The query returned the NSEC4 RRs that prove that the requested data 1461 does not exist and shows the types that do exist at the wildcard. 1463 Authors' Addresses 1465 R. (Miek) Gieben 1466 SIDN 1467 Meander 501 1468 Arnhem, 6825 MD 1469 NL 1471 Phone: 1472 EMail: miek.gieben@sidn.nl 1473 URI: https://sidn.nl/ 1474 W. (Matthijs) Mekking 1475 NLnet Labs 1476 Science Park 400 1477 Amsterdam, 1098 XH 1478 NL 1480 Phone: 1481 EMail: matthijs@nlnetlabs.nl 1482 URI: http://www.nlnetlabs.nl/