idnits 2.17.1 draft-ietf-dnsop-nsec-aggressiveuse-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? 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 (October 7, 2016) is 2756 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Historic RFC: RFC 5074 ** Downref: Normative reference to an Informational RFC: RFC 7129 ** Obsolete normative reference: RFC 7719 (Obsoleted by RFC 8499) == Outdated reference: A later version (-05) exists of draft-ietf-dnsop-nxdomain-cut-03 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 3 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: Standards Track Keio/WIDE 6 Expires: April 10, 2017 W. Kumari 7 Google 8 October 7, 2016 10 Aggressive use of NSEC/NSEC3 11 draft-ietf-dnsop-nsec-aggressiveuse-04 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 allow DNSSEC validating resolvers 18 to generate negative answers within a range, and positive answers 19 from wildcards. This increases performance / decreases latency, 20 decreases resource utilization on both authoritative and recursive 21 servers, and also increases privacy. It may also help increase 22 resilience to certain DoS attacks in some circumstances. 24 This document updates RFC4035 by allowing validating resolvers to 25 generate negative based upon NSEC/NSEC3 records (and positive answers 26 in the presence of wildcards). 28 [ Ed note: Text inside square brackets ([]) is additional background 29 information, answers to frequently asked questions, general musings, 30 etc. They will be removed before publication.This document is being 31 collaborated on in Github at: https://github.com/wkumari/draft-ietf- 32 dnsop-nsec-aggressiveuse. The most recent version of the document, 33 open issues, etc should all be available here. The authors 34 (gratefully) accept pull requests.] 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on April 10, 2017. 53 Copyright Notice 55 Copyright (c) 2016 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 73 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 5. Aggressive Caching . . . . . . . . . . . . . . . . . . . . . 5 75 5.1. NSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 5.2. NSEC3 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 5.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 7 78 5.4. Consideration on TTL . . . . . . . . . . . . . . . . . . 7 79 6. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 7. Update to RFC 4035 . . . . . . . . . . . . . . . . . . . . . 8 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 83 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 84 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 85 11.1. Change History . . . . . . . . . . . . . . . . . . . . . 10 86 11.1.1. Version draft-fujiwara-dnsop-nsec-aggressiveuse-01 . 12 87 11.1.2. Version draft-fujiwara-dnsop-nsec-aggressiveuse-02 . 12 88 11.1.3. Version draft-fujiwara-dnsop-nsec-aggressiveuse-03 . 13 89 11.2. new section . . . . . . . . . . . . . . . . . . . . . . 13 90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 92 12.2. Informative References . . . . . . . . . . . . . . . . . 14 93 Appendix A. Detailed implementation notes . . . . . . . . . . . 14 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 96 1. Introduction 98 A DNS negative cache exists, and is used to cache the fact that a 99 name does not exist. This method of negative caching requires exact 100 matching; this leads to unnecessary additional lookups, increases 101 latency, leads to extra resource utilization on both authoritative 102 and recursive servers, and decreases privacy by leaking queries. 104 This document updates RFC 4035 to allow recursive resolvers to use 105 NSEC/NSEC3 resource records to synthesize negative answers from the 106 information they have in the cache. This allows validating resolvers 107 to respond with NXDOMAIN immediately if the name in question falls 108 into a range expressed by a NSEC/NSEC3 resource record already in the 109 cache. It also allows the synthesis of positive answers in the 110 presence of wildcard records. 112 Aggressive Negative Caching was first proposed in Section 6 of DNSSEC 113 Lookaside Validation (DLV) [RFC5074] in order to find covering NSEC 114 records efficiently. 116 Section 3 of [I-D.vixie-dnsext-resimprove] "Stopping Downward Cache 117 Search on NXDOMAIN" and [I-D.ietf-dnsop-nxdomain-cut] proposed 118 another approach to use NXDOMAIN information effectively. 120 2. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 Many of the specialized terms used in this document are defined in 127 DNS Terminology [RFC7719]. 129 The key words "Closest Encloser" and "Source of Synthesis" in this 130 document are to be interpreted as described in [RFC4592]. 132 "Closest Encloser" is also defined in NSEC3 [RFC5155], as is "Next 133 closer name". 135 3. Problem Statement 137 The DNS negative cache caches negative (non-existent) information, 138 and requires an exact match in most instances [RFC2308]. 140 Assume that the (DNSSEC signed) "example.com" zone contains: 142 apple.example.com IN A 192.0.2.1 143 elephant.example.com IN A 192.0.2.2 144 *.example.com IN A 192.0.2.3 145 zebra.example.com IN A 192.0.2.4 147 If a validating resolver receives a query for cat.example.com, it 148 contacts its resolver (which may be itself) to query the example.com 149 servers and will get back an NSEC record starting that there are no 150 records (alphabetically) between apple and elephant, or an NSEC3 151 record stating there is nothing between two hashed names. The 152 resolver then knows that cat.example.com does not exist; however, it 153 does not use the fact that the proof covers a range (apple to 154 elephant) to suppress queries for other labels that fall within this 155 range. This means that if the validating resolver gets a query for 156 ball.example.com (or dog.example.com) it will once again go off and 157 query the example.com servers for these names. 159 Further, if a query is received for lion.example.com, it contacts its 160 resolver (which may be itself) to query the example.com servers and 161 will get back an NSEC record stating that there are no records 162 (alphabetically) between elephant and zebra (or an NSEC3 record 163 stating there is nothing between two hashed names), as well as an 164 answer for lion.example.com, with the label count of the signature 165 set to two (see [RFC7129], section 5.3 for more details). 167 Apart from wasting bandwidth, this also wastes resources on the 168 recursive server (it needs to keep state for outstanding queries), 169 wastes resources on the authoritative server (it has to answer 170 additional questions), increases latency (the end user has to wait 171 longer than necessary to get back an NXDOMAIN answer), can be used by 172 attackers to cause a DoS (see additional resources), and also has 173 privacy implications (e.g: typos leak out further than necessary). 175 4. Background 177 DNSSEC [RFC4035] and [RFC5155] both provide "authenticated denial of 178 existence"; this is a cryptographic proof that the queried for name 179 does not exist, accomplished by providing a (DNSSEC secured) record 180 containing the names which appear alphabetically before and after the 181 queried for name. In the example above, if the (DNSSEC validating) 182 recursive server were to query for dog.example.com it would receive a 183 (signed) NSEC record stating that there are no labels between "apple" 184 and "elephant" (or, for NSEC3, a similar pair of hashed names). This 185 is a signed, cryptographic proof that these names are the ones before 186 and after the queried for label. As dog.example.com falls within 187 this range, the recursive server knows that dog.example.com really 188 does not exist. 190 This document specifies that this NSEC/NSEC3 record should be used to 191 generate negative answers for any queries that the validating server 192 receives that fall within the range covered by the record (for the 193 TTL for the record). This document also specifies that a positive 194 answer should be generated for any queries that the validating server 195 receives that are proven to be covered by a wildcard record. 197 Section 4.5 of [RFC4035] says: 199 "In theory, a resolver could use wildcards or NSEC RRs to generate 200 positive and negative responses (respectively) until the TTL or 201 signatures on the records in question expire. However, it seems 202 prudent for resolvers to avoid blocking new authoritative data or 203 synthesizing new data on their own. Resolvers that follow this 204 recommendation will have a more consistent view of the namespace." 205 and "The reason for these recommendations is that, between the 206 initial query and the expiration of the data from the cache, the 207 authoritative data might have been changed (for example, via dynamic 208 update).". In other words, if a resolver generates negative answers 209 from an NSEC record, it will not send any queries for names within 210 that NSEC range (for the TTL). If a new name is added to the zone 211 during this interval the resolver will not know this. Similarly, if 212 the resolver is generating responses from a wildcard record, it will 213 continue to do so (for the 215 We believe this recommendation can be relaxed because, in the absense 216 of this technique, a lookup for the exact name could have come in 217 during this interval, and so a negative answer could already be 218 cached (see [RFC2308] for more background). This means that zone 219 operators should have no expectation that an added name would work 220 immediately. With DNSSEC and Aggressive NSEC, the TTL of the NSEC 221 record is the authoritative statement of how quickly a name can start 222 working within a zone. 224 5. Aggressive Caching 226 Section 4.5 of [RFC4035] says that "In theory, a resolver could use 227 wildcards or NSEC RRs to generate positive and negative responses 228 (respectively) until the TTL or signatures on the records in question 229 expire. However, it seems prudent for resolvers to avoid blocking 230 new authoritative data or synthesizing new data on their own. 231 Resolvers that follow this recommendation will have a more consistent 232 view of the namespace". 234 This document relaxes this this restriction, as follows: 236 +--------------------------------------------------------------+ 237 | Once the records are validated, DNSSEC enabled validating | 238 | resolvers MAY use wildcards and NSEC/NSEC3 resource records | 239 | to generate positive and negative responses until the | 240 | effective TTLs or signatures for those records expire. | 241 +--------------------------------------------------------------+ 243 If the validating resolver's cache has sufficient information to 244 validate the query, the resolver SHOULD use NSEC/NSEC3/wildcard 245 records aggressively. Otherwise, it MUST fall back to send the query 246 to the authoritative DNS servers. 248 5.1. NSEC 250 Implementations which support aggressive use of NSEC SHOULD enable 251 this by default. Implementations MAY provide a configuration switch 252 to disable aggressive use of NSEC and allow it to be enabled or 253 disabled per domain. 255 The validating resolver needs to check the existence of an NSEC RR 256 matching/covering the source of synthesis and an NSEC RR covering the 257 query name. 259 If denial of existence can be determined according to the rules set 260 out in Section 5.4 of [RFC4035], using NSEC records in the cache, 261 then the resolver can immediately return an NXDOMAIN or NODATA (as 262 appropriate) response. 264 5.2. NSEC3 266 NSEC3 aggressive negative caching is more difficult than NSEC 267 aggressive caching. If the zone is signed with NSEC3, the validating 268 resolver needs to check the existence of non-terminals and wildcards 269 which derive from query names. 271 A validating resolver implementation MAY support aggressive use of 272 NSEC3. If it does support aggressive use of NSEC3, it SHOULD enable 273 this by default. It MAY provide a configuration switch to disable 274 aggressive use of NSEC3 and allow it to be enabled or disabled for 275 specific zones. 277 If denial of existence can be determined according to the rules set 278 out in [RFC5155] sections 8.4, 8.5, 8.6, 8.7,using NSEC3 records in 279 the cache, then the resolver can immediately return an NXDOMAIN or 280 NODATA response (as appropriate). 282 If a covering NSEC3 RR has Opt-Out flag, the covering NSEC3 RR does 283 not prove the non-existence of the domain name and the aggressive 284 negative caching is not possible for the domain name. 286 5.3. Wildcards 288 The last paragraph of [RFC4035] Section 4.5 also discusses the use of 289 wildcards and NSEC RRs to generate positive responses and recommends 290 that it not be relied upon. Just like the case for the aggressive 291 use of NSEC/NSEC3 for negative answers, we revise this 292 recommendation. 294 As long as the validating resolver can determine that a name would 295 not exist without the wildcard match, it MAY synthesize an answer for 296 that name using the cached deduced wildcard. If the corresponding 297 wildcard record is not in the cache, it MUST fall back to send the 298 query to the authoritative DNS servers. 300 An implementation MAY support aggressive use of wildcards. It SHOULD 301 provide a configuration switch to disable aggressive use of 302 wildcards. 304 5.4. 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. 310 Section 5 of [RFC2308] states that the maximum number of negative 311 cache TTL value is 3 hours (10800). It is RECOMMENDED that 312 validating resolvers limit the maximum effective TTL value of 313 negative responses (NSEC/NSEC3 RRs) to this same value. 315 Section 5 of [RFC2308]also states that a negative cache entry TTL is 316 taken from the minimum of the SOA.MINIMUM field and SOA's TTL. This 317 can be less than the TTL of an NSEC or NSEC3 record, since their TTL 318 is equal to the SOA.MINIMUM field (see [RFC4035]section 2.3 and 319 [RFC5155] section 3.) 321 A resolver that supports aggressive use of NSEC and NSEC3 should 322 reduce the TTL of NSEC and NSEC3 records to match the TTL of the SOA 323 record in the authority section of a negative response, if the SOA 324 TTL is smaller. 326 6. Benefits 328 The techniques described in this document provide a number of 329 benefits, including (in no specific order): 331 Reduced latency: By answering directly from cache, validating 332 resolvers can immediately inform clients that the name they are 333 looking for does not exist, improving the user experience. 335 Decreased recursive server load: By answering negative queries from 336 the cache, validating servers avoid having to send a query and 337 wait for a response. In addition to decreasing the bandwidth 338 used, it also means that the server does not need to allocate and 339 maintain state, thereby decreasing memory and CPU load. 341 Decreased authorative server load: Because recursive servers can 342 answer (negative) queries without asking the authoritative server, 343 the authoritative servers receive fewer queries. This decreases 344 the authoritative server bandwidth, queries per second and CPU 345 utilization. 347 The scale of the benefit depends upon multiple factors, including the 348 query distribution. For example, at the time of this writing, around 349 65% of queries to Root Name servers result in NXDOMAIN responses (see 350 statis [root-servers.org]); this technique will eliminate a sizable 351 quantity of these. 353 The technique described in this document may also mitigate so-called 354 "random QNAME attacks", in which attackers send many queries for 355 random sub-domains to resolvers. As the resolver will not have the 356 answers cached, it has to ask external servers for each random query, 357 leading to a DoS on the authoritative servers (and often resolvers). 358 Aggressive NSEC may help mitigate these attacks by allowing the 359 resolver to answer directly from cache for any random queries which 360 fall within already requested ranges. It will not always work as an 361 effective defense, not least because not many zones are DNSSEC signed 362 at all -- but it will still provide an additional layer of defense. 364 7. Update to RFC 4035 366 Section 4.5 of [RFC4035] shows that "In theory, a resolver could use 367 wildcards or NSEC RRs to generate positive and negative responses 368 (respectively) until the TTL or signatures on the records in question 369 expire. However, it seems prudent for resolvers to avoid blocking 370 new authoritative data or synthesizing new data on their own. 371 Resolvers that follow this recommendation will have a more consistent 372 view of the namespace". 374 The paragraph is updated as follows: 376 +--------------------------------------------------------------+ 377 | Once the records are validated, DNSSEC enabled validating | 378 | resolvers MAY use wildcards and NSEC/NSEC3 resource records | 379 | to generate positive and negative responses until the | 380 | effective TTLs or signatures for those records expire. | 381 +--------------------------------------------------------------+ 383 8. IANA Considerations 385 This document has no IANA actions. 387 9. Security Considerations 389 Use of NSEC / NSEC3 resource records without DNSSEC validation may 390 create serious security issues, and so this technique requires DNSSEC 391 validation. 393 Newly registered resource records may not be used immediately. 394 However, choosing suitable TTL value and negative cache TTL value 395 (SOA MINIMUM field) will mitigate the delay concern, and it is not a 396 security problem. 398 It is also suggested to limit the maximum TTL value of NSEC / NSEC3 399 resource records in the negative cache to, for example, 10800 seconds 400 (3hrs), to mitigate this issue. Implementations which comply with 401 this proposal are recommended to have a configurable maximum value of 402 NSEC RRs in the negative cache. 404 Although the TTL of NSEC/NSEC3 records is typically fairly short 405 (minutes or hours), their RRSIG expiration time can be much further 406 in the future (weeks). An attacker who is able to successfully spoof 407 responses might poison a cache with old NSEC/NSEC3 records. If the 408 resolver is NOT making aggressive use of NSEC/NSEC3, the attacker has 409 to repeat the attack for every query. If the resolver IS making 410 aggressive use of NSEC/NSEC3, one successful attack would be able to 411 suppress many queries for new names, up to the negative TTL. 413 10. Implementation Status 415 Unbound currenty implements aggressive negative caching, as does 416 Google Public DNS. 418 11. Acknowledgments 420 The authors gratefully acknowledge DLV [RFC5074] author Samuel Weiler 421 and the Unbound developers. 423 The authors would like to specifically thank Stephane Bortzmeyer, 424 Tony Finch, Tatuya JINMEI for extensive review and comments, and also 425 Mark Andrews, Casey Deccio, Alexander Dupuy, Olafur Gudmundsson, Bob 426 Harold, Shumon Huque, John Levine, Pieter Lexis and Matthijs Mekking 427 (who even sent pull requests!). 429 11.1. Change History 431 RFC Editor: Please remove this section prior to publication. 433 -03 to -04: 435 o Working group does want the "positive" answers, not just negative 436 ones. This requires readding what used to be Section 7, and a 437 bunch of cleanup, including: 439 * Additional text in the Problem Statement 441 * Added a wildcard record to the zone. 443 * Added "or positive answers from wildcards" type text (where 444 appropriate) to explain that this isn't just for negative 445 answers. 447 * Reworded much of the Wildcard text. 449 o Incorporated pull request from Tony Finch (thanks!): 450 https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse/ 451 pull/1 453 o More fixups from Tony (including text): https://www.ietf.org/mail- 454 archive/web/dnsop/current/msg18271.html. This included much 455 clearer text on TTL, refernces to the NSEC / NSEC3 RFCs (instead 456 of my clumsy summary), good text on replays, etc. 458 o Converted the "zone file" to a figure to make it more readable. 460 o Text from Tim W: "If a validating resolver receives a query for 461 cat.example.com, it contacts its resolver (which may be itself) to 462 query..." - which satisfies Jinmei's concern (which I was too 463 dense to grock). 465 o Fixup of the "validation required" in security considerations. 467 -02 to -03: 469 o Integrated a bunch of comments from Matthijs Mekking - details in: 470 https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse/ 471 pull/1. I decided to keep "Aggressive Negative Caching" instead 472 of "Aggressive USE OF Negative Caching" for readability. 474 o Attempted to address Bob Harold's comment on the readability 475 issues with "But, it will be more effective when both are 476 enabled..." in Section 5.4 - https://www.ietf.org/mail- 477 archive/web/dnsop/current/msg17997.html 479 o MAYs and SHOULD drifted in the text block. Fixed - thanks to 480 https://mailarchive.ietf.org/arch/msg/ 481 dnsop/2ljmmzxtIMCFMLOZmWcSbTYVOy4 483 o A number of good edits from Stephane in: https://www.ietf.org/ 484 mail-archive/web/dnsop/current/msg18109.html 486 o A bunch more edits from Jinmei, as in: https://www.ietf.org/mail- 487 archive/web/dnsop/current/msg18206.html 489 -01 to -02: 491 o Added Section 6 - Benefits (as suggested by Jinmei). 493 o Removed Appendix B (Jinmei) 495 o Replaced "full-service" with "validating" (where applicable) 497 o Integrated other comments from Jinmei from https://www.ietf.org/ 498 mail-archive/web/dnsop/current/msg17875.html 500 o Integrated comment from co-authors, including re-adding parts of 501 Appendix B, terminology, typos. 503 o Tried to explain under what conditions this may actually mitigate 504 attacks. 506 -00 to -01: 508 o Comments from DNSOP meeting in Berlin. 510 o Changed intended status to Standards Track (updates RFC 4035) 512 o Added a section "Updates to RFC 4035" 514 o Some language clarification / typo / cleanup 515 o Cleaned up the TTL section a bit. 517 o Removed Effects section, Additional proposal section, and pseudo 518 code. 520 o Moved "mitigation of random subdomain attacks" to Appendix. 522 From draft-fujiwara-dnsop-nsec-aggressiveuse-03 -> draft-ietf-dnsop- 523 nsec-aggressiveuse 525 o Document adopted by DNSOP WG. 527 o Adoption comments 529 o Changed main purpose to performance 531 o Use NSEC3/Wildcard keywords 533 o Improved wordings (from good comments) 535 o Simplified pseudo code for NSEC3 537 o Added Warren as co-author. 539 o Reworded much of the problem statement 541 o Reworked examples to better explain the problem / solution. 543 11.1.1. Version draft-fujiwara-dnsop-nsec-aggressiveuse-01 545 o Added reference to DLV [RFC5074] and imported some sentences. 547 o Added Aggressive Negative Caching Flag idea. 549 o Added detailed algorithms. 551 11.1.2. Version draft-fujiwara-dnsop-nsec-aggressiveuse-02 553 o Added reference to [I-D.vixie-dnsext-resimprove] 555 o Added considerations for the CD bit 557 o Updated detailed algorithms. 559 o Moved Aggressive Negative Caching Flag idea into Additional 560 Proposals 562 11.1.3. Version draft-fujiwara-dnsop-nsec-aggressiveuse-03 564 o Added "Partial implementation" 566 o Section 4,5,6 reorganized for better representation 568 o Added NODATA answer in Section 4 570 o Trivial updates 572 o Updated pseudo code 574 11.2. new section 576 12. References 578 12.1. Normative References 580 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 581 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 582 RFC2119, March 1997, 583 . 585 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 586 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 587 . 589 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 590 Rose, "Protocol Modifications for the DNS Security 591 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 592 . 594 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 595 System", RFC 4592, DOI 10.17487/RFC4592, July 2006, 596 . 598 [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074, 599 DOI 10.17487/RFC5074, November 2007, 600 . 602 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 603 Security (DNSSEC) Hashed Authenticated Denial of 604 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 605 . 607 [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of 608 Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129, 609 February 2014, . 611 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 612 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 613 2015, . 615 12.2. Informative References 617 [I-D.ietf-dnsop-nxdomain-cut] 618 Bortzmeyer, S. and S. Huque, "NXDOMAIN really means there 619 is nothing underneath", draft-ietf-dnsop-nxdomain-cut-03 620 (work in progress), May 2016. 622 [I-D.vixie-dnsext-resimprove] 623 Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS 624 Resolvers for Resiliency, Robustness, and Responsiveness", 625 draft-vixie-dnsext-resimprove-00 (work in progress), June 626 2010. 628 [root-servers.org] 629 IANA, "Root Server Technical Operations Assn", 630 . 632 Appendix A. Detailed implementation notes 634 o Previously, cached negative responses were indexed by QNAME, 635 QCLASS, QTYPE, and the setting of the CD bit (see RFC 4035, 636 Section 4.7), and only queries matching the index key would be 637 answered from the cache. With aggressive negative caching, the 638 validator, in addition to checking to see if the answer is in its 639 cache before sending a query, checks to see whether any cached and 640 validated NSEC record denies the existence of the sought 641 record(s). Using aggressive negative caching, a validator will 642 not make queries for any name covered by a cached and validated 643 NSEC record. Furthermore, a validator answering queries from 644 clients will synthesize a negative answer whenever it has an 645 applicable validated NSEC in its cache unless the CD bit was set 646 on the incoming query. (Imported from Section 6 of [RFC5074]). 648 o Implementing aggressive negative caching suggests that a validator 649 will need to build an ordered data structure of NSEC and NSEC3 650 records for each signer domain name of NSEC / NSEC3 records in 651 order to efficiently find covering NSEC / NSEC3 records. Call the 652 table as NSEC_TABLE. (Imported from Section 6.1 of [RFC5074] and 653 expanded.) 655 o The aggressive negative caching may be inserted at the cache 656 lookup part of the recursive resolvers. 658 o If errors happen in aggressive negative caching algorithm, 659 resolvers MUST fall back to resolve the query as usual. "Resolve 660 the query as usual" means that the resolver must process the query 661 as though it does not implement aggressive negative caching. 663 Authors' Addresses 665 Kazunori Fujiwara 666 Japan Registry Services Co., Ltd. 667 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 668 Chiyoda-ku, Tokyo 101-0065 669 Japan 671 Phone: +81 3 5215 8451 672 Email: fujiwara@jprs.co.jp 674 Akira Kato 675 Keio University/WIDE Project 676 Graduate School of Media Design, 4-1-1 Hiyoshi 677 Kohoku, Yokohama 223-8526 678 Japan 680 Phone: +81 45 564 2490 681 Email: kato@wide.ad.jp 683 Warren Kumari 684 Google 685 1600 Amphitheatre Parkway 686 Mountain View, CA 94043 687 US 689 Email: warren@kumari.net