idnits 2.17.1 draft-ietf-dnsext-nsec3-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2334. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2345. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2352. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2358. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (December 11, 2007) is 5943 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) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2929 (Obsoleted by RFC 5395) -- Obsolete informational reference (is this intentional?): RFC 2672 (Obsoleted by RFC 6672) -- Obsolete informational reference (is this intentional?): RFC 2898 (Obsoleted by RFC 8018) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Laurie 3 Internet-Draft G. Sisson 4 Intended status: Standards Track R. Arends 5 Expires: June 13, 2008 Nominet 6 D. Blacka 7 VeriSign, Inc. 8 December 11, 2007 10 DNSSEC Hashed Authenticated Denial of Existence 11 draft-ietf-dnsext-nsec3-13 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on June 13, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 The Domain Name System Security Extensions (DNSSEC) introduced the 45 NSEC resource record (RR) for authenticated denial of existence. 46 This document introduces an alternative resource record, NSEC3, which 47 similarly provides authenticated denial of existence. However, it 48 also provides measures against zone enumeration and permits gradual 49 expansion of delegation-centric zones. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 56 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 6 58 3. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 7 59 3.1. RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.1.1. Hash Algorithm . . . . . . . . . . . . . . . . . . . . 8 61 3.1.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 8 62 3.1.3. Iterations . . . . . . . . . . . . . . . . . . . . . . 8 63 3.1.4. Salt Length . . . . . . . . . . . . . . . . . . . . . 8 64 3.1.5. Salt . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.1.6. Hash Length . . . . . . . . . . . . . . . . . . . . . 9 66 3.1.7. Next Hashed Owner Name . . . . . . . . . . . . . . . . 9 67 3.1.8. Type Bit Maps . . . . . . . . . . . . . . . . . . . . 9 68 3.2. NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 9 69 3.2.1. Type Bit Maps Encoding . . . . . . . . . . . . . . . . 10 70 3.3. Presentation Format . . . . . . . . . . . . . . . . . . . 11 71 4. The NSEC3PARAM Record . . . . . . . . . . . . . . . . . . . . 12 72 4.1. RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 12 73 4.1.1. Hash Algorithm . . . . . . . . . . . . . . . . . . . . 12 74 4.1.2. Flag Fields . . . . . . . . . . . . . . . . . . . . . 12 75 4.1.3. Iterations . . . . . . . . . . . . . . . . . . . . . . 13 76 4.1.4. Salt Length . . . . . . . . . . . . . . . . . . . . . 13 77 4.1.5. Salt . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 4.2. NSEC3PARAM RDATA Wire Format . . . . . . . . . . . . . . . 13 79 4.3. Presentation Format . . . . . . . . . . . . . . . . . . . 13 80 5. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 14 81 6. Opt-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 7. Authoritative Server Considerations . . . . . . . . . . . . . 15 83 7.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . 15 84 7.2. Zone Serving . . . . . . . . . . . . . . . . . . . . . . . 17 85 7.2.1. Closest Encloser Proof . . . . . . . . . . . . . . . . 18 86 7.2.2. Name Error Responses . . . . . . . . . . . . . . . . . 18 87 7.2.3. No Data Responses, QTYPE is not DS . . . . . . . . . . 19 88 7.2.4. No Data Responses, QTYPE is DS . . . . . . . . . . . . 19 89 7.2.5. Wildcard No Data Responses . . . . . . . . . . . . . . 19 90 7.2.6. Wildcard Answer Responses . . . . . . . . . . . . . . 19 91 7.2.7. Referrals to Unsigned Subzones . . . . . . . . . . . . 20 92 7.2.8. Responding to Queries for NSEC3 Owner Names . . . . . 20 93 7.2.9. Server Response to a Run-time Collision . . . . . . . 20 94 7.3. Secondary Servers . . . . . . . . . . . . . . . . . . . . 20 95 7.4. Zones Using Unknown Hash Algorithms . . . . . . . . . . . 21 96 7.5. Dynamic Update . . . . . . . . . . . . . . . . . . . . . . 21 97 8. Validator Considerations . . . . . . . . . . . . . . . . . . . 22 98 8.1. Responses with Unknown Hash Types . . . . . . . . . . . . 22 99 8.2. Verifying NSEC3 RRs . . . . . . . . . . . . . . . . . . . 22 100 8.3. Closest Encloser Proof . . . . . . . . . . . . . . . . . . 23 101 8.4. Validating Name Error Responses . . . . . . . . . . . . . 24 102 8.5. Validating No Data Responses, QTYPE is not DS . . . . . . 24 103 8.6. Validating No Data Responses, QTYPE is DS . . . . . . . . 24 104 8.7. Validating Wildcard No Data Responses . . . . . . . . . . 24 105 8.8. Validating Wildcard Answer Responses . . . . . . . . . . . 24 106 8.9. Validating Referrals to Unsigned Subzones . . . . . . . . 25 107 9. Resolver Considerations . . . . . . . . . . . . . . . . . . . 25 108 9.1. NSEC3 Resource Record Caching . . . . . . . . . . . . . . 25 109 9.2. Use of the AD Bit . . . . . . . . . . . . . . . . . . . . 25 110 10. Special Considerations . . . . . . . . . . . . . . . . . . . . 26 111 10.1. Domain Name Length Restrictions . . . . . . . . . . . . . 26 112 10.2. DNAME at the Zone Apex . . . . . . . . . . . . . . . . . . 26 113 10.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . . 26 114 10.4. Transitioning a Signed Zone from NSEC to NSEC3 . . . . . . 27 115 10.5. Transitioning a Signed Zone From NSEC3 to NSEC . . . . . . 28 116 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 117 12. Security Considerations . . . . . . . . . . . . . . . . . . . 30 118 12.1. Hashing Considerations . . . . . . . . . . . . . . . . . . 30 119 12.1.1. Dictionary Attacks . . . . . . . . . . . . . . . . . . 30 120 12.1.2. Collisions . . . . . . . . . . . . . . . . . . . . . . 30 121 12.1.3. Transitioning to a New Hash Algorithm . . . . . . . . 30 122 12.1.4. Using High Iteration Values . . . . . . . . . . . . . 31 123 12.2. Opt-Out Considerations . . . . . . . . . . . . . . . . . . 31 124 12.3. Other Considerations . . . . . . . . . . . . . . . . . . . 32 125 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 126 13.1. Normative References . . . . . . . . . . . . . . . . . . . 32 127 13.2. Informative References . . . . . . . . . . . . . . . . . . 33 128 Appendix A. Example Zone . . . . . . . . . . . . . . . . . . . . 34 129 Appendix B. Example Responses . . . . . . . . . . . . . . . . . . 39 130 B.1. Name Error . . . . . . . . . . . . . . . . . . . . . . . . 39 131 B.2. No Data Error . . . . . . . . . . . . . . . . . . . . . . 41 132 B.2.1. No Data Error, Empty Non-Terminal . . . . . . . . . . 41 133 B.3. Referral to an Opt-Out Unsigned Zone . . . . . . . . . . . 42 134 B.4. Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 44 135 B.5. Wildcard No Data Error . . . . . . . . . . . . . . . . . . 46 136 B.6. DS Child Zone No Data Error . . . . . . . . . . . . . . . 47 137 Appendix C. Special Considerations . . . . . . . . . . . . . . . 48 138 C.1. Salting . . . . . . . . . . . . . . . . . . . . . . . . . 48 139 C.2. Hash Collision . . . . . . . . . . . . . . . . . . . . . . 49 140 C.2.1. Avoiding Hash Collisions During Generation . . . . . . 49 141 C.2.2. Second Preimage Requirement Analysis . . . . . . . . . 50 142 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 143 Intellectual Property and Copyright Statements . . . . . . . . . . 52 145 1. Introduction 147 1.1. Rationale 149 The DNS Security Extensions included the NSEC RR to provide 150 authenticated denial of existence. Though the NSEC RR meets the 151 requirements for authenticated denial of existence, it introduces a 152 side-effect in that the contents of a zone can be enumerated. This 153 property introduces undesired policy issues. 155 The enumeration is enabled by the set of NSEC records that exists 156 inside a signed zone. An NSEC record lists two names that are 157 ordered canonically, in order to show that nothing exists between the 158 two names. The complete set of NSEC records lists all the names in a 159 zone. It is trivial to enumerate the content of a zone by querying 160 for names that do not exist. 162 An enumerated zone can be used, for example, as a source of probable 163 e-mail addresses for spam, or as a key for multiple WHOIS queries to 164 reveal registrant data which many registries may have legal 165 obligations to protect. Many registries therefore prohibit copying 166 of their zone data; however, the use of NSEC RRs renders these 167 policies unenforceable. 169 A second problem is that the cost to cryptographically secure 170 delegations to unsigned zones is high, relative to the perceived 171 security benefit, in two cases: large, delegation-centric zones, and 172 zones where insecure delegations will be updated rapidly. In these 173 cases, the costs of maintaining the NSEC RR chain may be extremely 174 high and use of the "Opt-Out" convention may be more appropriate (for 175 these unsecured zones). 177 This document presents the NSEC3 Resource Record which can be used as 178 an alternative to NSEC to mitigate these issues. 180 Earlier work to address these issues include [I-D.jas-dnsext-no], 181 [RFC4956] and [I-D.laurie-dnsext-nsec2v2]. 183 1.2. Reserved Words 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in [RFC2119]. 189 1.3. Terminology 191 The reader is assumed to be familiar with the basic DNS and DNSSEC 192 concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034], 194 [RFC4035] and subsequent RFCs that update them: [RFC2136], [RFC2181] 195 and [RFC2308]. 197 The following terminology is used throughout this document: 199 Zone enumeration: the practice of discovering the full content of a 200 zone via successive queries. Zone enumeration was non-trivial 201 prior to the introduction of DNSSEC. 203 Original owner name: the owner name corresponding to a hashed owner 204 name. 206 Hashed owner name: the owner name created after applying the hash 207 function to an owner name. 209 Hash order: the order in which hashed owner names are arranged 210 according to their numerical value, treating the leftmost (lowest 211 numbered) octet as the most significant octet. Note that this 212 order is the same as the canonical DNS name order specified in 213 [RFC4034] when the hashed owner names are in base32 encoded with 214 Extended Hex Alphabet [RFC4648]. 216 Empty non-terminal: a domain name that owns no resource records, but 217 has one or more subdomains that do. 219 Delegation: an NS RRSet with a name different from the current zone 220 apex (non-zone-apex), signifying a delegation to a child zone. 222 Secure delegation: a name containing a delegation (NS RRSet), and a 223 signed DS RRSet, signifying a delegation to a signed child zone. 225 Insecure delegation: a name containing a delegation (NS RRSet), but 226 lacking a DS RRSet, signifying a delegation to an unsigned child 227 zone. 229 Opt-Out NSEC3 resource record: an NSEC3 resource record which has 230 the Opt-Out flag set to 1. 232 Opt-Out zone: a zone with at least one Opt-Out NSEC3 RR. 234 Closest encloser: the longest existing ancestor of a name. See also 235 section 3.3.1 of [RFC4592]. 237 Closest provable encloser: the longest ancestor of a name that can 238 be proven to exist. Note that this is only different from the 239 closest encloser in an Opt-Out zone. 241 Next closer name: the name one label longer than the closest 242 provable encloser of a name. 244 Base32: the "Base 32 Encoding with Extended Hex Alphabet" as 245 specified in [RFC4648]. Note that trailing padding characters 246 ("=") are not used in the NSEC3 specification. 248 To cover: An NSEC3 RR is said to "cover" a name if the hash of the 249 name or "next closer" name falls between the owner name and the 250 next hashed owner name of the NSEC3. In other words, if it proves 251 the nonexistence of the name, either directly or by proving the 252 nonexistence of an ancestor of the name. 254 To match: An NSEC3 RR is said to "match" a name if the owner name of 255 the NSEC3 RR is the same as the hashed owner name of that name. 257 2. Backwards Compatibility 259 This specification describes a protocol change that is not generally 260 backwards compatible with [RFC4033], [RFC4034] and [RFC4035]. In 261 particular, security-aware resolvers that are unaware of this 262 specification (NSEC3-unaware resolvers) may fail to validate the 263 responses introduced by this document. 265 In order to aid deployment, this specification uses a signaling 266 technique to prevent NSEC3-unaware resolvers from attempting to 267 validate responses from NSEC3-signed zones. 269 This specification allocates two new DNSKEY algorithm identifiers for 270 this purpose. Algorithm XX, DSA-NSEC3-SHA1 [### RFC-editor update 271 required, temporarily, XX=131] is an alias for algorithm 3, DSA. 272 Algorithm YY, RSASHA1-NSEC3-SHA1 [### RFC-editor update required, 273 temporarily, YY=133] is an alias for algorithm 5, RSASHA1. These are 274 not new algorithms, they are additional identifiers for the existing 275 algorithms. 277 Zones signed according to this specification MUST only use these 278 algorithm identifiers for their DNSKEY RRs. Because these new 279 identifiers will be unknown algorithms to existing, NSEC3-unaware 280 resolvers, those resolvers will then treat responses from the NSEC3 281 signed zone as insecure, as detailed in [RFC4035], section 5.2. 283 These algorithm identifiers are used with the NSEC3 hash algorithm 284 SHA1. Using other NSEC3 hash algorithms requires allocation of a new 285 alias (see Section 12.1.3). 287 Security aware resolvers that are aware of this specification MUST 288 recognize the new algorithm identifiers and treat them as equivalent 289 to the algorithms that they alias. 291 A methodology for transitioning from a DNSSEC signed zone to a zone 292 signed using NSEC3 is discussed in Section 10.4. 294 3. The NSEC3 Resource Record 296 The NSEC3 Resource Record (RR) provides authenticated denial of 297 existence for DNS Resource Record Sets. 299 The NSEC3 RR lists RR types present at the original owner name of the 300 NSEC3 RR. It includes the next hashed owner name in the hash order 301 of the zone. The complete set of NSEC3 RRs in a zone indicates which 302 RRSets exist for the original owner name of the RR and form a chain 303 of hashed owner names in the zone. This information is used to 304 provide authenticated denial of existence for DNS data. To provide 305 protection against zone enumeration, the owner names used in the 306 NSEC3 RR are cryptographic hashes of the original owner name 307 prepended as a single label to the name of the zone. The NSEC3 RR 308 indicates which hash function is used to construct the hash, which 309 salt is used, and how many iterations of the hash function are 310 performed over the original owner name. The hashing technique is 311 described fully in Section 5. 313 Hashed owner names of unsigned delegations may be excluded from the 314 chain. An NSEC3 RR whose span covers the hash of an owner name or 315 "next closer" name of an unsigned delegation is referred to as an 316 Opt-Out NSEC3 RR and is indicated by the presence of a flag. 318 The owner name for the NSEC3 RR is the base32 encoding of the hashed 319 owner name prepended as a single label to the name of the zone. 321 The type value for the NSEC3 RR is NN. [### RFC-editor update 322 required, the examples assume NN=50] 324 The NSEC3 RR RDATA format is class independent and is described 325 below. 327 The class MUST be the same as the class of the original owner name. 329 The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL 330 field. This is in the spirit of negative caching [RFC2308]. 332 3.1. RDATA Fields 334 3.1.1. Hash Algorithm 336 The Hash Algorithm field identifies the cryptographic hash algorithm 337 used to construct the hash-value. 339 The values for this field are defined in the NSEC3 hash algorithm 340 registry, described in Section 11. 342 3.1.2. Flags 344 The Flags field contains 8 one-bit flags that can be used to indicate 345 different processing. All undefined flags must be zero. The only 346 flag defined by this specification is the Opt-Out flag. 348 3.1.2.1. Opt-Out Flag 350 If the Opt-Out flag is set, the NSEC3 record covers zero or more 351 unsigned delegations. 353 If the Opt-Out flag is clear, the NSEC3 record covers zero unsigned 354 delegations. 356 The Opt-Out Flag indicates whether this NSEC3 RR may cover unsigned 357 delegations. It is the least significant bit in the Flags field. 358 See Section 6 for details about the use of this flag. 360 3.1.3. Iterations 362 The Iterations field defines the number of additional times the hash 363 function has been performed. More iterations result in greater 364 resiliency of the hash value against dictionary attacks, but at a 365 higher computational cost for both the server and resolver. See 366 Section 5 for details of the use of this field, and Section 10.3 for 367 limitations on the value. 369 3.1.4. Salt Length 371 The Salt Length field defines the length of the Salt field in octets, 372 ranging in value from 0 to 255. 374 3.1.5. Salt 376 The Salt field is appended to the original owner name before hashing 377 in order to defend against pre-calculated dictionary attacks. See 378 Section 5 for details on how the salt is used. 380 3.1.6. Hash Length 382 The Hash Length field defines the length of the Next Hashed Owner 383 Name field, ranging in value from 1 to 255 octets. 385 3.1.7. Next Hashed Owner Name 387 The Next Hashed Owner Name field contains the next hashed owner name 388 in hash order. This value is in binary format. Given the ordered 389 set of all hashed owner names, the Next Hashed Owner Name field 390 contains the hash of an owner name that immediately follows the owner 391 name of the given NSEC3 RR. The value of the Next Hashed Owner Name 392 field in the last NSEC3 RR in the zone is the same as the hashed 393 owner name of the first NSEC3 RR in the zone in hash order. Note 394 that, unlike the owner name of the NSEC3 RR, the value of this field 395 does not contain the appended zone name. 397 3.1.8. Type Bit Maps 399 The Type Bit Maps field identifies the RRSet types which exist at the 400 original owner name of the NSEC3 RR. 402 3.2. NSEC3 RDATA Wire Format 404 The RDATA of the NSEC3 RR is as shown below: 406 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Hash Alg. | Flags | Iterations | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Salt Length | Salt / 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Hash Length | Next Hashed Owner Name / 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 / Type Bit Maps / 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Hash Algorithm is a single octet. 420 Flags field is a single octet, the Opt-Out flag is the least 421 significant bit, as shown below: 423 0 1 2 3 4 5 6 7 424 +-+-+-+-+-+-+-+-+ 425 | |O| 426 +-+-+-+-+-+-+-+-+ 427 Iterations is represented as a 16-bit unsigned integer, with the most 428 significant bit first. 430 Salt Length is represented as an unsigned octet. Salt Length 431 represents the length of the Salt field in octets. If the value is 432 zero, the following Salt field is omitted. 434 Salt, if present, is encoded as a sequence of binary octets. The 435 length of this field is determined by the preceding Salt Length 436 field. 438 Hash Length is represented as an unsigned octet. Hash Length 439 represents the length of the Next Hashed Owner Name field in octets. 441 The next hashed owner name is not base32 encoded, unlike the owner 442 name of the NSEC3 RR. It is the unmodified binary hash value. It 443 does not include the name of the containing zone. The length of this 444 field is determined by the preceding Hash Length field. 446 3.2.1. Type Bit Maps Encoding 448 The encoding of the Type Bit Maps field is the same as that used by 449 the NSEC RR, described in [RFC4034]. It is explained and clarified 450 here for clarity. 452 The RR type space is split into 256 window blocks, each representing 453 the low-order 8 bits of the 16-bit RR type space. Each block that 454 has at least one active RR type is encoded using a single octet 455 window number (from 0 to 255), a single octet bitmap length (from 1 456 to 32) indicating the number of octets used for the bitmap of the 457 window block, and up to 32 octets (256 bits) of bitmap. 459 Blocks are present in the NSEC3 RR RDATA in increasing numerical 460 order. 462 Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ 464 where "|" denotes concatenation. 466 Each bitmap encodes the low-order 8 bits of RR types within the 467 window block, in network bit order. The first bit is bit 0. For 468 window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds 469 to RR type 2 (NS), and so forth. For window block 1, bit 1 470 corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to 471 1, it indicates that an RRSet of that type is present for the 472 original owner name of the NSEC3 RR. If a bit is set to 0, it 473 indicates that no RRSet of that type is present for the original 474 owner name of the NSEC3 RR. 476 Since bit 0 in window block 0 refers to the non-existing RR type 0, 477 it MUST be set to 0. After verification, the validator MUST ignore 478 the value of bit 0 in window block 0. 480 Bits representing Meta-TYPEs or QTYPEs as specified in [RFC2929] 481 (section 3.1) or within the range reserved for assignment only to 482 QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in 483 zone data. If encountered, they must be ignored upon reading. 485 Blocks with no types present MUST NOT be included. Trailing zero 486 octets in the bitmap MUST be omitted. The length of the bitmap of 487 each block is determined by the type code with the largest numerical 488 value, within that block, among the set of RR types present at the 489 original owner name of the NSEC3 RR. Trailing octets not specified 490 MUST be interpreted as zero octets. 492 3.3. Presentation Format 494 The presentation format of the RDATA portion is as follows: 496 o The Hash Algorithm field is represented as an unsigned decimal 497 integer. The value has a maximum of 255. 499 o The Flags field is represented as an unsigned decimal integer. 500 The value has a maximum of 255. 502 o The Iterations field is represented as an unsigned decimal 503 integer. The value is between 0 and 65535, inclusive. 505 o The Salt Length field is not represented. 507 o The Salt field is represented as a sequence of case-insensitive 508 hexadecimal digits. Whitespace is not allowed within the 509 sequence. The Salt field is represented as "-" (without the 510 quotes) when the Salt Length field has value 0. 512 o The Hash Length field is not represented. 514 o The Next Hashed Owner Name field is represented as an unpadded 515 sequence of case-insensitive base32 digits, without whitespace. 517 o The Type Bit Maps field is represented as a sequence of RR type 518 mnemonics. When the mnemonic is not known, the TYPE 519 representation as described in [RFC3597] (section 5) MUST be used. 521 4. The NSEC3PARAM Record 523 The NSEC3PARAM RR contains the NSEC3 parameters (hash algorithm, 524 flags, iterations and salt) needed by authoritative servers to 525 calculate hashed owner names. The presence of an NSEC3PARAM RR at a 526 zone apex indicates that the specified parameters may be used by 527 authoritative servers to choose an appropriate set of NSEC3 RRs for 528 negative responses. The NSEC3PARAM RR is not used by validators or 529 resolvers. 531 If an NSEC3PARAM RR is present at the apex of a zone with a Flags 532 field value of zero, then there MUST be an NSEC3 RR using the same 533 hash algorithm, iterations and salt parameters present at every 534 hashed owner name in the zone. That is, the zone MUST contain a 535 complete set of NSEC3 RRs with the same hash algorithm, iterations 536 and salt parameters. 538 The owner name for the NSEC3PARAM RR is the name of the zone apex. 540 The type value for the NSEC3PARAM RR is MM. [### RFC-editor update 541 required, the examples assume MM=51] 543 The NSEC3PARAM RR RDATA format is class independent and is described 544 below. 546 The class MUST be the same as the NSEC3 RRs to which this RR refers. 548 4.1. RDATA Fields 550 The RDATA for this RR mirrors the first four fields in the NSEC3 RR. 552 4.1.1. Hash Algorithm 554 The Hash Algorithm field identifies the cryptographic hash algorithm 555 used to construct the hash-value. 557 The acceptable values are the same as the corresponding field in the 558 NSEC3 RR. 560 4.1.2. Flag Fields 562 The Opt-Out flag is not used and is set to zero. 564 All other flags are reserved for future use, and must be zero. 566 NSEC3PARAM RRs with a Flags field value other than zero MUST be 567 ignored. 569 4.1.3. Iterations 571 The Iterations field defines the number of additional times the hash 572 is performed. 574 Its acceptable values are the same as the corresponding field in the 575 NSEC3 RR. 577 4.1.4. Salt Length 579 The Salt Length field defines the length of the salt in octets, 580 ranging in value from 0 to 255. 582 4.1.5. Salt 584 The Salt field is appended to the original owner name before hashing. 586 4.2. NSEC3PARAM RDATA Wire Format 588 The RDATA of the NSEC3PARAM RR is as shown below: 590 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Hash Alg. | Flags | Iterations | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Salt Length | Salt / 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 Hash Algorithm is a single octet. 600 Flags field is a single octet. 602 Iterations is represented as a 16-bit unsigned integer, with the most 603 significant bit first. 605 Salt Length is represented as an unsigned octet. Salt Length 606 represents the length of the following Salt field in octets. If the 607 value is zero, the Salt field is omitted. 609 Salt, if present, is encoded as a sequence of binary octets. The 610 length of this field is determined by the preceding Salt Length 611 field. 613 4.3. Presentation Format 615 The presentation format of the RDATA portion is as follows: 617 o The Hash Algorithm field is represented as an unsigned decimal 618 integer. The value has a maximum of 255. 620 o The Flags field is represented as an unsigned decimal integer. 621 The value has a maximum value of 255. 623 o The Iterations field is represented as an unsigned decimal 624 integer. The value is between 0 and 65535, inclusive. 626 o The Salt Length field is not represented. 628 o The Salt field is represented as a sequence of case-insensitive 629 hexadecimal digits. Whitespace is not allowed within the 630 sequence. This field is represented as "-" (without the quotes) 631 when the Salt Length field is zero. 633 5. Calculation of the Hash 635 The hash calculation uses three of the NSEC3 RDATA fields: Hash 636 Algorithm, Salt, and Iterations. 638 Define H(x) to be the hash of x using the Hash Algorithm selected by 639 the NSEC3 RR, k to be the number of Iterations, and || to indicate 640 concatenation. Then define: 642 IH(salt, x, 0) = H(x || salt), and 644 IH(salt, x, k) = H(IH(salt, x, k-1) || salt), if k > 0 646 Then the calculated hash of an owner name is 648 IH(salt, owner name, iterations), 650 where the owner name is in the canonical form, defined as: 652 The wire format of the owner name where: 654 1. The owner name is fully expanded (no DNS name compression) and 655 fully qualified; 657 2. All uppercase US-ASCII letters are replaced by the corresponding 658 lowercase US-ASCII letters; 660 3. If the owner name is a wildcard name, the owner name is in its 661 original unexpanded form, including the "*" label (no wildcard 662 substitution); 664 This form is as defined in section 6.2 of [RFC4034]. 666 The method to calculate the Hash is based on [RFC2898]. 668 6. Opt-Out 670 In this specification, as in [RFC4033], [RFC4034] and [RFC4035], NS 671 RRSets at delegation points are not signed and may be accompanied by 672 a DS RRSet. With the Opt-Out bit clear, the security status of the 673 child zone is determined by the presence or absence of this DS RRSet, 674 cryptographically proven by the signed NSEC3 RR at the hashed owner 675 name of the delegation. Setting the Opt-Out flag modifies this by 676 allowing insecure delegations to exist within the signed zone without 677 a corresponding NSEC3 RR at the hashed owner name of the delegation. 679 An Opt-Out NSEC3 RR is said to cover a delegation if the hash of the 680 owner name or "next closer" name of the delegation is between the 681 owner name of the NSEC3 RR and the next hashed owner name. 683 An Opt-Out NSEC3 RR does not assert the existence or non-existence of 684 the insecure delegations that it may cover. This allows for the 685 addition or removal of these delegations without recalculating or re- 686 signing RRs in the NSEC3 RR chain. However, Opt-Out NSEC3 RRs do 687 assert the (non)existence of other, authoritative RRSets. 689 An Opt-Out NSEC3 RR MAY have the same original owner name as an 690 insecure delegation. In this case, the delegation is proven insecure 691 by the lack of a DS bit in the type map and the signed NSEC3 RR does 692 assert the existence of the delegation. 694 Zones using Opt-Out MAY contain a mixture of Opt-Out NSEC3 RRs and 695 non-Opt-Out NSEC3 RRs. If an NSEC3 RR is not Opt-Out, there MUST NOT 696 be any hashed owner names of insecure delegations (nor any other RRs) 697 between it and the name indicated by the next hashed owner name in 698 the NSEC3 RDATA. If it is Opt-Out, it MUST only cover hashed owner 699 names or hashed "next closer" names of insecure delegations. 701 The effects of the Opt-Out flag on signing, serving, and validating 702 responses are covered in following sections. 704 7. Authoritative Server Considerations 706 7.1. Zone Signing 708 Zones using NSEC3 must satisfy the following properties: 710 o Each owner name within the zone that owns authoritative RRSets 711 MUST have a corresponding NSEC3 RR. Owner names that correspond 712 to unsigned delegations MAY have a corresponding NSEC3 RR. 713 However, if there is not a corresponding NSEC3 RR, there MUST be 714 an Opt-Out NSEC3 RR that covers the "next closer" name to the 715 delegation. Other non-authoritative RRs are not represented by 716 NSEC3 RRs. 718 o Each empty non-terminal MUST have a corresponding NSEC3 RR, unless 719 the empty non-terminal is only derived from an insecure delegation 720 covered by an Opt-Out NSEC3 RR. 722 o The TTL value for any NSEC3 RR SHOULD be the same as the minimum 723 TTL value field in the zone SOA RR. 725 o The Type Bit Maps field of every NSEC3 RR in a signed zone MUST 726 indicate the presence of all types present at the original owner 727 name, except for the types solely contributed by an NSEC3 RR 728 itself. Note that this means that the NSEC3 type itself will 729 never be present in the Type Bit Maps. 731 The following steps describe a method of proper construction of NSEC3 732 RRs. This is not the only such possible method. 734 1. Select the hash algorithm and the values for salt and iterations. 736 2. For each unique original owner name in the zone add an NSEC3 RR. 738 * If Opt-Out is being used, owner names of unsigned delegations 739 MAY be excluded. 741 * The owner name of the NSEC3 RR is the hash of the original 742 owner name, prepended as a single label to the zone name. 744 * The Next Hashed Owner Name field is left blank for the moment. 746 * If Opt-Out is being used, set the Opt-Out bit to one. 748 * For collision detection purposes, optionally keep track of the 749 original owner name with the NSEC3 RR. 751 * Additionally, for collision detection purposes, optionally 752 create an additional NSEC3 RR corresponding to the original 753 owner name with the asterisk label prepended (i.e., as if a 754 wildcard existed as a child of this owner name) and keep track 755 of this original owner name. Mark this NSEC3 RR as temporary. 757 3. For each RRSet at the original owner name, set the corresponding 758 bit in the Type Bit Maps field. 760 4. If the difference in number of labels between the apex and the 761 original owner name is greater than 1, additional NSEC3 RRs need 762 to be added for every empty non-terminal between the apex and the 763 original owner name. This process may generate NSEC3 RRs with 764 duplicate hashed owner names. Optionally, for collision 765 detection, track the original owner names of these NSEC3 RRs and 766 create temporary NSEC3 RRs for wildcard collisions in a similar 767 fashion to step 1. 769 5. Sort the set of NSEC3 RRs into hash order. 771 6. Combine NSEC3 RRs with identical hashed owner names by replacing 772 them with a single NSEC3 RR with the Type Bit Maps field 773 consisting of the union of the types represented by the set of 774 NSEC3 RRs. If the original owner name was tracked, then 775 collisions may be detected when combining, as all of the matching 776 NSEC3 RRs should have the same original owner name. Discard any 777 possible temporary NSEC3 RRs. 779 7. In each NSEC3 RR, insert the next hashed owner name by using the 780 value of the next NSEC3 RR in hash order. The next hashed owner 781 name of the last NSEC3 RR in the zone contains the value of the 782 hashed owner name of the first NSEC3 RR in the hash order. 784 8. Finally, add an NSEC3PARAM RR with the same Hash Algorithm, 785 Iterations and Salt fields to the zone apex. 787 If a hash collision is detected, then a new salt has to be chosen and 788 the signing process restarted. 790 7.2. Zone Serving 792 This specification modifies DNSSEC-enabled DNS responses generated by 793 authoritative servers. In particular, it replaces the use of NSEC 794 RRs in such responses with NSEC3 RRs. 796 In the following response cases, the NSEC RRs dictated by DNSSEC 797 [RFC4035] are replaced with NSEC3 RRs that prove the same facts. 798 Responses that would not contain NSEC RRs are unchanged by this 799 specification. 801 When returning responses containing multiple NSEC3 RRs, all of the 802 NSEC3 RRs MUST use the same hash algorithm, iteration, and salt 803 values. The Flags field value MUST be either zero or one. 805 7.2.1. Closest Encloser Proof 807 For many NSEC3 responses a proof of the closest encloser is required. 808 This is a proof that some ancestor of the QNAME is the closest 809 encloser of QNAME. 811 This proof consists of (up to) two different NSEC3 RRs: 813 o An NSEC3 RR that matches the closest (provable) encloser. 815 o An NSEC3 RR that covers the "next closer" name to the closest 816 encloser. 818 The first NSEC3 RR essentially proposes a possible closest encloser, 819 and proves that the particular encloser does, in fact, exist. The 820 second NSEC3 RR proves that the possible closest encloser is the 821 closest, and proves that QNAME (and any ancestors between QNAME and 822 the closest encloser) do not exist. 824 These NSEC3 RRs are collectively referred to as the "closest encloser 825 proof" in the subsequent descriptions. 827 For example, the closest encloser proof for the nonexistent 828 "alpha.beta.gamma.example." owner name might prove that 829 "gamma.example." is the closest encloser. This response would 830 contain the NSEC3 RR that matches "gamma.example.", and would also 831 contain the NSEC3 RR that covers "beta.gamma.example." (which is the 832 "next closer" name.) 834 It is possible, when using Opt-Out (Section 6), to not be able to 835 prove the actual closest encloser because it is, or is part of an 836 insecure delegation covered by an Opt-Out span. In this case, 837 instead of proving the actual closest encloser, the closest provable 838 encloser is used. That is, the closest enclosing authoritative name 839 is used instead. In this case, the set of NSEC3 RRs used for this 840 proof is referred to as the "closest provable encloser proof." 842 7.2.2. Name Error Responses 844 To prove the nonexistence of QNAME a closest encloser proof and an 845 NSEC3 RR covering the (nonexistent) wildcard RR at the closest 846 encloser MUST be included in the response. This collection of (up 847 to) three NSEC3 RRs proves both that QNAME does not exist and that a 848 wildcard that could have matched QNAME also does not exist. 850 For example, if "gamma.example." is the closest provable encloser to 851 QNAME, then a NSEC3 RR covering "*.gamma.example." is included in the 852 authority section of the response. 854 7.2.3. No Data Responses, QTYPE is not DS 856 The server MUST include the NSEC3 RR that matches QNAME. This NSEC3 857 RR MUST NOT have the bits corresponding to either the QTYPE or CNAME 858 set in its Type Bit Maps field. 860 7.2.4. No Data Responses, QTYPE is DS 862 If there is an NSEC3 RR that matches QNAME, the server MUST return it 863 in the response. The bits corresponding with DS and CNAME MUST NOT 864 be set in the Type Bit Maps field of this NSEC3 RR. 866 If no NSEC3 RR matches QNAME, the server MUST return a closest 867 provable encloser proof for QNAME. The NSEC3 RR that covers the 868 "next closer" name MUST have the Opt-Out bit set (note that this is 869 true by definition - if the Opt-Out bit is not set, something has 870 gone wrong). 872 If a server is authoritative for both sides of a zone cut at QNAME, 873 the server MUST return the proof from the parent side of the zone 874 cut. 876 7.2.5. Wildcard No Data Responses 878 If there is a wildcard match for QNAME, but QTYPE is not present at 879 that name, the response MUST include a closest encloser proof for 880 QNAME and MUST include the NSEC3 RR that matches the wildcard. This 881 combination proves both that QNAME itself does not exist and that a 882 wildcard that matches QNAME does exist. Note that the closest 883 encloser to QNAME MUST be the immediate ancestor of the wildcard RR 884 (if this is not the case, then something has gone wrong). 886 7.2.6. Wildcard Answer Responses 888 If there is a wildcard match for QNAME and QTYPE, then, in addition 889 to the expanded wildcard RRSet returned in the answer section of the 890 response, proof that the wildcard match was valid must be returned. 892 This proof is accomplished by proving that both QNAME does not exist, 893 and that the closest encloser of the QNAME and the immediate ancestor 894 of the wildcard are the same (i.e., the correct wildcard matched). 896 To this end, the NSEC3 RR that covers the "next closer" name of the 897 immediate ancestor of the wildcard MUST be returned. It is not 898 necessary to return an NSEC3 RR that matches the closest encloser, as 899 the existence of this closest encloser is proven by the presence of 900 the expanded wildcard in the response. 902 7.2.7. Referrals to Unsigned Subzones 904 If there is an NSEC3 RR that matches the delegation name, then that 905 NSEC3 RR MUST be included in the response. The DS bit in the type 906 bit maps of the NSEC3 RR MUST NOT be set. 908 If the zone is Opt-Out, then there may not be an NSEC3 RR 909 corresponding to the delegation. In this case, the closest provable 910 encloser proof MUST be included in the response. The included NSEC3 911 RR that covers the "next closer" name for the delegation MUST have 912 the Opt-Out flag set to one. (Note that this will be the case unless 913 something has gone wrong). 915 7.2.8. Responding to Queries for NSEC3 Owner Names 917 The owner names of NSEC3 RRs are not represented in the NSEC3 RR 918 chain like other owner names. As a result, each NSEC3 owner name is 919 covered by another NSEC3 RR, effectively negating the existence of 920 the NSEC3 RR. This is a paradox, since the existence of an NSEC3 RR 921 can be proven by its RRSIG RRSet. 923 If the following conditions are all true: 925 o The QNAME equals the owner name of an existing NSEC3 RR, and 927 o No RR types exist at the QNAME, nor at any descendant of QNAME. 929 Then the response MUST be constructed as a Name Error response 930 (Section 7.2.2). Or, in other words, the authoritative name server 931 will act, as if the owner name of the NSEC3 RR did not exist. 933 Note that NSEC3 RRs are returned as a result of an AXFR or IXFR 934 query. 936 7.2.9. Server Response to a Run-time Collision 938 If the hash of a non-existing QNAME collides with the owner name of 939 an existing NSEC3 RR, then the server will be unable to return a 940 response that proves that QNAME does not exist. In this case, the 941 server MUST return a response with an RCODE of 2 (server failure). 943 Note that with the hash algorithm specified in this document, SHA-1, 944 such collisions are highly unlikely. 946 7.3. Secondary Servers 948 Secondary servers (and perhaps other entities) need to reliably 949 determine which NSEC3 parameters (i.e., hash, salt and iterations) 950 are present at every hashed owner name, in order to be able to choose 951 an appropriate set of NSEC3 RRs for negative responses. This is 952 indicated by an NSEC3PARAM RR present at the zone apex. 954 If there are multiple NSEC3PARAM RRs present, there are multiple 955 valid NSEC3 chains present. The server must choose one of them, but 956 may use any criteria to do so. 958 7.4. Zones Using Unknown Hash Algorithms 960 Zones that are signed according to this specification, but are using 961 an unrecognized NSEC3 hash algorithm value, cannot be effectively 962 served. Such zones SHOULD be rejected when loading. Servers SHOULD 963 respond with RCODE=2 (server failure) responses when handling queries 964 that would fall under such zones. 966 7.5. Dynamic Update 968 A zone signed using NSEC3 may accept dynamic updates [RFC2136]. 969 However, NSEC3 introduces some special considerations for dynamic 970 updates. 972 Adding and removing names in a zone MUST account for the creation or 973 removal of empty non-terminals. 975 o When removing a name with a corresponding NSEC3 RR, any NSEC3 RRs 976 corresponding to empty non-terminals created by that name MUST be 977 removed. Note that more than one name may be asserting the 978 existence of a particular empty non-terminal. 980 o When adding a name that requires adding an NSEC3 RR, NSEC3 RRs 981 MUST also be added for any empty non-terminals that are created. 982 That is, if there is not an existing NSEC3 RR matching an empty 983 non-terminal, it must be created and added. 985 The presence of Opt-Out in a zone means that some additions or 986 delegations of names will not require changes to the NSEC3 RRs in a 987 zone. 989 o When removing a delegation RRSet, if that delegation does not have 990 a matching NSEC3 RR, then it was opted out. In this case, nothing 991 further needs to be done. 993 o When adding a delegation RRSet, if the "next closer" name of the 994 delegation is covered by an existing Opt-Out NSEC3 RR, then the 995 delegation MAY be added without modifying the NSEC3 RRs in the 996 zone. 998 The presence of Opt-Out in a zone means that when adding or removing 999 NSEC3 RRs, the value of the Opt-Out flag that should be set in new or 1000 modified NSEC3 RRs is ambiguous. Servers SHOULD follow this set of 1001 basic rules to resolve the ambiguity. 1003 The central concept to these rules is that the state of the Opt-Out 1004 flag of the covering NSEC3 RR is preserved. 1006 o When removing an NSEC3 RR, the value of the Opt-Out flag for the 1007 previous NSEC3 RR (the one whose next hashed owner name is 1008 modified) should not be changed. 1010 o When adding an NSEC3 RR, the value of the Opt-Out flag is set to 1011 the value of the Opt-Out flag of the NSEC3 RR that previously 1012 covered the owner name of the NSEC3 RR. That is, the now previous 1013 NSEC3 RR. 1015 If the zone in question is consistent with its use of the Opt-Out 1016 flag (that is, all NSEC3 RRs in the zone have the same value for the 1017 flag) then these rules will retain that consistency. If the zone is 1018 not consistent in the use of the flag (i.e., a partially Opt-Out 1019 zone), then these rules will not retain the same pattern of use of 1020 the Opt-Out flag. 1022 For zones that partially use the Opt-Out flag, if there is a logical 1023 pattern for that use, the pattern could be maintained by using a 1024 local policy on the server. 1026 8. Validator Considerations 1028 8.1. Responses with Unknown Hash Types 1030 A validator MUST ignore NSEC3 RRs with unknown hash types. The 1031 practical result of this is that responses containing only such NSEC3 1032 RRs will generally be considered bogus. 1034 8.2. Verifying NSEC3 RRs 1036 A validator MUST ignore NSEC3 RRs with a Flag fields value other than 1037 zero or one. 1039 A validator MAY treat a response as bogus if the response contains 1040 NSEC3 RRs that contain different values for hash algorithm, 1041 iterations, or salt from each other for that zone. 1043 8.3. Closest Encloser Proof 1045 In order to verify a closest encloser proof, the validator MUST find 1046 the longest name, X, such that 1048 o X is an ancestor of QNAME that is matched by an NSEC3 RR present 1049 in the response. This is a candidate for the closest encloser. 1050 And: 1052 o The name one label longer than X (but still an ancestor of--or 1053 equal to--QNAME) is covered by an NSEC3 RR present in the 1054 response. 1056 One possible algorithm for verifying this proof is as follows: 1058 1. Set SNAME=QNAME. Clear the flag. 1060 2. Check whether SNAME exists: 1062 * If there is no NSEC3 RR in the response that matches SNAME 1063 (i.e., an NSEC3 RR whose owner name is the same as the hash of 1064 SNAME, prepended as a single label to the zone name), clear 1065 the flag. 1067 * If there is an NSEC3 RR in the response that covers SNAME, set 1068 the flag. 1070 * If there is a matching NSEC3 RR in the response and the flag 1071 was set, then the proof is complete, and SNAME is the closest 1072 encloser. 1074 * If there is a matching NSEC3 RR in the response, but the flag 1075 is not set, then the response is bogus. 1077 3. Truncate SNAME by one label from the left, go to step 2. 1079 Once the closest encloser has been discovered, the validator MUST 1080 check that the NSEC3 RR that has the closest encloser as the original 1081 owner name is from the proper zone. The DNAME type bit must not be 1082 set and the NS type bit may only be set if the SOA type bit is set. 1083 If this is not the case, it would be an indication that an attacker 1084 is using them to falsely deny the existence of RRs for which the 1085 server is not authoritative. 1087 In the following descriptions, the phrase "a closest (provable) 1088 encloser proof for X" means that the algorithm above (or an 1089 equivalent algorithm) proves that X does not exist by proving that an 1090 ancestor of X is its closest encloser. 1092 8.4. Validating Name Error Responses 1094 A validator MUST verify that there is a closest encloser proof for 1095 QNAME present in the response and that there is an NSEC3 RR that 1096 covers the wildcard at the closest encloser (i.e., the name formed by 1097 prepending the asterisk label to the closest encloser.) 1099 8.5. Validating No Data Responses, QTYPE is not DS 1101 The validator MUST verify that an NSEC3 RR that matches QNAME is 1102 present and that both the QTYPE and the CNAME type are not set in its 1103 Type Bit Maps field. 1105 Note that this test also covers the case where the NSEC3 RR exists 1106 because it corresponds to an empty non-terminal, in which case the 1107 NSEC3 RR will have an empty Type Bit Maps field. 1109 8.6. Validating No Data Responses, QTYPE is DS 1111 If there is an NSEC3 RR that matches QNAME present in the response, 1112 then that NSEC3 RR MUST NOT have the bits corresponding to DS and 1113 CNAME set in its Type Bit Maps field. 1115 If there is no such NSEC3 RR, then the validator MUST verify that a 1116 closest provable encloser proof for QNAME is present in the response, 1117 and that the NSEC3 RR that covers the "next closer" name has the Opt- 1118 Out bit set. 1120 8.7. Validating Wildcard No Data Responses 1122 The validator MUST verify a closest encloser proof for QNAME and MUST 1123 find an NSEC3 RR present in the response that matches the wildcard 1124 name generated by prepending the asterisk label to the closest 1125 encloser. Furthermore, the bits corresponding to both QTYPE and 1126 CNAME MUST NOT be set in the wildcard matching NSEC3 RR. 1128 8.8. Validating Wildcard Answer Responses 1130 The verified wildcard answer RRSet in the response provides the 1131 validator with a (candidate) closest encloser for QNAME. This 1132 closest encloser is the immediate ancestor to the generating 1133 wildcard. 1135 Validators MUST verify that there is an NSEC3 RR that covers the 1136 "next closer" name to QNAME present in the response. This proves 1137 that QNAME itself did not exist and that the correct wildcard was 1138 used to generate the response. 1140 8.9. Validating Referrals to Unsigned Subzones 1142 The delegation name in a referral is the owner name of the NS RRSet 1143 present in the authority section of the referral response. 1145 If there is an NSEC3 RR present in the response that matches the 1146 delegation name, then the validator MUST ensure that the NS bit is 1147 set and that the DS bit is not set in the Type Bit Maps field of the 1148 NSEC3 RR. The validator MUST also ensure that the NSEC3 RR is from 1149 the correct (i.e., parent) zone. This is done by ensuring that the 1150 SOA bit is not set in the Type Bit Maps field of this NSEC3 RR. 1152 Note that the presence of an NS bit implies the absence of a DNAME 1153 bit, so there is no need to check for the DNAME bit in the Type Bit 1154 Maps field of the NSEC3 RR. 1156 If there is no NSEC3 RR present that matches the delegation name, 1157 then the validator MUST verify a closest provable encloser proof for 1158 the delegation name. The validator MUST verify that the Opt-Out bit 1159 is set in the NSEC3 RR that covers the "next closer" name to the 1160 delegation name. 1162 9. Resolver Considerations 1164 9.1. NSEC3 Resource Record Caching 1166 Caching resolvers MUST be able to retrieve the appropriate NSEC3 RRs 1167 when returning responses that contain them. In DNSSEC [RFC4035], in 1168 many cases it is possible to find the correct NSEC RR to return in a 1169 response by name (e.g., when returning a referral, the NSEC RR will 1170 always have the same owner name as the delegation.) With this 1171 specification, that will not be true, nor will a cache be able to 1172 calculate the name(s) of the appropriate NSEC3 RR(s). 1173 Implementations may need to use new methods for caching and 1174 retrieving NSEC3 RRs. 1176 9.2. Use of the AD Bit 1178 The AD bit, as defined by [RFC4035], MUST NOT be set when returning a 1179 response containing a closest (provable) encloser proof in which the 1180 NSEC3 RR that covers the "next closer" name has the Opt-Out bit set. 1182 This rule is based on what this closest encloser proof actually 1183 proves: names that would be covered by the Opt-Out NSEC3 RR may or 1184 may not exist as insecure delegations. As such, not all the data in 1185 responses containing such closest encloser proofs will have been 1186 cryptographically verified, so the AD bit cannot be set. 1188 10. Special Considerations 1190 10.1. Domain Name Length Restrictions 1192 Zones signed using this specification have additional domain name 1193 length restrictions imposed upon them. In particular, zones with 1194 names that, when converted into hashed owner names, exceed the 255 1195 octet length limit imposed by [RFC1035] cannot use this 1196 specification. 1198 The actual maximum length of a domain name in a particular zone 1199 depends on both the length of the zone name (versus the whole domain 1200 name) and the particular hash function used. 1202 As an example, SHA-1 produces a hash of 160 bits. The base-32 1203 encoding of 160 bits results in 32 characters. The 32 characters are 1204 prepended to the name of the zone as a single label, which includes a 1205 length field of a single octet. The maximum length of the zone name, 1206 when using SHA-1, is 222 octets (255 - 33). 1208 10.2. DNAME at the Zone Apex 1210 The DNAME specification [RFC2672] section 3 has a 'no-descendants' 1211 limitation. If a DNAME RR is present at node N, there MUST be no 1212 data at any descendant of N. 1214 If N is the apex of the zone, there will be NSEC3 and RRSIG types 1215 present at descendants of N. This specification updates the DNAME 1216 specification to allow NSEC3 and RRSIG types at descendants of the 1217 apex regardless of the existence of DNAME at the apex. 1219 10.3. Iterations 1221 Setting the number of iterations used allows the zone owner to choose 1222 the cost of computing a hash, and so the cost of generating a 1223 dictionary. Note that this is distinct from the effect of salt, 1224 which prevents the use of a single precomputed dictionary for all 1225 time. 1227 Obviously the number of iterations also affects the zone owner's cost 1228 of signing and serving the zone as well as the validator's cost of 1229 verifying responses from the zone. We therefore impose an upper 1230 limit on the number of iterations. We base this on the number of 1231 iterations that approximates the cost of verifying an RRSet. 1233 The limits, therefore, are based on the size of the smallest zone 1234 signing key, rounded up to the nearest table value (or rounded down 1235 if the key is larger than the largest table value.) 1236 A zone owner MUST NOT use a value higher than shown in the table 1237 below for iterations for the given key size. A resolver MAY treat a 1238 response with a higher value as insecure, after the validator has 1239 verified that the signature over the NSEC3 RR is correct. 1241 +----------+------------+ 1242 | Key Size | Iterations | 1243 +----------+------------+ 1244 | 1024 | 150 | 1245 | 2048 | 500 | 1246 | 4096 | 2,500 | 1247 +----------+------------+ 1249 This table is based on an approximation of the ratio between the cost 1250 of an SHA-1 calculation and the cost of an RSA verification for keys 1251 of size 1024 bits (150 to 1), 2048 bits (500 to 1) and 4096 bits 1252 (2500 to 1). 1254 The ratio between SHA-1 calculation and DSA verification is higher 1255 (1500 to 1 for keys of size 1024). A higher iteration count degrades 1256 performance, while DSA verification is already more expensive than 1257 RSA for the same key size. Therefore the values in the table MUST be 1258 used independent of the key algorithm. 1260 10.4. Transitioning a Signed Zone from NSEC to NSEC3 1262 When transitioning an already signed and trusted zone to this 1263 specification, care must be taken to prevent client validation 1264 failures during the process. 1266 The basic procedure is as follows: 1268 1. Transition all DNSKEYs to DNSKEYs using the algorithm aliases 1269 described in Section 2. The actual method for safely and 1270 securely changing the DNSKEY RRSet of the zone is outside the 1271 scope of this specification. However, the end result MUST be 1272 that all DS RRs in the parent use the specified algorithm 1273 aliases. 1275 After this transition is complete, all NSEC3-unaware clients will 1276 treat the zone as insecure. At this point, the authoritative 1277 server still returns negative and wildcard responses that contain 1278 NSEC RRs. 1280 2. Add signed NSEC3 RRs to the zone, either incrementally or all at 1281 once. If adding incrementally, then the last RRSet added MUST be 1282 the NSEC3PARAM RRSet. 1284 3. Upon the addition of the NSEC3PARAM RRSet, the server switches to 1285 serving negative and wildcard responses with NSEC3 RRs according 1286 to this specification. 1288 4. Remove the NSEC RRs either incrementally or all at once. 1290 10.5. Transitioning a Signed Zone From NSEC3 to NSEC 1292 To safely transition back to a DNSSEC [RFC4035] signed zone, simply 1293 reverse the procedure above: 1295 1. Add NSEC RRs incrementally or all at once. 1297 2. Remove the NSEC3PARAM RRSet. This will signal the server to use 1298 the NSEC RRs for negative and wildcard responses. 1300 3. Remove the NSEC3 RRs either incrementally or all at once. 1302 4. Transition all of the DNSKEYs to DNSSEC algorithm identifiers. 1303 After this transition is complete, all NSEC3-unaware clients will 1304 treat the zone as secure. 1306 11. IANA Considerations 1308 Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm 1309 parameter, this document does not define a particular mechanism for 1310 safely transitioning from one NSEC3 hash algorithm to another. When 1311 specifying a new hash algorithm for use with NSEC3, a transition 1312 mechanism MUST also be defined. 1314 This document updates the IANA registry "DOMAIN NAME SYSTEM 1315 PARAMETERS" [http://www.iana.org/assignments/dns-parameters] in sub- 1316 registry "TYPES", by defining two new types. Section 3 defines the 1317 NSEC3 RR type NN, (value 50 suggested). Section 4 defines the 1318 NSEC3PARAM RR type MM (value 51 suggested). 1320 This document updates the IANA registry "DNS SECURITY ALGORITHM 1321 NUMBERS - per [RFC4035]" 1322 http://www.iana.org/assignments/dns-sec-alg-numbers]. Section 2 1323 defines the aliases DSA-NSEC3-SHA1 (XX) and RSASHA1-NSEC3-SHA1 (YY) 1324 for respectively existing registrations DSA and RSASHA1 in 1325 combination with NSEC3 hash algorithm SHA1. 1327 Since these algorithm numbers are aliases for existing DNSKEY 1328 algorithm numbers, the flags that exist for the original algorithm 1329 are valid for the alias algorithm. 1331 This document creates a new IANA registry for NSEC3 flags. This 1332 registry should be named "DNSSEC NSEC3 Flags". The initial contents 1333 of this registry are: 1335 0 1 2 3 4 5 6 7 1336 +---+---+---+---+---+---+---+---+ 1337 | | | | | | | |Opt| 1338 | | | | | | | |Out| 1339 +---+---+---+---+---+---+---+---+ 1341 bit 7 is the Opt-Out flag. 1343 bits 0 - 6 are available for assignment. 1345 Assignment of additional NSEC3 Flags in this registry requires IETF 1346 Standards Action [RFC2434]. 1348 This document creates a new IANA registry for NSEC3PARAM flags. This 1349 registry should be named "DNSSEC NSEC3PARAM Flags". The initial 1350 contents of this registry are: 1352 0 1 2 3 4 5 6 7 1353 +---+---+---+---+---+---+---+---+ 1354 | | | | | | | | 0 | 1355 +---+---+---+---+---+---+---+---+ 1357 bit 7 is reserved and must be 0. 1359 bits 0 - 6 are available for assignment. 1361 Assignment of additional NSEC3PARAM Flags in this registry requires 1362 IETF Standards Action [RFC2434]. 1364 Finally, this document creates a new IANA registry for NSEC3 hash 1365 algorithms. This registry should be named "DNSSEC NSEC3 Hash 1366 Algorithms". The initial contents of this registry are: 1368 0 is Reserved 1370 1 is SHA-1. 1372 2-255 Available for assignment 1374 Assignment of additional NSEC3 hash algorithms in this registry 1375 requires IETF Standards Action [RFC2434]. 1377 12. Security Considerations 1379 12.1. Hashing Considerations 1381 12.1.1. Dictionary Attacks 1383 The NSEC3 RRs are still susceptible to dictionary attacks (i.e. the 1384 attacker retrieves all the NSEC3 RRs, then calculates the hashes of 1385 all likely domain names, comparing against the hashes found in the 1386 NSEC3 RRs, and thus enumerating the zone). These are substantially 1387 more expensive than enumerating the original NSEC RRs would have 1388 been, and in any case, such an attack could also be used directly 1389 against the name server itself by performing queries for all likely 1390 names, though this would obviously be more detectable. The expense 1391 of this off-line attack can be chosen by setting the number of 1392 iterations in the NSEC3 RR. 1394 Zones are also susceptible to a pre-calculated dictionary attack -- 1395 that is, a list of hashes for all likely names is computed once, then 1396 NSEC3 RR is scanned periodically and compared against the precomputed 1397 hashes. This attack is prevented by changing the salt on a regular 1398 basis. 1400 The salt SHOULD be at least 64 bits long and unpredictable, so that 1401 an attacker cannot anticipate the value of the salt and compute the 1402 next set of dictionaries before the zone is published. 1404 12.1.2. Collisions 1406 Hash collisions between QNAME and the owner name of an NSEC3 RR may 1407 occur. When they do, it will be impossible to prove the non- 1408 existence of the colliding QNAME. However, with SHA-1, this is 1409 highly unlikely (on the order of 1 in 2^160). Note that DNSSEC 1410 already relies on the presumption that a cryptographic hash function 1411 is second pre-image resistant, since these hash functions are used 1412 for generating and validating signatures and DS RRs. 1414 12.1.3. Transitioning to a New Hash Algorithm 1416 Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm 1417 parameter, this document does not define a particular mechanism for 1418 safely transitioning from one NSEC3 hash algorithm to another. When 1419 specifying a new hash algorithm for use with NSEC3, a transition 1420 mechanism MUST also be defined. It is possible that the only 1421 practical and palatable transition mechanisms may require an 1422 intermediate transition to an insecure state, or to a state that uses 1423 NSEC records instead of NSEC3. 1425 12.1.4. Using High Iteration Values 1427 Since validators should treat responses containing NSEC3 RRs with 1428 high iteration values as insecure, presence of just one signed NSEC3 1429 RR with a high iteration value in a zone provides attackers with a 1430 possible downgrade attack. 1432 The attack is simply to remove any existing NSEC3 RRs from a 1433 response, and replace or add a single (or multiple) NSEC3 RR that 1434 uses a high iterations value to the response. Validators will then 1435 be forced to treat the response as insecure. This attack would be 1436 effective only when all of following conditions are met: 1438 o There is at least one signed NSEC3 RR that uses a high iterations 1439 value present in the zone. 1441 o The attacker has access to one or more of these NSEC3 RRs. This 1442 is trivially true when the NSEC3 RRs with high iterations values 1443 are being returned in typical responses, but may also be true if 1444 the attacker can access the zone via AXFR or IXFR queries, or any 1445 other methodology. 1447 Using a high number of iterations also introduces an additional 1448 denial-of-service opportunity against servers, since servers must 1449 calculate several hashes per negative or wildcard response. 1451 12.2. Opt-Out Considerations 1453 The Opt-Out Flag (O) allows for unsigned names, in the form of 1454 delegations to unsigned zones, to exist within an otherwise signed 1455 zone. All unsigned names are, by definition, insecure, and their 1456 validity or existence cannot be cryptographically proven. 1458 In general: 1460 o Resource records with unsigned names (whether existing or not) 1461 suffer from the same vulnerabilities as RRs in an unsigned zone. 1462 These vulnerabilities are described in more detail in [RFC3833] 1463 (note in particular sections 2.3, "Name Chaining" and 2.6, 1464 "Authenticated Denial of Domain Names"). 1466 o Resource records with signed names have the same security whether 1467 or not Opt-Out is used. 1469 Note that with or without Opt-Out, an insecure delegation may be 1470 undetectably altered by an attacker. Because of this, the primary 1471 difference in security when using Opt-Out is the loss of the ability 1472 to prove the existence or nonexistence of an insecure delegation 1473 within the span of an Opt-Out NSEC3 RR. 1475 In particular, this means that a malicious entity may be able to 1476 insert or delete RRs with unsigned names. These RRs are normally NS 1477 RRs, but this also includes signed wildcard expansions (while the 1478 wildcard RR itself is signed, its expanded name is an unsigned name). 1480 Note that being able to add a delegation is functionally equivalent 1481 to being able to add any RR type: an attacker merely has to forge a 1482 delegation to name server under his/her control and place whatever 1483 RRs needed at the subzone apex. 1485 While in particular cases, this issue may not present a significant 1486 security problem, in general it should not be lightly dismissed. 1487 Therefore, it is strongly RECOMMENDED that Opt-Out be used sparingly. 1488 In particular, zone signing tools SHOULD NOT default to using Opt- 1489 Out, and MAY choose to not support Opt-Out at all. 1491 12.3. Other Considerations 1493 Walking the NSEC3 RRs will reveal the total number of RRs in the zone 1494 (plus empty non-terminals), and also what types there are. This 1495 could be mitigated by adding dummy entries, but certainly an upper 1496 limit can always be found. 1498 13. References 1500 13.1. Normative References 1502 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1503 STD 13, RFC 1034, November 1987. 1505 [RFC1035] Mockapetris, P., "Domain names - implementation and 1506 specification", STD 13, RFC 1035, November 1987. 1508 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1509 Requirement Levels", BCP 14, RFC 2119, March 1997. 1511 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 1512 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1513 RFC 2136, April 1997. 1515 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1516 Specification", RFC 2181, July 1997. 1518 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1519 NCACHE)", RFC 2308, March 1998. 1521 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1522 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1523 October 1998. 1525 [RFC2929] Eastlake, D., Brunner-Williams, E., and B. Manning, 1526 "Domain Name System (DNS) IANA Considerations", BCP 42, 1527 RFC 2929, September 2000. 1529 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 1530 (RR) Types", RFC 3597, September 2003. 1532 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1533 Rose, "DNS Security Introduction and Requirements", 1534 RFC 4033, March 2005. 1536 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1537 Rose, "Resource Records for the DNS Security Extensions", 1538 RFC 4034, March 2005. 1540 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1541 Rose, "Protocol Modifications for the DNS Security 1542 Extensions", RFC 4035, March 2005. 1544 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1545 Encodings", RFC 4648, October 2006. 1547 13.2. Informative References 1549 [I-D.jas-dnsext-no] 1550 Josefsson, S., "Authenticating denial of existence in DNS 1551 with minimum disclosure", draft-jas-dnsext-no-00 (work in 1552 progress), July 2000. 1554 [I-D.laurie-dnsext-nsec2v2] 1555 Laurie, B., "DNSSEC NSEC2 Owner and RDATA Format", 1556 draft-laurie-dnsext-nsec2v2-00 (work in progress), 1557 December 2004. 1559 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", 1560 RFC 2672, August 1999. 1562 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 1563 Specification Version 2.0", RFC 2898, September 2000. 1565 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 1566 Name System (DNS)", RFC 3833, August 2004. 1568 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 1569 System", RFC 4592, July 2006. 1571 [RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS Security 1572 (DNSSEC) Opt-In", RFC 4956, July 2007. 1574 Appendix A. Example Zone 1576 This is a zone showing its NSEC3 RRs. They can also be used as test 1577 vectors for the hash algorithm. 1579 The overall TTL and class are specified in the SOA RR, and are 1580 subsequently omitted for clarity. 1582 The zone is preceded by a list that contains the hashes of the 1583 original ownernames. 1585 ; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom 1586 ; H(a.example) = 35mthgpgcu1qg68fab165klnsnk3dpvl 1587 ; H(ai.example) = gjeqe526plbf1g8mklp59enfd789njgi 1588 ; H(ns1.example) = 2t7b4g4vsa5smi47k61mv5bv1a22bojr 1589 ; H(ns2.example) = q04jkcevqvmu85r014c7dkba38o0ji5r 1590 ; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h 1591 ; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en 1592 ; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995 1593 ; H(y.w.example) = ji6neoaepv8b5o6k4ev33abha8ht9fgc 1594 ; H(x.y.w.example) = 2vptu5timamqttgl4luu9kg21e0aor3s 1595 ; H(xx.example) = t644ebqk9bibcna874givr6joj62mlhv 1596 ; H(2t7b4g4vsa5smi47k61mv5bv1a22bojr.example) 1597 ; = kohar7mbb8dc2ce8a9qvl8hon4k53uhi 1598 example. 3600 IN SOA ns1.example. bugs.x.w.example. 1 3600 300 ( 1599 3600000 3600 ) 1600 RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( 1601 62827 example. 1602 hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ 1603 ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ 1604 rynLZNqsbLm40Q== ) 1605 NS ns1.example. 1606 NS ns2.example. 1607 RRSIG NS 133 1 3600 20150420235959 20051021000000 ( 1608 62827 example. 1609 D9+iBwcbeKL5+TorTfYn4/pLr2lSFwyGYCyM 1610 gfq4TpFaZpxrCJPLxHbKjdkR18jAt7+SR7B5 1611 JpiZcff2Cj2B0w== ) 1612 MX 1 xx.example. 1613 RRSIG MX 133 1 3600 20150420235959 20051021000000 ( 1614 62827 example. 1616 jsGuTpXTTrZHzUKnViUpJ8YyGNpDd6n/sy2g 1617 HnSC0nj2jPxTC5VENLo3GxSpCSA5DlAz57p+ 1618 RllUJk3DWktkjw== ) 1619 DNSKEY 256 3 133 ( 1620 AQO0gEmbZUL6xbD/xQczHbnwYnf+jQjwz/sU 1621 5k44rHTt0Ty+3aOdYoome9TjGMhwkkGby1TL 1622 ExXT48OGGdbfIme5 ) 1623 DNSKEY 257 3 133 ( 1624 AQOnsGyJvywVjYmiLbh0EwIRuWYcDiB/8blX 1625 cpkoxtpe19Oicv6Zko+8brVsTMeMOpcUeGB1 1626 zsYKWJ7BvR2894hX ) 1627 RRSIG DNSKEY 133 1 3600 20150420235959 ( 1628 20051021000000 22088 example. 1629 Xpo9ptByXb8M1JR1i0KuRmKGc/YeOLcc6Ptn 1630 RJOx6ADLSL2mU6AYX5tAJRMTKTXk6waLIaxu 1631 liqUBOkCjLUZMw== ) 1632 NSEC3PARAM 1 0 12 aabbccdd 1633 RRSIG NSEC3PARAM 133 1 3600 20150420235959 ( 1634 20051021000000 62827 example. 1635 pwUfI8cF9JJn5dTWI24nJy92HYrRPtPgHtgi 1636 jAlKx9QELe68pLKuGU/8Sf87kyV7yMXJYVhf 1637 HIB8wmHllsqM+g== ) 1638 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( 1639 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS 1640 SOA NSEC3PARAM RRSIG ) 1641 RRSIG NSEC3 133 2 3600 20150420235959 ( 1642 20051021000000 62827 example. 1643 rn2tv99+9StXbc7JaEnjT1+8I8f2vVOMOIbF 1644 xzlrn94lQLxEOYxQR4SrxDRP4/fC54Jui0Ix 1645 4eI9tMfaTVgehQ== ) 1646 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. A 192.0.2.127 1647 RRSIG A 133 2 3600 20150420235959 20051021000000 ( 1648 62827 example. 1649 GtJTFlvT5eYaK3rNUPQjpCKoIefvWZxQrDxU 1650 jYsmoIWdLOVOuD5ZSDDQA3anDctOHdA/XbXn 1651 o2uyWso1OzVlgg== ) 1652 NSEC3 1 1 12 aabbccdd ( 1653 2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG ) 1654 RRSIG NSEC3 133 2 3600 20150420235959 ( 1655 20051021000000 62827 example. 1656 fJER1Z3nGoN0HmZm99lqNLSpIf7jLXTMoGm2 1657 k4gIwlc0R4DztJp6Sq37OV6XnGdre4MfgRpB 1658 mAcgpPWC5A5eiw== ) 1659 2vptu5timamqttgl4luu9kg21e0aor3s.example. NSEC3 1 1 12 aabbccdd ( 1660 35mthgpgcu1qg68fab165klnsnk3dpvl MX RRSIG ) 1661 RRSIG NSEC3 133 2 3600 20150420235959 ( 1662 20051021000000 62827 example. 1663 os2mHXmu3bsaWu0XzT1R61fHL1a3LvyQ6bKq 1664 oKokSyJ0ch0jBqEdxP2BqUe0WW0ja19fQGCG 1665 8Bc+L9MbAeYsrw== ) 1666 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd ( 1667 b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG ) 1668 RRSIG NSEC3 133 2 3600 20150420235959 ( 1669 20051021000000 62827 example. 1670 QrjOpXVIvodCw0O8uPMNA+yEeS/o3KKkEIPX 1671 r5DoEShq2hymAsRTc/t9BvRKpcSTExyc5m3T 1672 vYN3GgN0W/0WHQ== ) 1673 a.example. NS ns1.a.example. 1674 NS ns2.a.example. 1675 DS 58470 5 1 ( 1676 3079F1593EBAD6DC121E202A8B766A6A4837206C ) 1677 RRSIG DS 133 2 3600 20150420235959 20051021000000 ( 1678 62827 example. 1679 qxw4j5LNe70UDu121YqAaqQjyjYbdKNd/4bE 1680 nH0kjQswuiGs9EuArCBhcWocWQDBku+A4HMH 1681 JdLqJr5p4JctLg== ) 1682 ns1.a.example. A 192.0.2.5 1683 ns2.a.example. A 192.0.2.6 1684 ai.example. A 192.0.2.9 1685 RRSIG A 133 2 3600 20150420235959 20051021000000 ( 1686 62827 example. 1687 qfXAvKr5o3Jixy5KXnVMEhABo3DDHYSR5+Ag 1688 lVxWCExWGMokdkafjW8Hb54+GrOFp/xmDoj5 1689 BXfXAqURwLqznA== ) 1690 HINFO "KLH-10" "ITS" 1691 RRSIG HINFO 133 2 3600 20150420235959 ( 1692 20051021000000 62827 example. 1693 BuDv+No06VEcIsEnvBdjdKm6kxQGrhOgKEKb 1694 Gsb8DJRjY7Lia+YG2//s6OlOIfxPmLlLiYpA 1695 i3q2sEjTJhocGQ== ) 1696 AAAA 2001:db8:0:0:0:0:f00:baa9 1697 RRSIG AAAA 133 2 3600 20150420235959 ( 1698 20051021000000 62827 example. 1699 m65zc0A16Xbx3jYb0t5vPwMzE2xS15mKh76M 1700 hSuKfiFVhBFcQ9IilEM0pXnLzt3ozrM/3X0x 1701 2ruyuN0zC+PABA== ) 1702 b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd ( 1703 gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG ) 1704 RRSIG NSEC3 133 2 3600 20150420235959 ( 1705 20051021000000 62827 example. 1706 GWDmUk8Sv0dxy/UZFol4Ss7Wz3wBiongcnVy 1707 strNODWwdnoO9z6pDh8JLk58ExfEgXm79i4b 1708 Ma6C/s/bkk1LvA== ) 1709 c.example. NS ns1.c.example. 1710 NS ns2.c.example. 1711 ns1.c.example. A 192.0.2.7 1712 ns2.c.example. A 192.0.2.8 1713 gjeqe526plbf1g8mklp59enfd789njgi.example. NSEC3 1 1 12 aabbccdd ( 1714 ji6neoaepv8b5o6k4ev33abha8ht9fgc HINFO A AAAA 1715 RRSIG ) 1716 RRSIG NSEC3 133 2 3600 20150420235959 ( 1717 20051021000000 62827 example. 1718 DCkJyHQSgA9HNA2AQUENLfmAdAqQ4iIcuqZV 1719 pF2x/i1UyWIBuV25iESs4hhwRVIU5uMZaBGE 1720 lNwi0H6f66BpOA== ) 1721 ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd ( 1722 k8udemvp1j2f7eg6jebps17vp3n8i58h ) 1723 RRSIG NSEC3 133 2 3600 20150420235959 ( 1724 20051021000000 62827 example. 1725 fvKWkD3lXNLyUn0/gN+i3Z8301oRujSFFrJy 1726 SfAPS2Q1bw1Q5eQoy7IE+ZtUVO15ha6C9cUh 1727 CArJyEk247MADA== ) 1728 k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd ( 1729 kohar7mbb8dc2ce8a9qvl8hon4k53uhi ) 1730 RRSIG NSEC3 133 2 3600 20150420235959 ( 1731 20051021000000 62827 example. 1732 IKJfInxfypsDiXKgT6HDvCPEIBu9lZCc0CWl 1733 c46+Gj/Jrg1NBkSJkKMjCERp1HT8tKU+zYp5 1734 Kyio/cddEaa5Gg== ) 1735 kohar7mbb8dc2ce8a9qvl8hon4k53uhi.example. NSEC3 1 1 12 aabbccdd ( 1736 q04jkcevqvmu85r014c7dkba38o0ji5r A RRSIG ) 1737 RRSIG NSEC3 133 2 3600 20150420235959 ( 1738 20051021000000 62827 example. 1739 j+XRmZBLAu/s0Ah49x7SChH2VsXAMD3nJE0m 1740 UEjzrjFxkdjhdIAFNlvPMn8gy6mIVe5eNc3r 1741 4+2KaJUEJhyUEQ== ) 1742 ns1.example. A 192.0.2.1 1743 RRSIG A 133 2 3600 20150420235959 20051021000000 ( 1744 62827 example. 1745 ratEKfeWD/pJJHO/XqEINvOp3so7pn9Pphxn 1746 fRiCOVsa527M/ucRcQqGYCF0CN4jAXhW+6BS 1747 ZzT0om+VdioRmg== ) 1748 ns2.example. A 192.0.2.2 1749 RRSIG A 133 2 3600 20150420235959 20051021000000 ( 1750 62827 example. 1751 mW/DJMbQyD5y5C+a70vWyIWZyQ+Xg1zzkWHX 1752 w3jfqmePgpdJnMrpGOcRIpy5irCFWiCwTp2o 1753 cPT+k0ccpxtkLQ== ) 1754 q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd ( 1755 r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG ) 1756 RRSIG NSEC3 133 2 3600 20150420235959 ( 1757 20051021000000 62827 example. 1758 ktIfH8VRjEKYPB0Qf4EdTuSlYn4DVSRRaGWc 1759 kVGmKzreEU5zs97CL8OQSa6C0JZX2yMBXijC 1760 Wu6EvgCXrflgiQ== ) 1761 r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd ( 1762 t644ebqk9bibcna874givr6joj62mlhv MX RRSIG ) 1763 RRSIG NSEC3 133 2 3600 20150420235959 ( 1764 20051021000000 62827 example. 1765 SzeyaiFOy9dFO1RKHAK4uVCb5GF4rNnxFMXu 1766 6hpM44cmLcDgshlnG1CwkkcihfKOiPIBWd7I 1767 bGhsbhqrBrn5Dg== ) 1768 t644ebqk9bibcna874givr6joj62mlhv.example. NSEC3 1 1 12 aabbccdd ( 1769 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom HINFO A AAAA 1770 RRSIG ) 1771 RRSIG NSEC3 133 2 3600 20150420235959 ( 1772 20051021000000 62827 example. 1773 hkULY2VaEg8lvI0cf+YkUB0rvOORGMGJnfms 1774 h2OecPBYfI9XGUBvqgIyNpNpK3nIFoW/VNO+ 1775 3H+6P1NzivDmog== ) 1776 *.w.example. MX 1 ai.example. 1777 RRSIG MX 133 2 3600 20150420235959 20051021000000 ( 1778 62827 example. 1779 DnT0Y6dRBM8f3v8HdKmZUsGVkXh+b+htujCR 1780 c423x6c8erEMGVnxcrmcrZ53qGXcMYJ+TDkq 1781 a7Xfz/f9xzvSTw== ) 1782 x.w.example. MX 1 xx.example. 1783 RRSIG MX 133 3 3600 20150420235959 20051021000000 ( 1784 62827 example. 1785 BLSDMos8kYR7+2U7iwwdqdhU82hzq0s57xtw 1786 F08tWU/d19jrNO6LdWfBL/FJ8zL8ZpEjhh6b 1787 8cj0f5yQOUyShw== ) 1788 x.y.w.example. MX 1 xx.example. 1789 RRSIG MX 133 4 3600 20150420235959 20051021000000 ( 1790 62827 example. 1791 GPzELyUCxrnyep8uMcqthUXjTqYBmgeaveb9 1792 2vQgzUyPLLamNN/YqMHr6tGQNxeMAhclxUSQ 1793 eoCggUBVhFfB1Q== ) 1794 xx.example. A 192.0.2.10 1795 RRSIG A 133 2 3600 20150420235959 20051021000000 ( 1796 62827 example. 1797 Sz+fPqY8II1VDq+dY48Q40dq1aoBR2RAuhKg 1798 QNKXEYcULtJo/hxxfEAkJSNBKU5QnHpnnT9L 1799 jqaSdob7ZhdxHg== ) 1800 HINFO "KLH-10" "TOPS-20" 1801 RRSIG HINFO 133 2 3600 20150420235959 ( 1802 20051021000000 62827 example. 1803 YJFwmD0By0NpGEvO1nE1ZTH10XrmpKnVuAEI 1804 cAxLLHyPs3qyGQdDEG7sQX5+PfiOGZrNmZef 1805 8NgQhW8kGEgN1Q== ) 1806 AAAA 2001:db8:0:0:0:0:f00:baaa 1807 RRSIG AAAA 133 2 3600 20150420235959 ( 1808 20051021000000 62827 example. 1809 VAJBlXoTOScrIM6yPlDsd9o05v39qIzFnemR 1810 2vgw1s4l8maJVWi9IHEg8oiypJvGwSCP1nFs 1811 EOlXyNFQJ0fWGA== ) 1813 Appendix B. Example Responses 1815 The examples in this section show response messages using the signed 1816 zone example in Appendix A. 1818 B.1. Name Error 1820 An authoritative name error. The NSEC3 RRs prove that the name does 1821 not exist and that there is no wildcard RR that should have been 1822 expanded. 1824 ;; Header: QR AA DO RCODE=3 1825 ;; 1826 ;; Question 1827 a.c.x.w.example. IN A 1829 ;; Answer 1830 ;; (empty) 1832 ;; Authority 1834 example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( 1835 3600000 3600 ) 1836 example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( 1837 62827 example. 1838 hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ 1839 ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ 1840 rynLZNqsbLm40Q== ) 1842 ;; NSEC3 RR that covers the "next closer" name (c.x.w.example) 1843 ;; H(c.x.w.example) = 0va5bpr2ou0vk0lbqeeljri88laipsfh 1845 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( 1846 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS 1847 SOA NSEC3PARAM RRSIG ) 1848 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 133 2 3600 ( 1849 20150420235959 20051021000000 62827 example. 1850 rn2tv99+9StXbc7JaEnjT1+8I8f2vVOMOIbF 1851 xzlrn94lQLxEOYxQR4SrxDRP4/fC54Jui0Ix 1852 4eI9tMfaTVgehQ== ) 1854 ;; NSEC3 RR that matches the closest encloser (x.w.example) 1855 ;; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995 1857 b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd ( 1858 gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG ) 1859 b4um86eghhds6nea196smvmlo4ors995.example. RRSIG NSEC3 133 2 3600 ( 1860 20150420235959 20051021000000 62827 example. 1861 GWDmUk8Sv0dxy/UZFol4Ss7Wz3wBiongcnVy 1862 strNODWwdnoO9z6pDh8JLk58ExfEgXm79i4b 1863 Ma6C/s/bkk1LvA== ) 1865 ;; NSEC3 RR that covers wildcard at the closest encloser (*.x.w.example) 1866 ;; H(*.x.w.example) = 92pqneegtaue7pjatc3l3qnk738c6v5m 1868 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd ( 1869 b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG ) 1870 35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 133 2 3600 ( 1871 20150420235959 20051021000000 62827 example. 1872 QrjOpXVIvodCw0O8uPMNA+yEeS/o3KKkEIPX 1873 r5DoEShq2hymAsRTc/t9BvRKpcSTExyc5m3T 1874 vYN3GgN0W/0WHQ== ) 1876 ;; Additional 1877 ;; (empty) 1879 The query returned three NSEC3 RRs that prove that the requested data 1880 does not exist and that no wildcard expansion applies. The negative 1881 response is authenticated by verifying the NSEC3 RRs. The 1882 corresponding RRSIGs indicate that the NSEC3 RRs are signed by an 1883 "example" DNSKEY of algorithm 133 and with key tag 62827. The 1884 resolver needs the corresponding DNSKEY RR in order to authenticate 1885 this answer. 1887 One of the owner names of the NSEC3 RRs matches the closest encloser. 1888 One of the NSEC3 RRs prove that there exists no longer name. One of 1889 the NSEC3 RRs prove that there exists no wildcard RRSets that should 1890 have been expanded. The closest encloser can be found by applying 1891 the algorithm in section Section 8.3. 1893 In the above example, the name 'x.w.example' hashes to 1894 'b4um86eghhds6nea196smvmlo4ors995'. This indicates that this might 1895 be the closest encloser. To prove that 'c.x.w.example' and 1896 '*.x.w.example' do not exist, these names are hashed to, 1897 respectively, '0va5bpr2ou0vk0lbqeeljri88laipsfh' and 1898 '92pqneegtaue7pjatc3l3qnk738c6v5m'. The first and last NSEC3 RRs 1899 prove that these hashed owner names do not exist. 1901 B.2. No Data Error 1903 A "no data" response. The NSEC3 RR proves that the name exists and 1904 that the requested RR type does not. 1906 ;; Header: QR AA DO RCODE=0 1907 ;; 1908 ;; Question 1909 ns1.example. IN MX 1911 ;; Answer 1912 ;; (empty) 1914 ;; Authority 1915 example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( 1916 3600000 3600 ) 1917 example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( 1918 62827 example. 1919 hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ 1920 ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ 1921 rynLZNqsbLm40Q== ) 1923 ;; NSEC3 RR matches the QNAME and shows that the MX type bit is not set. 1925 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. NSEC3 1 1 12 aabbccdd ( 1926 2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG ) 1927 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. RRSIG NSEC3 133 2 3600 ( 1928 20150420235959 20051021000000 62827 example. 1929 fJER1Z3nGoN0HmZm99lqNLSpIf7jLXTMoGm2 1930 k4gIwlc0R4DztJp6Sq37OV6XnGdre4MfgRpB 1931 mAcgpPWC5A5eiw== ) 1932 ;; Additional 1933 ;; (empty) 1935 The query returned an NSEC3 RR that proves that the requested name 1936 exists ("ns1.example." hashes to "2t7b4g4vsa5smi47k61mv5bv1a22bojr"), 1937 but the requested RR type does not exist (type MX is absent in the 1938 type code list of the NSEC3 RR), and was not a CNAME (type CNAME is 1939 also absent in the type code list of the NSEC3 RR.) 1941 B.2.1. No Data Error, Empty Non-Terminal 1943 A "no data" response because of an empty non-terminal. The NSEC3 RR 1944 proves that the name exists and that the requested RR type does not. 1946 ;; Header: QR AA DO RCODE=0 1947 ;; 1948 ;; Question 1949 y.w.example. IN A 1951 ;; Answer 1952 ;; (empty) 1954 ;; Authority 1955 example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( 1956 3600000 3600 ) 1957 example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( 1958 62827 example. 1959 hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ 1960 ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ 1961 rynLZNqsbLm40Q== ) 1963 ;; NSEC3 RR matches the QNAME and shows that the A type bit is not set. 1965 ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd ( 1966 k8udemvp1j2f7eg6jebps17vp3n8i58h ) 1967 ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. RRSIG NSEC3 133 2 3600 ( 1968 20150420235959 20051021000000 62827 example. 1969 fvKWkD3lXNLyUn0/gN+i3Z8301oRujSFFrJy 1970 SfAPS2Q1bw1Q5eQoy7IE+ZtUVO15ha6C9cUh 1971 CArJyEk247MADA== ) 1973 ;; Additional 1974 ;; (empty) 1976 The query returned an NSEC3 RR that proves that the requested name 1977 exists ("y.w.example." hashes to "ji6neoaepv8b5o6k4ev33abha8ht9fgc"), 1978 but the requested RR type does not exist (Type A is absent in the 1979 Type Bit Maps field of the NSEC3 RR). Note that, unlike an empty 1980 non-terminal proof using NSECs, this is identical to a No Data Error. 1981 This example is solely mentioned to be complete. 1983 B.3. Referral to an Opt-Out Unsigned Zone 1985 The NSEC3 RRs prove that nothing for this delegation was signed. 1986 There is no proof that the unsigned delegation exists. 1988 ;; Header: QR DO RCODE=0 1989 ;; 1990 ;; Question 1991 mc.c.example. IN MX 1993 ;; Answer 1994 ;; (empty) 1996 ;; Authority 1997 c.example. NS ns1.c.example. 1998 NS ns2.c.example. 2000 ;; NSEC3 RR that covers the "next closer" name (c.example) 2001 ;; H(c.example) = 4g6p9u5gvfshp30pqecj98b3maqbn1ck 2003 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd ( 2004 b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG ) 2005 35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 133 2 3600 ( 2006 20150420235959 20051021000000 62827 example. 2007 QrjOpXVIvodCw0O8uPMNA+yEeS/o3KKkEIPX 2008 r5DoEShq2hymAsRTc/t9BvRKpcSTExyc5m3T 2009 vYN3GgN0W/0WHQ== ) 2011 ;; NSEC3 RR that matches the closest encloser (example) 2012 ;; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom 2014 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( 2015 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS 2016 SOA NSEC3PARAM RRSIG ) 2017 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 133 2 3600 ( 2018 20150420235959 20051021000000 62827 example. 2019 rn2tv99+9StXbc7JaEnjT1+8I8f2vVOMOIbF 2020 xzlrn94lQLxEOYxQR4SrxDRP4/fC54Jui0Ix 2021 4eI9tMfaTVgehQ== ) 2023 ;; Additional 2024 ns1.c.example. A 192.0.2.7 2025 ns2.c.example. A 192.0.2.8 2027 The query returned a referral to the unsigned "c.example." zone. The 2028 response contains the closest provable encloser of "c.example" to be 2029 "example", since the hash of "c.example" 2030 ("4g6p9u5gvfshp30pqecj98b3maqbn1ck") is covered by the first NSEC3 RR 2031 and its Opt-Out bit is set. 2033 B.4. Wildcard Expansion 2035 A query that was answered with a response containing a wildcard 2036 expansion. The label count in the RRSIG RRSet in the answer section 2037 indicates that a wildcard RRSet was expanded to produce this 2038 response, and the NSEC3 RR proves that no "next closer" name exists 2039 in the zone. 2041 ;; Header: QR AA DO RCODE=0 2042 ;; 2043 ;; Question 2044 a.z.w.example. IN MX 2046 ;; Answer 2047 a.z.w.example. MX 1 ai.example. 2048 a.z.w.example. RRSIG MX 133 2 3600 20150420235959 20051021000000 ( 2049 62827 example. 2050 DnT0Y6dRBM8f3v8HdKmZUsGVkXh+b+htujCR 2051 c423x6c8erEMGVnxcrmcrZ53qGXcMYJ+TDkq 2052 a7Xfz/f9xzvSTw== ) 2054 ;; Authority 2055 example. NS ns1.example. 2056 example. NS ns2.example. 2057 example. RRSIG NS 133 1 3600 20150420235959 20051021000000 ( 2058 62827 example. 2059 D9+iBwcbeKL5+TorTfYn4/pLr2lSFwyGYCyM 2060 gfq4TpFaZpxrCJPLxHbKjdkR18jAt7+SR7B5 2061 JpiZcff2Cj2B0w== ) 2063 ;; NSEC3 RR that covers the "next closer" name (z.w.example) 2064 ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03 2066 q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd ( 2067 r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG ) 2068 q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 133 2 3600 ( 2069 20150420235959 20051021000000 62827 example. 2070 ktIfH8VRjEKYPB0Qf4EdTuSlYn4DVSRRaGWc 2071 kVGmKzreEU5zs97CL8OQSa6C0JZX2yMBXijC 2072 Wu6EvgCXrflgiQ== ) 2074 ;; Additional 2075 ai.example. A 192.0.2.9 2076 ai.example. RRSIG A 133 2 3600 20150420235959 20051021000000 ( 2077 62827 example. 2078 qfXAvKr5o3Jixy5KXnVMEhABo3DDHYSR5+Ag 2079 lVxWCExWGMokdkafjW8Hb54+GrOFp/xmDoj5 2080 BXfXAqURwLqznA== ) 2081 ai.example. AAAA 2001:db8:0:0:0:0:f00:baa9 2082 ai.example. RRSIG AAAA 133 2 3600 20150420235959 ( 2083 20051021000000 62827 example. 2084 m65zc0A16Xbx3jYb0t5vPwMzE2xS15mKh76M 2085 hSuKfiFVhBFcQ9IilEM0pXnLzt3ozrM/3X0x 2086 2ruyuN0zC+PABA== ) 2088 The query returned an answer that was produced as a result of 2089 wildcard expansion. The answer section contains a wildcard RRSet 2090 expanded as it would be in a traditional DNS response. The RRSIG 2091 Labels field value of 2 indicates that the answer is the result of 2092 wildcard expansion, as the "a.z.w.example" name contains 4 labels. 2093 This also shows that "w.example" exists, so there is no need for an 2094 NSEC3 RR that matches the closest encloser. 2096 The NSEC3 RR proves that no closer match could have been used to 2097 answer this query. 2099 B.5. Wildcard No Data Error 2101 A "no data" response for a name covered by a wildcard. The NSEC3 RRs 2102 prove that the matching wildcard name does not have any RRs of the 2103 requested type and that no closer match exists in the zone. 2105 ;; Header: QR AA DO RCODE=0 2106 ;; 2107 ;; Question 2108 a.z.w.example. IN AAAA 2110 ;; Answer 2111 ;; (empty) 2113 ;; Authority 2114 example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( 2115 3600000 3600 ) 2116 example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( 2117 62827 example. 2118 hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ 2119 ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ 2120 rynLZNqsbLm40Q== ) 2122 ;; NSEC3 RR that matches the closest encloser (w.example) 2123 ;; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h 2125 k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd ( 2126 kohar7mbb8dc2ce8a9qvl8hon4k53uhi ) 2127 k8udemvp1j2f7eg6jebps17vp3n8i58h.example. RRSIG NSEC3 133 2 3600 ( 2128 20150420235959 20051021000000 62827 example. 2129 IKJfInxfypsDiXKgT6HDvCPEIBu9lZCc0CWl 2130 c46+Gj/Jrg1NBkSJkKMjCERp1HT8tKU+zYp5 2131 Kyio/cddEaa5Gg== ) 2133 ;; NSEC3 RR that covers the "next closer" name (z.w.example) 2134 ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03 2135 q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd ( 2136 r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG ) 2137 q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 133 2 3600 ( 2138 20150420235959 20051021000000 62827 example. 2139 ktIfH8VRjEKYPB0Qf4EdTuSlYn4DVSRRaGWc 2140 kVGmKzreEU5zs97CL8OQSa6C0JZX2yMBXijC 2141 Wu6EvgCXrflgiQ== ) 2143 ;; NSEC3 RR that matches a wildcard at the closest encloser. 2144 ;; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en 2146 r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd ( 2147 t644ebqk9bibcna874givr6joj62mlhv MX RRSIG ) 2148 r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. RRSIG NSEC3 133 2 3600 ( 2149 20150420235959 20051021000000 62827 example. 2150 SzeyaiFOy9dFO1RKHAK4uVCb5GF4rNnxFMXu 2151 6hpM44cmLcDgshlnG1CwkkcihfKOiPIBWd7I 2152 bGhsbhqrBrn5Dg== ) 2154 ;; Additional 2155 ;; (empty) 2157 The query returned the NSEC3 RRs that prove that the requested data 2158 does not exist and no wildcard RR applies. 2160 B.6. DS Child Zone No Data Error 2162 A "no data" response for a QTYPE=DS query that was mistakenly sent to 2163 a name server for the child zone. 2165 ;; Header: QR AA DO RCODE=0 2166 ;; 2167 ;; Question 2168 example. IN DS 2170 ;; Answer 2171 ;; (empty) 2173 ;; Authority 2174 example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( 2175 3600000 3600 ) 2176 example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( 2177 62827 example. 2178 hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ 2179 ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ 2180 rynLZNqsbLm40Q== ) 2182 ;; NSEC3 RR matches the QNAME and shows that the DS type bit is not set. 2184 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( 2185 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS 2186 SOA NSEC3PARAM RRSIG ) 2187 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 133 2 3600 ( 2188 20150420235959 20051021000000 62827 example. 2189 rn2tv99+9StXbc7JaEnjT1+8I8f2vVOMOIbF 2190 xzlrn94lQLxEOYxQR4SrxDRP4/fC54Jui0Ix 2191 4eI9tMfaTVgehQ== ) 2193 ;; Additional 2194 ;; (empty) 2196 The query returned an NSEC3 RR showing that the requested was 2197 answered by the server authoritative for the zone "example". The 2198 NSEC3 RR indicates the presence of an SOA RR, showing that this NSEC3 2199 RR is from the apex of the child, not from the zone cut of the 2200 parent. Queries for the "example" DS RRSet should be sent to the 2201 parent servers (which are in this case the root servers). 2203 Appendix C. Special Considerations 2205 The following paragraphs clarify specific behavior and explain 2206 special considerations for implementations. 2208 C.1. Salting 2210 Augmenting original owner names with salt before hashing increases 2211 the cost of a dictionary of pre-generated hash-values. For every bit 2212 of salt, the cost of a precomputed dictionary doubles (because there 2213 must be an entry for each word combined with each possible salt 2214 value). The NSEC3 RR can use a maximum of 2040 bits (255 octets) of 2215 salt, multiplying the cost by 2^2040. This means that an attacker 2216 must, in practice, recompute the dictionary each time the salt is 2217 changed. 2219 Including a salt, regardless of size, does not affect the cost of 2220 constructing NSEC3 RRs. It does increase the size of the NSEC3 RR. 2222 There MUST be at least one complete set of NSEC3 RRs for the zone 2223 using the same salt value. 2225 The salt SHOULD be changed periodically to prevent pre-computation 2226 using a single salt. It is RECOMMENDED that the salt be changed for 2227 every re-signing. 2229 Note that this could cause a resolver to see RRs with different salt 2230 values for the same zone. This is harmless, since each RR stands 2231 alone (that is, it denies the set of owner names whose hashes, using 2232 the salt in the NSEC3 RR, fall between the two hashes in the NSEC3 2233 RR) - it is only the server that needs a complete set of NSEC3 RRs 2234 with the same salt in order to be able to answer every possible 2235 query. 2237 There is no prohibition with having NSEC3 RRs with different salts 2238 within the same zone. However, in order for authoritative servers to 2239 be able to consistently find covering NSEC3 RRs, the authoritative 2240 server MUST choose a single set of parameters (algorithm, salt, and 2241 iterations) to use when selecting NSEC3 RRs. 2243 C.2. Hash Collision 2245 Hash collisions occur when different messages have the same hash 2246 value. The expected number of domain names needed to give a 1 in 2 2247 chance of a single collision is about 2^(n/2) for a hash of length n 2248 bits (i.e. 2^80 for SHA-1). Though this probability is extremely 2249 low, the following paragraphs deal with avoiding collisions and 2250 assessing possible damage in the event of an attack using hash 2251 collisions. 2253 C.2.1. Avoiding Hash Collisions During Generation 2255 During generation of NSEC3 RRs, hash values are supposedly unique. 2256 In the (academic) case of a collision occurring, an alternative salt 2257 MUST be chosen and all hash values MUST be regenerated. 2259 C.2.2. Second Preimage Requirement Analysis 2261 A cryptographic hash function has a second-preimage resistance 2262 property. The second-preimage resistance property means that it is 2263 computationally infeasible to find another message with the same hash 2264 value as a given message, i.e. given preimage X, to find a second 2265 preimage X' != X such that hash(X) = hash(X'). The work factor for 2266 finding a second preimage is of the order of 2^160 for SHA-1. To 2267 mount an attack using an existing NSEC3 RR, an adversary needs to 2268 find a second preimage. 2270 Assuming an adversary is capable of mounting such an extreme attack, 2271 the actual damage is that a response message can be generated which 2272 claims that a certain QNAME (i.e. the second pre-image) does exist, 2273 while in reality QNAME does not exist (a false positive), which will 2274 either cause a security aware resolver to re-query for the non- 2275 existent name, or to fail the initial query. Note that the adversary 2276 can't mount this attack on an existing name but only on a name that 2277 the adversary can't choose and does not yet exist. 2279 Authors' Addresses 2281 Ben Laurie 2282 Nominet 2283 17 Perryn Road 2284 London W3 7LR 2285 England 2287 Phone: +44 20 8735 0686 2288 Email: ben@links.org 2290 Geoffrey Sisson 2291 Nominet 2292 Minerva House 2293 Edmund Halley Road 2294 Oxford Science Park 2295 Oxford OX4 4DQ 2296 UNITED KINGDOM 2298 Phone: +44 1865 332211 2299 Email: geoff@nominet.org.uk 2300 Roy Arends 2301 Nominet 2302 Minerva House 2303 Edmund Halley Road 2304 Oxford Science Park 2305 Oxford OX4 4DQ 2306 UNITED KINGDOM 2308 Phone: +44 1865 332211 2309 Email: roy@nominet.org.uk 2311 David Blacka 2312 VeriSign, Inc. 2313 21355 Ridgetop Circle 2314 Dulles, VA 20166 2315 US 2317 Phone: +1 703 948 3200 2318 Email: davidb@verisign.com 2320 Full Copyright Statement 2322 Copyright (C) The IETF Trust (2007). 2324 This document is subject to the rights, licenses and restrictions 2325 contained in BCP 78, and except as set forth therein, the authors 2326 retain all their rights. 2328 This document and the information contained herein are provided on an 2329 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2330 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2331 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2332 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2333 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2334 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2336 Intellectual Property 2338 The IETF takes no position regarding the validity or scope of any 2339 Intellectual Property Rights or other rights that might be claimed to 2340 pertain to the implementation or use of the technology described in 2341 this document or the extent to which any license under such rights 2342 might or might not be available; nor does it represent that it has 2343 made any independent effort to identify any such rights. Information 2344 on the procedures with respect to rights in RFC documents can be 2345 found in BCP 78 and BCP 79. 2347 Copies of IPR disclosures made to the IETF Secretariat and any 2348 assurances of licenses to be made available, or the result of an 2349 attempt made to obtain a general license or permission for the use of 2350 such proprietary rights by implementers or users of this 2351 specification can be obtained from the IETF on-line IPR repository at 2352 http://www.ietf.org/ipr. 2354 The IETF invites any interested party to bring to its attention any 2355 copyrights, patents or patent applications, or other proprietary 2356 rights that may cover technology that may be required to implement 2357 this standard. Please address the information to the IETF at 2358 ietf-ipr@ietf.org. 2360 Acknowledgment 2362 Funding for the RFC Editor function is provided by the IETF 2363 Administrative Support Activity (IASA).