idnits 2.17.1 draft-gieben-auth-denial-of-existence-dns-00.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? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Aug 2012) is 4270 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 748 -- Looks like a reference, but probably isn't: '3' on line 748 -- Looks like a reference, but probably isn't: '2' on line 748 -- 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) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Gieben 3 Internet-Draft SIDN Labs 4 Intended status: Informational W. Mekking 5 Expires: February 2, 2013 NLnet Labs 6 Aug 2012 8 Authenticated Denial of Existence in the DNS 9 draft-gieben-auth-denial-of-existence-dns-00 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. This document attempts to answer two simple questions. 18 When returning a negative DNSSEC response, a name server sometimes 19 includes up to two NSEC records. With NSEC3 the maximum amount is 20 three. 22 o Why do you need up to two NSEC records? 24 o And why does NSEC3 sometimes require an extra record? 26 The answer to the questions hinges on the concept of wildcards and 27 the "closest encloser". With NSEC, the name that is the "closest 28 encloser" is implicitly given in the record that also denies the 29 existence of the domain name. With NSEC3, due to its hashing, this 30 information has to be given explicitly to a resolver. It needs one 31 record to tell the resolver the closest encloser and then another to 32 deny the existence of the domain name. Both NSEC and NSEC3 may need 33 yet another record to deny or assert a wildcard presence. This 34 results in a maximum of two NSEC and three NSEC3 records, 35 respectively. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on February 2, 2013. 54 Copyright Notice 56 Copyright (c) 2012 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Denial of Existence . . . . . . . . . . . . . . . . . . . . . 4 71 2.1. NXDOMAIN . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2.2. NODATA . . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3. Secure Denial of Existence . . . . . . . . . . . . . . . . . . 5 75 3.1. NXT . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 3.2. NSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 3.3. NODATA Responses . . . . . . . . . . . . . . . . . . . . . 8 78 3.4. NO, NSEC2 and DNSNR . . . . . . . . . . . . . . . . . . . 10 79 3.5. NSEC3 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 3.6. Slaving an NSEC3 Zone . . . . . . . . . . . . . . . . . . 12 81 3.7. Wildcards in the DNS . . . . . . . . . . . . . . . . . . . 12 82 3.8. Returning Three NSEC3s . . . . . . . . . . . . . . . . . . 15 84 4. List of Hashed Owner Names . . . . . . . . . . . . . . . . . . 19 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 90 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 92 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 94 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 96 1. Introduction 98 DNSSEC can be somewhat of a complicated matter, and there are certain 99 areas of the specification that are more difficult to comprehend than 100 others. One such area is "authenticated denial of existence". 102 Authenticated denial of existence allows a DNSSEC enabled resolver to 103 validate that a certain domain name does not exist. It is also used 104 to signal that a domain name exists, but does not have the specific 105 RR type you were asking for. 107 The first is referred to as an NXDOMAIN [RFC2308] (non-existent 108 domain) and the latter a NODATA [RFC2308] response. 110 In this document we will explain how authenticated denial of 111 existence works. We begin by explaining the current technique in the 112 DNS and work our way up to DNSSEC. We explain the first steps taken 113 in DNSSEC and describe how NXT, NSEC and NSEC3 work. NO, NSEC2 and 114 DNSNR also briefly make their appearance, as they have paved the way 115 for NSEC3. 117 To complete the picture we also need to explain DNS wildcards as it 118 complicates matters. 120 Note: In this document domain names in zone file examples will have a 121 trailing dot, in the running text they will not. This text is 122 written for people who have a fair understanding of DNSSEC. This 123 document does not explain NSEC3 opt-out and secure delegations. 125 The following RFCs are not required reading, but they might help in 126 understanding the problem space. 128 o RFC 5155 [RFC5155] - Hashed Authenticated Denial of Existence; 130 o RFC 4592 [RFC4592] - The Role of Wildcards in the DNS. 132 And these provide some general DNSSEC information. 134 o RFC 4033, RFC 4034, RFC 4035 [RFC4033], [RFC4034], [RFC4035] - 135 DNSSEC Spec; 137 o RFC 4956 [RFC4956] - DNS Security (DNSSEC) Opt-In. This RFC has 138 the status experimental, but is a good read. 140 And these three drafts give some background information on the NSEC3 141 development. 143 o The NO RR [I-D.ietf-dnsext-not-existing-rr]; 145 o The NSEC2 RR [I-D.laurie-dnsext-nsec2v2]; 147 o The DNSNR RR [I-D.arends-dnsnr]. 149 2. Denial of Existence 151 We start with the basics and take a look at NXDOMAIN handling in the 152 DNS. To make it more visible we are going to use a small DNS zone, 153 with 3 names ("example.org", "a.example.org" and "d.example.org") and 154 3 types (SOA, A and TXT). For brevity the class is not shown 155 (defaults to IN), the NS records are left out and the SOA and RRSIG 156 records are shortened. Resulting in the following unsigned zone 157 file: 159 example.org. SOA ( ... ) 160 a.example.org. A 192.0.2.1 161 TXT "a record" 162 d.example.org. A 192.0.2.1 163 TXT "d record" 165 2.1. NXDOMAIN 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 information of the 186 name servers that have information concerning the "example.org" 187 domain. 189 If a resolver now 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 to 198 NXDOMAIN. From this the resolver concludes "b.example.org" does not 199 exist. 201 2.2. NODATA 203 It is important to realize, that NXDOMAIN is not the only type of 204 does-not-exist. A name may exist, but the type you are asking for 205 may not. This occurrence of non-existence is called a NODATA 206 [RFC2308] response. Let us ask our name server for "a.example.org 207 AAAA", and look at the answer: 209 ;; status: NOERROR, id: 7944 211 ;; AUTHORITY SECTION: 212 example.org. SOA ( ... ) 214 The status is NOERROR meaning that the "a.example.org" name exists. 215 But the reply does not contain an ANSWER section. Instead it has an 216 AUTHORITY section which holds the SOA record of "example.org". The 217 resolver has to put these pieces of information together and conclude 218 that "a.example.org" exists, but it does not have an "AAAA" record. 220 3. Secure Denial of Existence 222 The above has to be translated to the security aware world of DNSSEC. 223 But there are a few requirements DNSSEC brings to the table: 225 1. There is no online signing defined in DNSSEC. Although a name 226 server is free to compute the answer and signature(s) on-the-fly, 227 the protocol is written with a "first sign", "then load" attitude 228 in mind. It is rather asymmetrical, but a lot of the design in 229 DNSSEC stems from fact that you need to accommodate authenticated 230 denial of existence. If the DNS didn't have NXDOMAIN, DNSSEC 231 would be a lot simpler, but a lot less useful! 233 2. The DNS packet header is not signed. This means that a "status: 234 NXDOMAIN" can not be trusted. In fact the entire header may be 235 forged, including the AD bit (AD stands for Authenticated Data, 236 see RFC 3655 [RFC3655]), which may give some food for thought; 238 3. DNS wildcards complicate matters significantly. More about this 239 in later sections. 241 The first requirement implies that all denial of existence answers 242 need to be pre-computed, but it is impossible to precompute (all 243 conceivable) non-existence answers. In the example above, you need a 244 way to tell somebody who is asking for "b.example.org" that it does 245 not exists without using the name "b.example.org" in the answer. 246 This has been solved by introducing a record that defines an interval 247 between two existing names. Or to put it another way: it defines the 248 holes (non-existing names) in the zone. This record can be signed 249 beforehand and given to the resolver. 251 Given all these troubles, why didn't the designers of DNSSEC go 252 for the (easy) route and allowed for online signing? Well, at the 253 time (pre 2000), online signing was not feasible with the current 254 hardware. Keep in mind that the larger servers get between 2000 255 and 6000 queries per second (qps), with peaks up to 20,000 qps or 256 more. Scaling signature generation to these kind of levels is 257 always a challenge. Another issue was (and is) key management, 258 for online signing to work you need access to the private key(s). 259 This is considered a security risk. 261 The road to the current solution (NSEC/NSEC3) was long. It started 262 with the NXT (next) record. The NO (not existing) record was 263 introduced, but never made it to RFC. Later NXT was superseded by 264 NSEC (next secure) record. From there it went through NSEC2/DNSNR to 265 finally reach NSEC3 (next secure, version 3) in RFC 5155. 267 3.1. NXT 269 The first attempt to specify authenticated denial of existence was 270 NXT (RFC 2535 [RFC2535]). Section 5.1 of that RFC introduces the 271 record: 273 The NXT resource record is used to securely indicate that RRs with 274 an owner name in a certain name interval do not exist in a zone 275 and to indicate what RR types are present for an existing name. 277 By specifying what you do have, you implicitly tell what you don't 278 have. NXT is superseded by NSEC. In the next section we explain how 279 NSEC (and thus NXT) works. 281 3.2. NSEC 283 In RFC 3755 [RFC3755] all the DNSSEC types were given new names, SIG 284 was renamed RRSIG, KEY became DNSKEY and NXT was simply renamed to 285 NSEC and a few, minor issues were fixed in the process. 287 Just as NXT, NSEC is used to describe an interval between names: it 288 indirectly tells a resolver which names do not exist in a zone. 290 For this to work, we need our "example.org" zone to be sorted in 291 canonical ordering ([RFC4034], Section 6.1), and then create the 292 NSECs. We add three NSEC records, one for each name, and each one 293 "covers" a certain interval. The last NSEC record points back to the 294 first as required by the RFC. Also see Figure 1. 296 1. The first NSEC covers the interval between "example.org" and 297 "a.example.org"; 299 2. The second NSEC covers: "a.example.org" to "d.example.org"; 301 3. The third NSEC points back to "example.org", and covers 302 "d.example.org" to "example.org" (i.e. the end of the zone). 304 As we have defined the intervals and put those in resource records, 305 we now have something that can be signed. 307 example.org 308 ** 309 +-- ** <--+ 310 / . . \ 311 / . . \ 312 | . . | 313 v . . | 314 ** ** 315 a.example.org ** ---------> ** d.example.org 317 The NSEC records of example.org. The arrows represent NSEC records, 318 starting from the apex. 320 Figure 1 322 This signed zone is loaded into the name server. It looks like this: 324 example.org. SOA ( ... ) 325 DNSKEY ( ... ) 326 NSEC a.example.org. SOA NSEC DNSKEY RRSIG 327 RRSIG(SOA) ( ... ) 328 RRSIG(DNSKEY) ( ... ) 329 RRSIG(NSEC) ( ... ) 330 a.example.org. A 192.0.2.1 331 TXT "a record" 332 NSEC d.example.org. A TXT NSEC RRSIG 333 RRSIG(A) ( ... ) 334 RRSIG(TXT) ( ... ) 335 RRSIG(NSEC) ( ... ) 336 d.example.org. A 192.0.2.1 337 TXT "d record" 338 NSEC example.org. A TXT NSEC RRSIG 339 RRSIG(A) ( ... ) 340 RRSIG(TXT) ( ... ) 341 RRSIG(NSEC) ( ... ) 343 If a DNSSEC aware resolver asks for "b.example.org", it gets back a 344 "status: NXDOMAIN" packet, which by itself is meaningless as the 345 header can be forged. To be able to securely detect that "b" does 346 not exist, there must also be an NSEC record which _covers_ the name 347 space where "b" lives: 349 a.example.org. NSEC d.example.org. 351 does just do that: "b" should come after "a", but the next owner name 352 is "d.example.org", so "b" does not exist. 354 Only by making that calculation, can a resolver conclude that the 355 name "b" does not exist. If the signature of the NSEC record is 356 valid, "b" is proven not to exist. We have: _authenticated denial of 357 existence_. 359 3.3. NODATA Responses 361 NSEC records are also used in NODATA responses. In that case we need 362 to look more closely at the type bit map. The type bit map in an 363 NSEC record tells which types are defined for a name. If we look at 364 the NSEC record of "a.example.org" (see the reply below for an 365 example of the record) we see the following types in the bit map: A, 366 TXT, NSEC and RRSIG. So for the name "a" this indicates we must have 367 an A, TXT, NSEC and RRSIG record in the zone. 369 With the type bit map of the NSEC record a resolver can establish 370 that a name is there, but the type is not. A resolver asks for 371 "a.example.org AAAA". This is the reply that comes back: 373 ;; status: NOERROR, id: 44638 375 ;; AUTHORITY SECTION: 376 example.org. SOA ( ... ) 377 example.org. RRSIG(SOA) ( ... ) 378 a.example.org. NSEC d.example.org. A TXT NSEC RRSIG 379 a.example.org. RRSIG(NSEC) ( ... ) 381 Now the resolver should check the AUTHORITY section and conclude 382 that: 384 1. "a.example.org" exists (because of the NSEC with that owner name) 385 and; 387 2. that the type (AAAA) does not as it is _not_ listed in the type 388 bit map. 390 By understanding NSEC records, you have mastered the basics of 391 authenticated denial of existence. 393 But there were two issues with NSEC (and NXT). The first is that it 394 allows for zone walking. NSEC records point from one name to 395 another, in our example: "example.org", points to "a.example.org" 396 which points to "d.example.org" which points back to "example.org". 397 So we can reconstruct the entire "example.org" zone even when zone 398 transfers (AXFR) on the server are denied. 400 The second issue is that when a large, delegation heavy, zone deploys 401 DNSSEC, every name in the zone gets an NSEC plus RRSIG. This leads 402 to a huge increase in the zone size (when signed). This would in 403 turn mean that operators of large zones (or with a lot of zones) who 404 are deploying DNSSEC, face up front costs. This could hinder DNSSEC 405 adoption. 407 These two issues eventually lead to NSEC3 which: 409 o Adds a way to garble the next owner name, thus thwarting zone- 410 walking; 412 o Makes it possible to skip names for the next owner name. This 413 feature is called opt-out. It means not all names in your zone 414 get an NSEC3 plus ditto signature, making it possible to "grow 415 into" your DNSSEC deployment. Describing opt-out is (currently) 416 out of scope for this document. For those interested, opt-out is 417 explained in RFC 4956 [RFC4956], which is curiously titled 418 "(DNSSEC) Opt-In". Later this is incorporated into RFC 5155 419 [RFC5155]. 421 But before we delve in to NSEC3 lets first take a look at its 422 predecessors, NO, NSEC2 and DNSNR. 424 3.4. NO, NSEC2 and DNSNR 426 The NO record was the first to introduce the idea of hashed owner 427 names. It also fixed other shortcomings of the NXT record. At the 428 time (around 2000) zone walking was not considered important enough 429 to warrant the new record. People were also worried that deployment 430 would be hindered by developing an alternate means of denial of 431 existence. Thus the effort was shelved and NXT remained. When the 432 new DNSSEC specification was written, NSEC saw the light and 433 inherited the two issues from NXT. 435 Several years after that NSEC2 was introduced as a way to solve the 436 two issues of NSEC. The NSEC2 draft contains the following 437 paragraph: 439 This document proposes an alternate scheme which hides owner names 440 while permitting authenticated denial of existence of non-existent 441 names. The scheme uses two new RR types: NSEC2 and EXIST. 443 When an authenticated denial of existence scheme starts to talk about 444 EXIST records it is worth paying extra attention. 446 NSEC2 solved the zone walking issue, by hashing (with SHA1 and a 447 salt) the "next owner name" in the record, thereby making it useless 448 for zone walking. 450 But it did not have opt-out. Although promising, the proposal didn't 451 make it because of issues with wildcards and the odd EXISTS resource 452 record. 454 The DNSNR RR was another attempt that used hashed names to foil zone 455 walking and it also introduced the concept of opting out (called 456 "Authoritative Only Flag") which limited the use of DNSNR in 457 delegation heavy zones. This proposal didn't make it either, but it 458 provided valuable insights into the problem. 460 3.5. NSEC3 462 From the experience gained with NSEC2 and DNSNR, NSEC3 was forged. 463 It incorporates both opt-out and the hashing of names. NSEC3 solves 464 any issues people might have with NSEC, but it introduces some 465 additional complexity. 467 NSEC3 did not supersede NSEC, they are both defined for DNSSEC. So 468 DNSSEC is blessed with two different means to perform authenticated 469 denial of existence: NSEC and NSEC3. In NSEC3 every name is hashed, 470 including the owner name. 472 SHA1 is always used for the hashing. To make it even more difficult 473 to retrieve the original names, the hashing can be repeated several 474 times each time taking the previous hash as input. To thwart rainbow 475 table attacks, a custom salt is also added. In the NSEC3 for 476 "example.org" we have hashed the names twice and use the salt "DEAD". 477 Lets look at typical NSEC3 record: 479 15BG9L6359F5CH23E34DDUA6N1RIHL9H.example.org. ( 480 NSEC3 1 0 2 DEAD 04SKNAPCA5AL7QOS3KM2L9TL3P5OKQ4C 481 SOA RRSIG DNSKEY NSEC3PARAM ) 483 On the first line we see the hashed owner name: 484 "15BG9L6359F5CH23E34DDUA6N1RIHL9H.example.org", this is the hashed 485 name of "example.org". Note that even though we hashed 486 "example.org", the zone's name is added to make it look like a domain 487 name again. So un-hashed it sort of looks like: 488 "SHA1(example.org).example.org". 490 The next owner name "a.example.org" (line 2) is hashed to: 491 "04SKNAPCA5AL7QOS3KM2L9TL3P5OKQ4C". Note that ".example.org" is not 492 added to the next owner name, as this name always falls in the 493 current zone. 495 The "1 0 2 DEAD" section of the NSEC3 states: 497 o Hash Algorithm = 1 (SHA1, this is the default, no other hash 498 algorithms are defined for use in NSEC3); 500 o Opt Out = 0 (disabled); 502 o Hash Iterations = 2; 504 o Salt = "DEAD". 506 At the end we see the type bit map, which is identical to NSEC's bit 507 map, that lists the types present at the original owner name. Note 508 that the type NSEC3 is absent from the list in the example above. 509 This is due to the fact that the original owner name ("example.org") 510 does not have the NSEC3 type. It only exists for the hashed name. 512 Names like "1.h.example.org" hash to one label in NSEC3, 513 "1.h.example.org" becomes: 514 "117GERCPRCJGG8J04EV1NDRK8D1JT14K.example.org" when used as a owner 515 name. This is an important observation. By hashing the names you 516 loose the depth of a zone - hashing introduces a flat space of names, 517 as opposed to NSEC. 519 In fact the domain name used above: "1.h.example.org" creates an 520 empty non-terminal. Empty non-terminals are domain names that exist 521 but have no RR types associated with them but has one or more 522 subdomains that do ([RFC5155], Section 1.3). 524 1.h.example.org. TXT "1.h record" 526 Creates 2 names: 528 1. "1.h.example.org" that has the type: TXT; 530 2. "h.example.org" which has no types. This is the empty non- 531 terminal. An empty non-terminal will get an NSEC3 records, but 532 not an NSEC record. 534 3.6. Slaving an NSEC3 Zone 536 A secondary server slaving a zone with NSEC3 records needs to find 537 out the specifics (hash iterations and salt) to be able to hash 538 incoming query names. 540 To do this, it could scan the zone during the AXFR for NSEC3 records 541 and glance the NSEC3 parameters from them. However, it would need to 542 make sure that there is at least one complete set of NSEC3 records 543 for the zone using the same parameters. Therefore, it would need to 544 inspect all NSEC3 records. 546 A more graceful solution was designed. This solution was to create a 547 new record, NSEC3PARAM, which must be placed at the apex of the zone. 548 Its sole role is to provide a single, fixed place where a secondary 549 name server can directly see the NSEC3 parameters used. If NSEC3 550 were designed in the early days of DNS (+/- 1985) this information 551 was probably put in the SOA record. 553 3.7. Wildcards in the DNS 555 In the above sections we haven't revealed the entire story. There is 556 a complication: wildcards. Wildcards have been part of the DNS since 557 the first DNS RFCs. They allow to define _all_ names for a certain 558 type in one go. In our "example.org" zone we could for instance add 559 a wildcard record: 561 *.example.org. TXT "wildcard record" 563 For completeness our (unsigned) zone now looks like this: 565 example.org. SOA ( ... ) 566 *.example.org. TXT "wildcard record" 567 a.example.org. A 192.0.2.1 568 TXT "a record" 569 d.example.org. A 192.0.2.1 570 TXT "d record" 572 If a resolver asks for "z.example.org TXT", the name server will 573 respond with an _expanded wildcard_, instead of an NXDOMAIN: 575 ;; status: NOERROR, id: 13658 577 ;; ANSWER SECTION: 578 z.example.org. TXT "wildcard record" 580 Note however that the resolver can not detect that this answer came 581 from a wildcard. It just sees the answer as-is. How will this 582 answer look with DNSSEC? 584 ;; status: NOERROR, id: 51790 586 ;; ANSWER SECTION: 587 z.example.org. TXT "wildcard record" 588 z.example.org. RRSIG(TXT) ( ... ) 590 ;; AUTHORITY SECTION: 591 d.example.org. NSEC example.org. TXT RRSIG NSEC 592 d.example.org. RRSIG(NSEC) ( ... ) 594 The RRSIG of the "z.example.org" TXT record indicates there is a 595 wildcard configured. The RDATA of the signature lists a label count 596 [RFC4034], Section 3.1.3., of two (not visible in the answer above), 597 but the owner name of the signature has three labels. This mismatch 598 indicates there is a wildcard configured for the name 599 "*.example.org". The AUTHORITY section holds an NSEC. This NSEC 600 proves that the queried name "z.example.org" does not exist, and 601 wildcard name expansion was indeed allowed. 603 An astute reader may notice that it appears as if a 604 "z.example.org" RRSIG(TXT) is created out of thin air. This is 605 not the case. The signature for "z.example.org" does not exist. 606 The signature you are seeing is the one for "*.example.org" which 607 does exist, only the owner name is switched to "z.example.org". 608 So even with wildcards, no signatures are created on the fly. 610 One thing you may notice is that this reply has an NSEC record in it 611 _even_ though it is not an NXDOMAIN nor NODATA reply. In this case 612 it is there to tell the resolver this answer was synthesized from a 613 wildcard. 615 In the reply above we see that "z.example.org" was generated via 616 wildcard expansion. The DNSSEC standard mandates that an NSEC (or 617 NSEC3) is included in such responses. If it didn't, an attacker 618 could poison the cache with false data. 620 Suppose that the resolver would have asked for "a.example.org TXT", 621 an attacker could modify the packet in such way that it looks like 622 the response was generated through wildcard expansion, even though 623 there exists a record for "a.example.org TXT": "a.example.org. TXT 624 "a record"" 626 The tweaking simply consists of adjusting the ANSWER section to: 628 ;; status: NOERROR, id: 31827 630 ;; ANSWER SECTION 631 a.example.org. TXT "wildcard record" 632 a.example.org. RRSIG(TXT) ( ... ) 634 Which would be a perfectly valid answer if we would not require the 635 inclusion of an NSEC or NSEC3 record in the wildcard answer response. 636 The resolver believes that "a.example.org TXT" is a wildcard record, 637 and the real record is obscured. This is bad and defeats all the 638 security DNSSEC can deliver. Because of this, the NSEC or NSEC3 639 should be present. 641 Thus a resolver can detect such a spoofing attempt: 643 1. If the NSEC(3) is not present, assume the answer is spoofed; 645 2. If the NSEC(3) is there, check it. If the signature is not 646 correct, assume a spoofed answer. 648 Another way of putting this is that DNSSEC is there to ensure the 649 name server has followed the steps as outlined in [RFC1034], Section 650 4.3.2 for looking up names in the zone. It explicitly lists wildcard 651 lookup as one of these steps (3c), so with DNSSEC this must be 652 communicated to the resolver: hence the NSEC(3) record. 654 With NSEC the maximum number of NSEC records a resolver can get back 655 is two: one for the denial of existence and another for the wildcard. 656 We say maximum, because sometimes a single NSEC can prove both. With 657 NSEC3 it is three, as to why, we will explain in the next section. 659 3.8. Returning Three NSEC3s 661 With NSEC3 matters are even more complicated. So we have an NSEC3 662 that denies the existence of the requested name and an NSEC3 that 663 denies wildcard synthesis. What do we miss? 665 The short answer is that due to the hashing in NSEC3 you loose the 666 depth of your zone: everything is hashed into a flat plain. To make 667 up for this loss of information you need an extra record. The more 668 detailed explanation is quite a bit longer... 670 To understand NSEC3 we will need two definitions: 672 Closest encloser: Introduced in [RFC4592], this is the first 673 _existing_ name (this may be an empty non-terminal) in the zone 674 that is an ancestor of the name used in the query. Suppose the 675 query name is "x.2.example.org" then "example.org" is the "closest 676 encloser" in our example; 678 Next closer name: Introduced in the NSEC3 RFC, this is the closest 679 encloser with one more label added to the left. So if 680 "example.org" is the closest encloser for the query name 681 "x.2.example.org", "2.example.org" is the "next closer name". 683 An NSEC3 "closest encloser proof" consists of: 685 1. An NSEC3 RR that *matches* the "closest encloser". This means 686 the un-hashed owner name of the record is the closest encloser. 687 This bit of information tells a resolver: "The name you are 688 asking for does not exist, the closest I have is this". 690 2. An NSEC3 RR that *covers* the "next closer name". This means it 691 defines an interval in which the "next closer name" falls. This 692 tells the resolver: "The name in your question falls in this 693 interval, and therefor the name in your question does not exist. 694 In fact, the closest encloser is indeed the closest I have". 696 Take the following example. We take our zone, but now with the 697 following two records and it is signed with NSEC3. As said these 698 records create two non-terminals: "h.example.org" and 699 "3.example.org", but that is irrelevant for the theory here. 701 1.h.example.org. TXT "1.h record" 702 3.3.example.org. TXT "3.3 record" 704 The complete unsigned zone now looks like this. 706 example.org. SOA ( ... ) 707 1.h.example.org. TXT "1.h record" 708 3.3.example.org. TXT "3.3 record" 710 The resolver asks the following: "x.2.example.org TXT". This leads 711 to an NXDOMAIN response from the server, which contains three NSEC3 712 records. A list of hashed owner names can be found in Section 4. 713 Also see Figure 2 the numbers in the figure correspond with the 714 following NSEC3 records: 716 15BG9L6359F5CH23E34DDUA6N1RIHL9H.example.org. ( 717 NSEC3 1 0 2 DEAD 1AVVQN74SG75UKFVF25DGCETHGQ638EK SOA 718 RRSIG DNSKEY NSEC3PARAM ) 720 75B9ID679QQOV6LDFHD8OCSHSSSB6JVQ.example.org. ( 721 NSEC3 1 0 2 DEAD 8555T7QEGAU7PJTKSNBCHG4TD2M0JNPJ TXT 722 RRSIG ) 724 1AVVQN74SG75UKFVF25DGCETHGQ638EK.example.org. ( 725 NSEC3 1 0 2 DEAD 75B9ID679QQOV6LDFHD8OCSHSSSB6JVQ ) 727 If we would follow the NSEC approach, the resolver is only interested 728 in one thing. Does the hash of "x.2.example.org" fall in any of the 729 intervals of the NSEC3 records it got? 731 example.org 732 ** 733 +-- ** ..................... 734 [1] / . /\ . . 735 / . | . . 736 | . | . . 737 v . | . . 738 ** | ** ++ 739 h.example.org ** ----+----> ** 3.example.org ++ 2.example.org 740 . / [3] . | . 741 . / . | [2] . 742 . / . | . 743 . / . v . 744 1.h.example.org ** ** ++ 745 ** <--------- ** 3.3.example.org ++ x.2.example.org 747 x.2.example.org does not exist. The arrows represent the NSEC3 748 records, the ones numbered [1], [2] and [3] are the NSEC3s returned 749 in our answer. 751 Figure 2 753 The hash of "x.2.example.org" is "NDTU6DSTE50PR4A1F2QVR1V31G00I2I1". 755 Checking this hash on the first NSEC3 yields that it does not fall in 756 between the interval: "15BG9L6359F5CH23E34DDUA6N1RIHL9H" and 757 "1AVVQN74SG75UKFVF25DGCETHGQ638EK". For the second NSEC3 the answer 758 is also negative: the hash sorts outside the interval described by 759 "75B9ID679QQOV6LDFHD8OCSHSSSB6JVQ" and 760 "8555T7QEGAU7PJTKSNBCHG4TD2M0JNPJ". And the last NSEC3 also isn't of 761 any help. What is a resolver to do? It has been given the maximum 762 amount of NSEC3s and they all seem useless. 764 A question that you might have at this point is why doesn't the 765 server send an NSEC3 that covers the hash of "x.2.example.org", so 766 the resolver can validate in one step? While this indeed denies the 767 existence of "x.2.example.org" it is only half the answer. As 768 explained, a denial of existence answer needs to say something about 769 whether or not a wildcard should have been expanded. And to 770 communicate which wildcard that could have been, you need to tell the 771 resolver what the closest encloser is. 773 So this is where the closest encloser proof comes into play. And for 774 the proof to work, the resolver needs to know what the "closest 775 encloser" is. There must be an existing ancestor in the zone: a name 776 must exist that is shorter than the query name. The resolvers keeps 777 hashing, increasingly shorter names from the query name until an 778 owner name of an NSEC3 matches. This owner name is the "closest 779 encloser". 781 When the resolver has found the closest encloser, the next step is to 782 construct the "next closer name". This is the closest encloser with 783 the last chopped label from query name prepended to it: ".". The hash of this name should be 785 covered by the interval set in any of the other NSEC3 records. 787 Then the resolver needs to check the presence of a wildcard. It 788 creates the wildcard name by prepending the wildcard label to the 789 closest encloser: "*.", and use the hash of that. 791 Going back to our example the resolver must first detect the NSEC3 792 that matches the closest encloser. It does this by chopping up the 793 query name, hashing each instance (with the same number of iterations 794 and hash as the zone it is querying) and comparing that to the 795 answers given. So it has the following hashes to work with: 797 x.2.example.org: "NDTU6DSTE50PR4A1F2QVR1V31G00I2I1", last chopped 798 label: ""; 800 2.example.org: "7T70DRG4EKC28V93Q7GNBLEOPA7VLP6Q", last chopped 801 label: "x"; 803 example.org: "15BG9L6359F5CH23E34DDUA6N1RIHL9H", last chopped label: 804 "2"; 806 Of these hashes only one matches the owner name of one of the NSEC3 807 records: "15BG9L6359F5CH23E34DDUA6N1RIHL9H". This must be the 808 closest encloser (un-hashed: "example.org"). That's the main purpose 809 of that NSEC3 record: tell the resolver what the closest encloser is. 811 From that knowledge the resolver constructs the next closer, which in 812 this case is: "2.example.org"; "2" is the last label chopped, when 813 "example.org" is the closest encloser. The hash of this name should 814 be covered in any of the other NSEC3s. And it is, 815 "7T70DRG4EKC28V93Q7GNBLEOPA7VLP6Q" falls in the interval set by: 816 "75B9ID679QQOV6LDFHD8OCSHSSSB6JVQ" and 817 "8555T7QEGAU7PJTKSNBCHG4TD2M0JNPJ" (this is our second NSEC3). 819 So what does the resolver learn from this? 821 o "example.org" exists; 823 o "2.example.org" does not exist. 825 And if "2.example.org" does not exist, "x.2.example.org" also does 826 not exist. But only if there was no wildcard configured. So this is 827 the last step: check if there is a wildcard configured at the closest 828 encloser. 830 The resolver hashes "*.example.org" to 831 "22670TRPLHSR72PQQMEDLTG1KDQEOLB7". Only the last NSEC3 covers this 832 hash. The hash falls in the interval set by 833 "1AVVQN74SG75UKFVF25DGCETHGQ638EK" and 834 "75B9ID679QQOV6LDFHD8OCSHSSSB6JVQ" (this is our third NSEC3). This 835 means there is no wildcard at the closest encloser and 836 "x.2.example.org" definitely does not exist. 838 When we have validated the signatures, we reached our goal: 839 authenticated denial of existence. 841 Coming back to the original question: why do we need (up to) three 842 NSEC3 records? The resolver needs to be explicitly told what the 843 "closest encloser" is and this takes up a full NSEC3 record. Then 844 the next closer name needs to be covered in an NSEC3 record, and 845 finally an NSEC3 must say something about the wildcard. That makes 846 three records. 848 4. List of Hashed Owner Names 850 The following owner names are used in this document. The origin for 851 these names is "example.org". 853 +---------------+------------------------------------+ 854 | Original Name | Hashed Name | 855 +---------------+------------------------------------+ 856 | "@" | "15BG9L6359F5CH23E34DDUA6N1RIHL9H" | 857 | "*" | "22670TRPLHSR72PQQMEDLTG1KDQEOLB7" | 858 | "1.h" | "117GERCPRCJGG8J04EV1NDRK8D1JT14K" | 859 | "2" | "7T70DRG4EKC28V93Q7GNBLEOPA7VLP6Q" | 860 | "3.3" | "8555T7QEGAU7PJTKSNBCHG4TD2M0JNPJ" | 861 | "3" | "75B9ID679QQOV6LDFHD8OCSHSSSB6JVQ" | 862 | "a" | "04SKNAPCA5AL7QOS3KM2L9TL3P5OKQ4C" | 863 | "b" | "IUU8L5LMT76JELTP0BIR3TMG4U3UU8E7" | 864 | "h" | "1AVVQN74SG75UKFVF25DGCETHGQ638EK" | 865 | "x.2" | "NDTU6DSTE50PR4A1F2QVR1V31G00I2I1" | 866 +---------------+------------------------------------+ 868 Hashed owner names for the example.org zone. 870 Table 1 872 5. Security Considerations 874 This document raises no security issues. 876 6. IANA Considerations 878 This document has no actions for IANA. 880 7. Acknowledgements 882 This document would not be possible without the help of Ed Lewis, Roy 883 Arends, Wouter Wijngaards, Olaf Kolkman, Carsten Strotmann, Jan-Piet 884 Mens, Peter van Dijk, Marco Davids, Esther Makaay and Antoin 885 Verschuren. Also valuable, was the source code of Unbound 886 ("validator/val_nsec3.c"). Extensive feedback was received from 887 Karst Koymans. 889 8. References 891 8.1. Normative References 893 [RFC1034] Mockapetris, P., "Domain names - 894 concepts and facilities", STD 13, 895 RFC 1034, November 1987. 897 [RFC2308] Andrews, M., "Negative Caching of 898 DNS Queries (DNS NCACHE)", 899 RFC 2308, March 1998. 901 [RFC4033] Arends, R., Austein, R., Larson, 902 M., Massey, D., and S. Rose, "DNS 903 Security Introduction and 904 Requirements", RFC 4033, 905 March 2005. 907 [RFC4034] Arends, R., Austein, R., Larson, 908 M., Massey, D., and S. Rose, 909 "Resource Records for the DNS 910 Security Extensions", RFC 4034, 911 March 2005. 913 [RFC4035] Arends, R., Austein, R., Larson, 914 M., Massey, D., and S. Rose, 915 "Protocol Modifications for the 916 DNS Security Extensions", 917 RFC 4035, March 2005. 919 [RFC4592] Lewis, E., "The Role of Wildcards 920 in the Domain Name System", 921 RFC 4592, July 2006. 923 [RFC5155] Laurie, B., Sisson, G., Arends, 924 R., and D. Blacka, "DNS Security 925 (DNSSEC) Hashed Authenticated 926 Denial of Existence", RFC 5155, 927 March 2008. 929 8.2. Informative References 931 [I-D.arends-dnsnr] Arends, R., "DNSSEC Non- 932 Repudiation Resource Record", 933 draft-arends-dnsnr-00 (work in 934 progress), July 2004. 936 [I-D.ietf-dnsext-not-existing-rr] Josefsson, S., "Authenticating 937 denial of existence in DNS with 938 minimum disclosure", draft-ietf- 939 dnsext-not-existing-rr-01 (work in 940 progress), November 2000. 942 [I-D.laurie-dnsext-nsec2v2] Laurie, B., "DNSSEC NSEC2 Owner 943 and RDATA Format", 944 draft-laurie-dnsext-nsec2v2-00 945 (work in progress), December 2004. 947 [RFC2535] Eastlake, D., "Domain Name System 948 Security Extensions", RFC 2535, 949 March 1999. 951 [RFC3655] Wellington, B. and O. Gudmundsson, 952 "Redefinition of DNS Authenticated 953 Data (AD) bit", RFC 3655, 954 November 2003. 956 [RFC3755] Weiler, S., "Legacy Resolver 957 Compatibility for Delegation 958 Signer (DS)", RFC 3755, May 2004. 960 [RFC4956] Arends, R., Kosters, M., and D. 961 Blacka, "DNS Security (DNSSEC) 962 Opt-In", RFC 4956, July 2007. 964 Authors' Addresses 966 R. (Miek) Gieben 967 SIDN Labs 968 Meander 501 969 Arnhem, 6825 MD 970 NL 972 Phone: 973 EMail: miek.gieben@sidn.nl 974 URI: https://sidn.nl/ 976 W. (Matthijs) Mekking 977 NLnet Labs 978 Science Park 400 979 Amsterdam, 1098 XH 980 NL 982 Phone: 983 EMail: matthijs@nlnetlabs.nl 984 URI: http://www.nlnetlabs.nl/