idnits 2.17.1 draft-gieben-auth-denial-of-existence-dns-05.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 502: '... closest encloser, this SHOULD be used...' RFC 2119 keyword, line 648: '... "The validator MUST verify that an N...' RFC 2119 keyword, line 1259: '...rd's type bitmap MUST have the RRSIG a...' RFC 2119 keyword, line 1260: '...SEC bits set and SHOULD NOT have any o...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 25, 2013) is 3804 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 (==), 7 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: May 29, 2014 NLnet Labs 6 November 25, 2013 8 Authenticated Denial of Existence in the DNS 9 draft-gieben-auth-denial-of-existence-dns-05 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. 20 This document provides additional background commentary and some 21 context for the NSEC and NSEC3 mechanisms used by DNSSEC to provide 22 authenticated denial of existence responses 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 29, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Denial of Existence . . . . . . . . . . . . . . . . . . . . . 5 58 2.1. NXDOMAIN Responses . . . . . . . . . . . . . . . . . . . . 5 59 2.2. NODATA Responses . . . . . . . . . . . . . . . . . . . . . 6 61 3. Secure Denial of Existence . . . . . . . . . . . . . . . . . . 6 62 3.1. NXT . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 3.2. NSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.3. NODATA Responses . . . . . . . . . . . . . . . . . . . . . 10 65 3.4. Drawbacks of NSEC . . . . . . . . . . . . . . . . . . . . 11 67 4. Experimental and Deprecated Mechanisms: NO, NSEC2 and DNSNR . 11 69 5. NSEC3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 5.1. Opt-Out . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 5.2. Loading an NSEC3 Zone . . . . . . . . . . . . . . . . . . 15 72 5.3. Wildcards in the DNS . . . . . . . . . . . . . . . . . . . 16 73 5.4. CNAME Records . . . . . . . . . . . . . . . . . . . . . . 18 74 5.5. The Closest Encloser NSEC3 Record . . . . . . . . . . . . 19 75 5.6. Three To Tango . . . . . . . . . . . . . . . . . . . . . . 23 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 81 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 26 87 Appendix A. On-line Signing: Minimally Covering NSEC Records . . 27 89 Appendix B. On-line Signing: NSEC3 White Lies . . . . . . . . . . 29 91 Appendix C. List of Hashed Owner Names . . . . . . . . . . . . . 29 93 Appendix D. Changelog . . . . . . . . . . . . . . . . . . . . . . 30 94 D.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 95 D.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 96 D.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 97 D.4. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 98 D.5. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 99 D.6. -05 . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 101 1. Introduction 103 DNSSEC can be somewhat of a complicated matter, and there are certain 104 areas of the specification that are more difficult to comprehend than 105 others. One such area is "authenticated denial of existence". 107 Denial of existence is a mechanism that informs a resolver that a 108 certain domain name does not exist. It is also used to signal that a 109 domain name exists, but does not have the specific RR type you were 110 asking for. 112 The first is referred to as an NXDOMAIN (non-existent domain) 113 ([RFC2308] Section 2.1) and the latter a NODATA ([RFC2308] Section 114 2.2) response. Both are also known as negative responses. 116 Authenticated denial of existence uses cryptography to sign the 117 negative response. However, if there is no answer, what is it that 118 needs to be signed? To further complicate this matter, there is the 119 desire to pre-generate negative responses that are applicable for all 120 queries for non-existent names in the signed zone. See Section 3 for 121 the details. 123 In this document, we will explain how authenticated denial of 124 existence works. We begin by explaining the current technique in the 125 DNS and work our way up to DNSSEC. We explain the first steps taken 126 in DNSSEC and describe how NSEC and NSEC3 work. The NXT, NO, NSEC2 127 and DNSNR records also briefly make their appearance, as they have 128 paved the way for NSEC and NSEC3. 130 To complete the picture, we also need to explain DNS wildcards as 131 these complicate matters, especially combined with CNAME records. 133 Note: In this document, domain names in zone file examples will have 134 a trailing dot, in the running text they will not. This text is 135 written for people who have a fair understanding of DNSSEC. The 136 following RFCs are not required reading, but they help in 137 understanding the problem space. 139 o RFC 5155 [RFC5155] - Hashed Authenticated Denial of Existence; 141 o RFC 4592 [RFC4592] - The Role of Wildcards in the DNS. 143 And these provide some general DNSSEC information. 145 o RFC 4033, RFC 4034, RFC 4035 [RFC4033], [RFC4034], [RFC4035] - 146 DNSSEC Specification; 148 o RFC 4956 [RFC4956] - DNS Security (DNSSEC) Opt-In. This RFC has 149 experimental status, but is a good read. 151 These three drafts give some background information on the NSEC3 152 development. 154 o The NO record [I-D.ietf-dnsext-not-existing-rr]; 156 o The NSEC2 record [I-D.laurie-dnsext-nsec2v2]; 158 o The DNSNR record [I-D.arends-dnsnr]. 160 2. Denial of Existence 162 We start with the basics and take a look at NXDOMAIN handling in the 163 DNS. To make it more visible we are going to use a small DNS zone, 164 with 3 names ("example.org", "a.example.org" and "d.example.org") and 165 3 types (SOA, A and TXT). For brevity, the class is not shown 166 (defaults to IN) and the SOA record is shortened, resulting in the 167 following zone file: 169 example.org. SOA ( ... ) 170 example.org. NS a.example.org. 171 a.example.org. A 192.0.2.1 172 TXT "a record" 173 d.example.org. A 192.0.2.1 174 TXT "d record" 176 Figure 1: The unsigned "example.org" zone. 178 2.1. NXDOMAIN Responses 180 If a resolver asks for the TXT type belonging to "a.example.org" to 181 the name server serving this zone, it sends the following question: 182 "a.example.org TXT" 184 The name server looks in its zone data and generates an answer. In 185 this case a positive one: "Yes it exists and this is the data", 186 resulting in this reply: 188 ;; status: NOERROR, id: 28203 190 ;; ANSWER SECTION: 191 a.example.org. TXT "a record" 193 ;; AUTHORITY SECTION: 194 example.org. NS a.example.org. 196 The "status: NOERROR" signals that everything is OK, "id" is an 197 integer used to match questions and answers. In the ANSWER section, 198 we find our answer. The AUTHORITY section holds the names of the 199 name servers that have information concerning the "example.org" zone. 200 Note that including this information is optional. 202 If a resolver asks for "b.example.org TXT" it gets an answer that 203 this name does not exist: 205 ;; status: NXDOMAIN, id: 7042 207 ;; AUTHORITY SECTION: 208 example.org. SOA ( ... ) 210 In this case, we do not get an ANSWER section and the status is set 211 to NXDOMAIN. From this the resolver concludes that "b.example.org" 212 does not exist. The AUTHORITY section holds the SOA record of 213 "example.org" that the resolver can use to cache the negative 214 response. 216 2.2. NODATA Responses 218 It is important to realize that NXDOMAIN is not the only type of 219 does-not-exist. A name may exist, but the type you are asking for 220 may not. This occurrence of non-existence is called a NODATA 221 response. Let us ask our name server for "a.example.org AAAA", and 222 look at the answer: 224 ;; status: NOERROR, id: 7944 226 ;; AUTHORITY SECTION: 227 example.org. SOA ( ... ) 229 The status NOERROR shows that the "a.example.org" name exists, but 230 the reply does not contain an ANSWER section. This differentiates a 231 NODATA response from an NXDOMAIN response, the rest of the packet is 232 very similar. The resolver has to put these pieces of information 233 together and conclude that "a.example.org" exists, but it does not 234 have an "AAAA" record. 236 3. Secure Denial of Existence 238 The above has to be translated to the security aware world of DNSSEC. 239 But there are a few principles DNSSEC brings to the table: 241 1. A name server is free to compute the answer and signature(s) on- 242 the-fly, but the protocol is written with a "first sign, then 243 load" attitude in mind. It is rather asymmetrical, but a lot of 244 the design in DNSSEC stems from fact that you need to accommodate 245 authenticated denial of existence. If the DNS did not have 246 NXDOMAIN, DNSSEC would be a lot simpler, but a lot less useful! 248 2. The DNS packet header is not signed. This means that a "status: 249 NXDOMAIN" can not be trusted. In fact the entire header may be 250 forged, including the AD bit (AD stands for Authentic Data, see 251 RFC 3655 [RFC3655]), which may give some food for thought; 253 3. DNS wildcards and CNAME records complicate matters significantly. 254 More about this in later sections (Section 5.3 and Section 5.4). 256 The first principle implies that all denial of existence answers need 257 to be pre-computed, but it is impossible to pre-compute (all 258 conceivable) non-existence answers. 260 A generic denial record which can be used in all denial of existence 261 proofs is not an option: such a record is susceptible to replay 262 attacks. When you are querying a name server for any record that 263 actually exists, a man-in-the-middle could replay that generic denial 264 record that is unlimited in its scope and it would be impossible to 265 tell whether the response was genuine or spoofed. In other words, 266 the generic record can be replayed to falsely deny _all_ possible 267 responses. 269 We could also use the QNAME in the answer and sign that; essentially 270 signing an NXDOMAIN response. While this approach could have worked 271 technically, it is incompatible with off-line signing. 273 The way this has been solved is by introducing a record that defines 274 an interval between two existing names. Or to put it another way: it 275 defines the holes (non-existing names) in the zone. This record can 276 be signed beforehand and given to the resolver. Appendix A and 277 Appendix B describe on-line signing techniques that are compatible 278 with this scheme. 280 Given all these troubles, why didn't the designers of DNSSEC go 281 for the (easy) route and allowed for on-line signing? Well, at 282 that time (pre 2000), on-line signing was not feasible with the 283 then current hardware. Keep in mind that the larger servers get 284 between 2000 and 6000 queries per second (qps), with peaks up to 285 20,000 qps or more. Scaling signature generation to these kind of 286 levels is always a challenge. Another issue was (and is) key 287 management, for on-line signing to work _each_ authoritative name 288 server needs access to the private key(s). This is considered a 289 security risk. Hence, the protocol required not to rely on on- 290 line signing. 292 The road to the current solution (NSEC/NSEC3) was long. It started 293 with the NXT (next) record. The NO (not existing) record was 294 introduced, but never made it to RFC. Later on, NXT was superseded 295 by the NSEC (next secure) record. From there it went through NSEC2/ 296 DNSNR to finally reach NSEC3 (next secure, version 3) in RFC 5155. 298 3.1. NXT 300 The first attempt to specify authenticated denial of existence was 301 NXT (RFC 2535 [RFC2535]). Section 5.1 of that RFC introduces the 302 record: 304 "The NXT resource record is used to securely indicate that RRs 305 with an owner name in a certain name interval do not exist in a 306 zone and to indicate what RR types are present for an existing 307 name." 309 By specifying what you do have, you implicitly tell what you don't 310 have. NXT is superseded by NSEC. In the next section we explain how 311 NSEC (and thus NXT) works. 313 3.2. NSEC 315 In RFC 3755 [RFC3755] all the DNSSEC types were given new names, SIG 316 was renamed RRSIG, KEY became DNSKEY and NXT was renamed to NSEC and 317 a minor issue was fixed in the process, namely the type bitmap was 318 redefined to allow more than 127 types to be listed ([RFC2535], 319 Section 5.2). 321 Just as NXT, NSEC is used to describe an interval between names: it 322 indirectly tells a resolver which names do not exist in a zone. 324 For this to work, we need our "example.org" zone to be sorted in 325 canonical order ([RFC4034], Section 6.1), and then create the NSECs. 326 We add three NSEC records, one for each name, and each one covers a 327 certain interval. The last NSEC record points back to the first as 328 required by the RFC, and depicted in Figure 2. 330 1. The first NSEC covers the interval between "example.org" and 331 "a.example.org"; 333 2. The second NSEC covers "a.example.org" to "d.example.org"; 335 3. The third NSEC points back to "example.org", and covers 336 "d.example.org" to "example.org" (i.e. the end of the zone). 338 As we have defined the intervals and put those in resource records, 339 we now have something that can be signed. 341 example.org 342 ** 343 +-- ** <--+ 344 (1) / . . \ (3) 345 / . . \ 346 | . . | 347 v . . | 348 ** (2) ** 349 a.example.org ** ---------> ** d.example.org 351 Figure 2: The NSEC records of "example.org". The arrows represent 352 NSEC records, starting from the apex. 354 This signed zone is loaded into the name server. It looks like this: 356 example.org. SOA ( ... ) 357 DNSKEY ( ... ) 358 NS a.example.org. 359 NSEC a.example.org. NS SOA RRSIG NSEC DNSKEY 360 RRSIG(NS) ( ... ) 361 RRSIG(SOA) ( ... ) 362 RRSIG(NSEC) ( ... ) 363 RRSIG(DNSKEY) ( ... ) 364 a.example.org. A 192.0.2.1 365 TXT "a record" 366 NSEC d.example.org. A TXT RRSIG NSEC 367 RRSIG(A) ( ... ) 368 RRSIG(TXT) ( ... ) 369 RRSIG(NSEC) ( ... ) 370 d.example.org. A 192.0.2.1 371 TXT "d record" 372 NSEC example.org. A TXT RRSIG NSEC 373 RRSIG(A) ( ... ) 374 RRSIG(TXT) ( ... ) 375 RRSIG(NSEC) ( ... ) 377 Figure 3: The signed and sorted "example.org" zone with the added 378 NSEC records (and signatures). For brevity, the class is not shown 379 (defaults to IN) and the SOA, DNSKEY and RRSIG records are shortened. 381 If a DNSSEC aware resolver asks for "b.example.org", it gets back a 382 "status: NXDOMAIN" packet, which by itself is meaningless (remember 383 that the DNS packet header is not signed and thus can be forged). To 384 be able to securely detect that "b" does not exist, there must also 385 be a signed NSEC record which covers the name space where "b" lives. 386 The record: 388 a.example.org. NSEC d.example.org. A TXT RRSIG NSEC 389 does precisely that: "b" should come after "a", but the next owner 390 name is "d.example.org", so "b" does not exist. 392 Only by making that calculation, is a resolver able to conclude that 393 the name "b" does not exist. If the signature of the NSEC record is 394 valid, "b" is proven not to exist. We have authenticated denial of 395 existence. 397 Note that a man-in-the-middle may still replay this NXDOMAIN response 398 when you're querying for, say, "c.example.org". But it would not do 399 any harm since it is provably the proper response to the query. In 400 the future, there may be data published for "c.example.org". 401 Therefore, the RRSIG's RDATA include a validity period (not visible 402 in the zone above), so that an attacker cannot replay this NXDOMAIN 403 response for "c.example.org" forever. 405 3.3. NODATA Responses 407 NSEC records are also used in NODATA responses. In that case we need 408 to look more closely at the type bitmap. The type bitmap in an NSEC 409 record tells which types are defined for a name. If we look at the 410 NSEC record of "a.example.org", we see the following types in the 411 bitmap: A, TXT, NSEC and RRSIG. So for the name "a" this indicates 412 we must have an A, TXT, NSEC and RRSIG record in the zone. 414 With the type bitmap of the NSEC record, a resolver can establish 415 that a name is there, but the type is not. For example, if a 416 resolver asks for "a.example.org AAAA", the reply that comes back is: 418 ;; status: NOERROR, id: 44638 420 ;; AUTHORITY SECTION: 421 example.org. SOA ( ... ) 422 example.org. RRSIG(SOA) ( ... ) 423 a.example.org. NSEC d.example.org. A TXT RRSIG NSEC 424 a.example.org. RRSIG(NSEC) ( ... ) 426 The resolver should check the AUTHORITY section and conclude that: 428 (1) "a.example.org" exists (because of the NSEC with that owner 429 name) and; 431 (2) the type (AAAA) does not as it is not listed in the type bitmap. 433 The techniques used by NSEC form the basics of authenticated denial 434 of existence in DNSSEC. 436 3.4. Drawbacks of NSEC 438 There were two issues with NSEC (and NXT). The first is that it 439 allows for zone walking. NSEC records point from one name to 440 another, in our example: "example.org", points to "a.example.org" 441 which points to "d.example.org" which points back to "example.org". 442 So we can reconstruct the entire "example.org" zone, thus defeating 443 attempts to administratively block zone transfers ([RFC2065] Section 444 5.5). 446 The second issue is that when a large, delegation-centric ([RFC5155], 447 Section 1.1), zone deploys DNSSEC, every name in the zone gets an 448 NSEC plus RRSIG. So this leads to a huge increase in the zone size 449 (when signed). This would in turn mean that operators of such zones 450 who are deploying DNSSEC, face up front costs. This could hinder 451 DNSSEC adoption. 453 These two issues eventually lead to NSEC3 which: 455 o Adds a way to garble the owner names, thus thwarting zone walking; 457 o Makes it possible to skip names for the next owner name. This 458 feature is called Opt-Out (See Section 5.1). It means not all 459 names in your zone get an NSEC3 plus ditto signature, making it 460 possible to "grow into" your DNSSEC deployment. 462 Note that there are other ways to mitigate against zone walking. RFC 463 4470 [(#RFC4470) prevents zone walking by introducing minimally 464 covering NSEC records. This technique is described in Appendix A. 466 Before we delve into NSEC3, let us first take a look at its 467 predecessors: NO, NSEC2, and DNSNR. 469 4. Experimental and Deprecated Mechanisms: NO, NSEC2 and DNSNR 471 Long before NSEC was defined, the NO record was introduced. It was 472 the first record to use the idea of hashed owner names, to fix the 473 issue of zone walking that was present with the NXT record. It also 474 fixed the type bitmap issue of the NXT record, but not in a space 475 efficient way. At that time (around 2000) zone walking was not 476 considered important enough to warrant the new record. People were 477 also worried that DNSSEC deployment would be hindered by developing 478 an alternate means of denial of existence. Thus the effort was 479 shelved and NXT remained. 481 When the new DNSSEC specification [RFC4034] was written, people were 482 still not convinced that zone walking was a problem that should be 483 solved. So NSEC saw the light and inherited the two issues from NXT. 485 Several years after, NSEC2 was introduced as a way to solve the two 486 issues of NSEC. The NSEC2 draft contains the following paragraph: 488 "This document proposes an alternate scheme which hides owner 489 names while permitting authenticated denial of existence of non- 490 existent names. The scheme uses two new RR types: NSEC2 and 491 EXIST." 493 When an authenticated denial of existence scheme starts to talk about 494 EXIST records, it is worth paying extra attention. The EXIST record 495 was defined as a record without RDATA that would be used to signal 496 the presence of a domain name. From the draft: 498 "In order to prove the nonexistence of a record that might be 499 covered by a wildcard, it is necessary to prove the existence of 500 its closest encloser. This record does that. Its owner is the 501 closest encloser. It has no RDATA. If there is another RR that 502 proves the existence of the closest encloser, this SHOULD be used 503 instead of an EXIST record." 505 The introduction of this record led to questions on what wildcards 506 actually mean (especially in the context of DNSSEC). It is probably 507 not a coincidence that "The Role of Wildcards in the Domain Name 508 System" ([RFC4592]) was standardized before NSEC3 was. 510 NSEC2 solved the zone walking issue by hashing (with SHA1 and a salt) 511 the "next owner name" in the record, thereby making it useless for 512 zone walking. But it did not have Opt-Out. 514 The DNSNR record was another attempt that used hashed names to foil 515 zone walking and it also introduced the concept of opting out (called 516 "Authoritative Only Flag") which limited the use of DNSNR in 517 delegation-centric zones. 519 All these proposals didn't make it, but did provide valuable 520 insights. To summarize: 522 o The NO record introduced hashing, but this idea lingered in the 523 background for a long time; 525 o The NSEC2 record made it clear that wildcards were not completely 526 understood; 528 o The DNSNR record used a new flag field in the RDATA to signal Opt- 529 Out; 531 5. NSEC3 533 From the experience gained with NSEC2 and DNSNR, NSEC3 was forged. 534 It incorporates both Opt-Out and the hashing of names. NSEC3 solves 535 any issues people might have with NSEC, but it introduces some 536 additional complexity. 538 NSEC3 did not supersede NSEC, they are both defined for DNSSEC. So 539 DNSSEC is blessed with two different means to perform authenticated 540 denial of existence: NSEC and NSEC3. In NSEC3 every name is hashed, 541 including the owner name. This means that NSEC3 chain is sorted in 542 hash order, instead of canonical order. Because the owner names are 543 hashed, the next owner name for "example.org" is unlikely to be 544 "a.example.org". Because the next owner name is hashed, zone walking 545 becomes more difficult. 547 To make it even more difficult to retrieve the original names, the 548 hashing can be repeated several times each time taking the previous 549 hash as input. To prevent the reuse of pre-generated hash values 550 between zones a (per zone) salt can also be added. In the NSEC3 for 551 "example.org" we have hashed the names thrice ([RFC5155], Section 5) 552 and use the salt "DEAD". Lets look at typical NSEC3 record: 554 15bg9l6359f5ch23e34ddua6n1rihl9h.example.org. ( 555 NSEC3 1 0 2 DEAD A6EDKB6V8VL5OL8JNQQLT74QMJ7HEB84 556 NS SOA RRSIG DNSKEY NSEC3PARAM ) 558 On the first line we see the hashed owner name: 559 "15bg9l6359f5ch23e34ddua6n1rihl9h.example.org", this is the hashed 560 name of the fully qualified domain name (FQDN) "example.org" encoded 561 as Base32 ([RFC4648]). Note that even though we hashed 562 "example.org", the zone's name is added to make it look like a domain 563 name again. In our zone, the basic format is 564 "Base32(SHA1(FQDN)).example.org". The next hashed owner name 565 "A6EDKB6V8VL5OL8JNQQLT74QMJ7HEB84" (line 2) is the hashed version of 566 "d.example.org", represented as Base32. Note that "d.example.org" is 567 used are the next owner name, because in the hash ordering, its hash 568 comes after the hash of the zone's apex. Also note that 569 ".example.org" is not added to the next hashed owner name, as this 570 name always falls in the current zone. 572 The "1 0 2 DEAD" section of the NSEC3 states: 574 o Hash Algorithm = 1 (SHA1, this is the default, no other hash 575 algorithms are currently defined for use in NSEC3); 577 o Opt-Out = 0 (disabled); 578 o Hash Iterations = 2, this yields three iterations, as a zero value 579 is already one iteration; 581 o Salt = "DEAD". 583 At the end we see the type bitmap, which is identical to NSEC's 584 bitmap, that lists the types present at the original owner name. 585 Note that the type NSEC3 is absent from the list in the example 586 above. This is due to the fact that the original owner name 587 ("example.org") does not have the NSEC3 type. It only exists for the 588 hashed name. 590 Names like "1.h.example.org" hash to one label in NSEC3, 591 "1.h.example.org" becomes: 592 "117gercprcjgg8j04ev1ndrk8d1jt14k.example.org" when used as an owner 593 name. This is an important observation. By hashing the names you 594 lose the depth of a zone - hashing introduces a flat space of names, 595 as opposed to NSEC. 597 The name used above ("1.h.example.org") creates an empty non- 598 terminal. Empty non-terminals are domain names that have no RRs 599 associated with them, and exist only because they have one or more 600 sub-domains that do ([RFC5155], Section 1.3). The record: 602 1.h.example.org. TXT "1.h record" 604 creates two names: 606 1. "1.h.example.org" that has the type: TXT; 608 2. "h.example.org" which has no types. This is the empty non- 609 terminal. 611 An empty non-terminal will get an NSEC3 record, but not an NSEC 612 record. In Section 5.5 is shown how the resolver uses these NSEC3 613 records to validate the denial of existence proofs. 615 Note that NSEC3 might not always be useful. For example, highly 616 structures zones, like the reverse zones ip6.arpa and in-addr.arpa, 617 can be walked even with NSEC3 due to their structure. Also the names 618 in small, trivial zones can be easily guessed. In these cases, it 619 does not help to defend against zone walking, but does add the 620 computational load on authoritative servers and validators. 622 5.1. Opt-Out 624 Hashing mitigates the zone walking issue of NSEC. The other issue, 625 the high costs of securing a delegation to an insecure zone, is 626 tackled with Opt-Out. When using Opt-Out, names that are an insecure 627 delegation (and empty non-terminals that are only derived from 628 insecure delegations) don't require an NSEC3 record. For each 629 insecure delegation, the zone size can be decreased (compared with a 630 fully signed zone without using Opt-Out) with at least two records: 631 one NSEC3 record and one corresponding RRSIG record. If the insecure 632 delegation would introduce empty non-terminals, even more records can 633 be omitted from the zone. 635 Opt-Out NSEC3 records are not able to prove or deny the existence of 636 the insecure delegations. In other words, those delegation do not 637 benefit from the cryptographic security that DNSSEC provides. 639 A recently discovered corner case ([RFC5155-errata3441]) shows that 640 not only those delegations remain insecure, also the empty non- 641 terminal space that is derived from those delegations are insecure. 642 Because the names in this empty non-terminal space do exist according 643 to the definition in [RFC4592], the server should respond to queries 644 for these names with a NODATA response. However, the validator 645 requires an NSEC3 record proving the NODATA response ([RFC5155], 646 Section 8.5): 648 "The validator MUST verify that an NSEC3 RR that matches QNAME is 649 present and that both the QTYPE and the CNAME type are not set in 650 its Type Bit Maps field." 652 A way to resolve this contradiction in the specification is to always 653 provide empty non-terminals with an NSEC3 record, even if it is only 654 derived from an insecure delegation. 656 5.2. Loading an NSEC3 Zone 658 Whenever an authoritative server receives a query for a non-existing 659 record, it has to hash the incoming query name to determine into 660 which interval between two existing hashes it falls. To do that it 661 needs to know the zone's specific NSEC3 parameters (hash iterations 662 and salt). 664 One way to learn them is to scan the zone during loading for NSEC3 665 records and glean the NSEC3 parameters from them. However, it would 666 need to make sure that there is at least one complete set of NSEC3 667 records for the zone using the same parameters. Therefore, it would 668 need to inspect all NSEC3 records. 670 A more graceful solution was designed. The solution was to create a 671 new record, NSEC3PARAM, which must be placed at the apex of the zone. 672 Its role is to provide a fixed place where an authoritative name 673 server can directly see the NSEC3 parameters used, and by putting it 674 in the zone it allows for easy transfer to the secondaries. If NSEC3 675 were designed in the early days of DNS (+/- 1984) this information 676 would probably have been put in the SOA record. 678 5.3. Wildcards in the DNS 680 So far, we have only talked about denial of existence in negative 681 responses. However, denial of existence may also occur in positive 682 responses, i.e., where the ANSWER section of the response is not 683 empty. This can happen because of wildcards. 685 Wildcards have been part of the DNS since the first DNS RFCs. They 686 allow to define all names for a certain type in one go. In our 687 "example.org" zone we could for instance add a wildcard record: 689 *.example.org. TXT "wildcard record" 691 For completeness, our (unsigned) zone now looks like this: 693 example.org. SOA ( ... ) 694 example.org. NS a.example.org. 695 *.example.org. TXT "wildcard record" 696 a.example.org. A 192.0.2.1 697 TXT "a record" 698 d.example.org. A 192.0.2.1 699 TXT "d record" 701 Figure 4: The example.org zone with a wildcard record. 703 If a resolver asks for "z.example.org TXT", the name server will 704 respond with an expanded wildcard, instead of an NXDOMAIN: 706 ;; status: NOERROR, id: 13658 708 ;; ANSWER SECTION: 709 z.example.org. TXT "wildcard record" 711 Note however that the resolver can not detect that this answer came 712 from a wildcard. It just sees the answer as-is. How will this 713 answer look with DNSSEC? 714 ;; status: NOERROR, id: 51790 716 ;; ANSWER SECTION: 717 z.example.org. TXT "wildcard record" 718 z.example.org. RRSIG(TXT) ( ... ) 720 ;; AUTHORITY SECTION: 721 d.example.org. NSEC example.org. A TXT RRSIG NSEC 722 d.example.org. RRSIG(NSEC) ( ... ) 724 Figure 5: A response with an expanded wildcard and with DNSSEC. 726 The RRSIG of the "z.example.org" TXT record indicates there is a 727 wildcard configured. The RDATA of the signature lists a label count 728 [RFC4034], Section 3.1.3., of two (not visible in the answer above), 729 but the owner name of the signature has three labels. This mismatch 730 indicates there is a wildcard "*.example.org" configured. 732 An astute reader may notice that it appears as if a 733 "z.example.org" RRSIG(TXT) is created out of thin air. This is 734 not the case. The signature for "z.example.org" does not exist. 735 The signature you are seeing is the one for "*.example.org" which 736 does exist, only the owner name is switched to "z.example.org". 737 So even with wildcards, no signatures have to be created on the 738 fly. 740 The DNSSEC standard mandates that an NSEC (or NSEC3) is included in 741 such responses. If it wasn't, an attacker could mount a replay 742 attack and poison the cache with false data: Suppose that the 743 resolver has asked for "a.example.org TXT". An attacker could modify 744 the packet in such way that it looks like the response was generated 745 through wildcard expansion, even though there exists a record for 746 "a.example.org TXT". 748 The tweaking simply consists of adjusting the ANSWER section to: 750 ;; status: NOERROR, id: 31827 752 ;; ANSWER SECTION: 753 a.example.org. TXT "wildcard record" 754 a.example.org. RRSIG(TXT) ( ... ) 756 Figure 6: A forged response without the expanded wildcard. 758 Note the subtle difference from Figure 5 in the owner name. In this 759 response we see a "a.example.org TXT" record, for which a record with 760 different RDATA (See Figure 4) exist in the zone. 762 Which would be a perfectly valid answer if we would not require the 763 inclusion of an NSEC or NSEC3 record in the wildcard answer response. 764 The resolver believes that "a.example.org TXT" is a wildcard record, 765 and the real record is obscured. This is bad and defeats all the 766 security DNSSEC can deliver. Because of this, the NSEC or NSEC3 must 767 be present. 769 Another way of putting this is that DNSSEC is there to ensure the 770 name server has followed the steps as outlined in [RFC1034], Section 771 4.3.2 for looking up names in the zone. It explicitly lists wildcard 772 look up as one of these steps (3c), so with DNSSEC this must be 773 communicated to the resolver: hence the NSEC(3) record. 775 5.4. CNAME Records 777 So far, the maximum number of NSEC records a response will have is 778 two: one for the denial of existence and another for the wildcard. 779 We say maximum, because sometimes a single NSEC can prove both. With 780 NSEC3, this is three (as to why, we will explain in the next 781 section). 783 When we take CNAME wildcard records into account, we can have more 784 NSEC(3) records. For every wildcard expansion, we need to prove that 785 the expansion was allowed. Lets add some CNAME wildcard records to 786 our zone: 788 example.org. SOA ( ... ) 789 example.org. NS a.example.org. 790 *.example.org. TXT "wildcard record" 791 a.example.org. A 192.0.2.1 792 TXT "a record" 793 *.a.example.org. CNAME w.b 794 *.b.example.org. CNAME w.c 795 *.c.example.org. A 192.0.2.1 796 d.example.org. A 192.0.2.1 797 TXT "d record" 798 w.example.org. CNAME w.a 800 Figure 7: A wildcard CNAME chain added to the "example.org" zone. 802 A query for "w.example.org A" will result in the following response: 804 ;; status: NOERROR, id: 4307 806 ;; ANSWER SECTION: 807 w.example.org. CNAME w.a.example.org. 808 w.example.org. RRSIG(CNAME) ( ... ) 809 w.a.example.org. CNAME w.b.example.org. 810 w.a.example.org. RRSIG(CNAME) ( ... ) 811 w.b.example.org. CNAME w.c.example.org. 812 w.b.example.org. RRSIG(CNAME) ( ... ) 813 w.c.example.org. A 192.0.2.1 814 w.c.example.org. RRSIG(A) ( ... ) 816 ;; AUTHORITY SECTION: 817 *.a.example.org. NSEC *.b.example.org. CNAME RRSIG NSEC 818 *.a.example.org. RRSIG(NSEC) ( ... ) 819 *.b.example.org. NSEC *.c.example.org. CNAME RRSIG NSEC 820 *.b.example.org. RRSIG(NSEC) ( ... ) 821 *.c.example.org. NSEC d.example.org. A RRSIG NSEC 822 *.c.example.org. RRSIG(NSEC) ( ... ) 824 The NSEC record "*.a.example.org" proves that wildcard expansion to 825 "w.a.example.org" was appropriate: "w.a." falls in the gap "*.a" to 826 "*.b". Similar, the NSEC record "*.b.example.org" proves that there 827 was no direct match for "w.b.example.org" and "*.c.example.org" 828 denies the direct match for "w.c.example.org". 830 DNAME records and wildcard names should not be used as reiterated in 831 [RFC6672] Section 3.3. 833 5.5. The Closest Encloser NSEC3 Record 835 We can have one or more NSEC3 records that deny the existence of the 836 requested name and one NSEC3 record that deny wildcard synthesis. 837 What do we miss? 839 The short answer is that, due to the hashing in NSEC3 you loose the 840 depth of your zone: Everything is hashed into a flat plane. To make 841 up for this loss of information you need an extra record. 843 To understand NSEC3, we will need two definitions: 845 Closest encloser: Introduced in [RFC4592], "The closest encloser is 846 the node in the zone's tree of existing domain names that has the 847 most labels matching the query name (consecutively, counting from 848 the root label downward)." In our example, if the query name is 849 "x.2.example.org" then "example.org" is the "closest encloser"; 851 Next closer name: Introduced in the NSEC3 RFC, this is the closest 852 encloser with one more label added to the left. So if 853 "example.org" is the closest encloser for the query name 854 "x.2.example.org", "2.example.org" is the "next closer name". 856 An NSEC3 "closest encloser proof" consists of: 858 1. An NSEC3 record that *matches* the "closest encloser". This 859 means the unhashed owner name of the record is the closest 860 encloser. This bit of information tells a resolver: "The name 861 you are asking for does not exist, the closest I have is this". 863 2. An NSEC3 record that *covers* the "next closer name". This means 864 it defines an interval in which the "next closer name" falls. 865 This tells the resolver: "The next closer name falls in this 866 interval, and therefore the name in your question does not exist. 867 In fact, the closest encloser is indeed the closest I have". 869 These two records already deny the existence of the requested name, 870 so we do not need an NSEC3 record that covers the actual queried 871 name: By denying the existence of the next closer name, you also deny 872 the existence of the queried name. 874 Note that with NSEC, the existence of all empty non-terminals between 875 the two names are denied, hence implicitly contains the closest 876 encloser. 878 For a given query name, there is one (and only one) place where 879 wildcard expansion is possible. This is the "source of synthesis", 880 and is defined ([RFC4592], Section 2.1.1 and Section 3.3.1) as: 882 . 884 In other words, to deny wildcard synthesis, the resolver needs to 885 know the hash of the source of synthesis. Since it does not know 886 beforehand what the closest encloser of the query name is, it must be 887 provided in the answer. 889 Take the following example. We take our zone, and put two TXT 890 records to it. The records added are "1.h.example.org" and 891 "3.3.example.org". It is signed with NSEC3, resulting in the 892 following unsigned zone. 894 example.org. SOA ( ... ) 895 example.org. NS a.example.org. 896 1.h.example.org. TXT "1.h record" 897 3.3.example.org. TXT "3.3 record" 899 Figure 8: The added TXT records in example.org. These records create 900 two empty non-terminals: h.example.org and 3.example.org. 902 The resolver asks the following: "x.2.example.org TXT". This leads 903 to an NXDOMAIN response from the server, which contains three NSEC3 904 records. A list of hashed owner names can be found in Appendix C. 905 Also see Figure 9 the numbers in that figure correspond with the 906 following NSEC3 records: 908 15bg9l6359f5ch23e34ddua6n1rihl9h.example.org. ( 909 NSEC3 1 0 2 DEAD 1AVVQN74SG75UKFVF25DGCETHGQ638EK NS SOA RRSIG 910 DNSKEY NSEC3PARAM ) 912 1avvqn74sg75ukfvf25dgcethgq638ek.example.org. ( 913 NSEC3 1 0 2 DEAD 75B9ID679QQOV6LDFHD8OCSHSSSB6JVQ ) 915 75b9id679qqov6ldfhd8ocshsssb6jvq.example.org. ( 916 NSEC3 1 0 2 DEAD 8555T7QEGAU7PJTKSNBCHG4TD2M0JNPJ TXT RRSIG ) 918 If we would follow the NSEC approach, the resolver is only interested 919 in one thing. Does the hash of "x.2.example.org" fall in any of the 920 intervals of the NSEC3 records it got? 922 example.org 923 ** 924 +-- ** . . . . . . . . . . . 925 (1) / . ^ . . 926 / . | . . 927 | . | . . 928 v . | . . 929 ** | (2) ** ++ 930 h.example.org ** ----+----> ** 3.example.org ++ 2.example.org 931 . / . | . 932 . / (5) . | (3) . 933 . / . | . 934 . / . v . 935 1.h.example.org ** ** ++ 936 ** <--------- ** 3.3.example.org ++ x.2.example.org 937 (4) 939 Figure 9: x.2.example.org does not exist. The five arrows represent 940 the NSEC3 records, the ones numbered (1), (2) and (3) are the NSEC3s 941 returned in our answer. 2.example.org is covered by (3) and 942 x.2.example.org is covered by (4). 944 The hash of "x.2.example.org" is "ndtu6dste50pr4a1f2qvr1v31g00i2i1". 945 Checking this hash on the first NSEC3 yields that it does not fall in 946 between the interval: "15bg9l6359f5ch23e34ddua6n1rihl9h" and 947 "1avvqn74sg75ukfvf25dgcethgq638ek". For the second NSEC3 the answer 948 is also negative: the hash sorts outside the interval described by 949 "1avvqn74sg75ukfvf25dgcethgq638ek" and 950 "75b9id679qqov6ldfhd8ocshsssb6jvq". And the third NSEC3, with 951 interval "75b9id679qqov6ldfhd8ocshsssb6jvq" to 952 "8555t7qegau7pjtksnbchg4td2m0jnpj" also isn't of any help. 954 What is a resolver to do? It has been given the maximum amount of 955 NSEC3s and they all seem useless. 957 So this is where the closest encloser proof comes into play. And for 958 the proof to work, the resolver needs to know what the closest 959 encloser is. There must be an existing ancestor in the zone: a name 960 must exist that is shorter than the query name. The resolver keeps 961 hashing increasingly shorter names from the query name until an owner 962 name of an NSEC3 matches. This owner name is the closest encloser. 964 When the resolver has found the closest encloser, the next step is to 965 construct the next closer name. This is the closest encloser with 966 the last chopped label from query name pre-pended to it: ".". The hash of this name should be 968 covered by the interval set in any of the NSEC3 records. 970 Then the resolver needs to check the presence of a wildcard. It 971 creates the wildcard name by pre-pending the asterisk label to the 972 closest encloser: "*.", and uses the hash of that. 974 Going back to our example, the resolver must first detect the NSEC3 975 that matches the closest encloser. It does this by chopping up the 976 query name, hashing each instance (with the same number of iterations 977 and hash as the zone it is querying) and comparing that to the 978 answers given. So it has the following hashes to work with: 980 x.2.example.org: "ndtu6dste50pr4a1f2qvr1v31g00i2i1", last chopped 981 label: ""; 983 2.example.org: "7t70drg4ekc28v93q7gnbleopa7vlp6q", last chopped 984 label: "x"; 986 example.org: "15bg9l6359f5ch23e34ddua6n1rihl9h", last chopped label: 987 "2"; 989 Of these hashes only one matches the owner name of one of the NSEC3 990 records: "15bg9l6359f5ch23e34ddua6n1rihl9h". This must be the 991 closest encloser (unhashed: "example.org"). That's the main purpose 992 of that NSEC3 record: tell the resolver what the closest encloser is. 994 When using Opt-Out, it is possible that the actual closest encloser 995 to the QNAME does not have an NSEC3 record. If so, we will have to 996 do with the closest provable encloser, which is the closest enclosing 997 authoritative name that does have a NSEC3 record. In the worst case, 998 this is the NSEC3 record corresponding to the apex, this name must 999 always have an NSEC3 record. 1001 With the closest (provable) encloser, the resolver constructs the 1002 next closer, which in this case is: "2.example.org"; "2" is the last 1003 label chopped, when "example.org" is the closest encloser. The hash 1004 of this name should be covered in any of the other NSEC3s. And it 1005 is, "7t70drg4ekc28v93q7gnbleopa7vlp6q" falls in the interval set by: 1006 "75b9id679qqov6ldfhd8ocshsssb6jvq" and 1007 "8555t7qegau7pjtksnbchg4td2m0jnpj" (this is our second NSEC3). 1009 So what does the resolver learn from this? 1011 o "example.org" exists; 1013 o "2.example.org" does not exist. 1015 And if "2.example.org" does not exist, there is also no direct match 1016 for "x.2.example.org". The last step is to deny the existence of the 1017 source of synthesis, to prove that no wildcard expansion was 1018 possible. 1020 The resolver hashes "*.example.org" to 1021 "22670trplhsr72pqqmedltg1kdqeolb7" and checks that it is covered: in 1022 this case by the last NSEC3 (see Figure 9), the hash falls in the 1023 interval set by "1avvqn74sg75ukfvf25dgcethgq638ek" and 1024 "75b9id679qqov6ldfhd8ocshsssb6jvq". This means there is no wildcard 1025 record directly below the closest encloser and "x.2.example.org" 1026 definitely does not exist. 1028 When we have validated the signatures, we reached our goal: 1029 authenticated denial of existence. 1031 5.6. Three To Tango 1033 One extra NSEC3 record plus additional signature may seem a lot just 1034 to deny the existence of the wildcard record, but we cannot leave it 1035 out. If the standard would not mandate the closest encloser NSEC3 1036 record, but instead required two NSEC3 records: one to deny the query 1037 name and one to deny the wildcard record. An attacker could fool the 1038 resolver that the source of synthesis does not exist, while it in 1039 fact does. 1041 Suppose the wildcard record does exist, so our unsigned zone looks 1042 like this: 1044 example.org. SOA ( ... ) 1045 example.org. NS a.example.org. 1046 *.example.org. TXT "wildcard record" 1047 1.h.example.org. TXT "1.h record" 1048 3.3.example.org. TXT "3.3 record" 1050 The query "x.2.example.org TXT" should now be answered with: 1052 x.2.example.org. TXT "wildcard record" 1054 An attacker can deny this wildcard expansion by calculating the hash 1055 for the wildcard name "*.2.example.org" and searching for an NSEC3 1056 record that covers that hash. The hash of "*.2.example.org" is 1057 "fbq73bfkjlrkdoqs27k5qf81aqqd7hho". Looking through the NSEC3 1058 records in our zone we see that the NSEC3 record of "3.3" covers this 1059 hash: 1061 8555t7qegau7pjtksnbchg4td2m0jnpj.example.org. ( 1062 NSEC3 1 0 2 DEAD 15BG9L6359F5CH23E34DDUA6N1RIHL9H TXT RRSIG ) 1064 This record also covers the query name "x.2.example.org" 1065 ("ndtu6dste50pr4a1f2qvr1v31g00i2i1"). 1067 Now an attacker adds this NSEC3 record to the AUTHORITY section of 1068 the reply to deny both "x.2.example.org" and any wildcard expansion. 1069 The net result is that the resolver determines that "x.2.example.org" 1070 does not exist, while in fact it should have been synthesized via 1071 wildcard expansion. With the NSEC3 matching the closest encloser 1072 "example.org", the resolver can be sure that the wildcard expansion 1073 should occur at "*.example.org" and nowhere else. 1075 Coming back to the original question: why do we need up to three 1076 NSEC3 records to deny a requested name? The resolver needs to be 1077 explicitly told what the "closest encloser" is and this takes up a 1078 full NSEC3 record. Then, the next closer name needs to be covered in 1079 an NSEC3 record, and finally an NSEC3 must say something about 1080 whether wildcard expansion was possible. That makes three to tango. 1082 6. Security Considerations 1084 DNSSEC does not protect against denial of service attacks, nor does 1085 it provide confidentiality. For more general security considerations 1086 related to DNSSEC, please see RFC 4033, RFC 4034, RFC 4035 and RFC 1087 5155 ([RFC4033], [RFC4034], [RFC4035] and [RFC5155]). 1089 These RFCs are concise about why certain design choices have been 1090 made in the area of authenticated denial of existence. 1091 Implementations that do not correctly handle this aspect of DNSSEC, 1092 create a severe hole in the security DNSSEC adds. This is 1093 specifically troublesome for secure delegations: If an attacker is 1094 able to deny the existence of a DS record, the resolver cannot 1095 establish a chain of trust, and the resolver has to fall back to 1096 insecure DNS for the remainder of the query resolution. 1098 This document aims to fill this "documentation gap" and provide 1099 would-be implementors and other interested parties with enough 1100 background knowledge to better understand authenticated denial of 1101 existence. 1103 7. IANA Considerations 1105 This document has no actions for IANA. 1107 8. Acknowledgments 1109 This document would not be possible without the help of Ed Lewis, Roy 1110 Arends, Wouter Wijngaards, Olaf Kolkman, Carsten Strotmann, Jan-Piet 1111 Mens, Peter van Dijk, Marco Davids, Esther Makaay, Antoin Verschuren, 1112 Lukas Wunner, Joe Abley, Ralf Weber, Geoff Huston, Dave Lawrence, 1113 Tony Finch and Mark Andrews. Also valuable was the source code of 1114 Unbound. ("validator/val_nsec3.c") [Unbound]. 1116 Extensive feedback for early versions was received from Karst 1117 Koymans. 1119 9. References 1121 9.1. Normative References 1123 [RFC1034] Mockapetris, P., "Domain names - 1124 concepts and facilities", STD 13, 1125 RFC 1034, November 1987. 1127 [RFC2065] Eastlake, D. and C. Kaufman, 1128 "Domain Name System Security 1129 Extensions", RFC 2065, 1130 January 1997. 1132 [RFC2308] Andrews, M., "Negative Caching of 1133 DNS Queries (DNS NCACHE)", 1134 RFC 2308, March 1998. 1136 [RFC4033] Arends, R., Austein, R., Larson, 1137 M., Massey, D., and S. Rose, "DNS 1138 Security Introduction and 1139 Requirements", RFC 4033, 1140 March 2005. 1142 [RFC4034] Arends, R., Austein, R., Larson, 1143 M., Massey, D., and S. Rose, 1144 "Resource Records for the DNS 1145 Security Extensions", RFC 4034, 1146 March 2005. 1148 [RFC4035] Arends, R., Austein, R., Larson, 1149 M., Massey, D., and S. Rose, 1150 "Protocol Modifications for the 1151 DNS Security Extensions", 1152 RFC 4035, March 2005. 1154 [RFC4592] Lewis, E., "The Role of Wildcards 1155 in the Domain Name System", 1156 RFC 4592, July 2006. 1158 [RFC4648] Josefsson, S., "The Base16, 1159 Base32, and Base64 Data 1160 Encodings", RFC 4648, 1161 October 2006. 1163 [RFC5155] Laurie, B., Sisson, G., Arends, 1164 R., and D. Blacka, "DNS Security 1165 (DNSSEC) Hashed Authenticated 1166 Denial of Existence", RFC 5155, 1167 March 2008. 1169 [RFC6672] Rose, S. and W. Wijngaards, "DNAME 1170 Redirection in the DNS", RFC 6672, 1171 June 2012. 1173 9.2. Informative References 1175 [I-D.arends-dnsnr] Arends, R., "DNSSEC Non- 1176 Repudiation Resource Record", 1177 draft-arends-dnsnr-00 (work in 1178 progress), July 2004. 1180 [I-D.ietf-dnsext-not-existing-rr] Josefsson, S., "Authenticating 1181 denial of existence in DNS with 1182 minimum disclosure", draft-ietf- 1183 dnsext-not-existing-rr-01 (work in 1184 progress), November 2000. 1186 [I-D.laurie-dnsext-nsec2v2] Laurie, B., "DNSSEC NSEC2 Owner 1187 and RDATA Format", 1188 draft-laurie-dnsext-nsec2v2-00 1189 (work in progress), December 2004. 1191 [RFC2535] Eastlake, D., "Domain Name System 1192 Security Extensions", RFC 2535, 1193 March 1999. 1195 [RFC3655] Wellington, B. and O. Gudmundsson, 1196 "Redefinition of DNS Authenticated 1197 Data (AD) bit", RFC 3655, 1198 November 2003. 1200 [RFC3755] Weiler, S., "Legacy Resolver 1201 Compatibility for Delegation 1202 Signer (DS)", RFC 3755, May 2004. 1204 [RFC4470] Weiler, S. and J. Ihren, 1205 "Minimally Covering NSEC Records 1206 and DNSSEC On-line Signing", 1207 RFC 4470, April 2006. 1209 [RFC4956] Arends, R., Kosters, M., and D. 1210 Blacka, "DNS Security (DNSSEC) 1211 Opt-In", RFC 4956, July 2007. 1213 [RFC5155-errata3441] Lewis, E., "Technical Errata 1214 against RFC 5155 (not 1215 acknowledged)", January 2013. 1217 [Unbound] NLnet Labs, "Unbound: a 1218 validating, recursive, and caching 1219 DNS resolver", 2006, 1220 . 1222 [phreebird] Kaminsky, D., "Phreebird: a DNSSEC 1223 proxy", January 2011, . 1226 Appendix A. On-line Signing: Minimally Covering NSEC Records 1228 An NSEC record lists the next existing name in a zone, and thus makes 1229 it trivial to retrieve all the names from the zone. This can also be 1230 done with NSEC3, but an adversary will then retrieve all the hashed 1231 names. With DNSSEC on-line signing, zone walking can be prevented by 1232 faking the next owner name. 1234 To prevent retrieval of the next owner name with NSEC, a different, 1235 non-existing (according to the existence rules in []#RFC4592, Section 1236 2.2) name is used. However, not just any name can be used because a 1237 validator may make assumptions on the size of the span the NSEC 1238 record covers. The span must be large enough to cover the QNAME, but 1239 not too large that it covers existing names. 1241 [RFC4470] introduces a scheme for generating minimally covering NSEC 1242 records. These records use a next owner name that is lexically 1243 closer to the NSEC owner name than the actual next owner name, 1244 ensuring that no existing names are covered. The next owner name can 1245 be derived from the QNAME with the use of so-called epsilon 1246 functions. 1248 For example, to deny the existence of "b.example.org" in the zone 1249 from Section 3.2, the following NSEC record could have been 1250 generated: 1252 a.example.org. NSEC c.example.org. RRSIG NSEC 1254 This record also proves that "b.example.org" also does not exist, but 1255 an adversary _cannot_ use the next owner name in a zone walking 1256 attack. Note the type bitmap only has the RRSIG and NSEC set, 1257 because [RFC4470] states: 1259 The generated NSEC record's type bitmap MUST have the RRSIG and 1260 NSEC bits set and SHOULD NOT have any other bits set. 1262 This is because the NSEC records may appear at names that did not 1263 exist before the zone was signed. In this case however, 1264 "a.example.org" exists with other RR types and we could have also set 1265 the A and TXT types in the bitmap. 1267 Because DNS ordering is very strict, the span should be shortened to 1268 a minimum. In order to do so, the last character in the leftmost 1269 label of the NSEC owner name needs to be decremented and the label 1270 must be filled with octets of value 255 until the label length 1271 reaches the maximum of 63 octets. The next owner name is the QNAME 1272 with a leading label with a single null octet added. This gives the 1273 following minimally covering record for "b.example.org": 1275 a\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 1276 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 1277 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 1278 \255\255\255\255\255\255\255\255\255\255\255.example.org. ( 1279 NSEC \000.b.example.org. RRSIG NSEC ) 1281 Appendix B. On-line Signing: NSEC3 White Lies 1283 The same principle of minimally covering spans can be applied to 1284 NSEC3 records. This mechanism has been dubbed "NSEC3 White Lies" 1285 when it was implemented in Phreebird [phreebird]. Here, the NSEC3 1286 owner name is the hash of the QNAME minus one and the next owner name 1287 is the hash of the QNAME plus one. 1289 The following NSEC3 white lie denies "b.example.org" (recall this 1290 hashes to "iuu8l5lmt76jeltp0bir3tmg4u3uu8e7"): 1292 iuu8l5lmt76jeltp0bir3tmg4u3uu8e6.example.org. ( 1293 NSEC3 1 0 2 DEAD IUU815LMT76JELTP0BIR3TMG4U3UU8E8 ) 1295 The type bitmap is empty in this case. If the hash of 1296 "b.example.org" - 1 is a collision with an existing name, the bitmap 1297 should have been filled with the RR types that exist at that name. 1298 This record actually denies the existence of the next closer name 1299 (which is conveniently "b.example.org"). Of course the NSEC3 records 1300 to match the closest encloser and the one to deny the wildcard are 1301 still required. These can be generated too: 1303 # Matching `example.org`: `15bg9l6359f5ch23e34ddua6n1rihl9h` 1304 15bg9l6359f5ch23e34ddua6n1rihl9h.example.org. ( 1305 NSEC3 1 0 2 DEAD 15BG9L6359F5CH23E34DDUA6N1RIHL9I NS SOA RRSIG 1306 DNSKEY NSEC3PARAM ) 1308 # Covering `*.example.org`: `22670trplhsr72pqqmedltg1kdqeolb7` 1309 22670trplhsr72pqqmedltg1kdqeolb6.example.org.( 1310 NSEC3 1 0 2 DEAD 22670TRPLHSR72PQQMEDLTG1KDQEOLB8 ) 1312 Appendix C. List of Hashed Owner Names 1314 The following owner names are used in this document. The origin for 1315 these names is "example.org". 1317 +---------------+------------------------------------+ 1318 | Original Name | Hashed Name | 1319 +---------------+------------------------------------+ 1320 | "a" | "04sknapca5al7qos3km2l9tl3p5okq4c" | 1321 | "1.h" | "117gercprcjgg8j04ev1ndrk8d1jt14k" | 1322 | "@" | "15bg9l6359f5ch23e34ddua6n1rihl9h" | 1323 | "h" | "1avvqn74sg75ukfvf25dgcethgq638ek" | 1324 | "*" | "22670trplhsr72pqqmedltg1kdqeolb7" | 1325 | "3" | "75b9id679qqov6ldfhd8ocshsssb6jvq" | 1326 | "2" | "7t70drg4ekc28v93q7gnbleopa7vlp6q" | 1327 | "3.3" | "8555t7qegau7pjtksnbchg4td2m0jnpj" | 1328 | "d" | "a6edkb6v8vl5ol8jnqqlt74qmj7heb84" | 1329 | "*.2" | "fbq73bfkjlrkdoqs27k5qf81aqqd7hho" | 1330 | "b" | "iuu8l5lmt76jeltp0bir3tmg4u3uu8e7" | 1331 | "x.2" | "ndtu6dste50pr4a1f2qvr1v31g00i2i1" | 1332 +---------------+------------------------------------+ 1334 Table 1: Hashed owner names for "example.org" in hash order. 1336 Appendix D. Changelog 1338 [This section should be removed by the RFC editor before publishing] 1340 D.1. -00 1342 1. Initial document. 1344 D.2. -01 1346 1. Style and language changes; 1348 2. Figure captions; 1350 3. Security considerations added; 1352 4. Fix erroneous NSEC3 RR; 1354 5. Section on CNAMEs added; 1356 6. More detailed text on closest encloser proof. 1358 D.3. -02 1360 1. Lowercase NSEC3 hashed ownernames and add reference to Base32; 1362 2. Process the comments from Joe Abley and Geoff Huston. 1364 * Added section about Opt-Out; 1366 * Move experimental records in their own section; 1368 * Added DNAME reference with respect to wildcards; 1370 * Clarify the difference between the wildcard answers; 1372 * Add more context about the NO record; 1374 * Elaborate more about the EXIST records and its problems; 1376 * Added more text about the NSEC3PARAM records; 1378 * Apply assorted fixes throughout the document; 1380 * Moved table with hashed owner names to appendix. 1382 D.4. -03 1384 1. Changed affiliation for R. Gieben; 1386 2. Some minor updates. 1388 D.5. -04 1390 1. Added NS record in all zone examples; 1392 2. Some tweaks in the text regarding on-line signing; 1394 3. Add more text on a non-working "generic non-existence records". 1396 4. Add appendix on on-line signing; 1398 5. Add text on usefulness of NSEC3. 1400 D.6. -05 1402 1. Minor fixes and adjustments. 1404 Authors' Addresses 1406 R. (Miek) Gieben 1407 Google 1409 Phone: 1410 EMail: miek@google.com 1411 URI: 1413 W. (Matthijs) Mekking 1414 NLnet Labs 1415 Science Park 400 1416 Amsterdam, 1098 XH 1417 NL 1419 Phone: 1420 EMail: matthijs@nlnetlabs.nl 1421 URI: http://www.nlnetlabs.nl/