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