idnits 2.17.1 draft-gieben-auth-denial-of-existence-dns-02.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines 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 472: '... closest encloser, this SHOULD be used...' RFC 2119 keyword, line 610: '... "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 (January 07, 2013) is 4126 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 (~~), 2 warnings (==), 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 SIDN Labs 4 Intended status: Informational W. Mekking 5 Expires: July 09, 2013 NLnet Labs 6 January 07, 2013 8 Authenticated Denial of Existence in the DNS 9 draft-gieben-auth-denial-of-existence-dns-02 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 July 09, 2013. 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 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Denial of Existence . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. NXDOMAIN Responses . . . . . . . . . . . . . . . . . . . . 4 55 2.2. NODATA Responses . . . . . . . . . . . . . . . . . . . . . 4 56 3. Secure Denial of Existence . . . . . . . . . . . . . . . . . . 5 57 3.1. NXT . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3.2. NSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.3. NODATA Responses . . . . . . . . . . . . . . . . . . . . . 8 60 3.4. Drawbacks of NSEC . . . . . . . . . . . . . . . . . . . . 9 61 4. Experimental and Deprecated Mechanisms: NO, NSEC2 and DNSNR . 9 62 5. NSEC3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 5.1. Opt-Out . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 5.2. Loading an NSEC3 Zone . . . . . . . . . . . . . . . . . . 13 65 5.3. Wildcards in the DNS . . . . . . . . . . . . . . . . . . . 13 66 5.4. CNAME Records . . . . . . . . . . . . . . . . . . . . . . 15 67 5.5. The Closest Encloser NSEC3 Record . . . . . . . . . . . . 16 68 5.6. Three To Tango . . . . . . . . . . . . . . . . . . . . . . 20 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 75 Appendix A. List of Hashed Owner Names . . . . . . . . . . . . . 23 76 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . . 23 77 B.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 78 B.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 79 B.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 82 1. Introduction 84 DNSSEC can be somewhat of a complicated matter, and there are certain 85 areas of the specification that are more difficult to comprehend than 86 others. One such area is "authenticated denial of existence". 88 Denial of existence is a mechanism that informs a resolver that a 89 certain domain name does not exist. It is also used to signal that a 90 domain name exists, but does not have the specific RR type you were 91 asking for. 93 The first is referred to as an NXDOMAIN (non-existent domain) 94 ([RFC2308] Section 2.1) and the latter a NODATA ([RFC2308] Section 95 2.2) response. Both are also known as negative responses. 97 Authenticated denial of existence uses cryptography to sign the 98 negative response. However, if there is no answer, what is it that 99 needs to be signed? To further complicate this matter, there is the 100 desire to pre-generate negative responses that are applicable for all 101 queries for non-existent names in the signed zone. See Section 3 for 102 the details. 104 In this document, we will explain how authenticated denial of 105 existence works. We begin by explaining the current technique in the 106 DNS and work our way up to DNSSEC. We explain the first steps taken 107 in DNSSEC and describe how NSEC and NSEC3 work. The NXT, NO, NSEC2 108 and DNSNR records also briefly make their appearance, as they have 109 paved the way for NSEC and NSEC3. 111 To complete the picture, we also need to explain DNS wildcards as 112 these complicate matters, especially combined with CNAME records. 114 Note: In this document, domain names in zone file examples will have 115 a trailing dot, in the running text they will not. This text is 116 written for people who have a fair understanding of DNSSEC. The 117 following RFCs are not required reading, but they help in 118 understanding the problem space. 120 o RFC 5155 [RFC5155] - Hashed Authenticated Denial of Existence; 122 o RFC 4592 [RFC4592] - The Role of Wildcards in the DNS. 124 And these provide some general DNSSEC information. 126 o RFC 4033, RFC 4034, RFC 4035 [RFC4033], [RFC4034], [RFC4035] - 127 DNSSEC Specification; 129 o RFC 4956 [RFC4956] - DNS Security (DNSSEC) Opt-In. This RFC has 130 experimental status, but is a good read. 132 These three drafts give some background information on the NSEC3 133 development. 135 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 The unsigned "example.org" zone. 158 Figure 1 160 2.1. NXDOMAIN Responses 162 If a resolver asks for the TXT type belonging to "a.example.org" to 163 the name server serving this zone, it sends the following question: 164 "a.example.org TXT" 166 The name server looks in its zone data and generates an answer. In 167 this case a positive one: "Yes it exists and this is the data", 168 resulting in this reply: 170 ;; status: NOERROR, id: 28203 172 ;; ANSWER SECTION: 173 a.example.org. TXT "a record" 175 ;; AUTHORITY SECTION: 176 example.org. NS a.example.org. 178 The "status: NOERROR" signals that everything is OK, "id" is an 179 integer used to match questions and answers. In the ANSWER section, 180 we find our answer. The AUTHORITY section holds the names of the 181 name servers that have information concerning the "example.org" zone. 182 Note that including this information is optional. 184 If a resolver asks for "b.example.org TXT" it gets an answer that 185 this name does not exist: 187 ;; status: NXDOMAIN, id: 7042 189 ;; AUTHORITY SECTION: 190 example.org. SOA ( ... ) 192 In this case, we do not get an ANSWER section and the status is set 193 to NXDOMAIN. From this the resolver concludes that "b.example.org" 194 does not exist. The AUTHORITY section holds the SOA record of 195 "example.org" that the resolver can use to cache the negative 196 response. 198 2.2. NODATA Responses 200 It is important to realize that NXDOMAIN is not the only type of 201 does-not-exist. A name may exist, but the type you are asking for 202 may not. This occurrence of non-existence is called a NODATA 203 response. Let us ask our name server for "a.example.org AAAA", and 204 look at the answer: 206 ;; status: NOERROR, id: 7944 208 ;; AUTHORITY SECTION: 209 example.org. SOA ( ... ) 210 The status NOERROR shows that the "a.example.org" name exists, but 211 the reply does not contain an ANSWER section. This differentiates a 212 NODATA response from an NXDOMAIN response, the rest of the packet is 213 very similar. The resolver has to put these pieces of information 214 together and conclude that "a.example.org" exists, but it does not 215 have an "AAAA" record. 217 3. Secure Denial of Existence 219 The above has to be translated to the security aware world of DNSSEC. 220 But there are a few requirements DNSSEC brings to the table: 222 1. There is no online signing defined in DNSSEC. Although a name 223 server is free to compute the answer and signature(s) on-the-fly, 224 the protocol is written with a "first sign, then load" attitude 225 in mind. It is rather asymmetrical, but a lot of the design in 226 DNSSEC stems from fact that you need to accommodate authenticated 227 denial of existence. If the DNS did not have NXDOMAIN, DNSSEC 228 would be a lot simpler, but a lot less useful! 230 2. The DNS packet header is not signed. This means that a "status: 231 NXDOMAIN" can not be trusted. In fact the entire header may be 232 forged, including the AD bit (AD stands for Authentic Data, see 233 RFC 3655 [RFC3655]), which may give some food for thought; 235 3. DNS wildcards and CNAME records complicate matters significantly. 236 More about this in later sections (Section 5.3 and Section 5.4). 238 The first requirement implies that all denial of existence answers 239 need to be pre-computed, but it is impossible to pre-compute (all 240 conceivable) non-existence answers. A generic denial record which 241 can be used in all denial of existence proofs is not an option: such 242 a record is susceptible to replay attacks. When you are querying a 243 name server for a record that actually exists, a man-in-the-middle 244 may replay that generic denial record and it would be impossible to 245 tell whether the response was genuine or spoofed. 247 This has been solved by introducing a record that defines an interval 248 between two existing names. Or to put it another way: it defines the 249 holes (non-existing names) in the zone. This record can be signed 250 beforehand and given to the resolver. 252 Given all these troubles, why didn't the designers of DNSSEC go 253 for the (easy) route and allowed for online signing? Well, at 254 that time (pre 2000), online signing was not feasible with the 255 then current hardware. Keep in mind that the larger servers get 256 between 2000 and 6000 queries per second (qps), with peaks up to 257 20,000 qps or more. Scaling signature generation to these kind of 258 levels is always a challenge. Another issue was (and is) key 259 management, for online signing to work you need access to the 260 private key(s). This is considered a security risk. 262 The road to the current solution (NSEC/NSEC3) was long. It started 263 with the NXT (next) record. The NO (not existing) record was 264 introduced, but never made it to RFC. Later on, NXT was superseded 265 by the NSEC (next secure) record. From there it went through NSEC2/ 266 DNSNR to finally reach NSEC3 (next secure, version 3) in RFC 5155. 268 3.1. NXT 270 The first attempt to specify authenticated denial of existence was 271 NXT (RFC 2535 [RFC2535]). Section 5.1 of that RFC introduces the 272 record: 274 "The NXT resource record is used to securely indicate that RRs 275 with an owner name in a certain name interval do not exist in a 276 zone and to indicate what RR types are present for an existing 277 name." 279 By specifying what you do have, you implicitly tell what you don't 280 have. NXT is superseded by NSEC. In the next section we explain how 281 NSEC (and thus NXT) works. 283 3.2. NSEC 285 In RFC 3755 [RFC3755] all the DNSSEC types were given new names, SIG 286 was renamed RRSIG, KEY became DNSKEY and NXT was renamed to NSEC and 287 a minor issue was fixed in the process, namely the type bitmap was 288 redefined to allow more than 127 types to be listed ([RFC2535], 289 Section 5.2). 291 Just as NXT, NSEC is used to describe an interval between names: it 292 indirectly tells a resolver which names do not exist in a zone. 294 For this to work, we need our "example.org" zone to be sorted in 295 canonical order ([RFC4034], Section 6.1), and then create the NSECs. 296 We add three NSEC records, one for each name, and each one "covers" a 297 certain interval. The last NSEC record points back to the first as 298 required by the RFC, and depicted in Figure 2. 300 1. The first NSEC covers the interval between "example.org" and 301 "a.example.org"; 303 2. The second NSEC covers "a.example.org" to "d.example.org"; 305 3. The third NSEC points back to "example.org", and covers 306 "d.example.org" to "example.org" (i.e. the end of the zone). 308 As we have defined the intervals and put those in resource records, 309 we now have something that can be signed. 311 example.org 312 ** 313 +-- ** <--+ 314 (1) / . . \ (3) 315 / . . \ 316 | . . | 317 v . . | 318 ** (2) ** 319 a.example.org ** ---------> ** d.example.org 321 The NSEC records of "example.org". The arrows represent NSEC 322 records, starting from the apex. 324 Figure 2 326 This signed zone is loaded into the name server. It looks like this: 328 example.org. SOA ( ... ) 329 DNSKEY ( ... ) 330 NSEC a.example.org. SOA NSEC DNSKEY RRSIG 331 RRSIG(SOA) ( ... ) 332 RRSIG(DNSKEY) ( ... ) 333 RRSIG(NSEC) ( ... ) 334 a.example.org. A 192.0.2.1 335 TXT "a record" 336 NSEC d.example.org. A TXT NSEC RRSIG 337 RRSIG(A) ( ... ) 338 RRSIG(TXT) ( ... ) 339 RRSIG(NSEC) ( ... ) 340 d.example.org. A 192.0.2.1 341 TXT "d record" 342 NSEC example.org. A TXT NSEC RRSIG 343 RRSIG(A) ( ... ) 344 RRSIG(TXT) ( ... ) 345 RRSIG(NSEC) ( ... ) 347 The signed and sorted "example.org" zone with the added NSEC records 348 (and signatures). For brevity, the class is not shown (defaults to 349 IN), the NS records are left out and the SOA, DNSKEY and RRSIG 350 records are shortened. 352 Figure 3 354 If a DNSSEC aware resolver asks for "b.example.org", it gets back a 355 "status: NXDOMAIN" packet, which by itself is meaningless (remember 356 that the DNS packet header is not signed and thus can be forged). To 357 be able to securely detect that "b" does not exist, there must also 358 be a signed NSEC record which covers the name space where "b" lives. 359 The record: 361 a.example.org. NSEC d.example.org. A TXT NSEC RRSIG 362 does precisely that: "b" should come after "a", but the next owner 363 name is "d.example.org", so "b" does not exist. 365 Only by making that calculation, is a resolver able to conclude that 366 the name "b" does not exist. If the signature of the NSEC record is 367 valid, "b" is proven not to exist. We have authenticated denial of 368 existence. 370 Note that a man-in-the-middle may still replay this NXDOMAIN response 371 when you're querying for, say, "c.example.org". But it would not do 372 any harm since it is provably the proper response to the query. In 373 the future, there may be data published for "c.example.org". 374 Therefore, the RRSIGs RDATA include a validity period (not visible in 375 the zone above), so that an attacker cannot replay this NXDOMAIN 376 response for "c.example.org" forever. 378 3.3. NODATA Responses 380 NSEC records are also used in NODATA responses. In that case we need 381 to look more closely at the type bitmap. The type bitmap in an NSEC 382 record tells which types are defined for a name. If we look at the 383 NSEC record of "a.example.org", we see the following types in the 384 bitmap: A, TXT, NSEC and RRSIG. So for the name "a" this indicates 385 we must have an A, TXT, NSEC and RRSIG record in the zone. 387 With the type bitmap of the NSEC record, a resolver can establish 388 that a name is there, but the type is not. For example, if a 389 resolver asks for "a.example.org AAAA", the reply that comes back is: 391 ;; status: NOERROR, id: 44638 393 ;; AUTHORITY SECTION: 394 example.org. SOA ( ... ) 395 example.org. RRSIG(SOA) ( ... ) 396 a.example.org. NSEC d.example.org. A TXT NSEC RRSIG 397 a.example.org. RRSIG(NSEC) ( ... ) 399 The resolver should check the AUTHORITY section and conclude that: 401 (1) "a.example.org" exists (because of the NSEC with that owner name) 402 and; 404 (2) the type (AAAA) does not as it is not listed in the type bitmap. 406 The techniques used by NSEC form the basics of authenticated denial 407 of existence in DNSSEC. 409 3.4. Drawbacks of NSEC 411 There were two issues with NSEC (and NXT). The first is that it 412 allows for zone walking. NSEC records point from one name to 413 another, in our example: "example.org", points to "a.example.org" 414 which points to "d.example.org" which points back to "example.org". 415 So we can reconstruct the entire "example.org" zone, thus defeating 416 attempts to administratively block zone transfers ([RFC2065] Section 417 5.5). 419 The second issue is that when a large, delegation-centric ([RFC5155], 420 Section 1.1), zone deploys DNSSEC, every name in the zone gets an 421 NSEC plus RRSIG. So this leads to a huge increase in the zone size 422 (when signed). This would in turn mean that operators of such zones 423 who are deploying DNSSEC, face up front costs. This could hinder 424 DNSSEC adoption. 426 These two issues eventually lead to NSEC3 which: 428 o Adds a way to garble the next owner name, thus thwarting zone- 429 walking; 431 o Makes it possible to skip names for the next owner name. This 432 feature is called Opt-Out (See Section 5.1). It means not all 433 names in your zone get an NSEC3 plus ditto signature, making it 434 possible to "grow into" your DNSSEC deployment. 436 But before we delve into NSEC3, let us first take a look at its 437 predecessors: NO, NSEC2 and, DNSNR. 439 4. Experimental and Deprecated Mechanisms: NO, NSEC2 and DNSNR 441 Long before NSEC was defined, the NO record was introduced. It was 442 the first record to use the idea of hashed owner names, to fix the 443 issue of zone walking that was present with the NXT record. It also 444 fixed the type bitmap issue of the NXT record, but not in a space 445 efficient way. At that time (around 2000) zone walking was not 446 considered important enough to warrant the new record. People were 447 also worried that DNSSEC deployment would be hindered by developing 448 an alternate means of denial of existence. Thus the effort was 449 shelved and NXT remained. 451 When the new DNSSEC specification [RFC4034] was written, people were 452 still not convinced that zone walking was a problem that should be 453 solved. So NSEC saw the light and inherited the two issues from NXT. 455 Several years after, NSEC2 was introduced as a way to solve the two 456 issues of NSEC. The NSEC2 draft contains the following paragraph: 458 "This document proposes an alternate scheme which hides owner 459 names while permitting authenticated denial of existence of non- 460 existent names. The scheme uses two new RR types: NSEC2 and 461 EXIST." 463 When an authenticated denial of existence scheme starts to talk about 464 EXIST records, it is worth paying extra attention. The EXIST record 465 was defined as a record without RDATA that would be used to signal 466 the presence of a domain name. From the draft: 468 "In order to prove the nonexistence of a record that might be 469 covered by a wildcard, it is necessary to prove the existence of 470 its closest encloser. This record does that. Its owner is the 471 closest encloser. It has no RDATA. If there is another RR that 472 proves the existence of the closest encloser, this SHOULD be used 473 instead of an EXIST record." 475 The introduction of this record led to questions on what wildcards 476 actually means (especially in the context of DNSSEC). It is probably 477 not a coincidence that "The Role of Wildcards in the Domain Name 478 System" ([RFC4592]) was standardized before NSEC3. 480 NSEC2 solved the zone walking issue by hashing (with SHA1 and a salt) 481 the "next owner name" in the record, thereby making it useless for 482 zone walking. But it did not have Opt-Out. 484 The DNSNR record was another attempt that used hashed names to foil 485 zone walking and it also introduced the concept of opting out (called 486 "Authoritative Only Flag") which limited the use of DNSNR in 487 delegation-centric zones. 489 All these proposals didn't make it, but did provide valuable 490 insights. To summarize: 492 o The NO record introduced hashing, but this idea lingered in the 493 background for a long time; 495 o The NSEC2 record made it clear that wildcards were not completely 496 understood; 498 o The DNSNR record used a new flag field in the RDATA to signal Opt- 499 Out; 501 5. NSEC3 503 From the experience gained with NSEC2 and DNSNR, NSEC3 was forged. 504 It incorporates both Opt-Out and the hashing of names. NSEC3 solves 505 any issues people might have with NSEC, but it introduces some 506 additional complexity. 508 NSEC3 did not supersede NSEC, they are both defined for DNSSEC. So 509 DNSSEC is blessed with two different means to perform authenticated 510 denial of existence: NSEC and NSEC3. In NSEC3 every name is hashed, 511 including the owner name. This means that NSEC3 chain is sorted in 512 hash order, instead of canonical order. Because the owner names are 513 hashed, the next owner name for "example.org" is unlikely to be 514 "a.example.org". Because the next owner name is hashed, zone walking 515 becomes more difficult. 517 To make it even more difficult to retrieve the original names, the 518 hashing can be repeated several times each time taking the previous 519 hash as input. To prevent the reuse of pre-generated hash values 520 between zones a (per zone) salt can also be added. In the NSEC3 for 521 "example.org" we have hashed the names thrice ([RFC5155], Section 5) 522 and use the salt "DEAD". Lets look at typical NSEC3 record: 524 15bg9l6359f5ch23e34ddua6n1rihl9h.example.org. ( 525 NSEC3 1 0 2 DEAD A6EDKB6V8VL5OL8JNQQLT74QMJ7HEB84 526 SOA RRSIG DNSKEY NSEC3PARAM ) 528 On the first line we see the hashed owner name: 529 "15bg9l6359f5ch23e34ddua6n1rihl9h.example.org", this is the hashed 530 name of the fully qualified domain name (FQDN) "example.org" encoded 531 as Base32 ([RFC4648]). Note that even though we hashed 532 "example.org", the zone's name is added to make it look like a domain 533 name again. In our zone, the basic format is 534 "Base32(SHA1(FQDN)).example.org". The next hashed owner name 535 "A6EDKB6V8VL5OL8JNQQLT74QMJ7HEB84" (line 2) is the hashed version of 536 "d.example.org", represented as Base32. Note that ".example.org" is 537 not added to the next hashed owner name, as this name always falls in 538 the current zone. 540 The "1 0 2 DEAD" section of the NSEC3 states: 542 o Hash Algorithm = 1 (SHA1, this is the default, no other hash 543 algorithms are currently defined for use in NSEC3); 545 o Opt-Out = 0 (disabled); 547 o Hash Iterations = 2, this yields three iterations, as a zero value 548 is already one iteration; 550 o Salt = "DEAD". 552 At the end we see the type bitmap, which is identical to NSEC's 553 bitmap, that lists the types present at the original owner name. 554 Note that the type NSEC3 is absent from the list in the example 555 above. This is due to the fact that the original owner name 556 ("example.org") does not have the NSEC3 type. It only exists for the 557 hashed name. 559 Names like "1.h.example.org" hash to one label in NSEC3, 560 "1.h.example.org" becomes: 561 "117gercprcjgg8j04ev1ndrk8d1jt14k.example.org" when used as an owner 562 name. This is an important observation. By hashing the names you 563 lose the depth of a zone - hashing introduces a flat space of names, 564 as opposed to NSEC. 566 The domain name used above ("1.h.example.org") creates an empty non- 567 terminal. Empty non-terminals are domain names that have no RRs 568 associated with them, and exist only because they have one or more 569 subdomains that do ([RFC5155], Section 1.3). The record: 571 1.h.example.org. TXT "1.h record" 573 creates two names: 575 1. "1.h.example.org" that has the type: TXT; 577 2. "h.example.org" which has no types. This is the empty non- 578 terminal. 580 An empty non-terminal will get an NSEC3 record, but not an NSEC 581 record. In Section 5.5 is shown how the resolver uses these NSEC3 582 records to validate the denial of existence proofs. 584 5.1. Opt-Out 586 Hashing mitigates the zone walking issue of NSEC. The other issue, 587 the high costs of securing a delegation to an insecure zone, is 588 tackled with Opt-Out. When using Opt-Out, names that are an insecure 589 delegation (and empty non-terminals that are only derived from 590 insecure delegations) don't require an NSEC3 record. For each 591 insecure delegation, the zone size can be decreased (compared with a 592 fully signed zone without using Opt-Out) with at least two records: 593 one NSEC3 record and one corresponding RRSIG record. If the insecure 594 delegation would introduce empty non-terminals, even more records can 595 be omitted from the zone. 597 Opt-Out NSEC3 records are not able to prove or deny the existence of 598 the insecure delegations. In other words, those delegation do not 599 benefit from the cryptographic security that DNSSEC provides. 601 A recently discovered corner case ([RFC5155-errata3441]) shows that 602 not only those delegations remain insecure, also the empty non- 603 terminal space that is derived from those delegations are insecure. 604 Because the names in this empty non-terminal space do exist according 605 to the definition in [RFC4592], the server should respond to queries 606 for these names with a NODATA response. However, the validator 607 requires an NSEC3 record proving the NODATA response ([RFC5155], 608 Section 8.5): 610 "The validator MUST verify that an NSEC3 RR that matches QNAME is 611 present and that both the QTYPE and the CNAME type are not set in 612 its Type Bit Maps field." 614 A way to resolve this contradiction in the specification is to always 615 provide empty non-terminals with an NSEC3 record, even if it is only 616 derived from an insecure delegation. 618 5.2. Loading an NSEC3 Zone 620 Whenever an authoritative server receives a query for a non-existing 621 record, it has to hash the incoming query name to determine into 622 which interval between two existing hashes it falls. To do that it 623 needs to know the zone's specific NSEC3 parameters (hash iterations 624 and salt). 626 One way to learn them is to scan the zone during loading for NSEC3 627 records and glean the NSEC3 parameters from them. However, it would 628 need to make sure that there is at least one complete set of NSEC3 629 records for the zone using the same parameters. Therefore, it would 630 need to inspect all NSEC3 records. 632 A more graceful solution was designed. The solution was to create a 633 new record, NSEC3PARAM, which must be placed at the apex of the zone. 634 Its role is to provide a fixed place where an authoritative name 635 server can directly see the NSEC3 parameters used, and by putting it 636 in the zone it allows for easy transfer to the secondaries. If NSEC3 637 were designed in the early days of DNS (+/- 1984) this information 638 would probably have been put in the SOA record. 640 5.3. Wildcards in the DNS 642 So far, we have only talked about denial of existence in negative 643 responses. However, denial of existence may also occur in positive 644 responses, i.e., where the ANSWER section of the response is not 645 empty. This can happen because of wildcards. 647 Wildcards have been part of the DNS since the first DNS RFCs. They 648 allow to define all names for a certain type in one go. In our 649 "example.org" zone we could for instance add a wildcard record: 651 *.example.org. TXT "wildcard record" 653 For completeness, our (unsigned) zone now looks like this: 655 example.org. SOA ( ... ) 656 *.example.org. TXT "wildcard record" 657 a.example.org. A 192.0.2.1 658 TXT "a record" 659 d.example.org. A 192.0.2.1 660 TXT "d record" 662 The example.org zone with a wildcard record. 664 Figure 4 666 If a resolver asks for "z.example.org TXT", the name server will 667 respond with an expanded wildcard, instead of an NXDOMAIN: 669 ;; status: NOERROR, id: 13658 671 ;; ANSWER SECTION: 672 z.example.org. TXT "wildcard record" 674 Note however that the resolver can not detect that this answer came 675 from a wildcard. It just sees the answer as-is. How will this 676 answer look with DNSSEC? 678 ;; status: NOERROR, id: 51790 680 ;; ANSWER SECTION: 681 z.example.org. TXT "wildcard record" 682 z.example.org. RRSIG(TXT) ( ... ) 684 ;; AUTHORITY SECTION: 685 d.example.org. NSEC example.org. A TXT RRSIG NSEC 686 d.example.org. RRSIG(NSEC) ( ... ) 688 A response with an expanded wildcard and with DNSSEC. 690 Figure 5 692 The RRSIG of the "z.example.org" TXT record indicates there is a 693 wildcard configured. The RDATA of the signature lists a label count 694 [RFC4034], Section 3.1.3., of two (not visible in the answer above), 695 but the owner name of the signature has three labels. This mismatch 696 indicates there is a wildcard "*.example.org" configured. 698 An astute reader may notice that it appears as if a 699 "z.example.org" RRSIG(TXT) is created out of thin air. This is 700 not the case. The signature for "z.example.org" does not exist. 701 The signature you are seeing is the one for "*.example.org" which 702 does exist, only the owner name is switched to "z.example.org". 703 So even with wildcards, no signatures have to be created on the 704 fly. 706 The DNSSEC standard mandates that an NSEC (or NSEC3) is included in 707 such responses. If it wasn't, an attacker could mount a replay 708 attack and poison the cache with false data: Suppose that the 709 resolver has asked for "a.example.org TXT". An attacker could modify 710 the packet in such way that it looks like the response was generated 711 through wildcard expansion, even though there exists a record for 712 "a.example.org TXT". 714 The tweaking simply consists of adjusting the ANSWER section to: 716 ;; status: NOERROR, id: 31827 718 ;; ANSWER SECTION 719 a.example.org. TXT "wildcard record" 720 a.example.org. RRSIG(TXT) ( ... ) 722 A forged response without the expanded wildcard. 724 Figure 6 726 Note the subtle difference from Figure 5 in the owner name. In this 727 response we see a "a.example.org TXT" record, for which a record with 728 different RDATA (See Figure 4) exist in the zone. 730 Which would be a perfectly valid answer if we would not require the 731 inclusion of an NSEC or NSEC3 record in the wildcard answer response. 732 The resolver believes that "a.example.org TXT" is a wildcard record, 733 and the real record is obscured. This is bad and defeats all the 734 security DNSSEC can deliver. Because of this, the NSEC or NSEC3 must 735 be present. 737 Another way of putting this is that DNSSEC is there to ensure the 738 name server has followed the steps as outlined in [RFC1034], Section 739 4.3.2 for looking up names in the zone. It explicitly lists wildcard 740 look up as one of these steps (3c), so with DNSSEC this must be 741 communicated to the resolver: hence the NSEC(3) record. 743 5.4. CNAME Records 745 So far, the maximum number of NSEC records a response will have is 746 two: one for the denial of existence and another for the wildcard. 747 We say maximum, because sometimes a single NSEC can prove both. With 748 NSEC3, this is three (as to why, we will explain in the next 749 section). 751 When we take CNAME wildcard records into account, we can have more 752 NSEC(3) records. For every wildcard expansion, we need to prove that 753 the expansion was allowed. Lets add some CNAME wildcard records to 754 our zone: 756 example.org. SOA ( ... ) 757 *.example.org. TXT "wildcard record" 758 a.example.org. A 192.0.2.1 759 TXT "a record" 760 *.a.example.org. CNAME w.b 761 *.b.example.org. CNAME w.c 762 *.c.example.org. A 192.0.2.1 763 d.example.org. A 192.0.2.1 764 TXT "d record" 765 w.example.org. CNAME w.a 767 A wildcard CNAME chain added to the "example.org" zone. 769 Figure 7 771 A query for "w.example.org A" will result in the following response: 773 ;; status: NOERROR, id: 4307 775 ;; ANSWER SECTION: 776 w.example.org. CNAME w.a.example.org. 777 w.example.org. RRSIG(CNAME) ( ... ) 778 w.a.example.org. CNAME w.b.example.org. 779 w.a.example.org. RRSIG(CNAME) ( ... ) 780 w.b.example.org. CNAME w.c.example.org. 781 w.b.example.org. RRSIG(CNAME) ( ... ) 782 w.c.example.org. A 192.0.2.1 783 w.c.example.org. RRSIG(A) ( ... ) 785 ;; AUTHORITY SECTION: 786 *.a.example.org. NSEC *.b.example.org. CNAME RRSIG NSEC 787 *.a.example.org. RRSIG(NSEC) ( ... ) 788 *.b.example.org. NSEC *.c.example.org. CNAME RRSIG NSEC 789 *.b.example.org. RRSIG(NSEC) ( ... ) 790 *.c.example.org. NSEC d.example.org. A RRSIG NSEC 791 *.c.example.org. RRSIG(NSEC) ( ... ) 793 The NSEC record "*.a.example.org" proves that wildcard expansion to 794 "w.a.example.org" was appropriate: "w.a." falls in the gap "*.a" to 795 "*.b". Similar, the NSEC record "*.b.example.org" proves that there 796 was no direct match for "w.b.example.org" and "*.c.example.org" 797 denies the direct match for "w.c.example.org". 799 DNAME records and wildcard names should not be used as reiterated in 800 [RFC6672] Section 3.3. 802 5.5. The Closest Encloser NSEC3 Record 804 We can have one or more NSEC3 records that deny the existence of the 805 requested name and one NSEC3 record that deny wildcard synthesis. 806 What do we miss? 808 The short answer is that, due to the hashing in NSEC3 you loose the 809 depth of your zone: Everything is hashed into a flat plane. To make 810 up for this loss of information you need an extra record. 812 To understand NSEC3, we will need two definitions: 814 Closest encloser: Introduced in [RFC4592], "The closest encloser is 815 the node in the zone's tree of existing domain names that has the 816 most labels matching the query name (consecutively, counting from 817 the root label downward)." In our example, if the query name is 818 "x.2.example.org" then "example.org" is the "closest encloser"; 820 Next closer name: Introduced in the NSEC3 RFC, this is the closest 821 encloser with one more label added to the left. So if 822 "example.org" is the closest encloser for the query name 823 "x.2.example.org", "2.example.org" is the "next closer name". 825 An NSEC3 "closest encloser proof" consists of: 827 1. An NSEC3 record that *matches* the "closest encloser". This 828 means the unhashed owner name of the record is the closest 829 encloser. This bit of information tells a resolver: "The name 830 you are asking for does not exist, the closest I have is this". 832 2. An NSEC3 record that *covers* the "next closer name". This means 833 it defines an interval in which the "next closer name" falls. 834 This tells the resolver: "The next closer name falls in this 835 interval, and therefore the name in your question does not exist. 836 In fact, the closest encloser is indeed the closest I have". 838 These two records already deny the existence of the requested name, 839 so we do not need an NSEC3 record that covers the actual queried 840 name: By denying the existence of the next closer name, you also deny 841 the existence of the queried name. 843 For a given query name, there is one (and only one) place where 844 wildcard expansion is possible. This is the "source of synthesis", 845 and is defined ([RFC4592], Section 2.1.1 and Section 3.3.1) as: 847 . 849 In other words, to deny wildcard synthesis, the resolver needs to 850 know the hash of the source of synthesis. Since it does not know 851 beforehand what the closest encloser of the query name is, it must be 852 provided in the answer. 854 Take the following example. We take our zone, and put two TXT 855 records to it. The records added are "1.h.example.org" and 856 "3.3.example.org". It is signed with NSEC3, resulting in the 857 following unsigned zone. 859 example.org. SOA ( ... ) 860 1.h.example.org. TXT "1.h record" 861 3.3.example.org. TXT "3.3 record" 863 The added TXT records in example.org. These records create two empty 864 non-terminals: `h.example.org` and `3.example.org`. 866 Figure 8 868 The resolver asks the following: "x.2.example.org TXT". This leads 869 to an NXDOMAIN response from the server, which contains three NSEC3 870 records. A list of hashed owner names can be found in Appendix A. 871 Also see Figure 9 the numbers in that figure correspond with the 872 following NSEC3 records: 874 15bg9l6359f5ch23e34ddua6n1rihl9h.example.org. ( 875 NSEC3 1 0 2 DEAD 1AVVQN74SG75UKFVF25DGCETHGQ638EK SOA RRSIG 876 DNSKEY NSEC3PARAM ) 878 75b9id679qqov6ldfhd8ocshsssb6jvq.example.org. ( 879 NSEC3 1 0 2 DEAD 8555T7QEGAU7PJTKSNBCHG4TD2M0JNPJ TXT RRSIG ) 881 1avvqn74sg75ukfvf25dgcethgq638ek.example.org. ( 882 NSEC3 1 0 2 DEAD 75B9ID679QQOV6LDFHD8OCSHSSSB6JVQ ) 884 If we would follow the NSEC approach, the resolver is only interested 885 in one thing. Does the hash of "x.2.example.org" fall in any of the 886 intervals of the NSEC3 records it got? 888 example.org 889 ** 890 +-- ** . . . . . . . . . . . 891 (1) / . /\ . . 892 / . | . . 893 | . | . . 894 v . | . . 895 ** | ** -- 896 h.example.org ** ----+----> ** 3.example.org -- 2.example.org 897 . / (3) . | . 898 . / . | (2) . 899 . / . | . 900 . / . v . 901 1.h.example.org ** ** -- 902 ** <--------- ** 3.3.example.org -- x.2.example.org 904 x.2.example.org does not exist. The arrows represent the NSEC3 905 records, the ones numbered (1), (2) and (3) are the NSEC3s returned 906 in our answer. 908 Figure 9 910 The hash of "x.2.example.org" is "ndtu6dste50pr4a1f2qvr1v31g00i2i1". 911 Checking this hash on the first NSEC3 yields that it does not fall in 912 between the interval: "15bg9l6359f5ch23e34ddua6n1rihl9h" and 913 "1avvqn74sg75ukfvf25dgcethgq638ek". For the second NSEC3 the answer 914 is also negative: the hash sorts outside the interval described by 915 "75b9id679qqov6ldfhd8ocshsssb6jvq" and 916 "8555t7qegau7pjtksnbchg4td2m0jnpj". And the last NSEC3 also isn't of 917 any help. What is a resolver to do? It has been given the maximum 918 amount of NSEC3s and they all seem useless. 920 So this is where the closest encloser proof comes into play. And for 921 the proof to work, the resolver needs to know what the closest 922 encloser is. There must be an existing ancestor in the zone: a name 923 must exist that is shorter than the query name. The resolver keeps 924 hashing increasingly shorter names from the query name until an owner 925 name of an NSEC3 matches. This owner name is the closest encloser. 927 When the resolver has found the closest encloser, the next step is to 928 construct the next closer name. This is the closest encloser with 929 the last chopped label from query name prepended to it: ".". The hash of this name should be 931 covered by the interval set in any of the NSEC3 records. 933 Then the resolver needs to check the presence of a wildcard. It 934 creates the wildcard name by prepending the asterisk label to the 935 closest encloser: "*.", and uses the hash of that. 937 Going back to our example, the resolver must first detect the NSEC3 938 that matches the closest encloser. It does this by chopping up the 939 query name, hashing each instance (with the same number of iterations 940 and hash as the zone it is querying) and comparing that to the 941 answers given. So it has the following hashes to work with: 943 x.2.example.org: "ndtu6dste50pr4a1f2qvr1v31g00i2i1", last chopped 944 label: ""; 946 2.example.org: "7t70drg4ekc28v93q7gnbleopa7vlp6q", last chopped 947 label: "x"; 949 example.org: "15bg9l6359f5ch23e34ddua6n1rihl9h", last chopped label: 950 "2"; 952 Of these hashes only one matches the owner name of one of the NSEC3 953 records: "15bg9l6359f5ch23e34ddua6n1rihl9h". This must be the 954 closest encloser (unhashed: "example.org"). That's the main purpose 955 of that NSEC3 record: tell the resolver what the closest encloser is. 957 When using Opt-Out, it is possible that the actual closest encloser 958 to the QNAME does not have an NSEC3 record. If so, we will have to 959 do with the closest provable encloser, which is the closest enclosing 960 authoritative name that does have a NSEC3 record. In the worst case, 961 this is the NSEC3 record corresponding to the apex, this name must 962 always have an NSEC3 record. 964 With the closest (provable) encloser, the resolver constructs the 965 next closer, which in this case is: "2.example.org"; "2" is the last 966 label chopped, when "example.org" is the closest encloser. The hash 967 of this name should be covered in any of the other NSEC3s. And it 968 is, "7t70drg4ekc28v93q7gnbleopa7vlp6q" falls in the interval set by: 969 "75b9id679qqov6ldfhd8ocshsssb6jvq" and 970 "8555t7qegau7pjtksnbchg4td2m0jnpj" (this is our second NSEC3). 972 So what does the resolver learn from this? 974 o "example.org" exists; 976 o "2.example.org" does not exist. 978 And if "2.example.org" does not exist, there is also no direct match 979 for "x.2.example.org". The last step is to deny the existence of the 980 source of synthesis, to prove that no wildcard expansion was 981 possible. 983 The resolver hashes "*.example.org" to 984 "22670trplhsr72pqqmedltg1kdqeolb7" and checks that it is covered: in 985 this case by the last NSEC3 (see Figure 9), the hash falls in the 986 interval set by "1avvqn74sg75ukfvf25dgcethgq638ek" and 987 "75b9id679qqov6ldfhd8ocshsssb6jvq". This means there is no wildcard 988 record directly below the closest encloser and "x.2.example.org" 989 definitely does not exist. 991 When we have validated the signatures, we reached our goal: 992 authenticated denial of existence. 994 5.6. Three To Tango 996 One extra NSEC3 record plus additional signature may seem a lot just 997 to deny the existence of the wildcard record, but we cannot leave it 998 out. If the standard would not mandate the closest encloser NSEC3 999 record, but instead required two NSEC3 records: one to deny the query 1000 name and one to deny the wildcard record. An attacker could fool the 1001 resolver that the source of synthesis does not exist, while it in 1002 fact does. 1004 Suppose the wildcard record does exist, so our unsigned zone looks 1005 like this: 1007 example.org. SOA ( ... ) 1008 *.example.org. TXT "wildcard record" 1009 1.h.example.org. TXT "1.h record" 1010 3.3.example.org. TXT "3.3 record" 1012 The query "x.2.example.org TXT" should now be answered with: 1014 x.2.example.org. TXT "wildcard record" 1016 An attacker can deny this wildcard expansion by calculating the hash 1017 for the wildcard name "*.2.example.org" and searching for an NSEC3 1018 record that covers that hash. The hash of "*.2.example.org" is 1019 "fbq73bfkjlrkdoqs27k5qf81aqqd7hho". Looking through the NSEC3 1020 records in our zone we see that the NSEC3 record of "3.3" covers this 1021 hash: 1023 8555t7qegau7pjtksnbchg4td2m0jnpj.example.org. ( 1024 NSEC3 1 0 2 DEAD 15BG9L6359F5CH23E34DDUA6N1RIHL9H TXT RRSIG ) 1026 This record also covers the query name "x.2.example.org" 1027 ("ndtu6dste50pr4a1f2qvr1v31g00i2i1"). 1029 Now an attacker adds this NSEC3 record to the AUTHORITY section of 1030 the reply to deny both "x.2.example.org" and any wildcard expansion. 1031 The net result is that the resolver determines that "x.2.example.org" 1032 does not exist, while in fact it should have been synthesized via 1033 wildcard expansion. With the NSEC3 matching the closest encloser 1034 "example.org", the resolver can be sure that the wildcard expansion 1035 should occur at "*.example.org" and nowhere else. 1037 Coming back to the original question: why do we need up to three 1038 NSEC3 records to deny a requested name? The resolver needs to be 1039 explicitly told what the "closest encloser" is and this takes up a 1040 full NSEC3 record. Then, the next closer name needs to be covered in 1041 an NSEC3 record, and finally an NSEC3 must say something about 1042 whether wildcard expansion was possible. That makes three to tango. 1044 6. Security Considerations 1046 DNSSEC does not protect against denial of service attacks, nor does 1047 it provide confidentiality. For more general security considerations 1048 related to DNSSEC, please see RFC 4033, RFC 4034, RFC 4035 and RFC 1049 5155 ([RFC4033], [RFC4034], [RFC4035] and [RFC5155]). 1051 These RFCs are concise about why certain design choices have been 1052 made in the area of authenticated denial of existence. 1053 Implementations that do not correctly handle this aspect of DNSSEC, 1054 create a severe hole in the security DNSSEC adds. This is 1055 specifically troublesome for secure delegations: If an attacker is 1056 able to deny the existence of a DS record, the resolver cannot 1057 establish a chain of trust, and the resolver has to fall back to 1058 insecure DNS for the remainder of the query resolution. 1060 This document aims to fill this "documentation gap" and provide 1061 would-be implementors and other interested parties with enough 1062 background knowledge to better understand authenticated denial of 1063 existence. 1065 7. IANA Considerations 1067 This document has no actions for IANA. 1069 8. Acknowledgments 1071 This document would not be possible without the help of Ed Lewis, Roy 1072 Arends, Wouter Wijngaards, Olaf Kolkman, Carsten Strotmann, Jan-Piet 1073 Mens, Peter van Dijk, Marco Davids, Esther Makaay, Antoin Verschuren, 1074 Lukas Wunner, Joe Abley and Geoff Huston. Also valuable was the 1075 source code of Unbound ("validator/val_nsec3.c"). 1077 Extensive feedback for early versions was received from Karst 1078 Koymans. 1080 9. References 1082 9.1. Normative References 1084 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1085 STD 13, RFC 1034, November 1987. 1087 [RFC2065] Eastlake, D.E. and C. Kaufman, "Domain Name System 1088 Security Extensions", RFC 2065, January 1997. 1090 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1091 NCACHE)", RFC 2308, March 1998. 1093 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1094 Rose, "DNS Security Introduction and Requirements", RFC 1095 4033, March 2005. 1097 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1098 Rose, "Resource Records for the DNS Security Extensions", 1099 RFC 4034, March 2005. 1101 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1102 Rose, "Protocol Modifications for the DNS Security 1103 Extensions", RFC 4035, March 2005. 1105 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 1106 System", RFC 4592, July 2006. 1108 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1109 Encodings", RFC 4648, October 2006. 1111 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1112 Security (DNSSEC) Hashed Authenticated Denial of 1113 Existence", RFC 5155, March 2008. 1115 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 1116 DNS", RFC 6672, June 2012. 1118 9.2. Informative References 1120 [I-D.arends-dnsnr] 1121 Arends, R., "DNSSEC Non-Repudiation Resource Record", 1122 Internet-Draft draft-arends-dnsnr-00, July 2004. 1124 [I-D.ietf-dnsext-not-existing-rr] 1125 Josefsson, S., "Authenticating denial of existence in DNS 1126 with minimum disclosure", Internet-Draft draft-ietf- 1127 dnsext-not-existing-rr-01, November 2000. 1129 [I-D.laurie-dnsext-nsec2v2] 1130 Laurie, B., "DNSSEC NSEC2 Owner and RDATA Format", 1131 Internet-Draft draft-laurie-dnsext-nsec2v2-00, December 1132 2004. 1134 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 1135 RFC 2535, March 1999. 1137 [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS 1138 Authenticated Data (AD) bit", RFC 3655, November 2003. 1140 [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation 1141 Signer (DS)", RFC 3755, May 2004. 1143 [RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS Security 1144 (DNSSEC) Opt-In", RFC 4956, July 2007. 1146 [RFC5155-errata3441] 1147 Lewis, E., "Technical Errata against RFC 5155 (not 1148 acknowledged)", January 2013. 1150 Appendix A. List of Hashed Owner Names 1152 The following owner names are used in this document. The origin for 1153 these names is "example.org". 1155 +----------------+-------------------------------------+ 1156 | Original Name | Hashed Name | 1157 +----------------+-------------------------------------+ 1158 | "a" | "04sknapca5al7qos3km2l9tl3p5okq4c" | 1159 | "1.h" | "117gercprcjgg8j04ev1ndrk8d1jt14k" | 1160 | "@" | "15bg9l6359f5ch23e34ddua6n1rihl9h" | 1161 | "h" | "1avvqn74sg75ukfvf25dgcethgq638ek" | 1162 | "*" | "22670trplhsr72pqqmedltg1kdqeolb7" | 1163 | "3" | "75b9id679qqov6ldfhd8ocshsssb6jvq" | 1164 | "2" | "7t70drg4ekc28v93q7gnbleopa7vlp6q" | 1165 | "3.3" | "8555t7qegau7pjtksnbchg4td2m0jnpj" | 1166 | "d" | "a6edkb6v8vl5ol8jnqqlt74qmj7heb84" | 1167 | "*.2" | "fbq73bfkjlrkdoqs27k5qf81aqqd7hho" | 1168 | "b" | "iuu8l5lmt76jeltp0bir3tmg4u3uu8e7" | 1169 | "x.2" | "ndtu6dste50pr4a1f2qvr1v31g00i2i1" | 1170 +----------------+-------------------------------------+ 1172 Hashed owner names for "example.org" in hash order. 1174 Table 1 1176 Appendix B. Changelog 1178 [This section should be removed by the RFC editor before publishing] 1180 B.1. -00 1182 1. Initial document. 1184 B.2. -01 1186 1. Style and language changes; 1188 2. Figure captions; 1190 3. Security considerations added; 1192 4. Fix erroneous NSEC3 RR; 1194 5. Section on CNAMEs added; 1196 6. More detailed text on closest encloser proof. 1198 B.3. -02 1200 1. Lowercase NSEC3 hashed ownernames and add reference to Base32; 1202 2. Process the comments from Joe Abley and Geoff Huston. 1204 * Added section about Opt-Out; 1206 * Move experimental records in their own section; 1208 * Added DNAME reference with respect to wildcards; 1210 * Clarify the difference between the wildcard answers; 1212 * Add more context about the NO record; 1214 * Elaborate more about the EXIST records and its problems; 1216 * Added more text about the NSEC3PARAM records; 1218 * Apply assorted fixes throughout the document; 1220 * Moved table with hashed owner names to appendix. 1222 Authors' Addresses 1224 R. (Miek) Gieben 1225 SIDN Labs 1226 Meander 501 1227 Arnhem 6825 MD 1228 NL 1230 EMail: miek.gieben@sidn.nl 1231 URI: https://sidn.nl/ 1232 W. (Matthijs) Mekking 1233 NLnet Labs 1234 Science Park 400 1235 Amsterdam 1098 XH 1236 NL 1238 EMail: matthijs@nlnetlabs.nl 1239 URI: http://www.nlnetlabs.nl/