idnits 2.17.1 draft-ietf-dnsop-nsec-aggressiveuse-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 (Using the creation date from RFC4035, updated by this document, for RFC5378 checks: 2002-10-29) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 27, 2016) is 2852 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 ---------------------------------------------------------------------------- == Unused Reference: 'UNBOUND' is defined on line 552, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7719 (Obsoleted by RFC 8499) == Outdated reference: A later version (-05) exists of draft-ietf-dnsop-nxdomain-cut-03 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Fujiwara 3 Internet-Draft JPRS 4 Updates: 4035 (if approved) A. Kato 5 Intended status: Informational Keio/WIDE 6 Expires: December 29, 2016 W. Kumari 7 Google 8 June 27, 2016 10 Aggressive use of NSEC/NSEC3 11 draft-ietf-dnsop-nsec-aggressiveuse-00 13 Abstract 15 The DNS relies upon caching to scale; however, the cache lookup 16 generally requires an exact match. This document specifies the use 17 of NSEC/NSEC3 resource records to generate negative answers within a 18 range. This increases resilience to DoS attacks, increases 19 performance / decreases latency, decreases resource utilization on 20 both authoritative and recursive servers, and also increases privacy. 22 This document updates RFC4035 by allowing resolvers to generate 23 negative answers based upon NSEC/NSEC3 records. 25 [ Ed note: Text inside square brackets ([]) is additional background 26 information, answers to frequently asked questions, general musings, 27 etc. They will be removed before publication.This document is being 28 collaborated on in Github at: https://github.com/wkumari/draft-ietf- 29 dnsop-nsec-aggressiveuse. The most recent version of the document, 30 open issues, etc should all be available here. The authors 31 (gratefully) accept pull requests. 33 Known / open issues [To be moved to Github issue tracker]: 35 1. We say things like: "Currently the DNS does ..." - this will not 36 be true after this is deployed, but I'm having a hard time 37 rewording this. "Without the techniques described in this 38 document..." seems klunky. Perhaps "historically?!" 40 2. We currently say this SHOULD be enabled by default. Is that what 41 the working group wants, or should this be an implementation 42 choice? 44 ] 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at http://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on December 29, 2016. 63 Copyright Notice 65 Copyright (c) 2016 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 81 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 82 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 83 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 84 5. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 5 85 5.1. Aggressive Negative Caching . . . . . . . . . . . . . . . 5 86 5.2. NSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 6 87 5.3. NSEC3 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 88 5.4. Wildcard . . . . . . . . . . . . . . . . . . . . . . . . 7 89 5.5. Consideration on TTL . . . . . . . . . . . . . . . . . . 7 90 6. Effects . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 91 6.1. Decrease of root DNS server queries . . . . . . . . . . . 7 92 6.2. Mitigation of random subdomain attacks . . . . . . . . . 8 93 7. Additional proposals . . . . . . . . . . . . . . . . . . . . 8 94 7.1. Partial implementation . . . . . . . . . . . . . . . . . 8 95 7.2. Aggressive negative caching flag idea . . . . . . . . . . 9 96 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 97 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 98 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 99 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 100 12. Change History . . . . . . . . . . . . . . . . . . . . . . . 10 101 12.1. Version draft-fujiwara-dnsop-nsec-aggressiveuse-01 . . . 10 102 12.2. Version draft-fujiwara-dnsop-nsec-aggressiveuse-02 . . . 10 103 12.3. Version draft-fujiwara-dnsop-nsec-aggressiveuse-03 . . . 11 104 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 105 13.1. Normative References . . . . . . . . . . . . . . . . . . 11 106 13.2. Informative References . . . . . . . . . . . . . . . . . 12 107 Appendix A. Aggressive negative caching from RFC 5074 . . . . . 12 108 Appendix B. Detailed implementation idea . . . . . . . . . . . . 13 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 111 1. Introduction 113 A DNS negative cache currently exists, and is used to cache the fact 114 that a name does not exist. This method of negative caching requires 115 exact matching; this leads to unnecessary additional lookups, which 116 have negative implications for DoS survivability, increases latency, 117 leads to extra resource utilization on both authoritative and 118 recursive servers, and decreases privacy by leaking queries. 120 This document updates RFC 4035 to allow recursive resolvers to use 121 NSEC/NSEC3 resource records to aggressively cache negative answers. 122 This would allow such resolvers to respond with NXDOMAIN immediately 123 if the name in question falls into a range expressed by a NSEC/NSEC3 124 resource record already in the cache. 126 Aggressive Negative Caching was first proposed in Section 6 of DNSSEC 127 Lookaside Validation (DLV) [RFC5074] in order to find covering NSEC 128 records efficiently. 130 Section 3 of [I-D.vixie-dnsext-resimprove] "Stopping Downward Cache 131 Search on NXDOMAIN" and [I-D.ietf-dnsop-nxdomain-cut] proposed 132 another approach to use NXDOMAIN information effectively. 134 2. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [RFC2119]. 140 Many of the specialized terms used in this document are defined in 141 DNS Terminology [RFC7719]. 143 The key words "Closest Encloser" and "Source of Synthesis" in this 144 document are to be interpreted as described in[RFC4592]. 146 "Closest Encloser" is also defined in NSEC3 [RFC5155], as is "Next 147 closer name". 149 3. Problem Statement 151 The current DNS negative cache caches negative (non-existent) 152 information, and requires an exact match in most instances [RFC2308]. 154 Assume that the (DNSSEC signed) "example.com" zone contains: 156 apple.example.com IN A 192.0.2.1 158 elephant.example.com IN A 192.0.2.2 160 zebra.example.com IN A 192.0.2.3 162 If a recursive resolver gets a query for cat.example.com, it will 163 query the example.com authoritative servers and will get back an NSEC 164 (or NSEC3) record starting that there are no records between apple 165 and elephant. The recursive resolver then knows that cat.example.com 166 does not exist; however, it (currently) does not use the fact that 167 the proof covers a range (apple to elephant) to suppress queries for 168 other labels that fall within this range. This means that if the 169 recursive resolvers gets a query for ball.example.com (or 170 dog.example.com) it will once again go off and query the example.com 171 servers for these names. 173 Apart from wasting bandwidth, this also wastes resources on the 174 recursive server (it needs to keep state for outstanding queries), 175 wastes resources on the authoritative server (it has to answer 176 additional questions), increases latency (the end user has to wait 177 longer than necessary to get back an NXDOMAIN answer), can be used by 178 attackers to cause a DoS (see additional resources), and also has 179 privacy implications (e.g: typos leak out further than necessary). 181 4. Background 183 DNSSEC [RFC4035] and [RFC5155] both provide "authenticated denial of 184 existence"; this is a cryptographic proof that the queried for name 185 does not exist, accomplished by providing a (DNSSEC secured) record 186 containing the names which appear alphabetically before and after the 187 queried for name. In the example above, if the (DNSSEC validating) 188 recursive server were to query for lion.example.com it would receive 189 a (signed) NSEC/NSEC3 record stating that there are no labels between 190 "elephant" and "zebra". This is a signed, cryptographic proof that 191 these names are the ones before and after the queried for label. As 192 lion.example.com falls within this range, the recursive server knows 193 that lion.example.com really does not exist. This document specifies 194 that this NSEC/NSEC3 record should be used to generate negative 195 answers for any queries that the recursive server receives that fall 196 within the range covered by the record (for the TTL for the record). 198 [RFC4035]; Section 4.5 states: 200 For a zone signed with NSEC, it would be possible to use the 201 information carried in NSEC resource records to indicate the non- 202 existence of a range of names. However, such use is discouraged by 203 Section 4.5 of RFC4035. It is recommended that readers read RFC4035 204 in its entirety for a better understanding. At the root of the 205 concern is that new records could have been added to the zone during 206 the TTL of the NSEC record, and that generating negative responses 207 from the NSEC record would hide these. We believe this 208 recommendation can be relaxed because lookups for the specific name 209 could have come in during the normal negative cache time and so 210 operators should have no expectation that an added name would work 211 immediately. We think that the TTL of the NSEC record is the 212 authoritive statement of how quickly a name can start working within 213 a zone. 215 5. Proposed Solution 217 5.1. Aggressive Negative Caching 219 Section 4.5 of [RFC4035] shows that "In theory, a resolver could use 220 wildcards or NSEC RRs to generate positive and negative responses 221 (respectively) until the TTL or signatures on the records in question 222 expire. However, it seems prudent for resolvers to avoid blocking 223 new authoritative data or synthesizing new data on their own. 224 Resolvers that follow this recommendation will have a more consistent 225 view of the namespace". 227 To reduce non-existent queries sent to authoritative DNS servers, 228 this restriction could be relaxed, as follows: 230 +--------------------------------------------------------------+ 231 | Once the records are validated, DNSSEC enabled full-service | 232 | resolvers MAY use NSEC/NSEC3 resource records to generate | 233 | negative responses until their effective TTLs or signatures | 234 | for those records expire. | 235 +--------------------------------------------------------------+ 237 If the full-service resolver's cache have enough information to 238 validate the query, the full-service resolver MAY use NSEC/NSEC3/ 239 wildcard records aggressively. Otherwise, the full-service resolver 240 MUST fall back to send the query to the authoritative DNS servers. 242 If the query name has the matching NSEC/NSEC3 RR and it proves the 243 information requested does not exist, the full-service resolver may 244 respond with a NODATA (empty) answer. 246 5.2. NSEC 248 If a full-service resolver implementation supports aggressive 249 negative caching, then it SHOULD support aggressive use of NSEC and 250 enable it by default. It SHOULD provide a configuration switch to 251 disable aggressive use of NSEC and allow it to be enabled or disabled 252 for specific zones. 254 The validating resolver needs to check the existence of an NSEC RR 255 matching/covering the source of synthesis and an NSEC RR covering the 256 query name. 258 If the full-service resolver's cache contains an NSEC RR covering the 259 source of synthesis and the covering NSEC RR of the query name, the 260 full-service resolver may respond with NXDOMAIN error immediately. 262 5.3. NSEC3 264 NSEC3 aggressive negative caching is more difficult. If the zone is 265 signed with NSEC3, the validating resolver needs to check the 266 existence of non-terminals and wildcards which derive from query 267 names. 269 If the full-service resolver's cache contains an NSEC3 RR matching 270 the closest encloser, an NSEC3 RR covering the next closer name, and 271 an NSEC3 RR covering the source of synthesis, it is possible for the 272 full-service resolver to respond with NXDOMAIN immediately. 274 If a covering NSEC3 RR has Opt-Out flag, the covering NSEC3 RR does 275 not prove the non-existence of the domain name and the aggressive 276 negative caching is not possible for the domain name. 278 A full-service resolver implementation MAY support aggressive use of 279 NSEC3. It SHOULD provide a configuration switch to disable 280 aggressive use of NSEC3 and allow it to be enabled or disabled for 281 specific zones. 283 5.4. Wildcard 285 The last paragraph of RFC 4035 Section 4.5 discusses aggressive use 286 of a cached deduced wildcard (as well as aggressive use of NSEC) and 287 recommends that it is not relied upon. 289 Just like the case for the aggressive use of NSEC discussed in this 290 draft, we could revisit this recommendation. As long as the full- 291 service resolver knows a name would not exist without the wildcard 292 match, it could answer a query for that name using the cached deduced 293 wildcard, and it may be justified for performance and other benefits. 294 (Note that, so far, this is orthogonal to "when aggressive use (of 295 NSEC) is enabled"). 297 Furthermore, when aggressive use of NSEC is enabled, the aggressive 298 use of cached deduced wildcard will be more effective. 300 A full-service resolver implementation MAY support aggressive use of 301 wildcards. It SHOULD provide a configuration switch to disable 302 aggressive use of wildcards. 304 5.5. Consideration on TTL 306 The TTL value of negative information is especially important, 307 because newly added domain names cannot be used while the negative 308 information is effective. Section 5 of RFC 2308 states the maximum 309 number of negative cache TTL value is 3 hours (10800). So the full- 310 service resolver SHOULD limit the maximum effective TTL value of 311 negative responses (NSEC/NSEC3 RRs) to 10800 (3 hours). It is 312 reasonably small but still effective for the purpose of this 313 document, since it can eliminate significant amount of DNS attacks 314 with randomly generated names. 316 6. Effects 318 6.1. Decrease of root DNS server queries 320 Aggressive use of NSEC/NSEC3 resource records results in a decrease 321 of queries to the root - this decreases load on the root servers (the 322 majority of queries currently result in NXDOMAIN responses), and 323 increases privacy. 325 People may generate many typos in TLD, and they will result in 326 unnecessary DNS queries. Some implementations leak non-existent TLD 327 queries whose second level domain are different each other. Well 328 observed examples are ".local" and ".belkin". With this proposal, it 329 is possible to return NXDOMAIN immediately to such queries without 330 further DNS recursive resolution process. It may reduces round trip 331 time, as well as reduces the DNS queries to corresponding 332 authoritative servers, including Root DNS servers. 334 6.2. Mitigation of random subdomain attacks 336 Random sub-domain attacks (referred to as "Water Torture" attacks or 337 NXDomain attacks) send many queries for non-existent information to 338 full-service resolvers. Their query names consist of random prefixes 339 and a target domain name. The negative cache does not work well, and 340 thus targeted full-service resolvers end up sending queries to 341 authoritative DNS servers of the target domain name. 343 When the number of queries is large, the full-service resolvers drop 344 queries from both legitimate users and attackers as their outstanding 345 queues are filled up. 347 For example, BIND 9.10.2 [BIND9] full-service resolvers answer 348 SERVFAIL and Unbound 1.5.2 full-service resolvers drop most of 349 queries under 10,000 queries per second attack. 351 The countermeasures implemented at this moment are rate limiting and 352 disabling name resolution of target domain names in ad-hoc manner. 354 If the full-service resolver supports aggressive negative caching and 355 the target domain name is signed with NSEC/NSEC3 (without Opt-Out), 356 it may be used as a possible countermeasure of random subdomain 357 attacks. 359 However, attackers can set the CD bit to their attack queries. The 360 CD bit disables signature validation and the aggressive negative 361 caching will be of no use. 363 7. Additional proposals 365 There are additional proposals to the aggressive negative caching. 367 7.1. Partial implementation 369 It is possible to implement aggressive negative caching partially. 371 DLV aggressive negative caching [RFC5074] is an implementation of 372 NSEC aggressive negative caching which targets DLV domain names. 374 NSEC3 is somewhat more complex to implement, and some implementations 375 may choose to only implement aggressive negative caching for NSEC. 377 Root only aggressive negative caching is also possible. It uses NSEC 378 and RRSIG resource records whose signer domain name is root. 380 [I-D.wkumari-dnsop-cheese-shop] proposed root only aggressive 381 negative caching in order to decrease defects and standardize 382 quickly. The root zone has certain properties that make it a special 383 case: It is DNSSEC signed and uses NSEC, the majority of the queries 384 are "junk" queries, the rate of change is relatively slow, and there 385 are no corner cases such as wildcards. Because of these properties, 386 we know that generated negative answers will work. 388 7.2. Aggressive negative caching flag idea 390 Authoritative DNS servers that dynamically generate NSEC records 391 normally generate minimally covering NSEC Records [RFC4470]. 392 Aggressive negative caching does not work with minimally covering 393 NSEC records. Most of DNS operators don't want zone enumeration and 394 zone information leaks. They prefer NSEC resource records with 395 narrow ranges. When a flag shows a full-service resolver supporting 396 the aggressive negative caching and a query has the aggressive 397 negative caching flag, authoritative DNS servers can generate NSEC 398 resource records with wider range under random subdomain attacks. 399 However, anyone (including attackers) can always use the flag.. 401 8. IANA Considerations 403 This document has no IANA actions. 405 9. Security Considerations 407 Newly registered resource records may not be used immediately. 408 However, choosing suitable TTL value will mitigate the delay concern, 409 and it is not a security problem. 411 It is also suggested to limit the maximum TTL value of NSEC / NSEC3 412 resource records in the negative cache to, for example, 10800 seconds 413 (3hrs), to mitigate this issue. Implementations which comply with 414 this proposal are recommended to have a configurable maximum value of 415 NSEC RRs in the negative cache. 417 Aggressive use of NSEC / NSEC3 resource records without DNSSEC 418 validation may cause security problems. It is highly recommended to 419 apply DNSSEC validation. 421 10. Implementation Status 423 Unbound has aggressive negative caching code in its DLV validator. 424 The author implemented NSEC aggressive caching using Unbound and its 425 DLV validator code. 427 11. Acknowledgments 429 The authors gratefully acknowledge DLV [RFC5074] author Samuel Weiler 430 and Unbound developers. Olafur Gudmundsson and Pieter Lexis proposed 431 aggressive negative caching flag idea. Valuable comments were 432 provided by Bob Harold, Tatuya JINMEI, Shumon Huque, Mark Andrews, 433 Casey Deccio, Bob Harold, Stephane Bortzmeyer and Matthijs Mekking. 435 12. Change History 437 This section is used for tracking the update of this document. Will 438 be removed after finalize. 440 From draft-fujiwara-dnsop-nsec-aggressiveuse-03 -> draft-ietf-dnsop- 441 nsec-aggressiveuse 443 o Document adopted by DNSOP WG. 445 o Adoption comments 447 o Changed main purpose to performance 449 o Use NSEC3/Wildcard keywords 451 o Improved wordings (from good comments) 453 o Simplified pseudo code for NSEC3 455 o Added Warren as co-author. 457 o Reworded much of the problem statement 459 o Reworked examples to better explain the problem / solution. 461 12.1. Version draft-fujiwara-dnsop-nsec-aggressiveuse-01 463 o Added reference to DLV [RFC5074] and imported some sentences. 465 o Added Aggressive Negative Caching Flag idea. 467 o Added detailed algorithms. 469 12.2. Version draft-fujiwara-dnsop-nsec-aggressiveuse-02 471 o Added reference to [I-D.vixie-dnsext-resimprove] 473 o Added considerations for the CD bit 474 o Updated detailed algorithms. 476 o Moved Aggressive Negative Caching Flag idea into Additional 477 Proposals 479 12.3. Version draft-fujiwara-dnsop-nsec-aggressiveuse-03 481 o Added "Partial implementation" 483 o Section 4,5,6 reorganized for better representation 485 o Added NODATA answer in Section 4 487 o Trivial updates 489 o Updated pseudo code 491 13. References 493 13.1. Normative References 495 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 496 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 497 RFC2119, March 1997, 498 . 500 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 501 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 502 . 504 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 505 Rose, "Protocol Modifications for the DNS Security 506 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 507 . 509 [RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records 510 and DNSSEC On-line Signing", RFC 4470, DOI 10.17487/ 511 RFC4470, April 2006, 512 . 514 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 515 System", RFC 4592, DOI 10.17487/RFC4592, July 2006, 516 . 518 [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074, 519 DOI 10.17487/RFC5074, November 2007, 520 . 522 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 523 Security (DNSSEC) Hashed Authenticated Denial of 524 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 525 . 527 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 528 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 529 2015, . 531 13.2. Informative References 533 [BIND9] Internet Systems Consortium, Inc., "Name Server Software", 534 2000, . 536 [I-D.ietf-dnsop-nxdomain-cut] 537 Bortzmeyer, S. and S. Huque, "NXDOMAIN really means there 538 is nothing underneath", draft-ietf-dnsop-nxdomain-cut-03 539 (work in progress), May 2016. 541 [I-D.vixie-dnsext-resimprove] 542 Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS 543 Resolvers for Resiliency, Robustness, and Responsiveness", 544 draft-vixie-dnsext-resimprove-00 (work in progress), June 545 2010. 547 [I-D.wkumari-dnsop-cheese-shop] 548 Kumari, W. and G. Huston, "Believing NSEC records in the 549 DNS root.", draft-wkumari-dnsop-cheese-shop-01 (work in 550 progress), February 2016. 552 [UNBOUND] NLnet Labs, "Unbound DNS validating resolver", 2006, 553 . 555 Appendix A. Aggressive negative caching from RFC 5074 557 Imported from Section 6 of [RFC5074]. 559 Previously, cached negative responses were indexed by QNAME, QCLASS, 560 QTYPE, and the setting of the CD bit (see RFC 4035, Section 4.7), and 561 only queries matching the index key would be answered from the cache. 562 With aggressive negative caching, the validator, in addition to 563 checking to see if the answer is in its cache before sending a query, 564 checks to see whether any cached and validated NSEC record denies the 565 existence of the sought record(s). 567 Using aggressive negative caching, a validator will not make queries 568 for any name covered by a cached and validated NSEC record. 569 Furthermore, a validator answering queries from clients will 570 synthesize a negative answer whenever it has an applicable validated 571 NSEC in its cache unless the CD bit was set on the incoming query. 573 Imported from Section 6.1 of [RFC5074]. 575 Implementing aggressive negative caching suggests that a validator 576 will need to build an ordered data structure of NSEC records in order 577 to efficiently find covering NSEC records. Only NSEC records from 578 DLV domains need to be included in this data structure. 580 Appendix B. Detailed implementation idea 582 Section 6.1 of [RFC5074] is expanded as follows. 584 Implementing aggressive negative caching suggests that a validator 585 will need to build an ordered data structure of NSEC and NSEC3 586 records for each signer domain name of NSEC / NSEC3 records in order 587 to efficiently find covering NSEC / NSEC3 records. Call the table as 588 NSEC_TABLE. 590 The aggressive negative caching may be inserted at the cache lookup 591 part of the full-service resolvers. 593 If errors happen in aggressive negative caching algorithm, resolvers 594 MUST fall back to resolve the query as usual. "Resolve the query as 595 usual" means that the full-resolver resolve the query in Recursive- 596 mode as if the full-service resolver does not implement aggressive 597 negative caching. 599 To implement aggressive negative caching, resolver algorithm near 600 cache lookup will be changed as follows: 602 QNAME = the query name; 603 QTYPE = the query type; 604 if ({QNAME,QTYPE} entry exists in the cache) { 605 // the resolver responds the RRSet from the cache 606 resolve the query as usual; 607 } 609 // if NSEC* exists, QTYPE existence is proved by type bitmap 610 if (matching NSEC/NSEC3 of QNAME exists in the cache) { 611 if (QTYPE exists in type bitmap of NSEC/NSEC3 of QNAME) { 612 // the entry exists, however, it is not in the cache. 613 // need to iterate QNAME/QTYPE. 614 resolve the query as usual; 615 } else { 616 // QNAME exists, QTYPE does not exist. 617 the resolver can generate NODATA response; 619 } 620 } 622 // Find closest enclosing NS RRset in the cache. 623 // The owner of this NS RRset will be a suffix of the QNAME 624 // - the longest suffix of any NS RRset in the cache. 625 SIGNER = closest enclosing NS RRSet of QNAME in the cache; 627 // Check the NS RR of the SIGNER 628 if (NS RR of SIGNER and its RRSIG RR do not exist in the cache 629 or SIGNER zone is not signed or not validated) { 630 Resolve the query as usual; 631 } 633 if (SIGNER zone does not have NSEC_TABLE) { 634 Resolve the query as usual; 635 } 637 if (SIGNER zone is signed with NSEC) { // NSEC mode 639 // Check the non-existence of QNAME 640 CoveringNSEC = Find the covering NSEC of QNAME from NSEC_TABLE; 641 if (Covering NSEC doesn't exist in the cache and NSEC_TABLE) { 642 Resolve the query as usual. 643 } 645 // Select the longest existing name of QNAME from covering NSEC 646 ClosestEncloser = common part of both owner name and 647 next domain name of CoveringNSEC; 649 if (*.LongestExistName entry exists in the cache) { 650 the resolver can generate positive response 651 // synthesize the wildcard *.TEST 652 } 653 if covering NSEC RR of "*.LongestExistName" at SIGNER zone exists 654 in the cache { 655 the resolver can generate negative response; 656 } 657 //*.LongestExistName may exist. cannot generate negative response 658 Resolve the query as usual. 660 } else 661 if (SIGNER zone is signed with NSEC3) { 662 // NSEC3 mode 664 ClosestEncloser = Find the closest encloser of QNAME 665 from the cache 666 // to prove the non-existence of QNAME, 667 // closest encloser of QNAME must be in the cache 669 NextCloserName = the next closer name of QNAME 670 SourceOfSyhthesis = *.ClosestEncloser 672 if (matching NSEC3 of ClosestEncloser exists in the cache 673 and 674 covering NSEC3 of NextCloserName exists in the cache 675 and covering NSEC3 is not Opt-Out flag set) { 677 // ClosestEncloser exists, and NextCloserName does not exist 678 // then we need to check *.ClosestEncloser 680 if (*.ClosestEncloser entry exists in the cache) { 681 if (*.ClosestEncloser/QTYPE entry exists in the cache) { 682 the resolver can generate positive response 683 } else { 684 // lack of *.ClosestEncloser/QTYPE information 685 Resolve the query as usual 686 } 687 } else 688 if (covering NSEC3 of *.ClosestEncloser exists 689 and covering NSEC3 is not Opt-Out flag set) { 690 the resolver can generate negative response; 691 } 692 } 693 // no matching/covering NSEC3 of QNAME information 694 Resolve the query as usual 695 } 697 Authors' Addresses 699 Kazunori Fujiwara 700 Japan Registry Services Co., Ltd. 701 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 702 Chiyoda-ku, Tokyo 101-0065 703 Japan 705 Phone: +81 3 5215 8451 706 Email: fujiwara@jprs.co.jp 707 Akira Kato 708 Keio University/WIDE Project 709 Graduate School of Media Design, 4-1-1 Hiyoshi 710 Kohoku, Yokohama 223-8526 711 Japan 713 Phone: +81 45 564 2490 714 Email: kato@wide.ad.jp 716 Warren Kumari 717 Google 718 1600 Amphitheatre Parkway 719 Mountain View, CA 94043 720 US 722 Email: warren@kumari.net