idnits 2.17.1 draft-gieben-auth-denial-of-existence-dns-04.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 489: '... closest encloser, this SHOULD be used...' RFC 2119 keyword, line 635: '... "The validator MUST verify that an N...' RFC 2119 keyword, line 1223: '...rd's type bitmap MUST have the RRSIG a...' RFC 2119 keyword, line 1224: '...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 22, 2013) is 3807 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 26, 2014 NLnet Labs 6 November 22, 2013 8 Authenticated Denial of Existence in the DNS 9 draft-gieben-auth-denial-of-existence-dns-04 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 26, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Denial of Existence . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. NXDOMAIN Responses . . . . . . . . . . . . . . . . . . . 4 58 2.2. NODATA Responses . . . . . . . . . . . . . . . . . . . . 5 59 3. Secure Denial of Existence . . . . . . . . . . . . . . . . . 5 60 3.1. NXT . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 3.2. NSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3.3. NODATA Responses . . . . . . . . . . . . . . . . . . . . 9 63 3.4. Drawbacks of NSEC . . . . . . . . . . . . . . . . . . . . 9 64 4. Experimental and Deprecated Mechanisms: NO, NSEC2 and DNSNR . 10 65 5. NSEC3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 5.1. Opt-Out . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 5.2. Loading an NSEC3 Zone . . . . . . . . . . . . . . . . . . 14 68 5.3. Wildcards in the DNS . . . . . . . . . . . . . . . . . . 15 69 5.4. CNAME Records . . . . . . . . . . . . . . . . . . . . . . 17 70 5.5. The Closest Encloser NSEC3 Record . . . . . . . . . . . . 18 71 5.6. Three To Tango . . . . . . . . . . . . . . . . . . . . . 22 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 74 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 24 77 9.2. Informative References . . . . . . . . . . . . . . . . . 25 78 Appendix A. DNSSEC On-line Signing . . . . . . . . . . . . . . . 25 79 A.1. Minimally Covering NSEC Records . . . . . . . . . . . . . 26 80 A.2. NSEC3 White Lies . . . . . . . . . . . . . . . . . . . . 27 81 Appendix B. List of Hashed Owner Names . . . . . . . . . . . . . 27 82 Appendix C. Changelog . . . . . . . . . . . . . . . . . . . . . 28 83 C.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 84 C.2. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 85 C.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 86 C.4. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 87 C.5. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 89 1. Introduction 91 DNSSEC can be somewhat of a complicated matter, and there are certain 92 areas of the specification that are more difficult to comprehend than 93 others. One such area is "authenticated denial of existence". 95 Denial of existence is a mechanism that informs a resolver that a 96 certain domain name does not exist. It is also used to signal that a 97 domain name exists, but does not have the specific RR type you were 98 asking for. 100 The first is referred to as an NXDOMAIN (non-existent domain) 101 ([RFC2308] Section 2.1) and the latter a NODATA ([RFC2308] 102 Section 2.2) response. Both are also known as negative responses. 104 Authenticated denial of existence uses cryptography to sign the 105 negative response. However, if there is no answer, what is it that 106 needs to be signed? To further complicate this matter, there is the 107 desire to pre-generate negative responses that are applicable for all 108 queries for non-existent names in the signed zone. See Section 3 for 109 the details. 111 In this document, we will explain how authenticated denial of 112 existence works. We begin by explaining the current technique in the 113 DNS and work our way up to DNSSEC. We explain the first steps taken 114 in DNSSEC and describe how NSEC and NSEC3 work. The NXT, NO, NSEC2 115 and DNSNR records also briefly make their appearance, as they have 116 paved the way for NSEC and NSEC3. 118 To complete the picture, we also need to explain DNS wildcards as 119 these complicate matters, especially combined with CNAME records. 121 Note: In this document, domain names in zone file examples will have 122 a trailing dot, in the running text they will not. This text is 123 written for people who have a fair understanding of DNSSEC. The 124 following RFCs are not required reading, but they help in 125 understanding the problem space. 127 o RFC 5155 [RFC5155] - Hashed Authenticated Denial of Existence; 129 o RFC 4592 [RFC4592] - The Role of Wildcards in the DNS. 131 And these provide some general DNSSEC information. 133 o RFC 4033, RFC 4034, RFC 4035 [RFC4033], [RFC4034], [RFC4035] - 134 DNSSEC Specification; 136 o RFC 4956 [RFC4956] - DNS Security (DNSSEC) Opt-In. This RFC has 137 experimental status, but is a good read. 139 These three drafts give some background information on the NSEC3 140 development. 142 o The NO record [I-D.ietf-dnsext-not-existing-rr]; 144 o The NSEC2 record [I-D.laurie-dnsext-nsec2v2]; 145 o The DNSNR record [I-D.arends-dnsnr]. 147 2. Denial of Existence 149 We start with the basics and take a look at NXDOMAIN handling in the 150 DNS. To make it more visible we are going to use a small DNS zone, 151 with 3 names ("example.org", "a.example.org" and "d.example.org") and 152 3 types (SOA, A and TXT). For brevity, the class is not shown 153 (defaults to IN) and the SOA record is shortened, resulting in the 154 following zone file: 156 example.org. SOA ( ... ) 157 example.org. NS a.example.org. 158 a.example.org. A 192.0.2.1 159 TXT "a record" 160 d.example.org. A 192.0.2.1 161 TXT "d record" 163 Figure 1: The unsigned "example.org" zone. 165 2.1. NXDOMAIN Responses 167 If a resolver asks for the TXT type belonging to "a.example.org" to 168 the name server serving this zone, it sends the following question: 169 "a.example.org TXT" 171 The name server looks in its zone data and generates an answer. In 172 this case a positive one: "Yes it exists and this is the data", 173 resulting in this reply: 175 ;; status: NOERROR, id: 28203 177 ;; ANSWER SECTION: 178 a.example.org. TXT "a record" 180 ;; AUTHORITY SECTION: 181 example.org. NS a.example.org. 183 The "status: NOERROR" signals that everything is OK, "id" is an 184 integer used to match questions and answers. In the ANSWER section, 185 we find our answer. The AUTHORITY section holds the names of the 186 name servers that have information concerning the "example.org" zone. 187 Note that including this information is optional. 189 If a resolver asks for "b.example.org TXT" it gets an answer that 190 this name does not exist: 192 ;; status: NXDOMAIN, id: 7042 194 ;; AUTHORITY SECTION: 195 example.org. SOA ( ... ) 197 In this case, we do not get an ANSWER section and the status is set 198 to NXDOMAIN. From this the resolver concludes that "b.example.org" 199 does not exist. The AUTHORITY section holds the SOA record of 200 "example.org" that the resolver can use to cache the negative 201 response. 203 2.2. NODATA Responses 205 It is important to realize that NXDOMAIN is not the only type of 206 does-not-exist. A name may exist, but the type you are asking for 207 may not. This occurrence of non-existence is called a NODATA 208 response. Let us ask our name server for "a.example.org AAAA", and 209 look at the answer: 211 ;; status: NOERROR, id: 7944 213 ;; AUTHORITY SECTION: 214 example.org. SOA ( ... ) 216 The status NOERROR shows that the "a.example.org" name exists, but 217 the reply does not contain an ANSWER section. This differentiates a 218 NODATA response from an NXDOMAIN response, the rest of the packet is 219 very similar. The resolver has to put these pieces of information 220 together and conclude that "a.example.org" exists, but it does not 221 have an "AAAA" record. 223 3. Secure Denial of Existence 225 The above has to be translated to the security aware world of DNSSEC. 226 But there are a few principles DNSSEC brings to the table: 228 1. A name server is free to compute the answer and signature(s) on- 229 the-fly, but the protocol is written with a "first sign, then 230 load" attitude in mind. It is rather asymmetrical, but a lot of 231 the design in DNSSEC stems from fact that you need to accommodate 232 authenticated denial of existence. If the DNS did not have 233 NXDOMAIN, DNSSEC would be a lot simpler, but a lot less useful! 235 2. The DNS packet header is not signed. This means that a "status: 236 NXDOMAIN" can not be trusted. In fact the entire header may be 237 forged, including the AD bit (AD stands for Authentic Data, see 238 RFC 3655 [RFC3655]), which may give some food for thought; 240 3. DNS wildcards and CNAME records complicate matters significantly. 241 More about this in later sections (Section 5.3 and Section 5.4). 243 The first principle implies that all denial of existence answers need 244 to be pre-computed, but it is impossible to pre-compute (all 245 conceivable) non-existence answers. 247 A generic denial record which can be used in all denial of existence 248 proofs is not an option: such a record is susceptible to replay 249 attacks. When you are querying a name server for any record that 250 actually exists, a man-in-the-middle could replay that generic denial 251 record that is unlimited in its scope and it would be impossible to 252 tell whether the response was genuine or spoofed. In other words, 253 the generic record can be replayed to falsely deny _all_ possible 254 responses. 256 Another way would be to use the QNAME in the answer and sign that; 257 essentially signing an NXDOMAIN response. While this approach could 258 have worked technically, it is incompatible with off-line signing 259 techniques. Appendix A describes compatible on-line signing 260 techniques in more detail. 262 The way this has been solved is by introducing a record that defines 263 an interval between two existing names. Or to put it another way: it 264 defines the holes (non-existing names) in the zone. This record can 265 be signed beforehand and given to the resolver. 267 Given all these troubles, why didn't the designers of DNSSEC go 268 for the (easy) route and allowed for on-line signing? Well, at 269 that time (pre 2000), on-line signing was not feasible with the 270 then current hardware. Keep in mind that the larger servers get 271 between 2000 and 6000 queries per second (qps), with peaks up to 272 20,000 qps or more. Scaling signature generation to these kind of 273 levels is always a challenge. Another issue was (and is) key 274 management, for on-line signing to work you need access to the 275 private key(s). This is considered a security risk. 277 The road to the current solution (NSEC/NSEC3) was long. It started 278 with the NXT (next) record. The NO (not existing) record was 279 introduced, but never made it to RFC. Later on, NXT was superseded 280 by the NSEC (next secure) record. From there it went through NSEC2/ 281 DNSNR to finally reach NSEC3 (next secure, version 3) in RFC 5155. 283 3.1. NXT 285 The first attempt to specify authenticated denial of existence was 286 NXT (RFC 2535 [RFC2535]). Section 5.1 of that RFC introduces the 287 record: 289 "The NXT resource record is used to securely indicate that RRs 290 with an owner name in a certain name interval do not exist in a 291 zone and to indicate what RR types are present for an existing 292 name." 294 By specifying what you do have, you implicitly tell what you don't 295 have. NXT is superseded by NSEC. In the next section we explain how 296 NSEC (and thus NXT) works. 298 3.2. NSEC 300 In RFC 3755 [RFC3755] all the DNSSEC types were given new names, SIG 301 was renamed RRSIG, KEY became DNSKEY and NXT was renamed to NSEC and 302 a minor issue was fixed in the process, namely the type bitmap was 303 redefined to allow more than 127 types to be listed ([RFC2535], 304 Section 5.2). 306 Just as NXT, NSEC is used to describe an interval between names: it 307 indirectly tells a resolver which names do not exist in a zone. 309 For this to work, we need our "example.org" zone to be sorted in 310 canonical order ([RFC4034], Section 6.1), and then create the NSECs. 311 We add three NSEC records, one for each name, and each one covers a 312 certain interval. The last NSEC record points back to the first as 313 required by the RFC, and depicted in Figure 2. 315 1. The first NSEC covers the interval between "example.org" and 316 "a.example.org"; 318 2. The second NSEC covers "a.example.org" to "d.example.org"; 320 3. The third NSEC points back to "example.org", and covers 321 "d.example.org" to "example.org" (i.e. the end of the zone). 323 As we have defined the intervals and put those in resource records, 324 we now have something that can be signed. 326 example.org 327 ** 328 +-- ** <--+ 329 (1) / . . \ (3) 330 / . . \ 332 | . . | 333 v . . | 334 ** (2) ** 335 a.example.org ** ---------> ** d.example.org 337 Figure 2: The NSEC records of "example.org". The arrows represent 338 NSEC records, starting from the apex. 340 This signed zone is loaded into the name server. It looks like this: 342 example.org. SOA ( ... ) 343 DNSKEY ( ... ) 344 NS a.example.org. 345 NSEC a.example.org. NS SOA RRSIG NSEC DNSKEY 346 RRSIG(NS) ( ... ) 347 RRSIG(SOA) ( ... ) 348 RRSIG(NSEC) ( ... ) 349 RRSIG(DNSKEY) ( ... ) 350 a.example.org. A 192.0.2.1 351 TXT "a record" 352 NSEC d.example.org. A TXT RRSIG NSEC 353 RRSIG(A) ( ... ) 354 RRSIG(TXT) ( ... ) 355 RRSIG(NSEC) ( ... ) 356 d.example.org. A 192.0.2.1 357 TXT "d record" 358 NSEC example.org. A TXT RRSIG NSEC 359 RRSIG(A) ( ... ) 360 RRSIG(TXT) ( ... ) 361 RRSIG(NSEC) ( ... ) 363 Figure 3: The signed and sorted "example.org" zone with the added 364 NSEC records (and signatures). For brevity, the class is not shown 365 (defaults to IN) and the SOA, DNSKEY and RRSIG records are shortened. 367 If a DNSSEC aware resolver asks for "b.example.org", it gets back a 368 "status: NXDOMAIN" packet, which by itself is meaningless (remember 369 that the DNS packet header is not signed and thus can be forged). To 370 be able to securely detect that "b" does not exist, there must also 371 be a signed NSEC record which covers the name space where "b" lives. 372 The record: 374 a.example.org. NSEC d.example.org. A TXT RRSIG NSEC 376 does precisely that: "b" should come after "a", but the next owner 377 name is "d.example.org", so "b" does not exist. 379 Only by making that calculation, is a resolver able to conclude that 380 the name "b" does not exist. If the signature of the NSEC record is 381 valid, "b" is proven not to exist. We have authenticated denial of 382 existence. 384 Note that a man-in-the-middle may still replay this NXDOMAIN response 385 when you're querying for, say, "c.example.org". But it would not do 386 any harm since it is provably the proper response to the query. In 387 the future, there may be data published for "c.example.org". 388 Therefore, the RRSIG's RDATA include a validity period (not visible 389 in the zone above), so that an attacker cannot replay this NXDOMAIN 390 response for "c.example.org" forever. 392 3.3. NODATA Responses 394 NSEC records are also used in NODATA responses. In that case we need 395 to look more closely at the type bitmap. The type bitmap in an NSEC 396 record tells which types are defined for a name. If we look at the 397 NSEC record of "a.example.org", we see the following types in the 398 bitmap: A, TXT, NSEC and RRSIG. So for the name "a" this indicates 399 we must have an A, TXT, NSEC and RRSIG record in the zone. 401 With the type bitmap of the NSEC record, a resolver can establish 402 that a name is there, but the type is not. For example, if a 403 resolver asks for "a.example.org AAAA", the reply that comes back is: 405 ;; status: NOERROR, id: 44638 407 ;; AUTHORITY SECTION: 408 example.org. SOA ( ... ) 409 example.org. RRSIG(SOA) ( ... ) 410 a.example.org. NSEC d.example.org. A TXT RRSIG NSEC 411 a.example.org. RRSIG(NSEC) ( ... ) 413 The resolver should check the AUTHORITY section and conclude that: 415 (1) "a.example.org" exists (because of the NSEC with that owner 416 name) and; 418 (2) the type (AAAA) does not as it is not listed in the type bitmap. 420 The techniques used by NSEC form the basics of authenticated denial 421 of existence in DNSSEC. 423 3.4. Drawbacks of NSEC 425 There were two issues with NSEC (and NXT). The first is that it 426 allows for zone walking. NSEC records point from one name to 427 another, in our example: "example.org", points to "a.example.org" 428 which points to "d.example.org" which points back to "example.org". 429 So we can reconstruct the entire "example.org" zone, thus defeating 430 attempts to administratively block zone transfers ([RFC2065] 431 Section 5.5). 433 The second issue is that when a large, delegation-centric ([RFC5155], 434 Section 1.1), zone deploys DNSSEC, every name in the zone gets an 435 NSEC plus RRSIG. So this leads to a huge increase in the zone size 436 (when signed). This would in turn mean that operators of such zones 437 who are deploying DNSSEC, face up front costs. This could hinder 438 DNSSEC adoption. 440 These two issues eventually lead to NSEC3 which: 442 o Adds a way to garble the owner names, thus thwarting zone-walking; 444 o Makes it possible to skip names for the next owner name. This 445 feature is called Opt-Out (See Section 5.1). It means not all 446 names in your zone get an NSEC3 plus ditto signature, making it 447 possible to "grow into" your DNSSEC deployment. 449 Note that [RFC4470] also prevents zone walking by introducing 450 minimally covering NSEC records. This technique is described in 451 Appendix A; 453 Before we delve into NSEC3, let us first take a look at its 454 predecessors: NO, NSEC2, and DNSNR. 456 4. Experimental and Deprecated Mechanisms: NO, NSEC2 and DNSNR 458 Long before NSEC was defined, the NO record was introduced. It was 459 the first record to use the idea of hashed owner names, to fix the 460 issue of zone walking that was present with the NXT record. It also 461 fixed the type bitmap issue of the NXT record, but not in a space 462 efficient way. At that time (around 2000) zone walking was not 463 considered important enough to warrant the new record. People were 464 also worried that DNSSEC deployment would be hindered by developing 465 an alternate means of denial of existence. Thus the effort was 466 shelved and NXT remained. 468 When the new DNSSEC specification [RFC4034] was written, people were 469 still not convinced that zone walking was a problem that should be 470 solved. So NSEC saw the light and inherited the two issues from NXT. 472 Several years after, NSEC2 was introduced as a way to solve the two 473 issues of NSEC. The NSEC2 draft contains the following paragraph: 475 "This document proposes an alternate scheme which hides owner 476 names while permitting authenticated denial of existence of non- 477 existent names. The scheme uses two new RR types: NSEC2 and 478 EXIST." 480 When an authenticated denial of existence scheme starts to talk about 481 EXIST records, it is worth paying extra attention. The EXIST record 482 was defined as a record without RDATA that would be used to signal 483 the presence of a domain name. From the draft: 485 "In order to prove the nonexistence of a record that might be 486 covered by a wildcard, it is necessary to prove the existence of 487 its closest encloser. This record does that. Its owner is the 488 closest encloser. It has no RDATA. If there is another RR that 489 proves the existence of the closest encloser, this SHOULD be used 490 instead of an EXIST record." 492 The introduction of this record led to questions on what wildcards 493 actually mean (especially in the context of DNSSEC). It is probably 494 not a coincidence that "The Role of Wildcards in the Domain Name 495 System" ([RFC4592]) was standardized before NSEC3 was. 497 NSEC2 solved the zone walking issue by hashing (with SHA1 and a salt) 498 the "next owner name" in the record, thereby making it useless for 499 zone walking. But it did not have Opt-Out. 501 The DNSNR record was another attempt that used hashed names to foil 502 zone walking and it also introduced the concept of opting out (called 503 "Authoritative Only Flag") which limited the use of DNSNR in 504 delegation-centric zones. 506 All these proposals didn't make it, but did provide valuable 507 insights. To summarize: 509 o The NO record introduced hashing, but this idea lingered in the 510 background for a long time; 512 o The NSEC2 record made it clear that wildcards were not completely 513 understood; 515 o The DNSNR record used a new flag field in the RDATA to signal Opt- 516 Out; 518 5. NSEC3 520 From the experience gained with NSEC2 and DNSNR, NSEC3 was forged. 521 It incorporates both Opt-Out and the hashing of names. NSEC3 solves 522 any issues people might have with NSEC, but it introduces some 523 additional complexity. 525 NSEC3 did not supersede NSEC, they are both defined for DNSSEC. So 526 DNSSEC is blessed with two different means to perform authenticated 527 denial of existence: NSEC and NSEC3. In NSEC3 every name is hashed, 528 including the owner name. This means that NSEC3 chain is sorted in 529 hash order, instead of canonical order. Because the owner names are 530 hashed, the next owner name for "example.org" is unlikely to be 531 "a.example.org". Because the next owner name is hashed, zone walking 532 becomes more difficult. 534 To make it even more difficult to retrieve the original names, the 535 hashing can be repeated several times each time taking the previous 536 hash as input. To prevent the reuse of pre-generated hash values 537 between zones a (per zone) salt can also be added. In the NSEC3 for 538 "example.org" we have hashed the names thrice ([RFC5155], Section 5) 539 and use the salt "DEAD". Lets look at typical NSEC3 record: 541 15bg9l6359f5ch23e34ddua6n1rihl9h.example.org. ( 542 NSEC3 1 0 2 DEAD A6EDKB6V8VL5OL8JNQQLT74QMJ7HEB84 543 NS SOA RRSIG DNSKEY NSEC3PARAM ) 545 On the first line we see the hashed owner name: 546 "15bg9l6359f5ch23e34ddua6n1rihl9h.example.org", this is the hashed 547 name of the fully qualified domain name (FQDN) "example.org" encoded 548 as Base32 ([RFC4648]). Note that even though we hashed 549 "example.org", the zone's name is added to make it look like a domain 550 name again. In our zone, the basic format is 551 "Base32(SHA1(FQDN)).example.org". The next hashed owner name 552 "A6EDKB6V8VL5OL8JNQQLT74QMJ7HEB84" (line 2) is the hashed version of 553 "d.example.org", represented as Base32. Note that "d.example.org" is 554 used are the next owner name, because in the hash ordering, its hash 555 comes after the hash of the zone's apex. Also note that 556 ".example.org" is not added to the next hashed owner name, as this 557 name always falls in the current zone. 559 The "1 0 2 DEAD" section of the NSEC3 states: 561 o Hash Algorithm = 1 (SHA1, this is the default, no other hash 562 algorithms are currently defined for use in NSEC3); 564 o Opt-Out = 0 (disabled); 565 o Hash Iterations = 2, this yields three iterations, as a zero value 566 is already one iteration; 568 o Salt = "DEAD". 570 At the end we see the type bitmap, which is identical to NSEC's 571 bitmap, that lists the types present at the original owner name. 572 Note that the type NSEC3 is absent from the list in the example 573 above. This is due to the fact that the original owner name 574 ("example.org") does not have the NSEC3 type. It only exists for the 575 hashed name. 577 Names like "1.h.example.org" hash to one label in NSEC3, 578 "1.h.example.org" becomes: 579 "117gercprcjgg8j04ev1ndrk8d1jt14k.example.org" when used as an owner 580 name. This is an important observation. By hashing the names you 581 lose the depth of a zone - hashing introduces a flat space of names, 582 as opposed to NSEC. 584 The name used above ("1.h.example.org") creates an empty non- 585 terminal. Empty non-terminals are domain names that have no RRs 586 associated with them, and exist only because they have one or more 587 sub-domains that do ([RFC5155], Section 1.3). The record: 589 1.h.example.org. TXT "1.h record" 591 creates two names: 593 1. "1.h.example.org" that has the type: TXT; 595 2. "h.example.org" which has no types. This is the empty non- 596 terminal. 598 An empty non-terminal will get an NSEC3 record, but not an NSEC 599 record. In Section 5.5 is shown how the resolver uses these NSEC3 600 records to validate the denial of existence proofs. 602 Note that NSEC3 might not always be useful. For example, highly 603 structures zones, like the reverse zones ip6.arpa and in-addr.arpa, 604 can be walked even with NSEC3 due to their structure. Also the names 605 in small, trivial zones can be easily guessed. In these cases, it 606 does not help to defend against zone walking, but does add the 607 computational load on authoritative servers and validators. 609 5.1. Opt-Out 611 Hashing mitigates the zone walking issue of NSEC. The other issue, 612 the high costs of securing a delegation to an insecure zone, is 613 tackled with Opt-Out. When using Opt-Out, names that are an insecure 614 delegation (and empty non-terminals that are only derived from 615 insecure delegations) don't require an NSEC3 record. For each 616 insecure delegation, the zone size can be decreased (compared with a 617 fully signed zone without using Opt-Out) with at least two records: 618 one NSEC3 record and one corresponding RRSIG record. If the insecure 619 delegation would introduce empty non-terminals, even more records can 620 be omitted from the zone. 622 Opt-Out NSEC3 records are not able to prove or deny the existence of 623 the insecure delegations. In other words, those delegation do not 624 benefit from the cryptographic security that DNSSEC provides. 626 A recently discovered corner case ([RFC5155-errata3441]) shows that 627 not only those delegations remain insecure, also the empty non- 628 terminal space that is derived from those delegations are insecure. 629 Because the names in this empty non-terminal space do exist according 630 to the definition in [RFC4592], the server should respond to queries 631 for these names with a NODATA response. However, the validator 632 requires an NSEC3 record proving the NODATA response ([RFC5155], 633 Section 8.5): 635 "The validator MUST verify that an NSEC3 RR that matches QNAME is 636 present and that both the QTYPE and the CNAME type are not set in 637 its Type Bit Maps field." 639 A way to resolve this contradiction in the specification is to always 640 provide empty non-terminals with an NSEC3 record, even if it is only 641 derived from an insecure delegation. 643 5.2. Loading an NSEC3 Zone 645 Whenever an authoritative server receives a query for a non-existing 646 record, it has to hash the incoming query name to determine into 647 which interval between two existing hashes it falls. To do that it 648 needs to know the zone's specific NSEC3 parameters (hash iterations 649 and salt). 651 One way to learn them is to scan the zone during loading for NSEC3 652 records and glean the NSEC3 parameters from them. However, it would 653 need to make sure that there is at least one complete set of NSEC3 654 records for the zone using the same parameters. Therefore, it would 655 need to inspect all NSEC3 records. 657 A more graceful solution was designed. The solution was to create a 658 new record, NSEC3PARAM, which must be placed at the apex of the zone. 659 Its role is to provide a fixed place where an authoritative name 660 server can directly see the NSEC3 parameters used, and by putting it 661 in the zone it allows for easy transfer to the secondaries. If NSEC3 662 were designed in the early days of DNS (+/- 1984) this information 663 would probably have been put in the SOA record. 665 5.3. Wildcards in the DNS 667 So far, we have only talked about denial of existence in negative 668 responses. However, denial of existence may also occur in positive 669 responses, i.e., where the ANSWER section of the response is not 670 empty. This can happen because of wildcards. 672 Wildcards have been part of the DNS since the first DNS RFCs. They 673 allow to define all names for a certain type in one go. In our 674 "example.org" zone we could for instance add a wildcard record: 676 *.example.org. TXT "wildcard record" 678 For completeness, our (unsigned) zone now looks like this: 680 example.org. SOA ( ... ) 681 example.org. NS a.example.org. 682 *.example.org. TXT "wildcard record" 683 a.example.org. A 192.0.2.1 684 TXT "a record" 685 d.example.org. A 192.0.2.1 686 TXT "d record" 688 Figure 4: The example.org zone with a wildcard record. 690 If a resolver asks for "z.example.org TXT", the name server will 691 respond with an expanded wildcard, instead of an NXDOMAIN: 693 ;; status: NOERROR, id: 13658 695 ;; ANSWER SECTION: 696 z.example.org. TXT "wildcard record" 698 Note however that the resolver can not detect that this answer came 699 from a wildcard. It just sees the answer as-is. How will this 700 answer look with DNSSEC? 702 ;; status: NOERROR, id: 51790 704 ;; ANSWER SECTION: 705 z.example.org. TXT "wildcard record" 706 z.example.org. RRSIG(TXT) ( ... ) 708 ;; AUTHORITY SECTION: 710 d.example.org. NSEC example.org. A TXT RRSIG NSEC 711 d.example.org. RRSIG(NSEC) ( ... ) 713 Figure 5: A response with an expanded wildcard and with DNSSEC. 715 The RRSIG of the "z.example.org" TXT record indicates there is a 716 wildcard configured. The RDATA of the signature lists a label count 717 [RFC4034], Section 3.1.3., of two (not visible in the answer above), 718 but the owner name of the signature has three labels. This mismatch 719 indicates there is a wildcard "*.example.org" configured. 721 An astute reader may notice that it appears as if a 722 "z.example.org" RRSIG(TXT) is created out of thin air. This is 723 not the case. The signature for "z.example.org" does not exist. 724 The signature you are seeing is the one for "*.example.org" which 725 does exist, only the owner name is switched to "z.example.org". 726 So even with wildcards, no signatures have to be created on the 727 fly. 729 The DNSSEC standard mandates that an NSEC (or NSEC3) is included in 730 such responses. If it wasn't, an attacker could mount a replay 731 attack and poison the cache with false data: Suppose that the 732 resolver has asked for "a.example.org TXT". An attacker could modify 733 the packet in such way that it looks like the response was generated 734 through wildcard expansion, even though there exists a record for 735 "a.example.org TXT". 737 The tweaking simply consists of adjusting the ANSWER section to: 739 ;; status: NOERROR, id: 31827 741 ;; ANSWER SECTION: 742 a.example.org. TXT "wildcard record" 743 a.example.org. RRSIG(TXT) ( ... ) 745 Figure 6: A forged response without the expanded wildcard. 747 Note the subtle difference from Figure 5 in the owner name. In this 748 response we see a "a.example.org TXT" record, for which a record with 749 different RDATA (See Figure 4) exist in the zone. 751 Which would be a perfectly valid answer if we would not require the 752 inclusion of an NSEC or NSEC3 record in the wildcard answer response. 753 The resolver believes that "a.example.org TXT" is a wildcard record, 754 and the real record is obscured. This is bad and defeats all the 755 security DNSSEC can deliver. Because of this, the NSEC or NSEC3 must 756 be present. 758 Another way of putting this is that DNSSEC is there to ensure the 759 name server has followed the steps as outlined in [RFC1034], 760 Section 4.3.2 for looking up names in the zone. It explicitly lists 761 wildcard look up as one of these steps (3c), so with DNSSEC this must 762 be communicated to the resolver: hence the NSEC(3) record. 764 5.4. CNAME Records 766 So far, the maximum number of NSEC records a response will have is 767 two: one for the denial of existence and another for the wildcard. 768 We say maximum, because sometimes a single NSEC can prove both. With 769 NSEC3, this is three (as to why, we will explain in the next 770 section). 772 When we take CNAME wildcard records into account, we can have more 773 NSEC(3) records. For every wildcard expansion, we need to prove that 774 the expansion was allowed. Lets add some CNAME wildcard records to 775 our zone: 777 example.org. SOA ( ... ) 778 example.org. NS a.example.org. 779 *.example.org. TXT "wildcard record" 780 a.example.org. A 192.0.2.1 781 TXT "a record" 782 *.a.example.org. CNAME w.b 783 *.b.example.org. CNAME w.c 784 *.c.example.org. A 192.0.2.1 785 d.example.org. A 192.0.2.1 786 TXT "d record" 787 w.example.org. CNAME w.a 789 Figure 7: A wildcard CNAME chain added to the "example.org" zone. 791 A query for "w.example.org A" will result in the following response: 793 ;; status: NOERROR, id: 4307 795 ;; ANSWER SECTION: 796 w.example.org. CNAME w.a.example.org. 797 w.example.org. RRSIG(CNAME) ( ... ) 798 w.a.example.org. CNAME w.b.example.org. 799 w.a.example.org. RRSIG(CNAME) ( ... ) 800 w.b.example.org. CNAME w.c.example.org. 801 w.b.example.org. RRSIG(CNAME) ( ... ) 802 w.c.example.org. A 192.0.2.1 803 w.c.example.org. RRSIG(A) ( ... ) 805 ;; AUTHORITY SECTION: 807 *.a.example.org. NSEC *.b.example.org. CNAME RRSIG NSEC 808 *.a.example.org. RRSIG(NSEC) ( ... ) 809 *.b.example.org. NSEC *.c.example.org. CNAME RRSIG NSEC 810 *.b.example.org. RRSIG(NSEC) ( ... ) 811 *.c.example.org. NSEC d.example.org. A RRSIG NSEC 812 *.c.example.org. RRSIG(NSEC) ( ... ) 814 The NSEC record "*.a.example.org" proves that wildcard expansion to 815 "w.a.example.org" was appropriate: "w.a." falls in the gap "*.a" to 816 "*.b". Similar, the NSEC record "*.b.example.org" proves that there 817 was no direct match for "w.b.example.org" and "*.c.example.org" 818 denies the direct match for "w.c.example.org". 820 DNAME records and wildcard names should not be used as reiterated in 821 [RFC6672] Section 3.3. 823 5.5. The Closest Encloser NSEC3 Record 825 We can have one or more NSEC3 records that deny the existence of the 826 requested name and one NSEC3 record that deny wildcard synthesis. 827 What do we miss? 829 The short answer is that, due to the hashing in NSEC3 you loose the 830 depth of your zone: Everything is hashed into a flat plane. To make 831 up for this loss of information you need an extra record. 833 To understand NSEC3, we will need two definitions: 835 Closest encloser: Introduced in [RFC4592], "The closest encloser is 836 the node in the zone's tree of existing domain names that has the 837 most labels matching the query name (consecutively, counting from 838 the root label downward)." In our example, if the query name is 839 "x.2.example.org" then "example.org" is the "closest encloser"; 841 Next closer name: Introduced in the NSEC3 RFC, this is the closest 842 encloser with one more label added to the left. So if 843 "example.org" is the closest encloser for the query name 844 "x.2.example.org", "2.example.org" is the "next closer name". 846 An NSEC3 "closest encloser proof" consists of: 848 1. An NSEC3 record that *matches* the "closest encloser". This 849 means the unhashed owner name of the record is the closest 850 encloser. This bit of information tells a resolver: "The name 851 you are asking for does not exist, the closest I have is this". 853 2. An NSEC3 record that *covers* the "next closer name". This means 854 it defines an interval in which the "next closer name" falls. 856 This tells the resolver: "The next closer name falls in this 857 interval, and therefore the name in your question does not exist. 858 In fact, the closest encloser is indeed the closest I have". 860 These two records already deny the existence of the requested name, 861 so we do not need an NSEC3 record that covers the actual queried 862 name: By denying the existence of the next closer name, you also deny 863 the existence of the queried name. 865 Note that with NSEC, the existence of all empty non-terminals between 866 the two names are denied, hence implicitly contains the closest 867 encloser. 869 For a given query name, there is one (and only one) place where 870 wildcard expansion is possible. This is the "source of synthesis", 871 and is defined ([RFC4592], Section 2.1.1 and Section 3.3.1) as: 873 . 875 In other words, to deny wildcard synthesis, the resolver needs to 876 know the hash of the source of synthesis. Since it does not know 877 beforehand what the closest encloser of the query name is, it must be 878 provided in the answer. 880 Take the following example. We take our zone, and put two TXT 881 records to it. The records added are "1.h.example.org" and 882 "3.3.example.org". It is signed with NSEC3, resulting in the 883 following unsigned zone. 885 example.org. SOA ( ... ) 886 example.org. NS a.example.org. 887 1.h.example.org. TXT "1.h record" 888 3.3.example.org. TXT "3.3 record" 890 Figure 8: The added TXT records in example.org. These records create 891 two empty non-terminals: h.example.org and 3.example.org. 893 The resolver asks the following: "x.2.example.org TXT". This leads 894 to an NXDOMAIN response from the server, which contains three NSEC3 895 records. A list of hashed owner names can be found in Appendix B. 896 Also see Figure 9 the numbers in that figure correspond with the 897 following NSEC3 records: 899 15bg9l6359f5ch23e34ddua6n1rihl9h.example.org. ( 900 NSEC3 1 0 2 DEAD 1AVVQN74SG75UKFVF25DGCETHGQ638EK NS SOA RRSIG 901 DNSKEY NSEC3PARAM ) 903 1avvqn74sg75ukfvf25dgcethgq638ek.example.org. ( 904 NSEC3 1 0 2 DEAD 75B9ID679QQOV6LDFHD8OCSHSSSB6JVQ ) 906 75b9id679qqov6ldfhd8ocshsssb6jvq.example.org. ( 907 NSEC3 1 0 2 DEAD 8555T7QEGAU7PJTKSNBCHG4TD2M0JNPJ TXT RRSIG ) 909 If we would follow the NSEC approach, the resolver is only interested 910 in one thing. Does the hash of "x.2.example.org" fall in any of the 911 intervals of the NSEC3 records it got? 913 example.org 914 ** 915 +-- ** . . . . . . . . . . . 916 (1) / . ^ . . 917 / . | . . 918 | . | . . 919 v . | . . 920 ** | ** ++ 921 h.example.org ** ----+----> ** 3.example.org ++ 2.example.org 922 . / (2) . | . 923 . / . | (3) . 924 . / (5) . | . 925 . / . v . 926 1.h.example.org ** ** ++ 927 ** <--------- ** 3.3.example.org ++ x.2.example.org 928 (4) 930 Figure 9: x.2.example.org does not exist. The five arrows represent 931 the NSEC3 records, the ones numbered (1), (2) and (3) are the NSEC3s 932 returned in our answer. 2.example.org is covered by (3) and 933 x.2.example.org is covered by (4). 935 The hash of "x.2.example.org" is "ndtu6dste50pr4a1f2qvr1v31g00i2i1". 936 Checking this hash on the first NSEC3 yields that it does not fall in 937 between the interval: "15bg9l6359f5ch23e34ddua6n1rihl9h" and 938 "1avvqn74sg75ukfvf25dgcethgq638ek". For the second NSEC3 the answer 939 is also negative: the hash sorts outside the interval described by 940 "1avvqn74sg75ukfvf25dgcethgq638ek" and 941 "75b9id679qqov6ldfhd8ocshsssb6jvq". And the third NSEC3, with 942 interval "75b9id679qqov6ldfhd8ocshsssb6jvq" to 943 "8555t7qegau7pjtksnbchg4td2m0jnpj" also isn't of any help. 945 What is a resolver to do? It has been given the maximum amount of 946 NSEC3s and they all seem useless. 948 So this is where the closest encloser proof comes into play. And for 949 the proof to work, the resolver needs to know what the closest 950 encloser is. There must be an existing ancestor in the zone: a name 951 must exist that is shorter than the query name. The resolver keeps 952 hashing increasingly shorter names from the query name until an owner 953 name of an NSEC3 matches. This owner name is the closest encloser. 955 When the resolver has found the closest encloser, the next step is to 956 construct the next closer name. This is the closest encloser with 957 the last chopped label from query name pre-pended to it: ".". The hash of this name should be 959 covered by the interval set in any of the NSEC3 records. 961 Then the resolver needs to check the presence of a wildcard. It 962 creates the wildcard name by pre-pending the asterisk label to the 963 closest encloser: "*.", and uses the hash of that. 965 Going back to our example, the resolver must first detect the NSEC3 966 that matches the closest encloser. It does this by chopping up the 967 query name, hashing each instance (with the same number of iterations 968 and hash as the zone it is querying) and comparing that to the 969 answers given. So it has the following hashes to work with: 971 x.2.example.org: "ndtu6dste50pr4a1f2qvr1v31g00i2i1", last chopped 972 label: ""; 974 2.example.org: "7t70drg4ekc28v93q7gnbleopa7vlp6q", last chopped 975 label: "x"; 977 example.org: "15bg9l6359f5ch23e34ddua6n1rihl9h", last chopped label: 978 "2"; 980 Of these hashes only one matches the owner name of one of the NSEC3 981 records: "15bg9l6359f5ch23e34ddua6n1rihl9h". This must be the 982 closest encloser (unhashed: "example.org"). That's the main purpose 983 of that NSEC3 record: tell the resolver what the closest encloser is. 985 When using Opt-Out, it is possible that the actual closest encloser 986 to the QNAME does not have an NSEC3 record. If so, we will have to 987 do with the closest provable encloser, which is the closest enclosing 988 authoritative name that does have a NSEC3 record. In the worst case, 989 this is the NSEC3 record corresponding to the apex, this name must 990 always have an NSEC3 record. 992 With the closest (provable) encloser, the resolver constructs the 993 next closer, which in this case is: "2.example.org"; "2" is the last 994 label chopped, when "example.org" is the closest encloser. The hash 995 of this name should be covered in any of the other NSEC3s. And it is, 996 "7t70drg4ekc28v93q7gnbleopa7vlp6q" falls in the interval set by: 997 "75b9id679qqov6ldfhd8ocshsssb6jvq" and 998 "8555t7qegau7pjtksnbchg4td2m0jnpj" (this is our second NSEC3). 1000 So what does the resolver learn from this? 1002 o "example.org" exists; 1004 o "2.example.org" does not exist. 1006 And if "2.example.org" does not exist, there is also no direct match 1007 for "x.2.example.org". The last step is to deny the existence of the 1008 source of synthesis, to prove that no wildcard expansion was 1009 possible. 1011 The resolver hashes "*.example.org" to 1012 "22670trplhsr72pqqmedltg1kdqeolb7" and checks that it is covered: in 1013 this case by the last NSEC3 (see Figure 9), the hash falls in the 1014 interval set by "1avvqn74sg75ukfvf25dgcethgq638ek" and 1015 "75b9id679qqov6ldfhd8ocshsssb6jvq". This means there is no wildcard 1016 record directly below the closest encloser and "x.2.example.org" 1017 definitely does not exist. 1019 When we have validated the signatures, we reached our goal: 1020 authenticated denial of existence. 1022 5.6. Three To Tango 1024 One extra NSEC3 record plus additional signature may seem a lot just 1025 to deny the existence of the wildcard record, but we cannot leave it 1026 out. If the standard would not mandate the closest encloser NSEC3 1027 record, but instead required two NSEC3 records: one to deny the query 1028 name and one to deny the wildcard record. An attacker could fool the 1029 resolver that the source of synthesis does not exist, while it in 1030 fact does. 1032 Suppose the wildcard record does exist, so our unsigned zone looks 1033 like this: 1035 example.org. SOA ( ... ) 1036 example.org. NS a.example.org. 1037 *.example.org. TXT "wildcard record" 1038 1.h.example.org. TXT "1.h record" 1039 3.3.example.org. TXT "3.3 record" 1041 The query "x.2.example.org TXT" should now be answered with: 1043 x.2.example.org. TXT "wildcard record" 1045 An attacker can deny this wildcard expansion by calculating the hash 1046 for the wildcard name "*.2.example.org" and searching for an NSEC3 1047 record that covers that hash. The hash of "*.2.example.org" is 1048 "fbq73bfkjlrkdoqs27k5qf81aqqd7hho". Looking through the NSEC3 1049 records in our zone we see that the NSEC3 record of "3.3" covers this 1050 hash: 1052 8555t7qegau7pjtksnbchg4td2m0jnpj.example.org. ( 1053 NSEC3 1 0 2 DEAD 15BG9L6359F5CH23E34DDUA6N1RIHL9H TXT RRSIG ) 1055 This record also covers the query name "x.2.example.org" 1056 ("ndtu6dste50pr4a1f2qvr1v31g00i2i1"). 1058 Now an attacker adds this NSEC3 record to the AUTHORITY section of 1059 the reply to deny both "x.2.example.org" and any wildcard expansion. 1060 The net result is that the resolver determines that "x.2.example.org" 1061 does not exist, while in fact it should have been synthesized via 1062 wildcard expansion. With the NSEC3 matching the closest encloser 1063 "example.org", the resolver can be sure that the wildcard expansion 1064 should occur at "*.example.org" and nowhere else. 1066 Coming back to the original question: why do we need up to three 1067 NSEC3 records to deny a requested name? The resolver needs to be 1068 explicitly told what the "closest encloser" is and this takes up a 1069 full NSEC3 record. Then, the next closer name needs to be covered in 1070 an NSEC3 record, and finally an NSEC3 must say something about 1071 whether wildcard expansion was possible. That makes three to tango. 1073 6. Security Considerations 1075 DNSSEC does not protect against denial of service attacks, nor does 1076 it provide confidentiality. For more general security considerations 1077 related to DNSSEC, please see RFC 4033, RFC 4034, RFC 4035 and RFC 1078 5155 ([RFC4033], [RFC4034], [RFC4035] and [RFC5155]). 1080 These RFCs are concise about why certain design choices have been 1081 made in the area of authenticated denial of existence. 1082 Implementations that do not correctly handle this aspect of DNSSEC, 1083 create a severe hole in the security DNSSEC adds. This is 1084 specifically troublesome for secure delegations: If an attacker is 1085 able to deny the existence of a DS record, the resolver cannot 1086 establish a chain of trust, and the resolver has to fall back to 1087 insecure DNS for the remainder of the query resolution. 1089 This document aims to fill this "documentation gap" and provide 1090 would-be implementors and other interested parties with enough 1091 background knowledge to better understand authenticated denial of 1092 existence. 1094 7. IANA Considerations 1095 This document has no actions for IANA. 1097 8. Acknowledgments 1099 This document would not be possible without the help of Ed Lewis, Roy 1100 Arends, Wouter Wijngaards, Olaf Kolkman, Carsten Strotmann, Jan-Piet 1101 Mens, Peter van Dijk, Marco Davids, Esther Makaay, Antoin Verschuren, 1102 Lukas Wunner, Joe Abley, Ralf Weber, Geoff Huston, Dave Lawrence, 1103 Tony Finch and Mark Andrews. Also valuable was the source code of 1104 Unbound. ("validator/val_nsec3.c") [Unbound]. 1106 Extensive feedback for early versions was received from Karst 1107 Koymans. 1109 9. References 1111 9.1. Normative References 1113 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1114 STD 13, RFC 1034, November 1987. 1116 [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security 1117 Extensions", RFC 2065, January 1997. 1119 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1120 NCACHE)", RFC 2308, March 1998. 1122 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1123 Rose, "DNS Security Introduction and Requirements", RFC 1124 4033, March 2005. 1126 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1127 Rose, "Resource Records for the DNS Security Extensions", 1128 RFC 4034, March 2005. 1130 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1131 Rose, "Protocol Modifications for the DNS Security 1132 Extensions", RFC 4035, March 2005. 1134 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 1135 System", RFC 4592, July 2006. 1137 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1138 Encodings", RFC 4648, October 2006. 1140 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1141 Security (DNSSEC) Hashed Authenticated Denial of 1142 Existence", RFC 5155, March 2008. 1144 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 1145 DNS", RFC 6672, June 2012. 1147 9.2. Informative References 1149 [I-D.arends-dnsnr] 1150 Arends, R., "DNSSEC Non-Repudiation Resource Record", 1151 draft-arends-dnsnr-00 (work in progress), July 2004. 1153 [I-D.ietf-dnsext-not-existing-rr] 1154 Josefsson, S., "Authenticating denial of existence in DNS 1155 with minimum disclosure", draft-ietf-dnsext-not-existing- 1156 rr-01 (work in progress), November 2000. 1158 [I-D.laurie-dnsext-nsec2v2] 1159 Laurie, B., "DNSSEC NSEC2 Owner and RDATA Format", draft- 1160 laurie-dnsext-nsec2v2-00 (work in progress), December 1161 2004. 1163 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 1164 RFC 2535, March 1999. 1166 [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS 1167 Authenticated Data (AD) bit", RFC 3655, November 2003. 1169 [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation 1170 Signer (DS)", RFC 3755, May 2004. 1172 [RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records 1173 and DNSSEC On-line Signing", RFC 4470, April 2006. 1175 [RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS Security 1176 (DNSSEC) Opt-In", RFC 4956, July 2007. 1178 [RFC5155-errata3441] 1179 Lewis, E., "Technical Errata against RFC 5155 (not 1180 acknowledged)", January 2013. 1182 [Unbound] NLnet Labs, "Unbound: a validating, recursive, and caching 1183 DNS resolver", 2006, . 1185 [phreebird] 1186 Kaminsky, D., "Phreebird: a DNSSEC proxy", January 2011, 1187 . 1189 Appendix A. DNSSEC On-line Signing 1190 A.1. Minimally Covering NSEC Records 1192 An NSEC record lists the next existing name in a zone, and thus makes 1193 it possible to retrieve all the names from the zone. This can also 1194 be done with NSEC3, but an adversary will then retrieve all the names 1195 in hashed format. With DNSSEC on-line signing, zone walking can be 1196 prevented by faking the next owner name. 1198 To prevent retrieval of the next owner name with NSEC, a different, 1199 non-existing (according to the existence rules in []#RFC4592, 1200 Section 2.2) name is used. However, not just any name can be used 1201 because a validator may make assumptions on the size of the span the 1202 NSEC record covers. The span must be large enough to cover the 1203 QNAME, but not too large that it covers existing names. 1205 [RFC4470] introduces a scheme for generating minimally covering NSEC 1206 records. These records use a next owner name that is lexically 1207 closer to the NSEC owner name than the actual next owner name, 1208 ensuring that no existing names are covered. The next owner name can 1209 be derived from the QNAME with the use of so-called epsilon 1210 functions. 1212 For example, to deny the existence of "b.example.org" in the zone 1213 from Section 3.2, the following NSEC record could have been 1214 generated: 1216 a.example.org. NSEC c.example.org. RRSIG NSEC 1218 This record also proves that "b.example.org" also does not exist, but 1219 an adversary _cannot_ use the next owner name in a zone walking 1220 attack. Note the type bitmap only has the RRSIG and NSEC set, 1221 because [RFC4470] states: 1223 The generated NSEC record's type bitmap MUST have the RRSIG and 1224 NSEC bits set and SHOULD NOT have any other bits set. 1226 This is because the NSEC records may appear at names that did not 1227 exist before the zone was signed. In this case however, 1228 "a.example.org" exists with other RR types and we could have also set 1229 the A and TXT types in the bitmap. 1231 Because DNS ordering is very strict, the span should be shortened to 1232 a minimum. In order to do so, the last character in the leftmost 1233 label of the NSEC owner name needs to be decremented and the label 1234 must be filled with octets of value 255 until the label length 1235 reaches the maximum of 63 octets. The next owner name is the QNAME 1236 with a leading label with a single null octet added. This gives the 1237 following minimally covering record for "b.example.org": 1239 a\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 1240 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 1241 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 1242 \255\255\255\255\255\255\255\255\255\255\255.example.org. ( 1243 NSEC \000.b.example.org. RRSIG NSEC ) 1245 A.2. NSEC3 White Lies 1247 The same principle of minimally covering spans can be applied to 1248 NSEC3 records. This mechanism has been dubbed "NSEC3 White Lies" 1249 when it was implemented in Phreebird [phreebird]. Here, the NSEC3 1250 owner name is the hash of the QNAME minus one and the next owner name 1251 is the hash of the QNAME plus one. 1253 The following NSEC3 white lie denies "b.example.org" (recall this 1254 hashes to "iuu8l5lmt76jeltp0bir3tmg4u3uu8e7"): 1256 iuu8l5lmt76jeltp0bir3tmg4u3uu8e6.example.org. ( 1257 NSEC3 1 0 2 DEAD IUU815LMT76JELTP0BIR3TMG4U3UU8E8 ) 1259 The type bitmap is empty in this case. If the hash of 1260 "b.example.org" - 1 is a collision with an existing name, the bitmap 1261 should have been filled with the RR types that exist at that name. 1262 This record actually denies the existence of the next closer of the 1263 closest encloser of "b.example.org" (which is conveniently 1264 "b.example.org"). Of course the NSEC3 records to match the closest 1265 encloser and to cover the source of synthesis are still required. 1266 These can be generated too: 1268 # Matching `example.org`: `15bg9l6359f5ch23e34ddua6n1rihl9h` 1269 15bg9l6359f5ch23e34ddua6n1rihl9h.example.org. ( 1270 NSEC3 1 0 2 DEAD 1AVVQN74SG75UKFVF25DGCETHGQ638EK NS SOA RRSIG 1271 DNSKEY NSEC3PARAM ) 1273 # Covering `*.example.org`: `22670trplhsr72pqqmedltg1kdqeolb7` 1274 22670trplhsr72pqqmedltg1kdqeolb6.example.org.( 1275 NSEC3 1 0 2 DEAD 22670TRPLHSR72PQQMEDLTG1KDQEOLB8 ) 1277 Appendix B. List of Hashed Owner Names 1279 The following owner names are used in this document. The origin for 1280 these names is "example.org". 1282 +----------------+-------------------------------------+ 1283 | Original Name | Hashed Name | 1284 +----------------+-------------------------------------+ 1285 | "a" | "04sknapca5al7qos3km2l9tl3p5okq4c" | 1286 | "1.h" | "117gercprcjgg8j04ev1ndrk8d1jt14k" | 1287 | "@" | "15bg9l6359f5ch23e34ddua6n1rihl9h" | 1288 | "h" | "1avvqn74sg75ukfvf25dgcethgq638ek" | 1289 | "*" | "22670trplhsr72pqqmedltg1kdqeolb7" | 1290 | "3" | "75b9id679qqov6ldfhd8ocshsssb6jvq" | 1291 | "2" | "7t70drg4ekc28v93q7gnbleopa7vlp6q" | 1292 | "3.3" | "8555t7qegau7pjtksnbchg4td2m0jnpj" | 1293 | "d" | "a6edkb6v8vl5ol8jnqqlt74qmj7heb84" | 1294 | "*.2" | "fbq73bfkjlrkdoqs27k5qf81aqqd7hho" | 1295 | "b" | "iuu8l5lmt76jeltp0bir3tmg4u3uu8e7" | 1296 | "x.2" | "ndtu6dste50pr4a1f2qvr1v31g00i2i1" | 1297 +----------------+-------------------------------------+ 1299 Table 1: Hashed owner names for "example.org" in hash order. 1301 Appendix C. Changelog 1303 [This section should be removed by the RFC editor before publishing] 1305 C.1. -00 1307 1. Initial document. 1309 C.2. -01 1311 1. Style and language changes; 1313 2. Figure captions; 1315 3. Security considerations added; 1317 4. Fix erroneous NSEC3 RR; 1319 5. Section on CNAMEs added; 1321 6. More detailed text on closest encloser proof. 1323 C.3. -02 1325 1. Lowercase NSEC3 hashed ownernames and add reference to Base32; 1327 2. Process the comments from Joe Abley and Geoff Huston. 1329 * Added section about Opt-Out; 1331 * Move experimental records in their own section; 1333 * Added DNAME reference with respect to wildcards; 1334 * Clarify the difference between the wildcard answers; 1336 * Add more context about the NO record; 1338 * Elaborate more about the EXIST records and its problems; 1340 * Added more text about the NSEC3PARAM records; 1342 * Apply assorted fixes throughout the document; 1344 * Moved table with hashed owner names to appendix. 1346 C.4. -03 1348 1. Changed affiliation for R. Gieben; 1350 2. Some minor updates. 1352 C.5. -04 1354 1. Added NS record in all zone examples; 1356 2. Some tweaks in the text regarding on-line signing; 1358 3. Add more text on a non-working "generic non-existence records". 1360 4. Add appendix on on-line signing; 1362 5. Add appendix on usefulness of NSEC3. 1364 Authors' Addresses 1366 R. (Miek) Gieben 1367 Google 1369 EMail: miek@google.com 1371 W. (Matthijs) Mekking 1372 NLnet Labs 1373 Science Park 400 1374 Amsterdam 1098 XH 1375 NL 1377 EMail: matthijs@nlnetlabs.nl 1378 URI: http://www.nlnetlabs.nl/