1 Internet Engineering Task Force (IETF) K. Fujiwara
2 Request for Comments: 8198 JPRS
3 Updates: 4035 A. Kato
4 Category: Standards Track Keio/WIDE
5 ISSN: 2070-1721 W. Kumari
6 Google
7 July 2017
8
9
10 Aggressive Use of DNSSEC-Validated Cache
11
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
Aggressive use of NSEC (not NSEC3) is implemented and enabled by default in BIND 9.18 (all versions). Ref: https://bind9.readthedocs.io/en/latest/reference.html?highlight=#namedconf-statement-synth-from-dnssec. Early implementations in BIND had poor performance, such that it could take longer to synthesize the answer than it would to resolve it again.
12 Abstract
13
14 The DNS relies upon caching to scale; however, the cache lookup
15 generally requires an exact match. This document specifies the use
16 of NSEC/NSEC3 resource records to allow DNSSEC-validating resolvers
17 to generate negative answers within a range and positive answers from
18 wildcards. This increases performance, decreases latency, decreases
19 resource utilization on both authoritative and recursive servers, and
20 increases privacy. Also, it may help increase resilience to certain
21 DoS attacks in some circumstances.
22
23 This document updates RFC 4035 by allowing validating resolvers to
24 generate negative answers based upon NSEC/NSEC3 records and positive
25 answers in the presence of wildcards.
26
27 Status of This Memo
28
29 This is an Internet Standards Track document.
30
31 This document is a product of the Internet Engineering Task Force
32 (IETF). It represents the consensus of the IETF community. It has
33 received public review and has been approved for publication by the
34 Internet Engineering Steering Group (IESG). Further information on
35 Internet Standards is available in Section 2 of RFC 7841.
36
37 Information about the current status of this document, any errata,
38 and how to provide feedback on it may be obtained at
39 http://www.rfc-editor.org/info/rfc8198.
40
41
42
43
44
45
46
47
48
49
50
51
52 Fujiwara, et al. Standards Track [Page 1]
53 RFC 8198 NSEC/NSEC3 Usage July 2017
54
55
56 Copyright Notice
57
58 Copyright (c) 2017 IETF Trust and the persons identified as the
59 document authors. All rights reserved.
60
61 This document is subject to BCP 78 and the IETF Trust's Legal
62 Provisions Relating to IETF Documents
63 (http://trustee.ietf.org/license-info) in effect on the date of
64 publication of this document. Please review these documents
65 carefully, as they describe your rights and restrictions with respect
66 to this document. Code Components extracted from this document must
67 include Simplified BSD License text as described in Section 4.e of
68 the Trust Legal Provisions and are provided without warranty as
69 described in the Simplified BSD License.
70
71 Table of Contents
72
73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
75 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
76 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
77 5. Aggressive Use of DNSSEC-Validated Cache . . . . . . . . . . 6
78 5.1. NSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 6
79 5.2. NSEC3 . . . . . . . . . . . . . . . . . . . . . . . . . . 6
80 5.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 6
81 5.4. Consideration on TTL . . . . . . . . . . . . . . . . . . 7
82 6. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 7
83 7. Update to RFC 4035 . . . . . . . . . . . . . . . . . . . . . 8
84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
87 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
88 10.2. Informative References . . . . . . . . . . . . . . . . . 10
89 Appendix A. Detailed Implementation Notes . . . . . . . . . . . 11
90 Appendix B. Procedure for Determining ENT vs. NXDOMAIN with NSEC 11
91 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107 Fujiwara, et al. Standards Track [Page 2]
108 RFC 8198 NSEC/NSEC3 Usage July 2017
109
110
111 1. Introduction
112
113 A DNS negative cache exists, and is used to cache the fact that an
114 RRset does not exist. This method of negative caching requires exact
115 matching; this leads to unnecessary additional lookups, increases
116 latency, leads to extra resource utilization on both authoritative
117 and recursive servers, and decreases privacy by leaking queries.
118
119 This document updates RFC 4035 to allow resolvers to use NSEC/NSEC3
120 resource records to synthesize negative answers from the information
121 they have in the cache. This allows validating resolvers to respond
122 with a negative answer immediately if the name in question falls into
123 a range expressed by an NSEC/NSEC3 resource record already in the
124 cache. It also allows the synthesis of positive answers in the
125 presence of wildcard records.
126
127 Aggressive negative caching was first proposed in Section 6 of DNSSEC
128 Lookaside Validation (DLV) [RFC5074] in order to find covering NSEC
129 records efficiently.
130
131 [RFC8020] and [RES-IMPROVE] propose steps to using NXDOMAIN
132 information for more effective caching. This document takes this
133 technique further.
134
135 2. Terminology
136
137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
139 "OPTIONAL" in this document are to be interpreted as described in BCP
140 14 [RFC2119] [RFC8174] when, and only when, they appear in all
141 capitals, as shown here.
142
143 Many of the specialized terms used in this document are defined in
144 DNS Terminology [RFC7719].
145
146 The key words "source of synthesis" in this document are to be
147 interpreted as described in [RFC4592].
148
149 3. Problem Statement
150
151 The DNS negative cache caches negative (non-existent) information,
152 and requires an exact match in most instances [RFC2308].
153
154 Assume that the (DNSSEC-signed) "example.com" zone contains:
155
156 albatross.example.com. IN A 192.0.2.1
157 elephant.example.com. IN A 192.0.2.2
158 zebra.example.com. IN A 192.0.2.3
159
160
161
162 Fujiwara, et al. Standards Track [Page 3]
163 RFC 8198 NSEC/NSEC3 Usage July 2017
164
165
166 If a validating resolver receives a query for cat.example.com, it
167 contacts its resolver (which may be itself) to query the example.com
168 servers and will get back an NSEC record stating that there are no
169 records (alphabetically) between albatross and elephant, or an NSEC3
170 record stating there is nothing between two hashed names. The
171 resolver then knows that cat.example.com does not exist; however, it
172 does not use the fact that the proof covers a range (albatross to
173 elephant) to suppress queries for other labels that fall within this
174 range. This means that if the validating resolver gets a query for
175 ball.example.com (or dog.example.com) it will once again go off and
176 query the example.com servers for these names.
177
178 Apart from wasting bandwidth, this also wastes resources on the
179 recursive server (it needs to keep state for outstanding queries),
180 wastes resources on the authoritative server (it has to answer
181 additional questions), increases latency (the end user has to wait
182 longer than necessary to get back an NXDOMAIN answer), can be used by
183 attackers to cause a DoS, and also has privacy implications (e.g.,
184 typos leak out further than necessary).
185
186 Another example: assume that the (DNSSEC-signed) "example.org" zone
187 contains:
188
189 avocado.example.org. IN A 192.0.2.1
190 *.example.org. IN A 192.0.2.2
191 zucchini.example.org. IN A 192.0.2.3
192
193 If a query is received for leek.example.org, the system contacts its
194 resolver (which may be itself) to query the example.org servers and
195 will get back an NSEC record stating that there are no records
196 (alphabetically) between avocado and zucchini (or an NSEC3 record
197 stating there is nothing between two hashed names), as well as an
198 answer for leek.example.org, with the label count of the signature
199 set to two (see [RFC7129], Section 5.3 for more details).
200
201 If the validating resolver gets a query for banana.example.org, it
202 will once again go off and query the example.org servers for
203 banana.example.org (even though it already has proof that there is a
204 wildcard record) -- just like above, this has privacy implications,
205 wastes resources, can be used to contribute to a DoS, etc.
206
207 4. Background
208
209 DNSSEC [RFC4035] and [RFC5155] both provide "authenticated denial of
210 existence"; this is a cryptographic proof that the queried-for name
211 does not exist or the type does not exist. Proof that a name does
212 not exist is accomplished by providing a (DNSSEC-secured) record
213 containing the names that appear alphabetically before and after the
214
215
216
217 Fujiwara, et al. Standards Track [Page 4]
218 RFC 8198 NSEC/NSEC3 Usage July 2017
219
220
221 queried-for name. In the first example above, if the (DNSSEC-
222 validating) recursive server were to query for dog.example.com, it
223 would receive a (signed) NSEC record stating that there are no labels
224 between "albatross" and "elephant" (or, for NSEC3, a similar pair of
225 hashed names). This is a signed, cryptographic proof that these
226 names are the ones before and after the queried-for label. As
227 dog.example.com falls within this range, the recursive server knows
228 that dog.example.com really does not exist. Proof that a type does
229 not exist is accomplished by providing a (DNSSEC-secured) record
230 containing the queried-for name, and a type bitmap that does not
231 include the requested type.
232
233 This document specifies that this NSEC/NSEC3 record should be used to
234 generate negative answers for any queries that the validating server
235 receives that fall within the range covered by the record (for the
236 TTL for the record). This document also specifies that a positive
237 answer should be generated for any queries that the validating server
238 receives that are proven to be covered by a wildcard record.
239
240 Section 4.5 of [RFC4035] says:
241
242 In theory, a resolver could use wildcards or NSEC RRs to generate
243 positive and negative responses (respectively) until the TTL or
244 signatures on the records in question expire. However, it seems
245 prudent for resolvers to avoid blocking new authoritative data or
246 synthesizing new data on their own. Resolvers that follow this
247 recommendation will have a more consistent view of the namespace.
248
249 And, earlier, Section 4.5 of [RFC4035] says:
250
251 The reason for these recommendations is that, between the initial
252 query and the expiration of the data from the cache, the
253 authoritative data might have been changed (for example, via
254 dynamic update).
255
256 In other words, if a resolver generates negative answers from an NSEC
257 record, it will not send any queries for names within that NSEC range
258 (for the TTL). If a new name is added to the zone during this
259 interval, the resolver will not know this. Similarly, if the
260 resolver is generating responses from a wildcard record, it will
261 continue to do so (for the TTL).
262
263 We believe that this recommendation can be relaxed because, in the
264 absence of this technique, a lookup for the exact name could have
265 come in during this interval, and so a negative answer could already
266 be cached (see [RFC2308] for more background). This means that zone
267 operators should have no expectation that an added name would work
268 immediately. With DNSSEC and aggressive use of DNSSEC-validated
269
270
271
272 Fujiwara, et al. Standards Track [Page 5]
273 RFC 8198 NSEC/NSEC3 Usage July 2017
274
275
276 cache, the TTL of the NSEC/NSEC3 record and the SOA.MINIMUM field are
277 the authoritative statement of how quickly a name can start working
278 within a zone.
279
280 5. Aggressive Use of DNSSEC-Validated Cache
281
282 This document relaxes the restriction given in Section 4.5 of
283 [RFC4035]. See Section 7 for more detail.
284
285 If the negative cache of the validating resolver has sufficient
286 information to validate the query, the resolver SHOULD use NSEC,
287 NSEC3, and wildcard records to synthesize answers as described in
288 this document. Otherwise, it MUST fall back to send the query to the
289 authoritative DNS servers.
290
291 5.1. NSEC
292
293 The validating resolver needs to check the existence of an NSEC RR
294 matching/covering the source of synthesis and an NSEC RR covering the
295 query name.
296
297 If denial of existence can be determined according to the rules set
298 out in Section 5.4 of [RFC4035], using NSEC records in the cache,
299 then the resolver can immediately return an NXDOMAIN or NODATA (as
300 appropriate) response.
301
302 5.2. NSEC3
303
304 NSEC3 aggressive negative caching is more difficult than NSEC
305 aggressive caching. If the zone is signed with NSEC3, the validating
306 resolver needs to check the existence of non-terminals and wildcards
307 that derive from query names.
308
309 If denial of existence can be determined according to the rules set
310 out in [RFC5155], Sections 8.4, 8.5, 8.6, and 8.7, using NSEC3
311 records in the cache, then the resolver can immediately return an
312 NXDOMAIN or NODATA response (as appropriate).
313
314 If a covering NSEC3 RR has an Opt-Out flag, the covering NSEC3 RR
315 does not prove the non-existence of the domain name and the
316 aggressive negative caching is not possible for the domain name.
317
318 5.3. Wildcards
319
320 The last paragraph of [RFC4035], Section 4.5 also discusses the use
321 of wildcards and NSEC RRs to generate positive responses and
322 recommends that it not be relied upon. Just like the case for the
323
324
325
326
327 Fujiwara, et al. Standards Track [Page 6]
328 RFC 8198 NSEC/NSEC3 Usage July 2017
329
330
331 aggressive use of NSEC/NSEC3 for negative answers, we revise this
332 recommendation.
333
334 As long as the validating resolver can determine that a name would
335 not exist without the wildcard match, determined according to the
336 rules set out in Section 5.3.4 of [RFC4035] (NSEC), or in Section 8.8
337 of [RFC5155], it SHOULD synthesize an answer (or NODATA response) for
338 that name using the cache-deduced wildcard. If the corresponding
339 wildcard record is not in the cache, it MUST fall back to send the
340 query to the authoritative DNS servers.
341
RFC9077 changes the definition of the NSEC and NSEC3 TTL to fix a problem where aggressive use of NSEC and NSEC3 records may deny the existence of names far beyond the intended lifetime of a denial.
342 5.4. Consideration on TTL
343
344 The TTL value of negative information is especially important,
345 because newly added domain names cannot be used while the negative
346 information is effective.
347
348 Section 5 of [RFC2308] suggests a maximum default negative cache TTL
349 value of 3 hours (10800). It is RECOMMENDED that validating
350 resolvers limit the maximum effective TTL value of negative responses
351 (NSEC/NSEC3 RRs) to this same value.
352
353 Section 5 of [RFC2308] also states that a negative cache entry TTL is
354 taken from the minimum of the SOA.MINIMUM field and SOA's TTL. This
355 can be less than the TTL of an NSEC or NSEC3 record, since their TTL
356 is equal to the SOA.MINIMUM field (see [RFC4035], Section 2.3 and
357 [RFC5155], Section 3).
358
359 A resolver that supports aggressive use of NSEC and NSEC3 SHOULD
360 reduce the TTL of NSEC and NSEC3 records to match the SOA.MINIMUM
361 field in the authority section of a negative response, if SOA.MINIMUM
362 is smaller.
363
364 6. Benefits
365
366 The techniques described in this document provide a number of
367 benefits, including (in no specific order):
368
369 Reduced latency: By answering directly from cache, validating
370 resolvers can immediately inform clients that the name they are
371 looking for does not exist, improving the user experience.
372
373 Decreased recursive server load: By answering queries from the cache
374 by synthesizing answers, validating servers avoid having to send a
375 query and wait for a response. In addition to decreasing the
376 bandwidth used, it also means that the server does not need to
377 allocate and maintain state, thereby decreasing memory and CPU
378 load.
379
380
381
382 Fujiwara, et al. Standards Track [Page 7]
383 RFC 8198 NSEC/NSEC3 Usage July 2017
384
385
386 Decreased authoritative server load: Because recursive servers can
387 answer queries without asking the authoritative server, the
388 authoritative servers receive fewer queries. This decreases the
389 authoritative server bandwidth, queries per second, and CPU
390 utilization.
391
392 The scale of the benefit depends upon multiple factors, including the
393 query distribution. For example, at the time of this writing, around
394 65% of queries to root name servers result in NXDOMAIN responses (see
395 statistics from [ROOT-SERVERS]); this technique will eliminate a
396 sizable quantity of these.
397
398 The technique described in this document may also mitigate so-called
399 "random QNAME attacks", in which attackers send many queries for
400 random subdomains to resolvers. As the resolver will not have the
401 answers cached, it has to ask external servers for each random query,
402 leading to a DoS on the authoritative servers (and often resolvers).
403 The technique may help mitigate these attacks by allowing the
404 resolver to answer directly from the cache for any random queries
405 that fall within already requested ranges. It will not always work
406 as an effective defense, not least because not many zones are DNSSEC
407 signed at all -- but it will still provide an additional layer of
408 defense.
409
410 As these benefits are only accrued by those using DNSSEC, it is hoped
411 that these techniques will lead to more DNSSEC deployment.
412
413 7. Update to RFC 4035
414
415 Section 4.5 of [RFC4035] shows that "In theory, a resolver could use
416 wildcards or NSEC RRs to generate positive and negative responses
417 (respectively) until the TTL or signatures on the records in question
418 expire. However, it seems prudent for resolvers to avoid blocking
419 new authoritative data or synthesizing new data on their own.
420 Resolvers that follow this recommendation will have a more consistent
421 view of the namespace".
422
423 The paragraph is updated as follows:
424
425 +-----------------------------------------------------------------+
426 | Once the records are validated, DNSSEC-enabled validating |
427 | resolvers SHOULD use wildcards and NSEC/NSEC3 resource records |
428 | to generate positive and negative responses until the |
429 | effective TTLs or signatures for those records expire. |
430 +-----------------------------------------------------------------+
431
432
433
434
435
436
437 Fujiwara, et al. Standards Track [Page 8]
438 RFC 8198 NSEC/NSEC3 Usage July 2017
439
440
441 8. IANA Considerations
442
443 This document does not require any IANA actions.
444
445 9. Security Considerations
446
447 Use of NSEC/NSEC3 resource records without DNSSEC validation may
448 create serious security issues, and so this technique requires DNSSEC
449 validation.
450
451 Newly registered resource records may not be used immediately.
452 However, choosing a suitable TTL value and a negative cache TTL value
453 (SOA.MINIMUM field) will mitigate the delay concern, and it is not a
454 security problem.
455
456 It is also suggested to limit the maximum TTL value of NSEC/NSEC3
457 resource records in the negative cache to, for example, 10800 seconds
458 (3 hours), to mitigate this issue.
459
460 Although the TTL of NSEC/NSEC3 records is typically fairly short
461 (minutes or hours), their RRSIG expiration time can be much further
462 in the future (weeks). An attacker who is able to successfully spoof
463 responses might poison a cache with old NSEC/NSEC3 records. If the
464 resolver is not making aggressive use of NSEC/NSEC3, the attacker has
465 to repeat the attack for every query. If the resolver is making
466 aggressive use of NSEC/NSEC3, one successful attack would be able to
467 suppress many queries for new names, up to the negative TTL.
468
469 10. References
470
471 10.1. Normative References
472
473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
474 Requirement Levels", BCP 14, RFC 2119,
475 DOI 10.17487/RFC2119, March 1997,
476 <http://www.rfc-editor.org/info/rfc2119>.
477
478 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
479 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
480 <http://www.rfc-editor.org/info/rfc2308>.
481
482 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
483 Rose, "Protocol Modifications for the DNS Security
484 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
485 <http://www.rfc-editor.org/info/rfc4035>.
486
487
488
489
490
491
492 Fujiwara, et al. Standards Track [Page 9]
493 RFC 8198 NSEC/NSEC3 Usage July 2017
494
495
496 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
497 System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
498 <http://www.rfc-editor.org/info/rfc4592>.
499
500 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
501 Security (DNSSEC) Hashed Authenticated Denial of
502 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
503 <http://www.rfc-editor.org/info/rfc5155>.
504
505 [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of
506 Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129,
507 February 2014, <http://www.rfc-editor.org/info/rfc7129>.
508
509 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
510 Terminology", RFC 7719, DOI 10.17487/RFC7719, December
511 2015, <http://www.rfc-editor.org/info/rfc7719>.
512
513 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
514 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
515 May 2017, <http://www.rfc-editor.org/info/rfc8174>.
516
517 10.2. Informative References
518
519 [RES-IMPROVE]
520 Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS
521 Resolvers for Resiliency, Robustness, and Responsiveness",
522 Work in Progress, draft-vixie-dnsext-resimprove-00, June
523 2010.
524
525 [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074,
526 DOI 10.17487/RFC5074, November 2007,
527 <http://www.rfc-editor.org/info/rfc5074>.
528
529 [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is
530 Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,
531 November 2016, <http://www.rfc-editor.org/info/rfc8020>.
532
533 [ROOT-SERVERS]
534 "Root Server Technical Operations Assn",
535 <http://www.root-servers.org/>.
536
537
538
539
540
541
542
543
544
545
546
547 Fujiwara, et al. Standards Track [Page 10]
548 RFC 8198 NSEC/NSEC3 Usage July 2017
549
550
551 Appendix A. Detailed Implementation Notes
552
553 o Previously, cached negative responses were indexed by QNAME,
554 QCLASS, QTYPE, and the setting of the CD bit (see RFC 4035,
555 Section 4.7), and only queries matching the index key would be
556 answered from the cache. With aggressive negative caching, the
557 validator, in addition to checking to see if the answer is in its
558 cache before sending a query, checks to see whether any cached and
559 validated NSEC record denies the existence of the sought
560 record(s). Using aggressive negative caching, a validator will
561 not make queries for any name covered by a cached and validated
562 NSEC record. Furthermore, a validator answering queries from
563 clients will synthesize a negative answer (or NODATA response)
564 whenever it has an applicable validated NSEC in its cache unless
565 the CD bit was set on the incoming query. (Imported from
566 Section 6 of [RFC5074].)
567
568 o Implementing aggressive negative caching suggests that a validator
569 will need to build an ordered data structure of NSEC and NSEC3
570 records for each signer domain name of NSEC/NSEC3 records in order
571 to efficiently find covering NSEC/NSEC3 records. Call the table
572 as "NSEC_TABLE". (Imported from Section 6.1 of [RFC5074] and
573 expanded.)
574
575 o The aggressive negative caching may be inserted at the cache
576 lookup part of the recursive resolvers.
577
578 o If errors happen in an aggressive negative caching algorithm,
579 resolvers MUST fall back to resolve the query as usual. "Resolve
580 the query as usual" means that the resolver must process the query
581 as though it does not implement aggressive negative caching.
582
583 Appendix B. Procedure for Determining ENT vs. NXDOMAIN with NSEC
584
585 This procedure outlines how to determine if a given name does not
586 exist, or is an ENT (empty non-terminal; see [RFC5155], Section 1.3)
587 with NSEC.
588
589 If the NSEC record has not been verified as secure, discard it.
590
591 If the given name sorts before or matches the NSEC owner name,
592 discard it as it does not prove the NXDOMAIN or ENT.
593
594 If the given name is a subdomain of the NSEC owner name and the NS
595 bit is present and the SOA bit is absent, then discard the NSEC as it
596 is from a parent zone.
597
598
599
600
601
602 Fujiwara, et al. Standards Track [Page 11]
603 RFC 8198 NSEC/NSEC3 Usage July 2017
604
605
606 If the next domain name sorts after the NSEC owner name and the given
607 name sorts after or matches next domain name, then discard the NSEC
608 record as it does not prove the NXDOMAIN or ENT.
609
610 If the next domain name sorts before or matches the NSEC owner name
611 and the given name is not a subdomain of the next domain name, then
612 discard the NSEC as it does not prove the NXDOMAIN or ENT.
613
614 You now have an NSEC record that proves the NXDOMAIN or ENT.
615
616 If the next domain name is a subdomain of the given name, you have an
617 ENT. Otherwise, you have an NXDOMAIN.
618
619 Acknowledgments
620
621 The authors gratefully acknowledge DNSSEC Lookaside Validation (DLV)
622 [RFC5074] author Samuel Weiler and the Unbound developers.
623
624 Thanks to Mark Andrews for providing the helpful notes for
625 implementors provided in Appendix B.
626
627 The authors would like to specifically thank Stephane Bortzmeyer (for
628 standing next to and helping edit), Ralph Dolmans, Tony Finch, Tatuya
629 JINMEI for extensive review and comments, and also Mark Andrews,
630 Casey Deccio, Alexander Dupuy, Olafur Gudmundsson, Bob Harold, Shumon
631 Huque, John Levine, Pieter Lexis, Matthijs Mekking (who even sent
632 pull requests!), and Ondrej Sury.
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657 Fujiwara, et al. Standards Track [Page 12]
658 RFC 8198 NSEC/NSEC3 Usage July 2017
659
660
661 Authors' Addresses
662
663 Kazunori Fujiwara
664 Japan Registry Services Co., Ltd.
665 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
666 Chiyoda-ku, Tokyo 101-0065
667 Japan
668
669 Phone: +81 3 5215 8451
670 Email: fujiwara@jprs.co.jp
671
672
673 Akira Kato
674 Keio University/WIDE Project
675 Graduate School of Media Design, 4-1-1 Hiyoshi
676 Kohoku, Yokohama 223-8526
677 Japan
678
679 Phone: +81 45 564 2490
680 Email: kato@wide.ad.jp
681
682
683 Warren Kumari
684 Google
685 1600 Amphitheatre Parkway
686 Mountain View, CA 94043
687 United States of America
688
689 Email: warren@kumari.net
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712 Fujiwara, et al. Standards Track [Page 13]
713
But the NSEC and NSEC3 RRs should, according to RFC4034 and RFC5155, already be at the value of the MINIMUM field in the SOA. Thus, the advice from RFC8198 would not actually change the TTL used for the NSEC and NSEC3 RRs for authoritative servers that follow the RFCs.
It also says:
RFC8198, Section 5.4 ("Consideration on TTL") is completely replaced by the following text: | The TTL value of negative information is especially important, | because newly added domain names cannot be used while the negative | information is effective. | | Section 5 of RFC2308 suggests a maximum default negative cache | TTL value of 3 hours (10800). It is RECOMMENDED that validating | resolvers limit the maximum effective TTL value of negative | responses (NSEC/NSEC3 RRs) to this same value. | | A resolver that supports aggressive use of NSEC and NSEC3 MAY | limit the TTL of NSEC and NSEC3 records to the lesser of the | SOA.MINIMUM field and the TTL of the SOA in a response, if | present. It MAY also use a previously cached SOA for a zone to | find these values. (The third paragraph of the original is removed, and the fourth paragraph is updated to allow resolvers to also take the lesser of the SOA TTL and SOA MINIMUM.)