idnits 2.17.00 (12 Aug 2021) /tmp/idnits19466/draft-ietf-dnsext-nsec3-04.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1765. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1742. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1749. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1755. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (February 2006) is 5938 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 3658 (ref. '10') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2929 (ref. '11') (Obsoleted by RFC 5395) ** Downref: Normative reference to an Informational RFC: RFC 3174 (ref. '13') -- No information found for draft-vixie-dnssec-ter - is the name correct? == Outdated reference: draft-josefsson-rfc3548bis has been published as RFC 4648 Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 8 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 Expires: August 5, 2006 R. Arends 5 Nominet 6 February 2006 8 DNSSEC Hash Authenticated Denial of Existence 9 draft-ietf-dnsext-nsec3-04 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 5, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 The DNS Security Extensions introduces the NSEC resource record for 43 authenticated denial of existence. This document introduces a new 44 resource record as an alternative to NSEC that provides measures 45 against zone enumeration and allows for gradual expansion of 46 delegation-centric zones. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 52 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 53 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. NSEC versus NSEC3 . . . . . . . . . . . . . . . . . . . . . . 5 55 3. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 5 56 3.1. NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 6 57 3.1.1. The Hash Function Field . . . . . . . . . . . . . . . 6 58 3.1.2. The Opt-In Flag Field . . . . . . . . . . . . . . . . 7 59 3.1.3. The Iterations Field . . . . . . . . . . . . . . . . . 8 60 3.1.4. The Salt Length Field . . . . . . . . . . . . . . . . 8 61 3.1.5. The Salt Field . . . . . . . . . . . . . . . . . . . . 8 62 3.1.6. The Next Hashed Ownername Field . . . . . . . . . . . 9 63 3.1.7. The Type Bit Maps Field . . . . . . . . . . . . . . . 9 64 3.2. The NSEC3 RR Presentation Format . . . . . . . . . . . . . 10 65 4. Creating Additional NSEC3 RRs for Empty Non-Terminals . . . . 11 66 5. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 11 67 6. Including NSEC3 RRs in a Zone . . . . . . . . . . . . . . . . 11 68 7. Responding to NSEC3 Queries . . . . . . . . . . . . . . . . . 12 69 8. Special Considerations . . . . . . . . . . . . . . . . . . . . 13 70 8.1. Proving Nonexistence . . . . . . . . . . . . . . . . . . . 13 71 8.2. Salting . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 8.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . . 15 73 8.4. Hash Collision . . . . . . . . . . . . . . . . . . . . . . 16 74 8.4.1. Avoiding Hash Collisions during generation . . . . . . 16 75 8.4.2. Second Preimage Requirement Analysis . . . . . . . . . 16 76 8.4.3. Possible Hash Value Truncation Method . . . . . . . . 17 77 8.4.4. Server Response to a Run-time Collision . . . . . . . 17 78 8.4.5. Parameters that Cover the Zone . . . . . . . . . . . . 18 79 9. Performance Considerations . . . . . . . . . . . . . . . . . . 18 80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 81 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 82 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 83 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 84 12.2. Informative References . . . . . . . . . . . . . . . . . . 22 85 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . 86 Appendix A. Example Zone . . . . . . . . . . . . . . . . . . . . 22 87 Appendix B. Example Responses . . . . . . . . . . . . . . . . . . 27 88 B.1. answer . . . . . . . . . . . . . . . . . . . . . . . . . . 27 89 B.1.1. Authenticating the Example DNSKEY RRset . . . . . . . 29 90 B.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . . 30 91 B.3. No Data Error . . . . . . . . . . . . . . . . . . . . . . 32 92 B.3.1. No Data Error, Empty Non-Terminal . . . . . . . . . . 33 93 B.4. Referral to Signed Zone . . . . . . . . . . . . . . . . . 34 94 B.5. Referral to Unsigned Zone using the Opt-In Flag . . . . . 35 95 B.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 36 96 B.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . . 38 97 B.8. DS Child Zone No Data Error . . . . . . . . . . . . . . . 39 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 99 Intellectual Property and Copyright Statements . . . . . . . . . . 42 101 1. Introduction 103 1.1. Rationale 105 The DNS Security Extensions included the NSEC RR to provide 106 authenticated denial of existence. Though the NSEC RR meets the 107 requirements for authenticated denial of existence, it introduced a 108 side-effect in that the contents of a zone can be enumerated. This 109 property introduces undesired policy issues. 111 An enumerated zone can be used either directly as a source of 112 probable e-mail addresses for spam, or indirectly as a key for 113 multiple WHOIS queries to reveal registrant data which many 114 registries may be under strict legal obligations to protect. Many 115 registries therefore prohibit copying of their zone file; however the 116 use of NSEC RRs renders these policies unenforceable. 118 A second problem was the requirement that the existence of all record 119 types in a zone - including unsigned delegation points - must be 120 accounted for, despite the fact that unsigned delegation point 121 records are not signed. This requirement has a side-effect that the 122 overhead of signed zones is not related to the increase in security 123 of subzones. This requirement does not allow the zones' size to grow 124 in relation to the growth of signed subzones. 126 In the past, solutions (draft-ietf-dnsext-dnssec-opt-in) have been 127 proposed as a measure against these side effects but at the time were 128 regarded as secondary over the need to have a stable DNSSEC 129 specification. With (draft-vixie-dnssec-ter) [14] a graceful 130 transition path to future enhancements is introduced, while current 131 DNSSEC deployment can continue. This document presents the NSEC3 132 Resource Record which mitigates these issues with the NSEC RR. 134 The reader is assumed to be familiar with the basic DNS and DNSSEC 135 concepts described in RFC 1034 [1], RFC 1035 [2], RFC 4033 [3], RFC 136 4034 [4], RFC 4035 [5] and subsequent RFCs that update them: RFC 2136 137 [6], RFC2181 [7] and RFC2308 [8]. 139 1.2. Reserved Words 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [9]. 145 1.3. Terminology 147 The practice of discovering the contents of a zone, i.e. enumerating 148 the domains within a zone, is known as "zone enumeration". Zone 149 enumeration was not practical prior to the introduction of DNSSEC. 151 In this document the term "original ownername" refers to a standard 152 ownername. Because this proposal uses the result of a hash function 153 over the original (unmodified) ownername, this result is referred to 154 as "hashed ownername". 156 "Hash order" means the order in which hashed ownernames are arranged 157 according to their numerical value, treating the leftmost (lowest 158 numbered) octet as the most significant octet. Note that this is the 159 same as the canonical ordering specified in RFC 4034 [4]. 161 An "empty non-terminal" is a domain name that owns no resource 162 records but has subdomains that do. 164 The "closest encloser" of a (nonexistent) domain name is the longest 165 domain name, including empty non-terminals, that matches the 166 rightmost part of the nonexistent domain name. 168 "Base32 encoding" is "Base 32 Encoding with Extended Hex Alphabet" as 169 specified in RFC 3548bis [15]. 171 2. NSEC versus NSEC3 173 This document does NOT obsolete the NSEC record, but gives an 174 alternative for authenticated denial of existence. NSEC and NSEC3 175 RRs can not co-exist in a zone. See draft-vixie-dnssec-ter [14] for 176 a signaling mechanism to allow for graceful transition towards NSEC3. 178 3. The NSEC3 Resource Record 180 The NSEC3 RR provides Authenticated Denial of Existence for DNS 181 Resource Record Sets. 183 The NSEC3 Resource Record (RR) lists RR types present at the NSEC3 184 RR's original ownername. It includes the next hashed ownername in 185 the hash order of the zone. The complete set of NSEC3 RRs in a zone 186 indicates which RRsets exist for the original ownername of the RRset 187 and form a chain of hashed ownernames in the zone. This information 188 is used to provide authenticated denial of existence for DNS data, as 189 described in RFC 4035 [5]. To provide protection against zone 190 enumeration, the ownernames used in the NSEC3 RR are cryptographic 191 hashes of the original ownername prepended to the name of the zone. 192 The NSEC3 RR indicates which hash function is used to construct the 193 hash, which salt is used, and how many iterations of the hash 194 function are performed over the original ownername. The hashing 195 technique is described fully in Section 5. 197 Hashed ownernames of unsigned delegations may be excluded from the 198 chain. An NSEC3 record which span covers the hash of an unsigned 199 delegation's ownername is referred to as an Opt-In NSEC3 record and 200 is indicated by the presence of a flag. 202 The ownername for the NSEC3 RR is the base32 encoding of the hashed 203 ownername prepended to the name of the zone.. 205 The type value for the NSEC3 RR is XX. 207 The NSEC3 RR RDATA format is class independent and is described 208 below. 210 The class MUST be the same as the original ownername's class. 212 The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL 213 field. This is in the spirit of negative caching [8]. 215 3.1. NSEC3 RDATA Wire Format 217 The RDATA of the NSEC3 RR is as shown below: 219 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Hash Function |O| Iterations | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Salt Length | Salt / 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 / Next Hashed Ownername / 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 / Type Bit Maps / 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 "O" is the Opt-In Flag field. 233 3.1.1. The Hash Function Field 235 The Hash Function field identifies the cryptographic hash function 236 used to construct the hash-value. 238 The values are as defined for the DS record (see RFC 3658 [10]). 240 On reception, a resolver MUST ignore an NSEC3 RR with an unknown hash 241 function value. 243 3.1.2. The Opt-In Flag Field 245 The Opt-In Flag field indicates whether this NSEC3 RR covers unsigned 246 delegations. 248 In DNSSEC, NS RRsets at delegation points are not signed, and may be 249 accompanied by a DS record. The security status of the subzone is 250 determined by the presence or absence of the DS RRset, 251 cryptographically proven by the NSEC record or the signed DS RRset. 252 The presence of the Opt-In flag expands this definition by allowing 253 insecure delegations to exist within an otherwise signed zone without 254 the corresponding NSEC3 record at the delegation's (hashed) owner 255 name. These delegations are proven insecure by using a covering 256 NSEC3 record. 258 Resolvers must be able to distinguish between NSEC3 records and 259 Opt-In NSEC3 records. This is accomplished by setting the Opt-In 260 flag of the NSEC3 records that cover (or potentially cover) insecure 261 delegation nodes. 263 An Opt-In NSEC3 record does not assert the existence or non-existence 264 of the insecure delegations that it covers. This allows for the 265 addition or removal of these delegations without recalculating or 266 resigning records in the NSEC3 chain. However, Opt-In NSEC3 records 267 do assert the (non)existence of other, authoritative RRsets. 269 An Opt-In NSEC3 record MAY have the same original owner name as an 270 insecure delegation. In this case, the delegation is proven insecure 271 by the lack of a DS bit in type map and the signed NSEC3 record does 272 assert the existence of the delegation. 274 Zones using Opt-In MAY contain a mixture of Opt-In NSEC3 records and 275 non-Opt-In NSEC3 records. If an NSEC3 record is not Opt-In, there 276 MUST NOT be any hashed ownernames of insecure delegations (nor any 277 other records) between it and the RRsets indicated by the 'Next 278 Hashed Ownername' in the NSEC3 RDATA. If it is Opt-In, there MUST 279 only be hashed ownernames of insecure delegations between it and the 280 next node indicated by the 'Next Hashed Ownername' in the NSEC3 281 RDATA. 283 In summary, 284 o An Opt-In NSEC3 type is identified by an Opt-In Flag field value 285 of 1. 286 o A non Opt-In NSEC3 type is identified by an Opt-In Flag field 287 value of 0. 288 and, 289 o An Opt-In NSEC3 record does not assert the non-existence of a hash 290 ownername between its ownername and next hashed ownername, 291 although it does assert that any hashed name in this span MUST be 292 of an insecure delegation. 293 o An Opt-In NSEC3 record does assert the (non)existence of RRsets 294 with the same hashed owner name. 296 3.1.3. The Iterations Field 298 The Iterations field defines the number of times the hash has been 299 iterated. More iterations results in greater resiliency of the hash 300 value against dictionary attacks, but at a higher cost for both the 301 server and resolver. See Section 5 for details of this field's use. 303 Iterations make an attack more costly by making the hash computation 304 more computationally intensive, e.g. by iterating the hash function a 305 number of times. 307 When generating a few hashes this performance loss will not be a 308 problem, as a validator can handle a delay of a few milliseconds. 309 But when doing a dictionary attack it will also multiply the attack 310 workload by a factor, which is a problem for the attacker. 312 3.1.4. The Salt Length Field 314 The salt length field defines the length of the salt in octets. 316 3.1.5. The Salt Field 318 The Salt field is not present when the Salt Length Field has a value 319 of 0. 321 The Salt field is appended to the original ownername before hashing 322 in order to defend against precalculated dictionary attacks. See 323 Section 5 for details on how the salt is used. 325 Salt is used to make dictionary attacks using precomputation more 326 costly. A dictionary can only be computed after the attacker has the 327 salt, hence a new salt means that the dictionary has to be 328 regenerated with the new salt. 330 There MUST be a complete set of NSEC3 records covering the entire 331 zone that use the same salt value. The requirement exists so that, 332 given any qname within a zone, at least one covering NSEC3 RRset may 333 be found. While it may be theoretically possible to produce a set of 334 NSEC3s that use different salts that cover the entire zone, it is 335 computationally infeasible to generate such a set. See Section 8.2 336 for further discussion. 338 The salt value SHOULD be changed from time to time - this is to 339 prevent the use of a precomputed dictionary to reduce the cost of 340 enumeration. 342 3.1.6. The Next Hashed Ownername Field 344 The Next Hashed Ownername field contains the next hashed ownername in 345 hash order. That is, given the set of all hashed owernames, the Next 346 Hashed Ownername contains the hash value that immediately follows the 347 owner hash value for the given NSEC3 record. The value of the Next 348 Hashed Ownername Field in the last NSEC3 record in the zone is the 349 same as the ownername of the first NSEC3 RR in the zone in hash 350 order. 352 Hashed ownernames of glue RRsets MUST NOT be listed in the Next 353 Hashed Ownername unless at least one authoritative RRset exists at 354 the same ownername. Hashed ownernames of delegation NS RRsets MUST 355 be listed if the Opt-In bit is clear. 357 Note that the Next Hashed Ownername field is not encoded, unlike the 358 NSEC3 RR's ownername. It is the unmodified binary hash value. It 359 does not include the name of the containing zone. 361 The length of this field is the length of the hash value produced by 362 the hash function selected by the Hash Function field. 364 3.1.7. The Type Bit Maps Field 366 The Type Bit Maps field identifies the RRset types which exist at the 367 NSEC3 RR's original ownername. 369 The Type bits for the NSEC3 RR and RRSIG RR MUST be set during 370 generation, and MUST be ignored during processing. 372 The RR type space is split into 256 window blocks, each representing 373 the low-order 8 bits of the 16-bit RR type space. Each block that 374 has at least one active RR type is encoded using a single octet 375 window number (from 0 to 255), a single octet bitmap length (from 1 376 to 32) indicating the number of octets used for the window block's 377 bitmap, and up to 32 octets (256 bits) of bitmap. 379 Blocks are present in the NSEC3 RR RDATA in increasing numerical 380 order. 382 "|" denotes concatenation 384 Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) + 385 Each bitmap encodes the low-order 8 bits of RR types within the 386 window block, in network bit order. The first bit is bit 0. For 387 window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds 388 to RR type 2 (NS), and so forth. For window block 1, bit 1 389 corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to 390 1, it indicates that an RRset of that type is present for the NSEC3 391 RR's ownername. If a bit is set to 0, it indicates that no RRset of 392 that type is present for the NSEC3 RR's ownername. 394 Since bit 0 in window block 0 refers to the non-existing RR type 0, 395 it MUST be set to 0. After verification, the validator MUST ignore 396 the value of bit 0 in window block 0. 398 Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [11] 399 (section 3.1) or within the range reserved for assignment only to 400 QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in 401 zone data. If encountered, they must be ignored upon reading. 403 Blocks with no types present MUST NOT be included. Trailing zero 404 octets in the bitmap MUST be omitted. The length of each block's 405 bitmap is determined by the type code with the largest numerical 406 value, within that block, among the set of RR types present at the 407 NSEC3 RR's actual ownername. Trailing zero octets not specified MUST 408 be interpreted as zero octets. 410 3.2. The NSEC3 RR Presentation Format 412 The presentation format of the RDATA portion is as follows: 414 The Opt-In Flag Field is represented as an unsigned decimal integer. 415 The value is either 0 or 1. 417 The Hash field is presented as a mnemonic of the hash or as an 418 unsigned decimal integer. The value has a maximum of 127. 420 The Iterations field is presented as an unsigned decimal integer. 422 The Salt Length field is not presented. 424 The Salt field is represented as a sequence of case-insensitive 425 hexadecimal digits. Whitespace is not allowed within the sequence. 426 The Salt Field is represented as "-" (without the quotes) when the 427 Salt Length field has value 0. 429 The Next Hashed Ownername field is represented as a sequence of case- 430 insensitive base32 digits, without whitespace. 432 The Type Bit Maps Field is represented as a sequence of RR type 433 mnemonics. When the mnemonic is not known, the TYPE representation 434 as described in RFC 3597 [12] (section 5) MUST be used. 436 4. Creating Additional NSEC3 RRs for Empty Non-Terminals 438 In order to prove the non-existence of a record that might be covered 439 by a wildcard, it is necessary to prove the existence of its closest 440 encloser. A closest encloser might be an empty non-terminal. 442 Additional NSEC3 RRs are generated for empty non-terminals. These 443 additional NSEC3 RRs are identical in format to NSEC3 RRs that cover 444 existing RRs in the zone except that their type-maps only indicated 445 the existence of an NSEC3 RRset and an RRSIG RRset. 447 This relaxes the requirement in Section 2.3 of RFC4035 that NSEC RRs 448 not appear at names that did not exist before the zone was signed. 449 [Comment.1] 451 5. Calculation of the Hash 453 Define H(x) to be the hash of x using the hash function selected by 454 the NSEC3 record and || to indicate concatenation. Then define: 456 IH(salt,x,0)=H(x || salt) 458 IH(salt,x,k)=H(IH(salt,x,k-1) || salt) if k > 0 460 Then the calculated hash of an ownername is 461 IH(salt,ownername,iterations-1), where the ownername is the canonical 462 form. 464 The canonical form of the ownername is the wire format of the 465 ownername where: 466 1. The ownername is fully expanded (no DNS name compression) and 467 fully qualified; 468 2. All uppercase US-ASCII letters are replaced by the corresponding 469 lowercase US-ASCII letters; 470 3. If the ownername is a wildcard name, the ownername is in its 471 original unexpanded form, including the "*" label (no wildcard 472 substitution); 473 This form is as defined in section 6.2 of RFC 4034 ([4]). 475 6. Including NSEC3 RRs in a Zone 477 Each ownername within the zone that owns authoritative RRsets MUST 478 have a corresponding NSEC3 RR. Ownernames that correspond to 479 unsigned delegations MAY have a corresponding NSEC3 RR, however, if 480 there is not, there MUST be a covering NSEC3 RR with the Opt-In flag 481 set to 1. Other non-authoritative RRs are not included in the set of 482 NSEC3 RRs. 484 Each empty non-terminal MUST have an NSEC3 record. 486 The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL 487 value field in the zone SOA RR. 489 The type bitmap of every NSEC3 resource record in a signed zone MUST 490 indicate the presence of both the NSEC3 RR type itself and its 491 corresponding RRSIG RR type. 493 The following steps describe the proper construction of NSEC3 494 records. [Comment.2] 495 1. For each unique original ownername in the zone, add an NSEC3 496 RRset. If Opt-In is being used, ownernames of unsigned 497 delegations may be excluded, but must be considered for empty- 498 non-terminals. The ownername of the NSEC3 RR is the hashed 499 equivalent of the original owner name, prepended to the zone 500 name. The Next Hashed Ownername field is left blank for the 501 moment. If Opt-In is being used, set the Opt-In bit to one. 502 2. For each RRset at the original owner name, set the corresponding 503 bit in the type bit map. 504 3. If the difference in number of labels between the apex and the 505 original ownername is greater then 1, additional NSEC3s need to 506 be added for every empty non-terminal between the apex and the 507 original ownername. This process may generate NSEC3 RRs with 508 duplicate hashed ownernames. 509 4. Sort the set of NSEC3 RRs into hash order. Hash order is the 510 ascending numerical order of the non-encoded hash values. 511 5. Combine NSEC3 RRs with identical hashed ownernames by replacing 512 with a single NSEC3 RR with the type map consisting of the union 513 of the types represented by the set of NSEC3 RRs. 514 6. In each NSEC3 RR, insert the Next Hashed Ownername by using the 515 value of the next NSEC3 RR in hash order. The Next Hashed 516 Ownername of the last NSEC3 in the zone contains the value of the 517 hashed ownername of the first NSEC3 in the hash order. 519 7. Responding to NSEC3 Queries 521 Since NSEC3 ownernames are not represented in the NSEC3 chain like 522 other zone ownernames, direct queries for NSEC3 ownernames present a 523 special case. 525 The special case arises when the following are all true: 526 o The QNAME equals an existing NSEC3 ownername, and 527 o There are no other record types that exist at QNAME, and 528 o The QTYPE does not equal NSEC3. 529 These conditions describe a particular case: the answer should be a 530 NOERROR/NODATA response, but there is no NSEC3 RRset for H(QNAME) to 531 include in the authority section. 533 However, the NSEC3 RRset with ownername equal to QNAME is able to 534 prove its own existence. Thus, when answering this query, the 535 authoritative server MUST include the NSEC3 RRset whose ownername 536 equals QNAME. This RRset proves that QNAME is an existing name with 537 types NSEC3 and RRSIG. The authoritative server MUST also include 538 the NSEC3 RRset that covers the hash of QNAME. This RRset proves 539 that no other types exist. 541 When validating a NOERROR/NODATA response, validators MUST check for 542 a NSEC3 RRset with ownername equals to QNAME, and MUST accept that 543 (validated) NSEC3 RRset as proof that QNAME exists. The validator 544 MUST also check for an NSEC3 RRset that covers the hash of QNAME as 545 proof that QTYPE doesn't exist. 547 Other cases where the QNAME equals an existing NSEC3 ownername may be 548 answered normally. 550 8. Special Considerations 552 The following paragraphs clarify specific behaviour explain special 553 considerations for implementations. 555 8.1. Proving Nonexistence 557 If a wildcard resource record appears in a zone, its asterisk label 558 is treated as a literal symbol and is treated in the same way as any 559 other ownername for purposes of generating NSEC3 RRs. RFC 4035 [5] 560 describes the impact of wildcards on authenticated denial of 561 existence. 563 In order to prove there exist no RRs for a domain, as well as no 564 source of synthesis, an RR must be shown for the closest encloser, 565 and non-existence must be shown for all closer labels and for the 566 wildcard at the closest encloser. 568 This can be done as follows. If the QNAME in the query is 569 omega.alfa.beta.example, and the closest encloser is beta.example 570 (the nearest ancestor to omega.alfa.beta.example), then the server 571 should return an NSEC3 that demonstrates the nonexistence of 572 alfa.beta.example, an NSEC3 that demonstrates the nonexistence of 573 *.beta.example, and an NSEC3 that demonstrates the existence of 574 beta.example. This takes between one and three NSEC3 records, since 575 a single record can, by chance, prove more than one of these facts. 577 When a verifier checks this response, then the existence of 578 beta.example together with the non-existence of alfa.beta.example 579 proves that the closest encloser is indeed beta.example. The non- 580 existence of *.beta.example shows that there is no wildcard at the 581 closest encloser, and so no source of synthesis for 582 omega.alfa.beta.example. These two facts are sufficient to satisfy 583 the resolver that the QNAME cannot be resolved. 585 In practice, since the NSEC3 owner and next names are hashed, if the 586 server responds with an NSEC3 for beta.example, the resolver will 587 have to try successively longer names, starting with example, moving 588 to beta.example, alfa.beta.example, and so on, until one of them 589 hashes to a value that matches the interval (but not the ownername 590 nor next owner name) of one of the returned NSEC3s (this name will be 591 alfa.beta.example). Once it has done this, it knows the closest 592 encloser (i.e. beta.example), and can then easily check the other two 593 required proofs. 595 Note that it is not possible for one of the shorter names tried by 596 the resolver to be denied by one of the returned NSEC3s, since, by 597 definition, all these names exist and so cannot appear within the 598 range covered by an NSEC3. Note, however, that the first name that 599 the resolver tries MUST be the apex of the zone, since names above 600 the apex could be denied by one of the returned NSEC3s. 602 8.2. Salting 604 Augmenting original ownernames with salt before hashing increases the 605 cost of a dictionary of pre-generated hash-values. For every bit of 606 salt, the cost of a precomputed dictionary doubles (because there 607 must be an entry for each word combined with each possible salt 608 value). The NSEC3 RR can use a maximum of 2040 bits (255 octets) of 609 salt, multiplying the cost by 2^2040. This means that an attacker 610 must, in practice, recompute the dictionary each time the salt is 611 changed. 613 There MUST be at least one complete set of NSEC3s for the zone using 614 the same salt value. 616 The salt SHOULD be changed periodically to prevent precomputation 617 using a single salt. It is RECOMMENDED that the salt be changed for 618 every resigning. 620 Note that this could cause a resolver to see records with different 621 salt values for the same zone. This is harmless, since each record 622 stands alone (that is, it denies the set of ownernames whose hashes, 623 using the salt in the NSEC3 record, fall between the two hashes in 624 the NSEC3 record) - it is only the server that needs a complete set 625 of NSEC3 records with the same salt in order to be able to answer 626 every possible query. 628 There is no prohibition with having NSEC3 with different salts within 629 the same zone. However, in order for authoritative servers to be 630 able to consistently find covering NSEC3 RRs, the authoritative 631 server MUST choose a single set of parameters (algorithm, salt, and 632 iterations) to use when selecting NSEC3s. In the absence of any 633 other metadata, the server does this by using the parameters from the 634 zone apex NSEC3, recognizable by the presence of the SOA bit in the 635 type map. If there is more than one NSEC3 record that meets this 636 description, then the server may arbitrarily choose one. Because of 637 this, if there is a zone apex NSEC3 RR within a zone, it MUST be part 638 of a complete NSEC3 set. Conversely, if there exists an incomplete 639 set of NSEC3 RRs using the same parameters within a zone, there MUST 640 NOT be an NSEC3 RR using those parameters with the SOA bit set. 642 8.3. Iterations 644 Setting the number of iterations used allows the zone owner to choose 645 the cost of computing a hash, and so the cost of generating a 646 dictionary. Note that this is distinct from the effect of salt, 647 which prevents the use of a single precomputed dictionary for all 648 time. 650 Obviously the number of iterations also affects the zone owner's cost 651 of signing the zone as well as the verifiers cost of verifying the 652 zone. We therefore impose an upper limit on the number of 653 iterations. We base this on the number of iterations that 654 approximately doubles the cost of signing the zone. 656 A zone owner MUST NOT use a value higher than shown in the table 657 below for iterations. A resolver MAY treat a response with a higher 658 value as bogus. 660 +--------------+------------+ 661 | RSA Key Size | Iterations | 662 +--------------+------------+ 663 | 1024 | 3,000 | 664 | 2048 | 20,000 | 665 | 4096 | 150,000 | 666 +--------------+------------+ 667 +--------------+------------+ 668 | DSA Key Size | Iterations | 669 +--------------+------------+ 670 | 1024 | 1,500 | 671 | 2048 | 5,000 | 672 +--------------+------------+ 674 This table is based on 150,000 SHA-1's per second, 50 RSA signs per 675 second for 1024 bit keys, 7 signs per second for 2048 bit keys, 1 676 sign per second for 4096 bit keys, 100 DSA signs per second for 1024 677 bit keys and 30 signs per second for 2048 bit keys. 679 Note that since RSA verifications are 10-100 times faster than 680 signatures (depending on key size), in the case of RSA the legal 681 values of iterations can substantially increase the cost of 682 verification. 684 8.4. Hash Collision 686 Hash collisions occur when different messages have the same hash 687 value. The expected number of domain names needed to give a 1 in 2 688 chance of a single collision is about 2^(n/2) for a hash of length n 689 bits (i.e. 2^80 for SHA-1). Though this probability is extremely 690 low, the following paragraphs deal with avoiding collisions and 691 assessing possible damage in the event of an attack using hash 692 collisions. 694 8.4.1. Avoiding Hash Collisions during generation 696 During generation of NSEC3 RRs, hash values are supposedly unique. 697 In the (academic) case of a collision occurring, an alternative salt 698 MUST be chosen and all hash values MUST be regenerated. 700 8.4.2. Second Preimage Requirement Analysis 702 A cryptographic hash function has a second-preimage resistance 703 property. The second-preimage resistance property means that it is 704 computationally infeasible to find another message with the same hash 705 value as a given message, i.e. given preimage X, to find a second 706 preimage X' != X such that hash(X) = hash(X'). The work factor for 707 finding a second preimage is of the order of 2^160 for SHA-1. To 708 mount an attack using an existing NSEC3 RR, an adversary needs to 709 find a second preimage. 711 Assuming an adversary is capable of mounting such an extreme attack, 712 the actual damage is that a response message can be generated which 713 claims that a certain QNAME (i.e. the second pre-image) does exist, 714 while in reality QNAME does not exist (a false positive), which will 715 either cause a security aware resolver to re-query for the non- 716 existent name, or to fail the initial query. Note that the adversary 717 can't mount this attack on an existing name but only on a name that 718 the adversary can't choose and does not yet exist. 720 8.4.3. Possible Hash Value Truncation Method 722 The previous sections outlined the low probability and low impact of 723 a second-preimage attack. When impact and probability are low, while 724 space in a DNS message is costly, truncation is tempting. Truncation 725 might be considered to allow for shorter ownernames and rdata for 726 hashed labels. In general, if a cryptographic hash is truncated to n 727 bits, then the expected number of domains required to give a 1 in 2 728 probability of a single collision is approximately 2^(n/2) and the 729 work factor to produce a second preimage is 2^n. 731 An extreme hash value truncation would be truncating to the shortest 732 possible unique label value. This would be unwise, since the work 733 factor to produce second preimages would then approximate the size of 734 the zone (sketch of proof: if the zone has k entries, then the length 735 of the names when truncated down to uniqueness should be proportional 736 to log_2(k). Since the work factor to produce a second pre-image is 737 2^n for an n-bit hash, then in this case it is 2^(C log_2(k)) (where 738 C is some constant), i.e. C'k - a work factor of k). 740 Though the mentioned truncation can be maximized to a certain 741 extreme, the probability of collision increases exponentially for 742 every truncated bit. Given the low impact of hash value collisions 743 and limited space in DNS messages, the balance between truncation 744 profit and collision damage may be determined by local policy. Of 745 course, the size of the corresponding RRSIG RR is not reduced, so 746 truncation is of limited benefit. 748 Truncation could be signaled simply by reducing the length of the 749 first label in the ownername. Note that there would have to be a 750 corresponding reduction in the length of the Next Hashed Ownername 751 field. 753 8.4.4. Server Response to a Run-time Collision 755 In the astronomically unlikely event that a server is unable to prove 756 nonexistence because the hash of the name that does not exist 757 collides with a name that does exist, the server is obviously broken, 758 and should, therefore, return a response with an RCODE of 2 (server 759 failure). 761 8.4.5. Parameters that Cover the Zone 763 Secondary servers (and perhaps other entities) need to reliably 764 determine which NSEC3 parameters (that is, hash, salt and iterations) 765 are present at every hashed ownername, in order to be able to choose 766 an appropriate set of NSEC3 records for negative responses. This is 767 indicated by the parameters at the apex: any set of parameters that 768 is used in an NSEC3 record whose original ownername is the apex of 769 the zone MUST be present throughout the zone. 771 A method to determine which NSEC3 in a complete chain corresponds to 772 the apex is to look for a NSEC3 RRset which has the SOA bit set in 773 the RDATA bit type maps field. 775 9. Performance Considerations 777 Iterated hashes impose a performance penalty on both authoritative 778 servers and resolvers. Therefore, the number of iterations should be 779 carefully chosen. In particular it should be noted that a high value 780 for iterations gives an attacker a very good denial of service 781 attack, since the attacker need not bother to verify the results of 782 their queries, and hence has no performance penalty of his own. 784 On the other hand, nameservers with low query rates and limited 785 bandwidth are already subject to a bandwidth based denial of service 786 attack, since responses are typically an order of magnitude larger 787 than queries, and hence these servers may choose a high value of 788 iterations in order to increase the difficulty of offline attempts to 789 enumerate their namespace without significantly increasing their 790 vulnerability to denial of service attacks. 792 10. IANA Considerations 794 IANA needs to allocate a RR type code for NSEC3 from the standard RR 795 type space (type XXX requested). IANA needs to open a new registry 796 for the NSEC3 Hash Functions. The range for this registry is 0-127. 797 Defined types are: 799 0 is reserved. 800 1 is SHA-1 ([13]). 801 127 is experimental. 803 11. Security Considerations 805 The NSEC3 records are still susceptible to dictionary attacks (i.e. 807 the attacker retrieves all the NSEC3 records, then calculates the 808 hashes of all likely domain names, comparing against the hashes found 809 in the NSEC3 records, and thus enumerating the zone). These are 810 substantially more expensive than enumerating the original NSEC 811 records would have been, and in any case, such an attack could also 812 be used directly against the name server itself by performing queries 813 for all likely names, though this would obviously be more detectable. 814 The expense of this off-line attack can be chosen by setting the 815 number of iterations in the NSEC3 RR. 817 Domains are also susceptible to a precalculated dictionary attack - 818 that is, a list of hashes for all likely names is computed once, then 819 NSEC3 is scanned periodically and compared against the precomputed 820 hashes. This attack is prevented by changing the salt on a regular 821 basis. 823 Walking the NSEC3 RRs will reveal the total number of records in the 824 zone, and also what types they are. This could be mitigated by 825 adding dummy entries, but certainly an upper limit can always be 826 found. 828 Hash collisions may occur. If they do, it will be impossible to 829 prove the non-existence of the colliding domain - however, this is 830 fantastically unlikely, and, in any case, DNSSEC already relies on 831 SHA-1 to not collide. 833 Responses to queries where QNAME equals an NSEC3 ownername that has 834 no other types may be undetectably changed from a NOERROR/NODATA 835 response to a NAME ERROR response. 837 The Opt-In Flag (O) allows for unsigned names, in the form of 838 delegations to unsigned subzones, to exist within an otherwise signed 839 zone. All unsigned names are, by definition, insecure, and their 840 validity or existence cannot by cryptographically proven. 842 In general: 843 Records with unsigned names (whether existing or not) suffer from 844 the same vulnerabilities as records in an unsigned zone. These 845 vulnerabilities are described in more detail in [16] (note in 846 particular sections 2.3, "Name Games" and 2.6, "Authenticated 847 Denial"). 848 Records with signed names have the same security whether or not 849 Opt-In is used. 851 Note that with or without Opt-In, an insecure delegation may be 852 undetectably altered by an attacker. Because of this, the primary 853 difference in security when using Opt-In is the loss of the ability 854 to prove the existence or nonexistence of an insecure delegation 855 within the span of an Opt-In NSEC3 record. 857 In particular, this means that a malicious entity may be able to 858 insert or delete records with unsigned names. These records are 859 normally NS records, but this also includes signed wildcard 860 expansions (while the wildcard record itself is signed, its expanded 861 name is an unsigned name). 863 For example, if a resolver received the following response from the 864 example zone above: 866 Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A 868 RCODE=NOERROR 870 Answer Section: 872 Authority Section: 873 DOES-NOT-EXIST.EXAMPLE. NS NS.FORGED. 874 EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. SOA NS \ 875 RRSIG DNSKEY 876 abcd... RRSIG NSEC3 ... 878 Additional Section: 880 The resolver would have no choice but to accept that the referral to 881 NS.FORGED. is valid. If a wildcard existed that would have been 882 expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could 883 have undetectably removed it and replaced it with the forged 884 delegation. 886 Note that being able to add a delegation is functionally equivalent 887 to being able to add any record type: an attacker merely has to forge 888 a delegation to nameserver under his/her control and place whatever 889 records needed at the subzone apex. 891 While in particular cases, this issue may not present a significant 892 security problem, in general it should not be lightly dismissed. 893 Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly. 894 In particular, zone signing tools SHOULD NOT default to using Opt-In, 895 and MAY choose to not support Opt-In at all. 897 12. References 898 12.1. Normative References 900 [1] Mockapetris, P., "Domain names - concepts and facilities", 901 STD 13, RFC 1034, November 1987. 903 [2] Mockapetris, P., "Domain names - implementation and 904 specification", STD 13, RFC 1035, November 1987. 906 [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 907 "DNS Security Introduction and Requirements", RFC 4033, 908 March 2005. 910 [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 911 "Resource Records for the DNS Security Extensions", RFC 4034, 912 March 2005. 914 [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 915 "Protocol Modifications for the DNS Security Extensions", 916 RFC 4035, March 2005. 918 [6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic 919 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 920 April 1997. 922 [7] Elz, R. and R. Bush, "Clarifications to the DNS Specification", 923 RFC 2181, July 1997. 925 [8] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", 926 RFC 2308, March 1998. 928 [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement 929 Levels", BCP 14, RFC 2119, March 1997. 931 [10] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", 932 RFC 3658, December 2003. 934 [11] Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain 935 Name System (DNS) IANA Considerations", BCP 42, RFC 2929, 936 September 2000. 938 [12] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) 939 Types", RFC 3597, September 2003. 941 [13] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", 942 RFC 3174, September 2001. 944 12.2. Informative References 946 [14] Vixie, P., "Extending DNSSEC-BIS (DNSSEC-TER)", 947 draft-vixie-dnssec-ter-01 (work in progress), June 2004. 949 [15] Josefsson, Ed., S,., "The Base16, Base32, and Base64 Data 950 Encodings.", draft-josefsson-rfc3548bis-00 (work in progress), 951 October 2005. 953 [16] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name 954 System (DNS)", RFC 3833, August 2004. 956 Editorial Comments 958 [Comment.1] Although, strictly speaking, the names *did* exist. 960 [Comment.2] Note that this method makes it impossible to detect 961 (extremely unlikely) hash collisions. 963 Appendix A. Example Zone 965 This is a zone showing its NSEC3 records. They can also be used as 966 test vectors for the hash algorithm. 968 The data in the example zone is currently broken, as it uses a 969 different base32 alphabet. This shall be fixed in the next release. 971 example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 972 1 973 3600 974 300 975 3600000 976 3600 ) 977 3600 RRSIG SOA 5 1 3600 20050712112304 ( 978 20050612112304 62699 example. 979 RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK 980 mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g 981 qYIt90txzE/4+g== ) 982 3600 NS ns1.example. 983 3600 NS ns2.example. 984 3600 RRSIG NS 5 1 3600 20050712112304 ( 985 20050612112304 62699 example. 986 hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l 987 m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d 988 1SH5r/wfjuCg+g== ) 989 3600 MX 1 xx.example. 991 3600 RRSIG MX 5 1 3600 20050712112304 ( 992 20050612112304 62699 example. 993 L/ZDLMSZJKITmSxmM9Kni37/wKQsdSg6FT0l 994 NMm14jy2Stp91Pwp1HQ1hAMkGWAqCMEKPMtU 995 S/o/g5C8VM6ftQ== ) 996 3600 DNSKEY 257 3 5 ( 997 AQOnsGyJvywVjYmiLbh0EwIRuWYcDiB/8blX 998 cpkoxtpe19Oicv6Zko+8brVsTMeMOpcUeGB1 999 zsYKWJ7BvR2894hX 1000 ) ; Key ID = 21960 1001 3600 DNSKEY 256 3 5 ( 1002 AQO0gEmbZUL6xbD/xQczHbnwYnf+jQjwz/sU 1003 5k44rHTt0Ty+3aOdYoome9TjGMhwkkGby1TL 1004 ExXT48OGGdbfIme5 1005 ) ; Key ID = 62699 1006 3600 RRSIG DNSKEY 5 1 3600 20050712112304 ( 1007 20050612112304 62699 example. 1008 e6EB+K21HbyZzoLUeRDb6+g0+n8XASYe6h+Z 1009 xtnB31sQXZgq8MBHeNFDQW9eZw2hjT9zMClx 1010 mTkunTYzqWJrmQ== ) 1011 3600 RRSIG DNSKEY 5 1 3600 20050712112304 ( 1012 20050612112304 21960 example. 1013 SnWLiNWLbOuiKU/F/wVMokvcg6JVzGpQ2VUk 1014 ZbKjB9ON0t3cdc+FZbOCMnEHRJiwgqlnncik 1015 3w7ZY2UWyYIvpw== ) 1016 5pe7ctl7pfs2cilroy5dcofx4rcnlypd.example. 3600 NSEC3 0 1 1 ( 1017 deadbeaf 1018 7nomf47k3vlidh4vxahhpp47l3tgv7a2 1019 NSEC3 RRSIG ) 1020 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( 1021 20050612112304 62699 example. 1022 PTWYq4WZmmtgh9UQif342HWf9DD9RuuM4ii5 1023 Z1oZQgRi5zrsoKHAgl2YXprF2Rfk1TLgsiFQ 1024 sb7KfbaUo/vzAg== ) 1025 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 NSEC3 0 1 1 ( 1026 deadbeaf 1027 dw4o7j64wnel3j4jh7fb3c5n7w3js2yb 1028 MX NSEC3 RRSIG ) 1029 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( 1030 20050612112304 62699 example. 1031 YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA 1032 ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo 1033 MEFQmc/gEuxojA== ) 1034 a.example. 3600 IN NS ns1.a.example. 1035 3600 IN NS ns2.a.example. 1036 3600 DS 58470 5 1 3079F1593EBAD6DC121E202A8B 1037 766A6A4837206C ) 1038 3600 RRSIG DS 5 2 3600 20050712112304 ( 1039 20050612112304 62699 example. 1040 QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn 1041 cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2 1042 0kx7rGKTc3RQDA== ) 1043 ns1.a.example. 3600 IN A 192.0.2.5 1044 ns2.a.example. 3600 IN A 192.0.2.6 1045 ai.example. 3600 IN A 192.0.2.9 1046 3600 RRSIG A 5 2 3600 20050712112304 ( 1047 20050612112304 62699 example. 1048 plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU 1049 6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq 1050 ZXW5S+1VjMZYzQ== ) 1051 3600 HINFO "KLH-10" "ITS" 1052 3600 RRSIG HINFO 5 2 3600 20050712112304 ( 1053 20050612112304 62699 example. 1054 AR0hG/Z/e+vlRhxRQSVIFORzrJTBpdNHhwUk 1055 tiuqg+zGqKK84eIqtrqXelcE2szKnF3YPneg 1056 VGNmbgPnqDVPiA== ) 1057 3600 AAAA 2001:db8:0:0:0:0:f00:baa9 1058 3600 RRSIG AAAA 5 2 3600 20050712112304 ( 1059 20050612112304 62699 example. 1060 PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV 1061 ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns 1062 l5/UqLCJJ9BDMg== ) 1063 b.example. 3600 IN NS ns1.b.example. 1064 3600 IN NS ns2.b.example. 1065 ns1.b.example. 3600 IN A 192.0.2.7 1066 ns2.b.example. 3600 IN A 192.0.2.8 1067 dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 NSEC3 0 1 1 ( 1068 deadbeaf 1069 gmnfcccja7wkax3iv26bs75myptje3qk 1070 MX DNSKEY NS SOA NSEC3 RRSIG ) 1071 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( 1072 20050612112304 62699 example. 1073 VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D 1074 C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R 1075 MOiKMSHozVebqw== ) 1076 gmnfcccja7wkax3iv26bs75myptje3qk.example. 3600 NSEC3 0 1 1 ( 1077 deadbeaf 1078 jt4bbfokgbmr57qx4nqucvvn7fmo6ab6 1079 DS NS NSEC3 RRSIG ) 1080 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( 1081 20050612112304 62699 example. 1082 ZqkdmF6eICpHyn1Cj7Yvw+nLcbji46Qpe76/ 1083 ZetqdZV7K5sO3ol5dOc0dZyXDqsJp1is5StW 1084 OwQBGbOegrW/Zw== ) 1085 jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 NSEC3 0 1 1 ( 1086 deadbeaf 1087 kcll7fqfnisuhfekckeeqnmbbd4maanu 1088 NSEC3 RRSIG ) 1089 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( 1090 20050612112304 62699 example. 1091 FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V 1092 IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK 1093 94Zbq3k8lgdpZA== ) 1094 kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 NSEC3 1 1 1 ( 1095 deadbeaf 1096 n42hbhnjj333xdxeybycax5ufvntux5d 1097 MX NSEC3 RRSIG ) 1098 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( 1099 20050612112304 62699 example. 1100 d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA 1101 IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx 1102 TOLtc5jPrkL4zQ== ) 1103 n42hbhnjj333xdxeybycax5ufvntux5d.example. 3600 NSEC3 0 1 1 ( 1104 deadbeaf 1105 nimwfwcnbeoodmsc6npv3vuaagaevxxu 1106 A NSEC3 RRSIG ) 1107 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( 1108 20050612112304 62699 example. 1109 MZGzllh+YFqZbY8SkHxARhXFiMDPS0tvQYyy 1110 91tj+lbl45L/BElD3xxB/LZMO8vQejYtMLHj 1111 xFPFGRIW3wKnrA== ) 1112 nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 NSEC3 0 1 1 ( 1113 deadbeaf 1114 vhgwr2qgykdkf4m6iv6vkagbxozphazr 1115 HINFO A AAAA NSEC3 RRSIG ) 1116 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( 1117 20050612112304 62699 example. 1118 c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx 1119 z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG 1120 jL33Wm1p07TBdw== ) 1121 ns1.example. 3600 A 192.0.2.1 1122 3600 RRSIG A 5 2 3600 20050712112304 ( 1123 20050612112304 62699 example. 1124 QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb 1125 BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr 1126 nWWLepz1PjjShQ== ) 1127 ns2.example. 3600 A 192.0.2.2 1128 3600 RRSIG A 5 2 3600 20050712112304 ( 1129 20050612112304 62699 example. 1130 UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3 1131 P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz 1132 AkeTJu3J3auUiA== ) 1133 vhgwr2qgykdkf4m6iv6vkagbxozphazr.example. 3600 NSEC3 0 1 1 ( 1134 deadbeaf 1135 wbyijvpnyj33pcpi3i44ecnibnaj7eiw 1136 HINFO A AAAA NSEC3 RRSIG ) 1137 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( 1138 20050612112304 62699 example. 1139 leFhoF5FXZAiNOxK4OBOOA0WKdbaD5lLDT/W 1140 kLoyWnQ6WGBwsUOdsEcVmqz+1n7q9bDf8G8M 1141 5SNSHIyfpfsi6A== ) 1142 *.w.example. 3600 MX 1 ai.example. 1143 3600 RRSIG MX 5 3 3600 20050712112304 ( 1144 20050612112304 62699 example. 1145 sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF 1146 xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ 1147 gQlgxEwhvQDEaQ== ) 1148 x.w.example. 3600 MX 1 xx.example. 1149 3600 RRSIG MX 5 3 3600 20050712112304 ( 1150 20050612112304 62699 example. 1151 s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w 1152 lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP 1153 U9VazOa1KEIq1w== ) 1154 x.y.w.example. 3600 MX 1 xx.example. 1155 3600 RRSIG MX 5 4 3600 20050712112304 ( 1156 20050612112304 62699 example. 1157 aKVCGO/Fx9rm04UUsHRTTYaDA8o8dGfyq6t7 1158 uqAcYxU9xiXP+xNtLHBv7er6Q6f2JbOs6SGF 1159 9VrQvJjwbllAfA== ) 1160 wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 NSEC3 0 1 1 ( 1161 deadbeaf 1162 zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui 1163 A NSEC3 RRSIG ) 1164 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( 1165 20050612112304 62699 example. 1166 ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN 1167 ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd 1168 oorBv4xkb0flXw== ) 1169 xx.example. 3600 A 192.0.2.10 1170 3600 RRSIG A 5 2 3600 20050712112304 ( 1171 20050612112304 62699 example. 1172 XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9 1173 tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj 1174 cxwCXWj82GVGdw== ) 1175 3600 HINFO "KLH-10" "TOPS-20" 1176 3600 RRSIG HINFO 5 2 3600 20050712112304 ( 1177 20050612112304 62699 example. 1178 ghS2DimOqPSacG9j6KMgXSfTMSjLxvoxvx3q 1179 OKzzPst4tEbAmocF2QX8IrSHr67m4ZLmd2Fk 1180 KMf4DgNBDj+dIQ== ) 1181 3600 AAAA 2001:db8:0:0:0:0:f00:baaa 1182 3600 RRSIG AAAA 5 2 3600 20050712112304 ( 1183 20050612112304 62699 example. 1184 rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo 1185 w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy 1186 rzKKwb8J04/ILw== ) 1187 zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 NSEC3 0 1 1 ( 1188 deadbeaf 1189 5pe7ctl7pfs2cilroy5dcofx4rcnlypd 1190 MX NSEC3 RRSIG ) 1191 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( 1192 20050612112304 62699 example. 1193 eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt 1194 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny 1195 OcFlrPGPMm48/A== ) 1197 Appendix B. Example Responses 1199 The examples in this section show response messages using the signed 1200 zone example in Appendix A. 1202 B.1. answer 1204 A successful query to an authoritative server. 1206 ;; Header: QR AA DO RCODE=0 1207 ;; 1208 ;; Question 1209 x.w.example. IN MX 1211 ;; Answer 1212 x.w.example. 3600 IN MX 1 xx.example. 1213 x.w.example. 3600 IN RRSIG MX 5 3 3600 20050712112304 ( 1214 20050612112304 62699 example. 1215 s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w 1216 lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP 1217 U9VazOa1KEIq1w== ) 1219 ;; Authority 1220 example. 3600 IN NS ns1.example. 1221 example. 3600 IN NS ns2.example. 1222 example. 3600 IN RRSIG NS 5 1 3600 20050712112304 ( 1223 20050612112304 62699 example. 1224 hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l 1225 m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d 1226 1SH5r/wfjuCg+g== ) 1228 ;; Additional 1229 xx.example. 3600 IN A 192.0.2.10 1230 xx.example. 3600 IN RRSIG A 5 2 3600 20050712112304 ( 1231 20050612112304 62699 example. 1232 XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9 1233 tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj 1234 cxwCXWj82GVGdw== ) 1235 xx.example. 3600 IN AAAA 2001:db8::f00:baaa 1236 xx.example. 3600 IN RRSIG AAAA 5 2 3600 20050712112304 ( 1237 20050612112304 62699 example. 1238 rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo 1239 w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy 1240 rzKKwb8J04/ILw== ) 1241 ns1.example. 3600 IN A 192.0.2.1 1242 ns1.example. 3600 IN RRSIG A 5 2 3600 20050712112304 ( 1243 20050612112304 62699 example. 1244 QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb 1245 BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr 1246 nWWLepz1PjjShQ== ) 1247 ns2.example. 3600 IN A 192.0.2.2 1248 ns2.example. 3600 IN RRSIG A 5 2 3600 20050712112304 ( 1249 20050612112304 62699 example. 1250 UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3 1251 P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz 1252 AkeTJu3J3auUiA== ) 1254 The query returned an MX RRset for "x.w.example". The corresponding 1255 RRSIG RR indicates that the MX RRset was signed by an "example" 1256 DNSKEY with algorithm 5 and key tag 62699. The resolver needs the 1257 corresponding DNSKEY RR in order to authenticate this answer. The 1258 discussion below describes how a resolver might obtain this DNSKEY 1259 RR. 1261 The RRSIG RR indicates the original TTL of the MX RRset was 3600, 1262 and, for the purpose of authentication, the current TTL is replaced 1263 by 3600. The RRSIG RR's labels field value of 3 indicates that the 1264 answer was not the result of wildcard expansion. The "x.w.example" 1265 MX RRset is placed in canonical form, and, assuming the current time 1266 falls between the signature inception and expiration dates, the 1267 signature is authenticated. 1269 B.1.1. Authenticating the Example DNSKEY RRset 1271 This example shows the logical authentication process that starts 1272 from a configured root DNSKEY RRset (or DS RRset) and moves down the 1273 tree to authenticate the desired "example" DNSKEY RRset. Note that 1274 the logical order is presented for clarity. An implementation may 1275 choose to construct the authentication as referrals are received or 1276 to construct the authentication chain only after all RRsets have been 1277 obtained, or in any other combination it sees fit. The example here 1278 demonstrates only the logical process and does not dictate any 1279 implementation rules. 1281 We assume the resolver starts with a configured DNSKEY RRset for the 1282 root zone (or a configured DS RRset for the root zone). The resolver 1283 checks whether this configured DNSKEY RRset is present in the root 1284 DNSKEY RRset (or whether a DS RR in the DS RRset matches some DNSKEY 1285 RR in the root DNSKEY RRset), whether this DNSKEY RR has signed the 1286 root DNSKEY RRset, and whether the signature lifetime is valid. If 1287 all these conditions are met, all keys in the DNSKEY RRset are 1288 considered authenticated. The resolver then uses one (or more) of 1289 the root DNSKEY RRs to authenticate the "example" DS RRset. Note 1290 that the resolver may have to query the root zone to obtain the root 1291 DNSKEY RRset or "example" DS RRset. 1293 Once the DS RRset has been authenticated using the root DNSKEY, the 1294 resolver checks the "example" DNSKEY RRset for some "example" DNSKEY 1295 RR that matches one of the authenticated "example" DS RRs. If such a 1296 matching "example" DNSKEY is found, the resolver checks whether this 1297 DNSKEY RR has signed the "example" DNSKEY RRset and the signature 1298 lifetime is valid. If these conditions are met, all keys in the 1299 "example" DNSKEY RRset are considered authenticated. 1301 Finally, the resolver checks that some DNSKEY RR in the "example" 1302 DNSKEY RRset uses algorithm 5 and has a key tag of 62699. This 1303 DNSKEY is used to authenticate the RRSIG included in the response. 1304 If multiple "example" DNSKEY RRs match this algorithm and key tag, 1305 then each DNSKEY RR is tried, and the answer is authenticated if any 1306 of the matching DNSKEY RRs validate the signature as described above. 1308 B.2. Name Error 1310 An authoritative name error. The NSEC3 RRs prove that the name does 1311 not exist and that no covering wildcard exists. 1313 ;; Header: QR AA DO RCODE=3 1314 ;; 1315 ;; Question 1316 a.c.x.w.example. IN A 1318 ;; Answer 1319 ;; (empty) 1321 ;; Authority 1322 example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 1323 1 1324 3600 1325 300 1326 3600000 1327 3600 1328 ) 1329 example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( 1330 20050612112304 62699 example. 1331 RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK 1332 mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g 1333 qYIt90txzE/4+g== ) 1334 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN NSEC3 0 1 1 ( 1335 deadbeaf 1336 dw4o7j64wnel3j4jh7fb3c5n7w3js2yb 1337 MX NSEC3 RRSIG ) 1338 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN RRSIG NSEC3 ( 1339 5 2 3600 20050712112304 1340 20050612112304 62699 example. 1341 YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA 1342 ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo 1343 MEFQmc/gEuxojA== ) 1344 nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN NSEC3 0 1 1 ( 1345 deadbeaf 1346 vhgwr2qgykdkf4m6iv6vkagbxozphazr 1347 HINFO A AAAA NSEC3 RRSIG ) 1348 nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN RRSIG NSEC3 ( 1349 5 2 3600 20050712112304 1350 20050612112304 62699 example. 1351 c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx 1352 z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG 1353 jL33Wm1p07TBdw== ) 1354 ;; Additional 1355 ;; (empty) 1357 The query returned two NSEC3 RRs that prove that the requested data 1358 does not exist and no wildcard applies. The negative reply is 1359 authenticated by verifying both NSEC3 RRs. The NSEC3 RRs are 1360 authenticated in a manner identical to that of the MX RRset discussed 1361 above. At least one of the owner names of the NSEC3 RRs will match 1362 the closest encloser. At least one of the NSEC3 RRs prove that there 1363 exists no longer name. At least one of the NSEC3 RRs prove that 1364 there exists no wildcard RRsets that should have been expanded. The 1365 closest encloser can be found by hashing the apex ownername (The SOA 1366 RR's ownername, or the ownername of the DNSKEY RRset referred by an 1367 RRSIG RR), matching it to the ownername of one of the NSEC3 RRs, and 1368 if that fails, continue by adding labels. In other words, the 1369 resolver first hashes example, checks for a matching NSEC3 ownername, 1370 then hashes w.example, checks, and finally hashes w.x.example and 1371 checks. 1373 In the above example, the name 'x.w.example' hashes to 1374 '7nomf47k3vlidh4vxahhpp47l3tgv7a2'. This indicates that this might 1375 be the closest encloser. To prove that 'c.x.w.example' and 1376 '*.x.w.example' do not exists, these names are hashed to respectively 1377 'qsgoxsf2lanysajhtmaylde4tqwnqppl' and 1378 'cvljzyf6nsckjowghch4tt3nohocpdka'. The two NSEC3 records prove that 1379 these hashed ownernames do not exists, since the names are within the 1380 given intervals. 1382 B.3. No Data Error 1384 A "no data" response. The NSEC3 RR proves that the name exists and 1385 that the requested RR type does not. 1387 ;; Header: QR AA DO RCODE=0 1388 ;; 1389 ;; Question 1390 ns1.example. IN MX 1392 ;; Answer 1393 ;; (empty) 1395 ;; Authority 1396 example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 1397 1 1398 3600 1399 300 1400 3600000 1401 3600 1402 ) 1403 example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( 1404 20050612112304 62699 example. 1405 RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK 1406 mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g 1407 qYIt90txzE/4+g== ) 1408 wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN NSEC3 0 1 1 ( 1409 deadbeaf 1410 zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui 1411 A NSEC3 RRSIG ) 1412 wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN RRSIG NSEC3 ( 1413 5 2 3600 20050712112304 1414 20050612112304 62699 example. 1415 ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN 1416 ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd 1417 oorBv4xkb0flXw== ) 1418 ;; Additional 1419 ;; (empty) 1421 The query returned an NSEC3 RR that proves that the requested name 1422 exists ("ns1.example." hashes to "wbyijvpnyj33pcpi3i44ecnibnaj7eiw"), 1423 but the requested RR type does not exist (type MX is absent in the 1424 type code list of the NSEC RR). The negative reply is authenticated 1425 by verifying the NSEC3 RR. The NSEC3 RR is authenticated in a manner 1426 identical to that of the MX RRset discussed above. 1428 B.3.1. No Data Error, Empty Non-Terminal 1430 A "no data" response because of an empty non-terminal. The NSEC3 RR 1431 proves that the name exists and that the requested RR type does not. 1433 ;; Header: QR AA DO RCODE=0 1434 ;; 1435 ;; Question 1436 y.w.example. IN A 1438 ;; Answer 1439 ;; (empty) 1441 ;; Authority 1442 example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 1443 1 1444 3600 1445 300 1446 3600000 1447 3600 1448 ) 1449 example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( 1450 20050612112304 62699 example. 1451 RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK 1452 mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g 1453 qYIt90txzE/4+g== ) 1454 jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN NSEC3 0 1 1 ( 1455 deadbeaf 1456 kcll7fqfnisuhfekckeeqnmbbd4maanu 1457 NSEC3 RRSIG ) 1458 jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN RRSIG NSEC3 ( 1459 5 2 3600 20050712112304 1460 20050612112304 62699 example. 1461 FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V 1462 IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK 1463 94Zbq3k8lgdpZA== ) 1465 The query returned an NSEC3 RR that proves that the requested name 1466 exists ("y.w.example." hashes to "jt4bbfokgbmr57qx4nqucvvn7fmo6ab6"), 1467 but the requested RR type does not exist (Type A is absent in the 1468 type-bit-maps of the NSEC3 RR). The negative reply is authenticated 1469 by verifying the NSEC3 RR. The NSEC3 RR is authenticated in a manner 1470 identical to that of the MX RRset discussed above. Note that, unlike 1471 generic empty non terminal proof using NSECs, this is identical to 1472 proving a No Data Error. This example is solely mentioned to be 1473 complete. 1475 B.4. Referral to Signed Zone 1477 Referral to a signed zone. The DS RR contains the data which the 1478 resolver will need to validate the corresponding DNSKEY RR in the 1479 child zone's apex. 1481 ;; Header: QR DO RCODE=0 1482 ;; 1484 ;; Question 1485 mc.a.example. IN MX 1487 ;; Answer 1488 ;; (empty) 1490 ;; Authority 1491 a.example. 3600 IN NS ns1.a.example. 1492 a.example. 3600 IN NS ns2.a.example. 1493 a.example. 3600 IN DS 58470 5 1 ( 1494 3079F1593EBAD6DC121E202A8B766A6A4837 1495 206C ) 1496 a.example. 3600 IN RRSIG DS 5 2 3600 20050712112304 ( 1497 20050612112304 62699 example. 1498 QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn 1499 cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2 1500 0kx7rGKTc3RQDA== ) 1502 ;; Additional 1503 ns1.a.example. 3600 IN A 192.0.2.5 1504 ns2.a.example. 3600 IN A 192.0.2.6 1506 The query returned a referral to the signed "a.example." zone. The 1507 DS RR is authenticated in a manner identical to that of the MX RRset 1508 discussed above. This DS RR is used to authenticate the "a.example" 1509 DNSKEY RRset. 1511 Once the "a.example" DS RRset has been authenticated using the 1512 "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset 1513 for some "a.example" DNSKEY RR that matches the DS RR. If such a 1514 matching "a.example" DNSKEY is found, the resolver checks whether 1515 this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether 1516 the signature lifetime is valid. If all these conditions are met, 1517 all keys in the "a.example" DNSKEY RRset are considered 1518 authenticated. 1520 B.5. Referral to Unsigned Zone using the Opt-In Flag 1522 The NSEC3 RR proves that nothing for this delegation was signed in 1523 the parent zone. There is no proof that the delegation exists 1524 ;; Header: QR DO RCODE=0 1525 ;; 1526 ;; Question 1527 mc.b.example. IN MX 1529 ;; Answer 1530 ;; (empty) 1532 ;; Authority 1533 b.example. 3600 IN NS ns1.b.example. 1534 b.example. 3600 IN NS ns2.b.example. 1535 kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN NSEC3 1 1 1 ( 1536 deadbeaf 1537 n42hbhnjj333xdxeybycax5ufvntux5d 1538 MX NSEC3 RRSIG ) 1539 kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN RRSIG NSEC3 ( 1540 5 2 3600 20050712112304 1541 20050612112304 62699 example. 1542 d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA 1543 IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx 1544 TOLtc5jPrkL4zQ== ) 1546 ;; Additional 1547 ns1.b.example. 3600 IN A 192.0.2.7 1548 ns2.b.example. 3600 IN A 192.0.2.8 1550 The query returned a referral to the unsigned "b.example." zone. The 1551 NSEC3 proves that no authentication leads from "example" to 1552 "b.example", since the hash of "b.example" 1553 ("ldjpfcucebeks5azmzpty4qlel4cftzo") is within the NSEC3 interval and 1554 the NSEC3 opt-in bit is set. The NSEC3 RR is authenticated in a 1555 manner identical to that of the MX RRset discussed above. 1557 B.6. Wildcard Expansion 1559 A successful query that was answered via wildcard expansion. The 1560 label count in the answer's RRSIG RR indicates that a wildcard RRset 1561 was expanded to produce this response, and the NSEC3 RR proves that 1562 no closer match exists in the zone. 1564 ;; Header: QR AA DO RCODE=0 1565 ;; 1566 ;; Question 1567 a.z.w.example. IN MX 1569 ;; Answer 1570 a.z.w.example. 3600 IN MX 1 ai.example. 1571 a.z.w.example. 3600 IN RRSIG MX 5 3 3600 20050712112304 ( 1572 20050612112304 62699 example. 1573 sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF 1574 xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ 1575 gQlgxEwhvQDEaQ== ) 1576 ;; Authority 1577 example. 3600 NS ns1.example. 1578 example. 3600 NS ns2.example. 1579 example. 3600 IN RRSIG NS 5 1 3600 20050712112304 ( 1580 20050612112304 62699 example. 1581 hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l 1582 m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d 1583 1SH5r/wfjuCg+g== ) 1584 zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3 0 1 1 ( 1585 deadbeaf 1586 5pe7ctl7pfs2cilroy5dcofx4rcnlypd 1587 MX NSEC3 RRSIG ) 1588 zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG NSEC3 ( 1589 5 2 3600 20050712112304 1590 20050612112304 62699 example. 1591 eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt 1592 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny 1593 OcFlrPGPMm48/A== ) 1594 ;; Additional 1595 ai.example. 3600 IN A 192.0.2.9 1596 ai.example. 3600 IN RRSIG A 5 2 3600 20050712112304 ( 1597 20050612112304 62699 example. 1598 plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU 1599 6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq 1600 ZXW5S+1VjMZYzQ== ) 1601 ai.example. 3600 AAAA 2001:db8::f00:baa9 1602 ai.example. 3600 IN RRSIG AAAA 5 2 3600 20050712112304 ( 1603 20050612112304 62699 example. 1604 PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV 1605 ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns 1606 l5/UqLCJJ9BDMg== ) 1608 The query returned an answer that was produced as a result of 1609 wildcard expansion. The answer section contains a wildcard RRset 1610 expanded as it would be in a traditional DNS response, and the 1611 corresponding RRSIG indicates that the expanded wildcard MX RRset was 1612 signed by an "example" DNSKEY with algorithm 5 and key tag 62699. 1613 The RRSIG indicates that the original TTL of the MX RRset was 3600, 1614 and, for the purpose of authentication, the current TTL is replaced 1615 by 3600. The RRSIG labels field value of 2 indicates that the answer 1616 is the result of wildcard expansion, as the "a.z.w.example" name 1617 contains 4 labels. The name "a.z.w.example" is replaced by 1618 "*.w.example", the MX RRset is placed in canonical form, and, 1619 assuming that the current time falls between the signature inception 1620 and expiration dates, the signature is authenticated. 1622 The NSEC3 proves that no closer match (exact or closer wildcard) 1623 could have been used to answer this query, and the NSEC3 RR must also 1624 be authenticated before the answer is considered valid. 1626 B.7. Wildcard No Data Error 1628 A "no data" response for a name covered by a wildcard. The NSEC3 RRs 1629 prove that the matching wildcard name does not have any RRs of the 1630 requested type and that no closer match exists in the zone. 1632 ;; Header: QR AA DO RCODE=0 1633 ;; 1634 ;; Question 1635 a.z.w.example. IN AAAA 1637 ;; Answer 1638 ;; (empty) 1640 ;; Authority 1641 example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 1642 1 1643 3600 1644 300 1645 3600000 1646 3600 1647 ) 1648 example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( 1649 20050612112304 62699 example. 1650 RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK 1651 mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g 1652 qYIt90txzE/4+g== ) 1653 zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3 0 1 1 ( 1654 deadbeaf 1655 5pe7ctl7pfs2cilroy5dcofx4rcnlypd 1656 MX NSEC3 RRSIG ) 1657 zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG NSEC3 ( 1658 5 2 3600 20050712112304 1659 20050612112304 62699 example. 1660 eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt 1661 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny 1662 OcFlrPGPMm48/A== ) 1663 ;; Additional 1664 ;; (empty) 1666 The query returned NSEC3 RRs that prove that the requested data does 1667 not exist and no wildcard applies. The negative reply is 1668 authenticated by verifying both NSEC3 RRs. 1670 B.8. DS Child Zone No Data Error 1672 A "no data" response for a QTYPE=DS query that was mistakenly sent to 1673 a name server for the child zone. 1675 ;; Header: QR AA DO RCODE=0 1676 ;; 1677 ;; Question 1678 example. IN DS 1680 ;; Answer 1681 ;; (empty) 1683 ;; Authority 1684 example. 3600 IN SOA ns1.example. bugs.x.w.example. ( 1685 1 1686 3600 1687 300 1688 3600000 1689 3600 1690 ) 1691 example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( 1692 20050612112304 62699 example. 1693 RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK 1694 mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g 1695 qYIt90txzE/4+g== ) 1696 dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN NSEC3 0 1 1 ( 1697 deadbeaf 1698 gmnfcccja7wkax3iv26bs75myptje3qk 1699 MX DNSKEY NS SOA NSEC3 RRSIG ) 1700 dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN RRSIG NSEC3 ( 1701 5 2 3600 20050712112304 1702 20050612112304 62699 example. 1703 VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D 1704 C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R 1705 MOiKMSHozVebqw== ) 1707 ;; Additional 1708 ;; (empty) 1710 The query returned NSEC RRs that shows the requested was answered by 1711 a child server ("example" server). The NSEC RR indicates the 1712 presence of an SOA RR, showing that the answer is from the child . 1713 Queries for the "example" DS RRset should be sent to the parent 1714 servers ("root" servers). 1716 Authors' Addresses 1718 Ben Laurie 1719 Nominet 1720 17 Perryn Road 1721 London W3 7LR 1722 England 1724 Phone: +44 (20) 8735 0686 1725 Email: ben@algroup.co.uk 1727 Geoffrey Sisson 1728 Nominet 1730 Roy Arends 1731 Nominet 1733 Intellectual Property Statement 1735 The IETF takes no position regarding the validity or scope of any 1736 Intellectual Property Rights or other rights that might be claimed to 1737 pertain to the implementation or use of the technology described in 1738 this document or the extent to which any license under such rights 1739 might or might not be available; nor does it represent that it has 1740 made any independent effort to identify any such rights. Information 1741 on the procedures with respect to rights in RFC documents can be 1742 found in BCP 78 and BCP 79. 1744 Copies of IPR disclosures made to the IETF Secretariat and any 1745 assurances of licenses to be made available, or the result of an 1746 attempt made to obtain a general license or permission for the use of 1747 such proprietary rights by implementers or users of this 1748 specification can be obtained from the IETF on-line IPR repository at 1749 http://www.ietf.org/ipr. 1751 The IETF invites any interested party to bring to its attention any 1752 copyrights, patents or patent applications, or other proprietary 1753 rights that may cover technology that may be required to implement 1754 this standard. Please address the information to the IETF at 1755 ietf-ipr@ietf.org. 1757 Disclaimer of Validity 1759 This document and the information contained herein are provided on an 1760 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1761 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1762 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1763 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1764 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1765 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1767 Copyright Statement 1769 Copyright (C) The Internet Society (2006). This document is subject 1770 to the rights, licenses and restrictions contained in BCP 78, and 1771 except as set forth therein, the authors retain all their rights. 1773 Acknowledgment 1775 Funding for the RFC Editor function is currently provided by the 1776 Internet Society.