idnits 2.17.1 draft-fujiwara-dnsop-nsec-aggressiveuse-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 06, 2015) is 3216 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-dnsop-dns-terminology-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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 Intended status: Informational A. Kato 5 Expires: January 7, 2016 Keio/WIDE 6 July 06, 2015 8 Aggressive use of NSEC/NSEC3 9 draft-fujiwara-dnsop-nsec-aggressiveuse-01 11 Abstract 13 While DNS highly depends on cache, its cache usage of non-existence 14 information was limited to exact matching. This draft proposes the 15 aggressive use of a NSEC/NSEC3 resource record, which is able to 16 express non-existence of range of names authoritatively. With this 17 proposal, shorter latency to many of negative responses is expected 18 as well as some level of mitigation of random sub-domain attacks 19 (referred to as "Water Torture" attacks). It is also expected that 20 non-existent TLD queries to Root DNS servers will decrease. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 7, 2016. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Proposed Solution: Aggressive Negative Caching . . . . . . . 3 60 5. Possible side effect . . . . . . . . . . . . . . . . . . . . 5 61 6. Another option . . . . . . . . . . . . . . . . . . . . . . . 5 62 7. Aggressive negative caching flag . . . . . . . . . . . . . . 6 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 10. Implementation Considerations . . . . . . . . . . . . . . . . 6 66 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 67 12. Change History . . . . . . . . . . . . . . . . . . . . . . . 7 68 12.1. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 7 69 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 13.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 13.2. Informative References . . . . . . . . . . . . . . . . . 8 72 Appendix A. Aggressive negative caching from RFC 5074 . . . . . 8 73 Appendix B. Detailed implementation idea . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 While negative (non-existence) information of DNS caching mechanism 79 has been known as DNS negative cache [RFC2308], it requires exact 80 matching in most cases. Assume that "example.com" zone doesn't have 81 names such as "a.example.com" and "b.example.com". When a full- 82 service resolver receives a query "a.example.com" , it performs a DNS 83 resolution process, and eventually gets NXDOMAIN and stores it into 84 its negative cache. When the full-service resolver receives another 85 query "b.example.com", it doesn't match with "a.example.com". So it 86 will send a query to one of the authoritative servers of 87 "example.com". This was because the NXDOMAIN response just says 88 there is no such name "a.example.com" and it doesn't tell anything 89 for "b.example.com". 91 Recently, DNSSEC [RFC4035] [RFC5155] has been practically deployed. 92 Two types of resource record (NSEC and NSEC3) are used for authentic 93 non-existence. For a zone signed with NSEC, it may be possible to 94 use the information carried in NSEC resource records to indicate that 95 the range of names where no valid name exists. Such use is 96 discouraged by Section 4.5 of RFC 4035, however. 98 This document proposes to make a minor change to RFC 4035 and the 99 full-service resolver can use NSEC/NSEC3 resource records 100 aggressively. 102 Aggressive Negative Caching was first proposed in Section 6 of DNSSEC 103 Lookaside Validation (DLV) [RFC5074] in order to find covering NSEC 104 records efficiently. Unbound [UNBOUND] has aggressive negative 105 caching code in its DLV validator. Unbound TODO file contains "NSEC/ 106 NSEC3 aggressive negative caching". 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 Many of the specialized terms used in this specification are defined 115 in DNS Terminology [I-D.ietf-dnsop-dns-terminology]. 117 3. Problem Statement 119 Random sub-domain attacks (referred to as "Water Torture" attacks) 120 send many non-existent queries to full-service resolvers. Their 121 query names consist of random prefixes and a target domain name. The 122 negative cache does not work well and target full-service resolvers 123 result in sending queries to authoritative DNS servers of the target 124 domain name. 126 When number of queries is large, the full-service resolvers drop 127 queries from both legitimate users and attackers as their outstanding 128 queues are filled up. 130 For example, BIND 9.10.2 [BIND9] full-service resolvers answer 131 SERVFAIL and Unbound 1.5.2 full-service resolvers drop most of 132 queries under 10,000 queries per second attack. 134 The countermeasures implemented at this moment are rate limiting and 135 disabling name resolution of target domain names. 137 4. Proposed Solution: Aggressive Negative Caching 139 If the target domain names are DNSSEC signed, aggressive use of NSEC/ 140 NSEC3 resource records mitigates the problem. 142 Section 4.5 of [RFC4035] shows that "In theory, a resolver could use 143 wildcards or NSEC RRs to generate positive and negative responses 144 (respectively) until the TTL or signatures on the records in question 145 expire. However, it seems prudent for resolvers to avoid blocking 146 new authoritative data or synthesizing new data on their own. 147 Resolvers that follow this recommendation will have a more consistent 148 view of the namespace". 150 To reduce non-existent queries sent to authoritative DNS servers, it 151 is suggested to relax this restriction as follows: 153 +--------------------------------------------------------------+ 154 | DNSSEC enabled full-service resolvers MAY use | 155 | NSEC/NSEC3 resource records to generate negative responses | 156 | until their effective TTLs or signatures on the records | 157 | in question expire. | 158 +--------------------------------------------------------------+ 160 If the full-service resolver's cache have enough information to 161 validate the query, the full-service resolver MAY use NSEC/NSEC3/ 162 wildcard records aggressively. Otherwise, the full-service resolver 163 MUST fall back to send the query to the authoritative DNS servers. 165 Necessary information to validate are wildcards which match the query 166 name, covering NSEC/NSEC3 of the wildcards, and covering NSEC/NSEC3 167 of (parts of) the query name. 169 If the zone has a wildcard and it is in the full-service resolver's 170 cache, the full-service resolver MAY generate positive responses 171 based on the information associated with the wildcard in the cache. 173 This approach is effective for DNSSEC signed zones with NSEC or 174 NSEC3, except zones with NSEC3 Opt-Out. To identify signing types of 175 the zone, validating resolvers need to build special cache of NSEC 176 and NSEC3 resource records for each signer domain name. When a query 177 name is not in the cache, find closest enclosing NS RRset in the 178 cache. The owner of this NS RRset may be the longest signer domain 179 name of the query name. If the NSEC/NSEC3 cache of the signer domain 180 name is empty, the aggressive negative caching is not possible. 181 Otherwise, there is at least one NSEC or NSEC3 resource records. The 182 record shows the signing type. If the resource record is NSEC3 and 183 with Opt-Out, the aggressive negative caching is not possible. 185 When the query name has a matching NSEC resource records in the cache 186 and there is no wildcard in the zone which the query name matches 187 with, the full-service resolver is allowed to respond with NXDOMAIN 188 error immediately. 190 NSEC3 aggressive negative caching is more difficult. If the zone is 191 signed with NSEC3, the validating resolver need to check the 192 existence of each label from the query name. If a label is not exist 193 in the zone, and there is no matching wildcard in the zone, the full- 194 service resolver is allowed to respond with NXDOMAIN error 195 immediately. 197 This function needs care on the TTL value of negative information 198 because newly added domain names cannot be used while the negative 199 information is effective. RFC 2308 states the maximum number of 200 negative cache TTL value is 10800 (3 hours). So the full-service 201 resolver SHOULD limit the maximum effective TTL value of negative 202 responses (NSEC/NSEC3 RRs) to 10800 (3 hours). It is reasonably 203 small but still effective for the purpose of this document as it can 204 eliminate significant amount of DNS attacks with randomly generated 205 names. 207 The same discussion is also applicable to wildcards. If a query name 208 is covered by a NSEC or a NSEC3 resource record in the cache and 209 there is a covering wildcard, the full-service resolver MAY use 210 wildcards to generate positive responses while wildcard and NSEC/ 211 NSEC3 resource records in the cache are effective. 213 5. Possible side effect 215 Aggressive use of NSEC/NSEC3 resource records may decrease queries to 216 Root DNS servers. 218 People may generate many typos in TLD, and they will result in 219 unnecessary DNS queries. Some implementations leak non-existent TLD 220 queries whose second level domain are different each other. Well 221 observed TLDs are ".local" and ".belkin". With this proposal, it is 222 possible to return NXDOMAIN immediately to such queries without 223 further DNS recursive resolution process. It may reduces round trip 224 time, as well as reduces the DNS queries to corresponding 225 authoritative servers, including Root DNS servers. 227 6. Another option 229 The proposed technique is applicable to zones where there is a NSEC 230 record to each owner name in the zone even without DNSSEC signed. 231 And it is also applicable to full-service resolvers without DNSSEC 232 validation. Full-service resolvers can set DNSSEC OK bit in query 233 packets and they will cache NSEC/NSEC3 resource records. They can 234 apply aggressive use of NSEC/NSEC3 resource records without DNSSEC 235 validation. 237 It is highly recommended to sign the zone, of course, and it is 238 recommended to apply DNSSEC validation of NSEC record prior to cache 239 it in the negative cache. 241 7. Aggressive negative caching flag 243 Authoritative DNS servers that dynamically generate NSEC records 244 normally generate minimally covering NSEC Records [RFC4470]. 245 Aggressive negative caching does not work with minimally covering 246 NSEC records. DNS operators don't want zone walking and zone 247 information leaks. They prefer NSEC resource records with narrow 248 ranges. When a query have the aggressive negative caching flag (AN 249 flag), they can generate NSEC resource records with wider range under 250 random subdomain attacks. 252 A full-service resolver which supports aggressive negative caching 253 SHOULD set the AN flag when sending queries to authoritative DNS 254 servers. 256 8. IANA Considerations 258 This document reserves one of these bits as the AN flag (Aggressive 259 Negative Caching flag) in EDNS Header Flags defined in EDNS0 260 [RFC6891]. 262 9. Security Considerations 264 Newly registered resource records may not be used immediately. 265 However, choosing suitable TTL value will mitigate the problem and it 266 is not a security problem. 268 It is also suggested to limit the maximum TTL value of NSEC resource 269 records in the negative cache to, for example, 10800 seconds (3hrs), 270 to mitigate the issue. Implementations which comply with this 271 proposal is suggested to have a configurable maximum value of NSEC 272 RRs in the negative cache. 274 Aggressive use of NSEC/NSEC3 resource records without DNSSEC 275 validation may cause security problems. 277 10. Implementation Considerations 279 Unbound has aggressive negative caching code in its DLV validator. 280 The author implemented NSEC aggressive caching using Unbound and its 281 DLV validator code. 283 11. Acknowledgments 285 The authors gratefully acknowledge DLV [RFC5074] author Samuel Weiler 286 and Unbound developers. Olafur Gudmundsson and Pieter Lexis proposed 287 aggressive negative caching flag idea. 289 12. Change History 291 This section is used for tracking the update of this document. Will 292 be removed after finalize. 294 12.1. Version 01 296 o Added reference to DLV [RFC5074] and imported some sentences. 298 o Added Aggressive Negative Caching Flag idea. 300 o Added detailed algorithms. 302 13. References 304 13.1. Normative References 306 [I-D.ietf-dnsop-dns-terminology] 307 Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 308 Terminology", draft-ietf-dnsop-dns-terminology-03 (work in 309 progress), June 2015. 311 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 312 Requirement Levels", BCP 14, RFC 2119, March 1997. 314 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 315 NCACHE)", RFC 2308, March 1998. 317 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 318 Rose, "Protocol Modifications for the DNS Security 319 Extensions", RFC 4035, March 2005. 321 [RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records 322 and DNSSEC On-line Signing", RFC 4470, April 2006. 324 [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074, 325 November 2007. 327 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 328 Security (DNSSEC) Hashed Authenticated Denial of 329 Existence", RFC 5155, March 2008. 331 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 332 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 334 13.2. Informative References 336 [BIND9] Internet Systems Consortium, Inc., "Name Server Software", 337 2000, . 339 [UNBOUND] NLnet Labs, "Unbound DNS validating resolver", 2006, 340 . 342 Appendix A. Aggressive negative caching from RFC 5074 344 Imported from RFC 5074. 346 Previously, cached negative responses were indexed by QNAME, QCLASS, 347 QTYPE, and the setting of the CD bit (see RFC 4035, Section 4.7), and 348 only queries matching the index key would be answered from the cache. 349 With aggressive negative caching, the validator, in addition to 350 checking to see if the answer is in its cache before sending a query, 351 checks to see whether any cached and validated NSEC record denies the 352 existence of the sought record(s). 354 Using aggressive negative caching, a validator will not make queries 355 for any name covered by a cached and validated NSEC record. 356 Furthermore, a validator answering queries from clients will 357 synthesize a negative answer whenever it has an applicable validated 358 NSEC in its cache unless the CD bit was set on the incoming query. 360 Implementing aggressive negative caching suggests that a validator 361 will need to build an ordered data structure of NSEC records in order 362 to efficiently find covering NSEC records. Only NSEC records from 363 DLV domains need to be included in this data structure. 365 Appendix B. Detailed implementation idea 367 Implementing aggressive negative caching suggests that a validator 368 need to build an ordered data structure of NSEC/NSEC3 records for 369 each signer domain name in order to efficiently find covering NSEC/ 370 NSEC3 records. 372 If errors happen in aggressive negative caching algorithm, resolvers 373 MUST fall back to resolve the query as usual. "Resolve the query as 374 usual" means that the full-resolver resolve the query in Recursive- 375 mode. 377 To implement aggressive negative caching, resolver algorithm near 378 cache lookup will be changed as follows: 380 If the query name entry exists in the cache { 381 resolve the query as usual. 383 // if RRSet (query name and query type) exists in the cache, 384 // the resolver responds the RRSet from the cache 385 // Otherwise, the resolver needs to iterate the query. 386 } 388 // Find closest enclosing NS RRset in the cache. 389 // The owner of this NS RRset will be a suffix of the QNAME 390 // - the longest suffix of any NS RRset in the cache. 391 SIGNER = closest enclosing NS RRSet of the QNAME in the cache. 393 If SIGNER zone does not have a special NSEC/NSEC3 data structure { 394 Resolve the query as usual. 395 } 397 if SIGNER zone is not signed or not validated { 398 Resolve the query as usual 399 } 401 If SIGNER zone is signed with NSEC { 402 // NSEC mode 403 If covering NSEC RR of the query name at SIGNER zone 404 doesn't exist in the cache { 405 Resolve the query as usual. 406 } 408 TEST = Find the longest existing domain name of the query name 409 from the covering NSEC RR 411 if "*.TEST" exists in the cache { 412 the resolver can generate positive response 413 or resolve the query as usual. 414 } 416 if covering NSEC RR of "*.TEST" at SIGNER zone exists 417 in the cache { 418 the resolver can generate negative response. 419 } 421 // Lack of information, need to resolve the query as usual 423 } else 424 if SIGNER zone is signed with NSEC3 and does not use Opt-Out { 425 // NSEC3 mode 427 QNAME = the query name 428 TEST = SIGNER 429 do { 430 UPPER = TEST 431 add a label from the QNAME to the start of TEST 432 If the covering NSEC3 of TEST exist in the cache { 433 // non-terminal name TEST does not exist 434 if *.UPPER or NSEC3 of *.UPPPER exist in the cache { 435 the resolver can generate negative response. 436 } else { 437 if the covering NSEC3 of *.UPPER exist in the cache { 438 the resolver can generate positive response. 439 } 440 // lack of information 441 break 442 } else 443 if the NSEC3 of TEST does not exist { 444 // lack of information 445 break 446 } 447 // TEST label exist, then need to check the rest of the QNAME 448 } while(TEST != QNAME) 449 // lack of information 450 } 451 Resolve the query as usual 453 Authors' Addresses 455 Kazunori Fujiwara 456 Japan Registry Services Co., Ltd. 457 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 458 Chiyoda-ku, Tokyo 101-0065 459 Japan 461 Phone: +81 3 5215 8451 462 Email: fujiwara@jprs.co.jp 464 Akira Kato 465 Keio University/WIDE Project 466 Graduate School of Media Design, 4-1-1 Hiyoshi 467 Kohoku, Yokohama 223-8526 468 Japan 470 Phone: +81 45 564 2490 471 Email: kato@wide.ad.jp