idnits 2.17.1 draft-gieben-auth-denial-of-existence-dns-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 467: '... closest encloser, this SHOULD be used...' RFC 2119 keyword, line 606: '... "The validator MUST verify that an N...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 14, 2013) is 3847 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) -- Obsolete informational reference (is this intentional?): RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3655 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3755 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Duplicate reference: RFC5155, mentioned in 'RFC5155-errata3441', was also mentioned in 'RFC5155'. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Gieben 3 Internet-Draft Google 4 Intended status: Informational W. Mekking 5 Expires: April 17, 2014 NLnet Labs 6 October 14, 2013 8 Authenticated Denial of Existence in the DNS 9 draft-gieben-auth-denial-of-existence-dns-03 11 Abstract 13 Authenticated denial of existence allows a resolver to validate that 14 a certain domain name does not exist. It is also used to signal that 15 a domain name exists, but does not have the specific RR type you were 16 asking for. When returning a negative DNSSEC response, a name server 17 usually includes up to two NSEC records. With NSEC3 this amount is 18 three. This document provides additional background commentary and 19 some context for the NSEC and NSEC3 mechanisms used by DNSSEC to 20 provide authenticated denial of existence responses 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 17, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Denial of Existence . . . . . . . . . . . . . . . . . . . . . 4 55 2.1. NXDOMAIN Responses . . . . . . . . . . . . . . . . . . . 4 56 2.2. NODATA Responses . . . . . . . . . . . . . . . . . . . . 5 57 3. Secure Denial of Existence . . . . . . . . . . . . . . . . . 5 58 3.1. NXT . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.2. NSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 3.3. NODATA Responses . . . . . . . . . . . . . . . . . . . . 9 61 3.4. Drawbacks of NSEC . . . . . . . . . . . . . . . . . . . . 9 62 4. Experimental and Deprecated Mechanisms: NO, NSEC2 and DNSNR . 10 63 5. NSEC3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 5.1. Opt-Out . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 5.2. Loading an NSEC3 Zone . . . . . . . . . . . . . . . . . . 14 66 5.3. Wildcards in the DNS . . . . . . . . . . . . . . . . . . 14 67 5.4. CNAME Records . . . . . . . . . . . . . . . . . . . . . . 17 68 5.5. The Closest Encloser NSEC3 Record . . . . . . . . . . . . 18 69 5.6. Three To Tango . . . . . . . . . . . . . . . . . . . . . 22 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 72 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 24 75 9.2. Informative References . . . . . . . . . . . . . . . . . 25 76 Appendix A. List of Hashed Owner Names . . . . . . . . . . . . . 25 77 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 26 78 B.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 79 B.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 80 B.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 81 B.4. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 83 1. Introduction 85 DNSSEC can be somewhat of a complicated matter, and there are certain 86 areas of the specification that are more difficult to comprehend than 87 others. One such area is "authenticated denial of existence". 89 Denial of existence is a mechanism that informs a resolver that a 90 certain domain name does not exist. It is also used to signal that a 91 domain name exists, but does not have the specific RR type you were 92 asking for. 94 The first is referred to as an NXDOMAIN (non-existent domain) 95 ([RFC2308] Section 2.1) and the latter a NODATA ([RFC2308] 96 Section 2.2) response. Both are also known as negative responses. 98 Authenticated denial of existence uses cryptography to sign the 99 negative response. However, if there is no answer, what is it that 100 needs to be signed? To further complicate this matter, there is the 101 desire to pre-generate negative responses that are applicable for all 102 queries for non-existent names in the signed zone. See Section 3 for 103 the details. 105 In this document, we will explain how authenticated denial of 106 existence works. We begin by explaining the current technique in the 107 DNS and work our way up to DNSSEC. We explain the first steps taken 108 in DNSSEC and describe how NSEC and NSEC3 work. The NXT, NO, NSEC2 109 and DNSNR records also briefly make their appearance, as they have 110 paved the way for NSEC and NSEC3. 112 To complete the picture, we also need to explain DNS wildcards as 113 these complicate matters, especially combined with CNAME records. 115 Note: In this document, domain names in zone file examples will have 116 a trailing dot, in the running text they will not. This text is 117 written for people who have a fair understanding of DNSSEC. The 118 following RFCs are not required reading, but they help in 119 understanding the problem space. 121 o RFC 5155 [RFC5155] - Hashed Authenticated Denial of Existence; 123 o RFC 4592 [RFC4592] - The Role of Wildcards in the DNS. 125 And these provide some general DNSSEC information. 127 o RFC 4033, RFC 4034, RFC 4035 [RFC4033], [RFC4034], [RFC4035] - 128 DNSSEC Specification; 130 o RFC 4956 [RFC4956] - DNS Security (DNSSEC) Opt-In. This RFC has 131 experimental status, but is a good read. 133 These three drafts give some background information on the NSEC3 134 development. 136 o The NO record [I-D.ietf-dnsext-not-existing-rr]; 137 o The NSEC2 record [I-D.laurie-dnsext-nsec2v2]; 139 o The DNSNR record [I-D.arends-dnsnr]. 141 2. Denial of Existence 143 We start with the basics and take a look at NXDOMAIN handling in the 144 DNS. To make it more visible we are going to use a small DNS zone, 145 with 3 names ("example.org", "a.example.org" and "d.example.org") and 146 3 types (SOA, A and TXT). For brevity, the class is not shown 147 (defaults to IN), the NS records are left out and the SOA record is 148 shortened, resulting in the following zone file: 150 example.org. SOA ( ... ) 151 a.example.org. A 192.0.2.1 152 TXT "a record" 153 d.example.org. A 192.0.2.1 154 TXT "d record" 156 Figure 1: The unsigned "example.org" zone. 158 2.1. NXDOMAIN Responses 160 If a resolver asks for the TXT type belonging to "a.example.org" to 161 the name server serving this zone, it sends the following question: 162 "a.example.org TXT" 164 The name server looks in its zone data and generates an answer. In 165 this case a positive one: "Yes it exists and this is the data", 166 resulting in this reply: 168 ;; status: NOERROR, id: 28203 170 ;; ANSWER SECTION: 171 a.example.org. TXT "a record" 173 ;; AUTHORITY SECTION: 174 example.org. NS a.example.org. 176 The "status: NOERROR" signals that everything is OK, "id" is an 177 integer used to match questions and answers. In the ANSWER section, 178 we find our answer. The AUTHORITY section holds the names of the 179 name servers that have information concerning the "example.org" zone. 180 Note that including this information is optional. 182 If a resolver asks for "b.example.org TXT" it gets an answer that 183 this name does not exist: 185 ;; status: NXDOMAIN, id: 7042 187 ;; AUTHORITY SECTION: 188 example.org. SOA ( ... ) 190 In this case, we do not get an ANSWER section and the status is set 191 to NXDOMAIN. From this the resolver concludes that "b.example.org" 192 does not exist. The AUTHORITY section holds the SOA record of 193 "example.org" that the resolver can use to cache the negative 194 response. 196 2.2. NODATA Responses 198 It is important to realize that NXDOMAIN is not the only type of 199 does-not-exist. A name may exist, but the type you are asking for 200 may not. This occurrence of non-existence is called a NODATA 201 response. Let us ask our name server for "a.example.org AAAA", and 202 look at the answer: 204 ;; status: NOERROR, id: 7944 206 ;; AUTHORITY SECTION: 207 example.org. SOA ( ... ) 209 The status NOERROR shows that the "a.example.org" name exists, but 210 the reply does not contain an ANSWER section. This differentiates a 211 NODATA response from an NXDOMAIN response, the rest of the packet is 212 very similar. The resolver has to put these pieces of information 213 together and conclude that "a.example.org" exists, but it does not 214 have an "AAAA" record. 216 3. Secure Denial of Existence 218 The above has to be translated to the security aware world of DNSSEC. 219 But there are a few requirements DNSSEC brings to the table: 221 1. There is no online signing defined in DNSSEC. Although a name 222 server is free to compute the answer and signature(s) on-the-fly, 223 the protocol is written with a "first sign, then load" attitude 224 in mind. It is rather asymmetrical, but a lot of the design in 225 DNSSEC stems from fact that you need to accommodate authenticated 226 denial of existence. If the DNS did not have NXDOMAIN, DNSSEC 227 would be a lot simpler, but a lot less useful! 229 2. The DNS packet header is not signed. This means that a "status: 230 NXDOMAIN" can not be trusted. In fact the entire header may be 231 forged, including the AD bit (AD stands for Authentic Data, see 232 RFC 3655 [RFC3655]), which may give some food for thought; 234 3. DNS wildcards and CNAME records complicate matters significantly. 235 More about this in later sections (Section 5.3 and Section 5.4). 237 The first requirement implies that all denial of existence answers 238 need to be pre-computed, but it is impossible to pre-compute (all 239 conceivable) non-existence answers. A generic denial record which 240 can be used in all denial of existence proofs is not an option: such 241 a record is susceptible to replay attacks. When you are querying a 242 name server for a record that actually exists, a man-in-the-middle 243 may replay that generic denial record and it would be impossible to 244 tell whether the response was genuine or spoofed. 246 This has been solved by introducing a record that defines an interval 247 between two existing names. Or to put it another way: it defines the 248 holes (non-existing names) in the zone. This record can be signed 249 beforehand and given to the resolver. 251 Given all these troubles, why didn't the designers of DNSSEC go 252 for the (easy) route and allowed for online signing? Well, at 253 that time (pre 2000), online signing was not feasible with the 254 then current hardware. Keep in mind that the larger servers get 255 between 2000 and 6000 queries per second (qps), with peaks up to 256 20,000 qps or more. Scaling signature generation to these kind of 257 levels is always a challenge. Another issue was (and is) key 258 management, for online signing to work you need access to the 259 private key(s). This is considered a security risk. 261 The road to the current solution (NSEC/NSEC3) was long. It started 262 with the NXT (next) record. The NO (not existing) record was 263 introduced, but never made it to RFC. Later on, NXT was superseded 264 by the NSEC (next secure) record. From there it went through NSEC2/ 265 DNSNR to finally reach NSEC3 (next secure, version 3) in RFC 5155. 267 3.1. NXT 269 The first attempt to specify authenticated denial of existence was 270 NXT (RFC 2535 [RFC2535]). Section 5.1 of that RFC introduces the 271 record: 273 "The NXT resource record is used to securely indicate that RRs 274 with an owner name in a certain name interval do not exist in a 275 zone and to indicate what RR types are present for an existing 276 name." 278 By specifying what you do have, you implicitly tell what you don't 279 have. NXT is superseded by NSEC. In the next section we explain how 280 NSEC (and thus NXT) works. 282 3.2. NSEC 284 In RFC 3755 [RFC3755] all the DNSSEC types were given new names, SIG 285 was renamed RRSIG, KEY became DNSKEY and NXT was renamed to NSEC and 286 a minor issue was fixed in the process, namely the type bitmap was 287 redefined to allow more than 127 types to be listed ([RFC2535], 288 Section 5.2). 290 Just as NXT, NSEC is used to describe an interval between names: it 291 indirectly tells a resolver which names do not exist in a zone. 293 For this to work, we need our "example.org" zone to be sorted in 294 canonical order ([RFC4034], Section 6.1), and then create the NSECs. 295 We add three NSEC records, one for each name, and each one covers a 296 certain interval. The last NSEC record points back to the first as 297 required by the RFC, and depicted in Figure 2. 299 1. The first NSEC covers the interval between "example.org" and 300 "a.example.org"; 302 2. The second NSEC covers "a.example.org" to "d.example.org"; 304 3. The third NSEC points back to "example.org", and covers 305 "d.example.org" to "example.org" (i.e. the end of the zone). 307 As we have defined the intervals and put those in resource records, 308 we now have something that can be signed. 310 example.org 311 ** 312 +-- ** <--+ 313 (1) / . . \ (3) 314 / . . \ 315 | . . | 316 v . . | 317 ** (2) ** 318 a.example.org ** ---------> ** d.example.org 320 Figure 2: The NSEC records of "example.org". The arrows represent 321 NSEC records, starting from the apex. 323 This signed zone is loaded into the name server. It looks like this: 325 example.org. SOA ( ... ) 326 DNSKEY ( ... ) 327 NSEC a.example.org. SOA NSEC DNSKEY RRSIG 328 RRSIG(SOA) ( ... ) 329 RRSIG(DNSKEY) ( ... ) 330 RRSIG(NSEC) ( ... ) 331 a.example.org. A 192.0.2.1 332 TXT "a record" 333 NSEC d.example.org. A TXT NSEC RRSIG 334 RRSIG(A) ( ... ) 335 RRSIG(TXT) ( ... ) 336 RRSIG(NSEC) ( ... ) 337 d.example.org. A 192.0.2.1 338 TXT "d record" 339 NSEC example.org. A TXT NSEC RRSIG 340 RRSIG(A) ( ... ) 341 RRSIG(TXT) ( ... ) 342 RRSIG(NSEC) ( ... ) 344 Figure 3: The signed and sorted "example.org" zone with the added 345 NSEC records (and signatures). For brevity, the class is not shown 346 (defaults to IN), the NS records are left out and the SOA, DNSKEY and 347 RRSIG records are shortened. 349 If a DNSSEC aware resolver asks for "b.example.org", it gets back a 350 "status: NXDOMAIN" packet, which by itself is meaningless (remember 351 that the DNS packet header is not signed and thus can be forged). To 352 be able to securely detect that "b" does not exist, there must also 353 be a signed NSEC record which covers the name space where "b" lives. 354 The record: 356 a.example.org. NSEC d.example.org. A TXT NSEC RRSIG 358 does precisely that: "b" should come after "a", but the next owner 359 name is "d.example.org", so "b" does not exist. 361 Only by making that calculation, is a resolver able to conclude that 362 the name "b" does not exist. If the signature of the NSEC record is 363 valid, "b" is proven not to exist. We have authenticated denial of 364 existence. 366 Note that a man-in-the-middle may still replay this NXDOMAIN response 367 when you're querying for, say, "c.example.org". But it would not do 368 any harm since it is provably the proper response to the query. In 369 the future, there may be data published for "c.example.org". 370 Therefore, the RRSIG's RDATA include a validity period (not visible 371 in the zone above), so that an attacker cannot replay this NXDOMAIN 372 response for "c.example.org" forever. 374 3.3. NODATA Responses 376 NSEC records are also used in NODATA responses. In that case we need 377 to look more closely at the type bitmap. The type bitmap in an NSEC 378 record tells which types are defined for a name. If we look at the 379 NSEC record of "a.example.org", we see the following types in the 380 bitmap: A, TXT, NSEC and RRSIG. So for the name "a" this indicates 381 we must have an A, TXT, NSEC and RRSIG record in the zone. 383 With the type bitmap of the NSEC record, a resolver can establish 384 that a name is there, but the type is not. For example, if a 385 resolver asks for "a.example.org AAAA", the reply that comes back is: 387 ;; status: NOERROR, id: 44638 389 ;; AUTHORITY SECTION: 390 example.org. SOA ( ... ) 391 example.org. RRSIG(SOA) ( ... ) 392 a.example.org. NSEC d.example.org. A TXT NSEC RRSIG 393 a.example.org. RRSIG(NSEC) ( ... ) 395 The resolver should check the AUTHORITY section and conclude that: 397 (1) "a.example.org" exists (because of the NSEC with that owner 398 name) and; 400 (2) the type (AAAA) does not as it is not listed in the type bitmap. 402 The techniques used by NSEC form the basics of authenticated denial 403 of existence in DNSSEC. 405 3.4. Drawbacks of NSEC 406 There were two issues with NSEC (and NXT). The first is that it 407 allows for zone walking. NSEC records point from one name to 408 another, in our example: "example.org", points to "a.example.org" 409 which points to "d.example.org" which points back to "example.org". 410 So we can reconstruct the entire "example.org" zone, thus defeating 411 attempts to administratively block zone transfers ([RFC2065] 412 Section 5.5). 414 The second issue is that when a large, delegation-centric ([RFC5155], 415 Section 1.1), zone deploys DNSSEC, every name in the zone gets an 416 NSEC plus RRSIG. So this leads to a huge increase in the zone size 417 (when signed). This would in turn mean that operators of such zones 418 who are deploying DNSSEC, face up front costs. This could hinder 419 DNSSEC adoption. 421 These two issues eventually lead to NSEC3 which: 423 o Adds a way to garble the next owner name, thus thwarting zone- 424 walking; 426 o Makes it possible to skip names for the next owner name. This 427 feature is called Opt-Out (See Section 5.1). It means not all 428 names in your zone get an NSEC3 plus ditto signature, making it 429 possible to "grow into" your DNSSEC deployment. 431 But before we delve into NSEC3, let us first take a look at its 432 predecessors: NO, NSEC2 and, DNSNR. 434 4. Experimental and Deprecated Mechanisms: NO, NSEC2 and DNSNR 436 Long before NSEC was defined, the NO record was introduced. It was 437 the first record to use the idea of hashed owner names, to fix the 438 issue of zone walking that was present with the NXT record. It also 439 fixed the type bitmap issue of the NXT record, but not in a space 440 efficient way. At that time (around 2000) zone walking was not 441 considered important enough to warrant the new record. People were 442 also worried that DNSSEC deployment would be hindered by developing 443 an alternate means of denial of existence. Thus the effort was 444 shelved and NXT remained. 446 When the new DNSSEC specification [RFC4034] was written, people were 447 still not convinced that zone walking was a problem that should be 448 solved. So NSEC saw the light and inherited the two issues from NXT. 450 Several years after, NSEC2 was introduced as a way to solve the two 451 issues of NSEC. The NSEC2 draft contains the following paragraph: 453 "This document proposes an alternate scheme which hides owner 454 names while permitting authenticated denial of existence of non- 455 existent names. The scheme uses two new RR types: NSEC2 and 456 EXIST." 458 When an authenticated denial of existence scheme starts to talk about 459 EXIST records, it is worth paying extra attention. The EXIST record 460 was defined as a record without RDATA that would be used to signal 461 the presence of a domain name. From the draft: 463 "In order to prove the nonexistence of a record that might be 464 covered by a wildcard, it is necessary to prove the existence of 465 its closest encloser. This record does that. Its owner is the 466 closest encloser. It has no RDATA. If there is another RR that 467 proves the existence of the closest encloser, this SHOULD be used 468 instead of an EXIST record." 470 The introduction of this record led to questions on what wildcards 471 actually mean (especially in the context of DNSSEC). It is probably 472 not a coincidence that "The Role of Wildcards in the Domain Name 473 System" ([RFC4592]) was standardized before NSEC3 was. 475 NSEC2 solved the zone walking issue by hashing (with SHA1 and a salt) 476 the "next owner name" in the record, thereby making it useless for 477 zone walking. But it did not have Opt-Out. 479 The DNSNR record was another attempt that used hashed names to foil 480 zone walking and it also introduced the concept of opting out (called 481 "Authoritative Only Flag") which limited the use of DNSNR in 482 delegation-centric zones. 484 All these proposals didn't make it, but did provide valuable 485 insights. To summarize: 487 o The NO record introduced hashing, but this idea lingered in the 488 background for a long time; 490 o The NSEC2 record made it clear that wildcards were not completely 491 understood; 493 o The DNSNR record used a new flag field in the RDATA to signal Opt- 494 Out; 496 5. NSEC3 498 From the experience gained with NSEC2 and DNSNR, NSEC3 was forged. 499 It incorporates both Opt-Out and the hashing of names. NSEC3 solves 500 any issues people might have with NSEC, but it introduces some 501 additional complexity. 503 NSEC3 did not supersede NSEC, they are both defined for DNSSEC. So 504 DNSSEC is blessed with two different means to perform authenticated 505 denial of existence: NSEC and NSEC3. In NSEC3 every name is hashed, 506 including the owner name. This means that NSEC3 chain is sorted in 507 hash order, instead of canonical order. Because the owner names are 508 hashed, the next owner name for "example.org" is unlikely to be 509 "a.example.org". Because the next owner name is hashed, zone walking 510 becomes more difficult. 512 To make it even more difficult to retrieve the original names, the 513 hashing can be repeated several times each time taking the previous 514 hash as input. To prevent the reuse of pre-generated hash values 515 between zones a (per zone) salt can also be added. In the NSEC3 for 516 "example.org" we have hashed the names thrice ([RFC5155], Section 5) 517 and use the salt "DEAD". Lets look at typical NSEC3 record: 519 15bg9l6359f5ch23e34ddua6n1rihl9h.example.org. ( 520 NSEC3 1 0 2 DEAD A6EDKB6V8VL5OL8JNQQLT74QMJ7HEB84 521 SOA RRSIG DNSKEY NSEC3PARAM ) 523 On the first line we see the hashed owner name: 524 "15bg9l6359f5ch23e34ddua6n1rihl9h.example.org", this is the hashed 525 name of the fully qualified domain name (FQDN) "example.org" encoded 526 as Base32 ([RFC4648]). Note that even though we hashed 527 "example.org", the zone's name is added to make it look like a domain 528 name again. In our zone, the basic format is 529 "Base32(SHA1(FQDN)).example.org". The next hashed owner name 530 "A6EDKB6V8VL5OL8JNQQLT74QMJ7HEB84" (line 2) is the hashed version of 531 "d.example.org", represented as Base32. Note that "d.example.org" is 532 used are the next owner name, because in the hash ordering, its hash 533 comes after the hash of the zone's apex. Also note that 534 ".example.org" is not added to the next hashed owner name, as this 535 name always falls in the current zone. 537 The "1 0 2 DEAD" section of the NSEC3 states: 539 o Hash Algorithm = 1 (SHA1, this is the default, no other hash 540 algorithms are currently defined for use in NSEC3); 542 o Opt-Out = 0 (disabled); 543 o Hash Iterations = 2, this yields three iterations, as a zero value 544 is already one iteration; 546 o Salt = "DEAD". 548 At the end we see the type bitmap, which is identical to NSEC's 549 bitmap, that lists the types present at the original owner name. 550 Note that the type NSEC3 is absent from the list in the example 551 above. This is due to the fact that the original owner name 552 ("example.org") does not have the NSEC3 type. It only exists for the 553 hashed name. 555 Names like "1.h.example.org" hash to one label in NSEC3, 556 "1.h.example.org" becomes: 557 "117gercprcjgg8j04ev1ndrk8d1jt14k.example.org" when used as an owner 558 name. This is an important observation. By hashing the names you 559 lose the depth of a zone - hashing introduces a flat space of names, 560 as opposed to NSEC. 562 The name used above ("1.h.example.org") creates an empty non- 563 terminal. Empty non-terminals are domain names that have no RRs 564 associated with them, and exist only because they have one or more 565 sub-domains that do ([RFC5155], Section 1.3). The record: 567 1.h.example.org. TXT "1.h record" 569 creates two names: 571 1. "1.h.example.org" that has the type: TXT; 573 2. "h.example.org" which has no types. This is the empty non- 574 terminal. 576 An empty non-terminal will get an NSEC3 record, but not an NSEC 577 record. In Section 5.5 is shown how the resolver uses these NSEC3 578 records to validate the denial of existence proofs. 580 5.1. Opt-Out 582 Hashing mitigates the zone walking issue of NSEC. The other issue, 583 the high costs of securing a delegation to an insecure zone, is 584 tackled with Opt-Out. When using Opt-Out, names that are an insecure 585 delegation (and empty non-terminals that are only derived from 586 insecure delegations) don't require an NSEC3 record. For each 587 insecure delegation, the zone size can be decreased (compared with a 588 fully signed zone without using Opt-Out) with at least two records: 589 one NSEC3 record and one corresponding RRSIG record. If the insecure 590 delegation would introduce empty non-terminals, even more records can 591 be omitted from the zone. 593 Opt-Out NSEC3 records are not able to prove or deny the existence of 594 the insecure delegations. In other words, those delegation do not 595 benefit from the cryptographic security that DNSSEC provides. 597 A recently discovered corner case ([RFC5155-errata3441]) shows that 598 not only those delegations remain insecure, also the empty non- 599 terminal space that is derived from those delegations are insecure. 600 Because the names in this empty non-terminal space do exist according 601 to the definition in [RFC4592], the server should respond to queries 602 for these names with a NODATA response. However, the validator 603 requires an NSEC3 record proving the NODATA response ([RFC5155], 604 Section 8.5): 606 "The validator MUST verify that an NSEC3 RR that matches QNAME is 607 present and that both the QTYPE and the CNAME type are not set in 608 its Type Bit Maps field." 610 A way to resolve this contradiction in the specification is to always 611 provide empty non-terminals with an NSEC3 record, even if it is only 612 derived from an insecure delegation. 614 5.2. Loading an NSEC3 Zone 616 Whenever an authoritative server receives a query for a non-existing 617 record, it has to hash the incoming query name to determine into 618 which interval between two existing hashes it falls. To do that it 619 needs to know the zone's specific NSEC3 parameters (hash iterations 620 and salt). 622 One way to learn them is to scan the zone during loading for NSEC3 623 records and glean the NSEC3 parameters from them. However, it would 624 need to make sure that there is at least one complete set of NSEC3 625 records for the zone using the same parameters. Therefore, it would 626 need to inspect all NSEC3 records. 628 A more graceful solution was designed. The solution was to create a 629 new record, NSEC3PARAM, which must be placed at the apex of the zone. 630 Its role is to provide a fixed place where an authoritative name 631 server can directly see the NSEC3 parameters used, and by putting it 632 in the zone it allows for easy transfer to the secondaries. If NSEC3 633 were designed in the early days of DNS (+/- 1984) this information 634 would probably have been put in the SOA record. 636 5.3. Wildcards in the DNS 637 So far, we have only talked about denial of existence in negative 638 responses. However, denial of existence may also occur in positive 639 responses, i.e., where the ANSWER section of the response is not 640 empty. This can happen because of wildcards. 642 Wildcards have been part of the DNS since the first DNS RFCs. They 643 allow to define all names for a certain type in one go. In our 644 "example.org" zone we could for instance add a wildcard record: 646 *.example.org. TXT "wildcard record" 648 For completeness, our (unsigned) zone now looks like this: 650 example.org. SOA ( ... ) 651 *.example.org. TXT "wildcard record" 652 a.example.org. A 192.0.2.1 653 TXT "a record" 654 d.example.org. A 192.0.2.1 655 TXT "d record" 657 Figure 4: The example.org zone with a wildcard record. 659 If a resolver asks for "z.example.org TXT", the name server will 660 respond with an expanded wildcard, instead of an NXDOMAIN: 662 ;; status: NOERROR, id: 13658 664 ;; ANSWER SECTION: 665 z.example.org. TXT "wildcard record" 667 Note however that the resolver can not detect that this answer came 668 from a wildcard. It just sees the answer as-is. How will this 669 answer look with DNSSEC? 671 ;; status: NOERROR, id: 51790 673 ;; ANSWER SECTION: 674 z.example.org. TXT "wildcard record" 675 z.example.org. RRSIG(TXT) ( ... ) 677 ;; AUTHORITY SECTION: 678 d.example.org. NSEC example.org. A TXT RRSIG NSEC 679 d.example.org. RRSIG(NSEC) ( ... ) 681 Figure 5: A response with an expanded wildcard and with DNSSEC. 683 The RRSIG of the "z.example.org" TXT record indicates there is a 684 wildcard configured. The RDATA of the signature lists a label count 685 [RFC4034], Section 3.1.3., of two (not visible in the answer above), 686 but the owner name of the signature has three labels. This mismatch 687 indicates there is a wildcard "*.example.org" configured. 689 An astute reader may notice that it appears as if a 690 "z.example.org" RRSIG(TXT) is created out of thin air. This is 691 not the case. The signature for "z.example.org" does not exist. 692 The signature you are seeing is the one for "*.example.org" which 693 does exist, only the owner name is switched to "z.example.org". 694 So even with wildcards, no signatures have to be created on the 695 fly. 697 The DNSSEC standard mandates that an NSEC (or NSEC3) is included in 698 such responses. If it wasn't, an attacker could mount a replay 699 attack and poison the cache with false data: Suppose that the 700 resolver has asked for "a.example.org TXT". An attacker could modify 701 the packet in such way that it looks like the response was generated 702 through wildcard expansion, even though there exists a record for 703 "a.example.org TXT". 705 The tweaking simply consists of adjusting the ANSWER section to: 707 ;; status: NOERROR, id: 31827 709 ;; ANSWER SECTION: 710 a.example.org. TXT "wildcard record" 711 a.example.org. RRSIG(TXT) ( ... ) 713 Figure 6: A forged response without the expanded wildcard. 715 Note the subtle difference from Figure 5 in the owner name. In this 716 response we see a "a.example.org TXT" record, for which a record with 717 different RDATA (See Figure 4) exist in the zone. 719 Which would be a perfectly valid answer if we would not require the 720 inclusion of an NSEC or NSEC3 record in the wildcard answer response. 721 The resolver believes that "a.example.org TXT" is a wildcard record, 722 and the real record is obscured. This is bad and defeats all the 723 security DNSSEC can deliver. Because of this, the NSEC or NSEC3 must 724 be present. 726 Another way of putting this is that DNSSEC is there to ensure the 727 name server has followed the steps as outlined in [RFC1034], 728 Section 4.3.2 for looking up names in the zone. It explicitly lists 729 wildcard look up as one of these steps (3c), so with DNSSEC this must 730 be communicated to the resolver: hence the NSEC(3) record. 732 5.4. CNAME Records 734 So far, the maximum number of NSEC records a response will have is 735 two: one for the denial of existence and another for the wildcard. 736 We say maximum, because sometimes a single NSEC can prove both. With 737 NSEC3, this is three (as to why, we will explain in the next 738 section). 740 When we take CNAME wildcard records into account, we can have more 741 NSEC(3) records. For every wildcard expansion, we need to prove that 742 the expansion was allowed. Lets add some CNAME wildcard records to 743 our zone: 745 example.org. SOA ( ... ) 746 *.example.org. TXT "wildcard record" 747 a.example.org. A 192.0.2.1 748 TXT "a record" 749 *.a.example.org. CNAME w.b 750 *.b.example.org. CNAME w.c 751 *.c.example.org. A 192.0.2.1 752 d.example.org. A 192.0.2.1 753 TXT "d record" 754 w.example.org. CNAME w.a 756 Figure 7: A wildcard CNAME chain added to the "example.org" zone. 758 A query for "w.example.org A" will result in the following response: 760 ;; status: NOERROR, id: 4307 762 ;; ANSWER SECTION: 763 w.example.org. CNAME w.a.example.org. 764 w.example.org. RRSIG(CNAME) ( ... ) 765 w.a.example.org. CNAME w.b.example.org. 766 w.a.example.org. RRSIG(CNAME) ( ... ) 767 w.b.example.org. CNAME w.c.example.org. 768 w.b.example.org. RRSIG(CNAME) ( ... ) 769 w.c.example.org. A 192.0.2.1 770 w.c.example.org. RRSIG(A) ( ... ) 772 ;; AUTHORITY SECTION: 773 *.a.example.org. NSEC *.b.example.org. CNAME RRSIG NSEC 774 *.a.example.org. RRSIG(NSEC) ( ... ) 775 *.b.example.org. NSEC *.c.example.org. CNAME RRSIG NSEC 776 *.b.example.org. RRSIG(NSEC) ( ... ) 777 *.c.example.org. NSEC d.example.org. A RRSIG NSEC 778 *.c.example.org. RRSIG(NSEC) ( ... ) 779 The NSEC record "*.a.example.org" proves that wildcard expansion to 780 "w.a.example.org" was appropriate: "w.a." falls in the gap "*.a" to 781 "*.b". Similar, the NSEC record "*.b.example.org" proves that there 782 was no direct match for "w.b.example.org" and "*.c.example.org" 783 denies the direct match for "w.c.example.org". 785 DNAME records and wildcard names should not be used as reiterated in 786 [RFC6672] Section 3.3. 788 5.5. The Closest Encloser NSEC3 Record 790 We can have one or more NSEC3 records that deny the existence of the 791 requested name and one NSEC3 record that deny wildcard synthesis. 792 What do we miss? 794 The short answer is that, due to the hashing in NSEC3 you loose the 795 depth of your zone: Everything is hashed into a flat plane. To make 796 up for this loss of information you need an extra record. 798 To understand NSEC3, we will need two definitions: 800 Closest encloser: Introduced in [RFC4592], "The closest encloser is 801 the node in the zone's tree of existing domain names that has the 802 most labels matching the query name (consecutively, counting from 803 the root label downward)." In our example, if the query name is 804 "x.2.example.org" then "example.org" is the "closest encloser"; 806 Next closer name: Introduced in the NSEC3 RFC, this is the closest 807 encloser with one more label added to the left. So if 808 "example.org" is the closest encloser for the query name 809 "x.2.example.org", "2.example.org" is the "next closer name". 811 An NSEC3 "closest encloser proof" consists of: 813 1. An NSEC3 record that *matches* the "closest encloser". This 814 means the unhashed owner name of the record is the closest 815 encloser. This bit of information tells a resolver: "The name 816 you are asking for does not exist, the closest I have is this". 818 2. An NSEC3 record that *covers* the "next closer name". This means 819 it defines an interval in which the "next closer name" falls. 820 This tells the resolver: "The next closer name falls in this 821 interval, and therefore the name in your question does not exist. 822 In fact, the closest encloser is indeed the closest I have". 824 These two records already deny the existence of the requested name, 825 so we do not need an NSEC3 record that covers the actual queried 826 name: By denying the existence of the next closer name, you also deny 827 the existence of the queried name. 829 For a given query name, there is one (and only one) place where 830 wildcard expansion is possible. This is the "source of synthesis", 831 and is defined ([RFC4592], Section 2.1.1 and Section 3.3.1) as: 833 . 835 In other words, to deny wildcard synthesis, the resolver needs to 836 know the hash of the source of synthesis. Since it does not know 837 beforehand what the closest encloser of the query name is, it must be 838 provided in the answer. 840 Take the following example. We take our zone, and put two TXT 841 records to it. The records added are "1.h.example.org" and 842 "3.3.example.org". It is signed with NSEC3, resulting in the 843 following unsigned zone. 845 example.org. SOA ( ... ) 846 1.h.example.org. TXT "1.h record" 847 3.3.example.org. TXT "3.3 record" 849 Figure 8: The added TXT records in example.org. These records create 850 two empty non-terminals: h.example.org and 3.example.org. 852 The resolver asks the following: "x.2.example.org TXT". This leads 853 to an NXDOMAIN response from the server, which contains three NSEC3 854 records. A list of hashed owner names can be found in Appendix A. 855 Also see Figure 9 the numbers in that figure correspond with the 856 following NSEC3 records: 858 15bg9l6359f5ch23e34ddua6n1rihl9h.example.org. ( 859 NSEC3 1 0 2 DEAD 1AVVQN74SG75UKFVF25DGCETHGQ638EK SOA RRSIG 860 DNSKEY NSEC3PARAM ) 862 75b9id679qqov6ldfhd8ocshsssb6jvq.example.org. ( 863 NSEC3 1 0 2 DEAD 8555T7QEGAU7PJTKSNBCHG4TD2M0JNPJ TXT RRSIG ) 865 1avvqn74sg75ukfvf25dgcethgq638ek.example.org. ( 866 NSEC3 1 0 2 DEAD 75B9ID679QQOV6LDFHD8OCSHSSSB6JVQ ) 868 If we would follow the NSEC approach, the resolver is only interested 869 in one thing. Does the hash of "x.2.example.org" fall in any of the 870 intervals of the NSEC3 records it got? 872 example.org 873 ** 874 +-- ** . . . . . . . . . . . 875 (1) / . ^ . . 876 / . | . . 877 | . | . . 878 v . | . . 879 ** | ** -- 880 h.example.org ** ----+----> ** 3.example.org -- 2.example.org 881 . / (3) . | . 882 . / . | (2) . 883 . / (5) . | . 884 . / . v . 885 1.h.example.org ** ** -- 886 ** <--------- ** 3.3.example.org -- x.2.example.org 887 (4) 889 Figure 9: x.2.example.org does not exist. The five arrows represent 890 the NSEC3 records, the ones numbered (1), (2) and (3) are the NSEC3s 891 returned in our answer. 2.example.org is covered by (2) and 892 x.2.example.org is covered by (4). 894 The hash of "x.2.example.org" is "ndtu6dste50pr4a1f2qvr1v31g00i2i1". 895 Checking this hash on the first NSEC3 yields that it does not fall in 896 between the interval: "15bg9l6359f5ch23e34ddua6n1rihl9h" and 897 "1avvqn74sg75ukfvf25dgcethgq638ek". For the second NSEC3 the answer 898 is also negative: the hash sorts outside the interval described by 899 "75b9id679qqov6ldfhd8ocshsssb6jvq" and 900 "8555t7qegau7pjtksnbchg4td2m0jnpj". And the third NSEC3, with 901 interval "1avvqn74sg75ukfvf25dgcethgq638ek" to 902 "75b9id679qqov6ldfhd8ocshsssb6jvq" also isn't of any help. What is a 903 resolver to do? It has been given the maximum amount of NSEC3s and 904 they all seem useless. 906 So this is where the closest encloser proof comes into play. And for 907 the proof to work, the resolver needs to know what the closest 908 encloser is. There must be an existing ancestor in the zone: a name 909 must exist that is shorter than the query name. The resolver keeps 910 hashing increasingly shorter names from the query name until an owner 911 name of an NSEC3 matches. This owner name is the closest encloser. 913 When the resolver has found the closest encloser, the next step is to 914 construct the next closer name. This is the closest encloser with 915 the last chopped label from query name pre-pended to it: ".". The hash of this name should be 917 covered by the interval set in any of the NSEC3 records. 919 Then the resolver needs to check the presence of a wildcard. It 920 creates the wildcard name by pre-pending the asterisk label to the 921 closest encloser: "*.", and uses the hash of that. 923 Going back to our example, the resolver must first detect the NSEC3 924 that matches the closest encloser. It does this by chopping up the 925 query name, hashing each instance (with the same number of iterations 926 and hash as the zone it is querying) and comparing that to the 927 answers given. So it has the following hashes to work with: 929 x.2.example.org: "ndtu6dste50pr4a1f2qvr1v31g00i2i1", last chopped 930 label: ""; 932 2.example.org: "7t70drg4ekc28v93q7gnbleopa7vlp6q", last chopped 933 label: "x"; 935 example.org: "15bg9l6359f5ch23e34ddua6n1rihl9h", last chopped label: 936 "2"; 938 Of these hashes only one matches the owner name of one of the NSEC3 939 records: "15bg9l6359f5ch23e34ddua6n1rihl9h". This must be the 940 closest encloser (unhashed: "example.org"). That's the main purpose 941 of that NSEC3 record: tell the resolver what the closest encloser is. 943 When using Opt-Out, it is possible that the actual closest encloser 944 to the QNAME does not have an NSEC3 record. If so, we will have to 945 do with the closest provable encloser, which is the closest enclosing 946 authoritative name that does have a NSEC3 record. In the worst case, 947 this is the NSEC3 record corresponding to the apex, this name must 948 always have an NSEC3 record. 950 With the closest (provable) encloser, the resolver constructs the 951 next closer, which in this case is: "2.example.org"; "2" is the last 952 label chopped, when "example.org" is the closest encloser. The hash 953 of this name should be covered in any of the other NSEC3s. And it is, 954 "7t70drg4ekc28v93q7gnbleopa7vlp6q" falls in the interval set by: 955 "75b9id679qqov6ldfhd8ocshsssb6jvq" and 956 "8555t7qegau7pjtksnbchg4td2m0jnpj" (this is our second NSEC3). 958 So what does the resolver learn from this? 960 o "example.org" exists; 962 o "2.example.org" does not exist. 964 And if "2.example.org" does not exist, there is also no direct match 965 for "x.2.example.org". The last step is to deny the existence of the 966 source of synthesis, to prove that no wildcard expansion was 967 possible. 969 The resolver hashes "*.example.org" to 970 "22670trplhsr72pqqmedltg1kdqeolb7" and checks that it is covered: in 971 this case by the last NSEC3 (see Figure 9), the hash falls in the 972 interval set by "1avvqn74sg75ukfvf25dgcethgq638ek" and 973 "75b9id679qqov6ldfhd8ocshsssb6jvq". This means there is no wildcard 974 record directly below the closest encloser and "x.2.example.org" 975 definitely does not exist. 977 When we have validated the signatures, we reached our goal: 978 authenticated denial of existence. 980 5.6. Three To Tango 982 One extra NSEC3 record plus additional signature may seem a lot just 983 to deny the existence of the wildcard record, but we cannot leave it 984 out. If the standard would not mandate the closest encloser NSEC3 985 record, but instead required two NSEC3 records: one to deny the query 986 name and one to deny the wildcard record. An attacker could fool the 987 resolver that the source of synthesis does not exist, while it in 988 fact does. 990 Suppose the wildcard record does exist, so our unsigned zone looks 991 like this: 993 example.org. SOA ( ... ) 994 *.example.org. TXT "wildcard record" 995 1.h.example.org. TXT "1.h record" 996 3.3.example.org. TXT "3.3 record" 998 The query "x.2.example.org TXT" should now be answered with: 1000 x.2.example.org. TXT "wildcard record" 1002 An attacker can deny this wildcard expansion by calculating the hash 1003 for the wildcard name "*.2.example.org" and searching for an NSEC3 1004 record that covers that hash. The hash of "*.2.example.org" is 1005 "fbq73bfkjlrkdoqs27k5qf81aqqd7hho". Looking through the NSEC3 1006 records in our zone we see that the NSEC3 record of "3.3" covers this 1007 hash: 1009 8555t7qegau7pjtksnbchg4td2m0jnpj.example.org. ( 1010 NSEC3 1 0 2 DEAD 15BG9L6359F5CH23E34DDUA6N1RIHL9H TXT RRSIG ) 1012 This record also covers the query name "x.2.example.org" 1013 ("ndtu6dste50pr4a1f2qvr1v31g00i2i1"). 1015 Now an attacker adds this NSEC3 record to the AUTHORITY section of 1016 the reply to deny both "x.2.example.org" and any wildcard expansion. 1017 The net result is that the resolver determines that "x.2.example.org" 1018 does not exist, while in fact it should have been synthesized via 1019 wildcard expansion. With the NSEC3 matching the closest encloser 1020 "example.org", the resolver can be sure that the wildcard expansion 1021 should occur at "*.example.org" and nowhere else. 1023 Coming back to the original question: why do we need up to three 1024 NSEC3 records to deny a requested name? The resolver needs to be 1025 explicitly told what the "closest encloser" is and this takes up a 1026 full NSEC3 record. Then, the next closer name needs to be covered in 1027 an NSEC3 record, and finally an NSEC3 must say something about 1028 whether wildcard expansion was possible. That makes three to tango. 1030 6. Security Considerations 1032 DNSSEC does not protect against denial of service attacks, nor does 1033 it provide confidentiality. For more general security considerations 1034 related to DNSSEC, please see RFC 4033, RFC 4034, RFC 4035 and RFC 1035 5155 ([RFC4033], [RFC4034], [RFC4035] and [RFC5155]). 1037 These RFCs are concise about why certain design choices have been 1038 made in the area of authenticated denial of existence. 1039 Implementations that do not correctly handle this aspect of DNSSEC, 1040 create a severe hole in the security DNSSEC adds. This is 1041 specifically troublesome for secure delegations: If an attacker is 1042 able to deny the existence of a DS record, the resolver cannot 1043 establish a chain of trust, and the resolver has to fall back to 1044 insecure DNS for the remainder of the query resolution. 1046 This document aims to fill this "documentation gap" and provide 1047 would-be implementors and other interested parties with enough 1048 background knowledge to better understand authenticated denial of 1049 existence. 1051 7. IANA Considerations 1053 This document has no actions for IANA. 1055 8. Acknowledgments 1057 This document would not be possible without the help of Ed Lewis, Roy 1058 Arends, Wouter Wijngaards, Olaf Kolkman, Carsten Strotmann, Jan-Piet 1059 Mens, Peter van Dijk, Marco Davids, Esther Makaay, Antoin Verschuren, 1060 Lukas Wunner, Joe Abley and Geoff Huston. Also valuable was the 1061 source code of Unbound ("validator/val_nsec3.c"). 1063 Extensive feedback for early versions was received from Karst 1064 Koymans. 1066 9. References 1068 9.1. Normative References 1070 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1071 STD 13, RFC 1034, November 1987. 1073 [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security 1074 Extensions", RFC 2065, January 1997. 1076 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1077 NCACHE)", RFC 2308, March 1998. 1079 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1080 Rose, "DNS Security Introduction and Requirements", RFC 1081 4033, March 2005. 1083 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1084 Rose, "Resource Records for the DNS Security Extensions", 1085 RFC 4034, March 2005. 1087 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1088 Rose, "Protocol Modifications for the DNS Security 1089 Extensions", RFC 4035, March 2005. 1091 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 1092 System", RFC 4592, July 2006. 1094 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1095 Encodings", RFC 4648, October 2006. 1097 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1098 Security (DNSSEC) Hashed Authenticated Denial of 1099 Existence", RFC 5155, March 2008. 1101 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 1102 DNS", RFC 6672, June 2012. 1104 9.2. Informative References 1106 [I-D.arends-dnsnr] 1107 Arends, R., "DNSSEC Non-Repudiation Resource Record", 1108 draft-arends-dnsnr-00 (work in progress), July 2004. 1110 [I-D.ietf-dnsext-not-existing-rr] 1111 Josefsson, S., "Authenticating denial of existence in DNS 1112 with minimum disclosure", draft-ietf-dnsext-not-existing- 1113 rr-01 (work in progress), November 2000. 1115 [I-D.laurie-dnsext-nsec2v2] 1116 Laurie, B., "DNSSEC NSEC2 Owner and RDATA Format", draft- 1117 laurie-dnsext-nsec2v2-00 (work in progress), December 1118 2004. 1120 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 1121 RFC 2535, March 1999. 1123 [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS 1124 Authenticated Data (AD) bit", RFC 3655, November 2003. 1126 [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation 1127 Signer (DS)", RFC 3755, May 2004. 1129 [RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS Security 1130 (DNSSEC) Opt-In", RFC 4956, July 2007. 1132 [RFC5155-errata3441] 1133 Lewis, E., "Technical Errata against RFC 5155 (not 1134 acknowledged)", January 2013. 1136 Appendix A. List of Hashed Owner Names 1138 The following owner names are used in this document. The origin for 1139 these names is "example.org". 1141 +----------------+-------------------------------------+ 1142 | Original Name | Hashed Name | 1143 +----------------+-------------------------------------+ 1144 | "a" | "04sknapca5al7qos3km2l9tl3p5okq4c" | 1145 | "1.h" | "117gercprcjgg8j04ev1ndrk8d1jt14k" | 1146 | "@" | "15bg9l6359f5ch23e34ddua6n1rihl9h" | 1147 | "h" | "1avvqn74sg75ukfvf25dgcethgq638ek" | 1148 | "*" | "22670trplhsr72pqqmedltg1kdqeolb7" | 1149 | "3" | "75b9id679qqov6ldfhd8ocshsssb6jvq" | 1150 | "2" | "7t70drg4ekc28v93q7gnbleopa7vlp6q" | 1151 | "3.3" | "8555t7qegau7pjtksnbchg4td2m0jnpj" | 1152 | "d" | "a6edkb6v8vl5ol8jnqqlt74qmj7heb84" | 1153 | "*.2" | "fbq73bfkjlrkdoqs27k5qf81aqqd7hho" | 1154 | "b" | "iuu8l5lmt76jeltp0bir3tmg4u3uu8e7" | 1155 | "x.2" | "ndtu6dste50pr4a1f2qvr1v31g00i2i1" | 1156 +----------------+-------------------------------------+ 1158 Table 1: Hashed owner names for "example.org" in hash order. 1160 Appendix B. Changelog 1162 [This section should be removed by the RFC editor before publishing] 1164 B.1. -00 1166 1. Initial document. 1168 B.2. -01 1170 1. Style and language changes; 1172 2. Figure captions; 1174 3. Security considerations added; 1176 4. Fix erroneous NSEC3 RR; 1178 5. Section on CNAMEs added; 1180 6. More detailed text on closest encloser proof. 1182 B.3. -02 1184 1. Lowercase NSEC3 hashed ownernames and add reference to Base32; 1186 2. Process the comments from Joe Abley and Geoff Huston. 1188 * Added section about Opt-Out; 1190 * Move experimental records in their own section; 1192 * Added DNAME reference with respect to wildcards; 1193 * Clarify the difference between the wildcard answers; 1195 * Add more context about the NO record; 1197 * Elaborate more about the EXIST records and its problems; 1199 * Added more text about the NSEC3PARAM records; 1201 * Apply assorted fixes throughout the document; 1203 * Moved table with hashed owner names to appendix. 1205 B.4. -03 1207 1. Changed affiliation for R. Gieben; 1209 2. Some minor updates. 1211 Authors' Addresses 1213 R. (Miek) Gieben 1214 Google 1216 EMail: miek@google.com 1218 W. (Matthijs) Mekking 1219 NLnet Labs 1220 Science Park 400 1221 Amsterdam 1098 XH 1222 NL 1224 EMail: matthijs@nlnetlabs.nl 1225 URI: http://www.nlnetlabs.nl/