1 Internet Engineering Task Force (IETF) D. Wessels
2 Request for Comments: 9520 W. Carroll
3 Updates: 2308, 4035, 4697 M. Thomas
4 Category: Standards Track Verisign
5 ISSN: 2070-1721 December 2023
6
7
8 Negative Caching of DNS Resolution Failures
9
10 Abstract
11
12 In the DNS, resolvers employ caching to reduce both latency for end
13 users and load on authoritative name servers. The process of
14 resolution may result in one of three types of responses: (1) a
15 response containing the requested data, (2) a response indicating the
16 requested data does not exist, or (3) a non-response due to a
17 resolution failure in which the resolver does not receive any useful
18 information regarding the data's existence. This document concerns
19 itself only with the third type.
20
21 RFC 2308 specifies requirements for DNS negative caching. There,
22 caching of TYPE 2 responses is mandatory and caching of TYPE 3
23 responses is optional. This document updates RFC 2308 to require
24 negative caching for DNS resolution failures.
25
26 RFC 4035 allows DNSSEC validation failure caching. This document
27 updates RFC 4035 to require caching for DNSSEC validation failures.
28
29 RFC 4697 prohibits aggressive requerying for NS records at a failed
30 zone's parent zone. This document updates RFC 4697 to expand this
31 requirement to all query types and to all ancestor zones.
32
33 Status of This Memo
34
35 This is an Internet Standards Track document.
36
37 This document is a product of the Internet Engineering Task Force
38 (IETF). It represents the consensus of the IETF community. It has
39 received public review and has been approved for publication by the
40 Internet Engineering Steering Group (IESG). Further information on
41 Internet Standards is available in Section 2 of RFC 7841.
42
43 Information about the current status of this document, any errata,
44 and how to provide feedback on it may be obtained at
45 https://www.rfc-editor.org/info/rfc9520.
46
47 Copyright Notice
48
49 Copyright (c) 2023 IETF Trust and the persons identified as the
50 document authors. All rights reserved.
51
52 This document is subject to BCP 78 and the IETF Trust's Legal
53 Provisions Relating to IETF Documents
54 (https://trustee.ietf.org/license-info) in effect on the date of
55 publication of this document. Please review these documents
56 carefully, as they describe your rights and restrictions with respect
57 to this document. Code Components extracted from this document must
58 include Revised BSD License text as described in Section 4.e of the
59 Trust Legal Provisions and are provided without warranty as described
60 in the Revised BSD License.
61
62 Table of Contents
63
64 1. Introduction
65 1.1. Motivation
66 1.2. Related Work
67 1.3. Terminology
68 2. Conditions That Lead to DNS Resolution Failures
69 2.1. SERVFAIL Responses
70 2.2. REFUSED Responses
71 2.3. Timeouts and Unreachable Servers
72 2.4. Delegation Loops
73 2.5. Alias Loops
74 2.6. DNSSEC Validation Failures
75 2.7. FORMERR Responses
76 3. Requirements for Caching DNS Resolution Failures
77 3.1. Retries and Timeouts
78 3.2. Caching
79 3.3. Requerying Delegation Information
80 3.4. DNSSEC Validation Failures
81 4. IANA Considerations
82 5. Security Considerations
83 6. Privacy Considerations
84 7. References
85 7.1. Normative References
86 7.2. Informative References
87 Acknowledgments
88 Authors' Addresses
89
90 1. Introduction
91
92 Caching has always been a fundamental component of DNS resolution on
93 the Internet. For example, [RFC0882] states:
94
95 | The sheer size of the database and frequency of updates suggest
96 | that it must be maintained in a distributed manner, with local
97 | caching to improve performance.
98
99 The early DNS RFCs ([RFC0882], [RFC0883], [RFC1034], and [RFC1035])
100 primarily discuss caching in the context of what [RFC2308] calls
101 "positive responses", that is, when the response includes the
102 requested data. In this case, a TTL is associated with each Resource
103 Record (RR) in the response. Resolvers can cache and reuse the data
104 until the TTL expires.
105
106 Section 4.3.4 of [RFC1034] describes negative response caching, but
107 notes it is optional and only talks about name errors (NXDOMAIN).
108 This is the origin of using the SOA MINIMUM field as a negative
109 caching TTL.
110
111 [RFC2308] updated [RFC1034] to specify new requirements for DNS
112 negative caching, including making it mandatory for caching resolvers
113 to cache name error (NXDOMAIN) and no data (NODATA) responses when an
114 SOA record is available to provide a TTL. [RFC2308] further
115 specified optional negative caching for two DNS resolution failure
116 cases: server failure and dead/unreachable servers.
117
118 This document updates [RFC2308] to require negative caching of all
119 DNS resolution failures and provides additional examples of
120 resolution failures, [RFC4035] to require caching for DNSSEC
121 validation failures, as well as [RFC4697] to expand the scope of
122 prohibiting aggressive requerying for NS records at a failed zone's
123 parent zone to all query types and to all ancestor zones.
124
125 1.1. Motivation
126
127 Operators of DNS services have known for some time that recursive
128 resolvers become more aggressive when they experience resolution
129 failures. A number of different anecdotes, experiments, and
130 incidents support this claim.
131
132 In December 2009, a secondary server for a number of in-addr.arpa
133 subdomains saw its traffic suddenly double, and queries of type
134 DNSKEY in particular increase by approximately two orders of
135 magnitude, coinciding with a DNSSEC key rollover by the zone operator
136 [DNSSEC-ROLLOVER]. This predated a signed root zone, and an
137 operating system vendor was providing non-root trust anchors to the
138 recursive resolver, which became out of date following the rollover.
139 Unable to validate responses for the affected in-addr.arpa zones,
140 recursive resolvers aggressively retried their queries.
141
142 In 2016, the Internet infrastructure company Dyn experienced a large
143 attack that impacted many high-profile customers. As documented in a
144 technical presentation detailing the attack (see [RETRY-STORM]), Dyn
145 staff wrote:
146
147 | At this point we are now experiencing botnet attack traffic and
148 | what is best classified as a "retry storm"
149 |
150 | Looking at certain large recursive platforms > 10x normal volume
151
152 In 2018, the root zone Key Signing Key (KSK) was rolled over
153 [KSK-ROLLOVER]. Throughout the rollover period, the root servers
154 experienced a significant increase in DNSKEY queries. Before the
155 rollover, a.root-servers.net and j.root-servers.net together received
156 about 15 million DNSKEY queries per day. At the end of the
157 revocation period, they received 1.2 billion per day: an 80x
158 increase. Removal of the revoked key from the zone caused DNSKEY
159 queries to drop to post-rollover but pre-revoke levels, indicating
160 there is still a population of recursive resolvers using the previous
161 root trust anchor and aggressively retrying DNSKEY queries.
162
163 In 2021, Verisign researchers used botnet query traffic to
164 demonstrate that certain large public recursive DNS services exhibit
165 very high query rates when all authoritative name servers for a zone
166 return refused (REFUSED) or server failure (SERVFAIL) responses (see
167 [BOTNET]). When the authoritative servers were configured normally,
168 query rates for a single botnet domain averaged approximately 50
169 queries per second. However, with the servers configured to return
170 SERVFAIL, the query rate increased to 60,000 per second.
171 Furthermore, increases were also observed at the root and Top-Level
172 Domain (TLD) levels, even though delegations at those levels were
173 unchanged and continued operating normally.
174
175 Later that same year, on October 4, Facebook experienced a widespread
176 and well-publicized outage [FB-OUTAGE]. During the 6-hour outage,
177 none of Facebook's authoritative name servers were reachable and did
178 not respond to queries. Recursive name servers attempting to resolve
179 Facebook domains experienced timeouts. During this time, query
180 traffic on the .COM/.NET infrastructure increased from 7,000 to
181 900,000 queries per second [OUTAGE-RESOLVER].
182
183 1.2. Related Work
184
185 [RFC2308] describes negative caching for four types of DNS queries
186 and responses: name errors, no data, server failures, and dead/
187 unreachable servers. It places the strongest requirements on
188 negative caching for name errors and no data responses, while server
189 failures and dead servers are left as optional.
190
191 [RFC4697] is a Best Current Practice that documents observed
192 resolution misbehaviors. It describes a number of situations that
193 can lead to excessive queries from recursive resolvers, including
194 requerying for delegation data, lame servers, responses blocked by
195 firewalls, and records with zero TTL. [RFC4697] makes a number of
196 recommendations, varying from "SHOULD" to "MUST".
197
198 [THUNDERING-HERD] describes "The DNS thundering herd problem" as a
199 situation arising when cached data expires at the same time for a
200 large number of users. Although that document is not focused on
201 negative caching, it does describe the benefits of combining multiple
202 identical queries to upstream name servers. That is, when a
203 recursive resolver receives multiple queries for the same name,
204 class, and type that cannot be answered from cached data, it should
205 combine or join them into a single upstream query rather than emit
206 repeated identical upstream queries.
207
208 [RFC5452], "Measures for Making DNS More Resilient against Forged
209 Answers", includes a section that describes the phenomenon known as
210 "Birthday Attacks". Here, again, the problem arises when a recursive
211 resolver emits multiple identical upstream queries. Multiple
212 outstanding queries make it easier for an attacker to guess and
213 correctly match some of the DNS message parameters, such as the port
214 number and ID field. This situation is further exacerbated in the
215 case of timeout-based resolution failures. Of course, DNSSEC is a
216 suitable defense to spoofing attacks.
217
218 [RFC8767] describes "Serving Stale Data to Improve DNS Resiliency".
219 This permits a recursive resolver to return possibly stale data when
220 it is unable to refresh cached, expired data. It introduces the idea
221 of a failure recheck timer and says:
222
223 | Attempts to refresh from non-responsive or otherwise failing
224 | authoritative nameservers are recommended to be done no more
225 | frequently than every 30 seconds.
226
227 1.3. Terminology
228
229 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
230 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
231 "OPTIONAL" in this document are to be interpreted as described in
232 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
233 capitals, as shown here.
234
235 DNS transport: In this document, "DNS transport" means a protocol
236 used to transport DNS messages between a client and a server.
237 This includes "classic DNS" transports, i.e., DNS-over-UDP and
238 DNS-over-TCP [RFC1034] [RFC7766], as well as newer encrypted DNS
239 transports, such as DNS-over-TLS [RFC7858], DNS-over-HTTPS
240 [RFC8484], DNS-over-QUIC [RFC9250], and similar communication of
241 DNS messages using other protocols. Note: at the time of writing,
242 not all DNS transports are standardized for all types of servers
243 but may become standardized in the future.
244
245 2. Conditions That Lead to DNS Resolution Failures
246
247 A DNS resolution failure occurs when none of the servers available to
248 a resolver client provide any useful response data for a particular
249 query name, type, and class. A response is considered useful when it
250 provides either the requested data, a referral to a descendant zone,
251 or an indication that no data exists at the given name.
252
253 It is common for resolvers to have multiple servers from which to
254 choose for a particular query. For example, in the case of stub-to-
255 recursive, the stub resolver may be configured with multiple
256 recursive resolver addresses. In the case of recursive-to-
257 authoritative, a given zone usually has more than one name server (NS
258 record), each of which can have multiple IP addresses and multiple
259 DNS transports.
260
261 Nothing in this document prevents a resolver from retrying a query at
262 a different server or the same server over a different DNS transport.
263 In the case of timeouts, a resolver can retry the same server and DNS
264 transport a limited number of times.
265
266 If any one of the available servers provides a useful response, then
267 it is not considered a resolution failure. However, if none of the
268 servers for a given query tuple <name, type, class> provide a useful
269 response, the result is a resolution failure.
270
271 Note that NXDOMAIN and NOERROR/NODATA responses are not conditions
272 for resolution failure. In these cases, the server is providing a
273 useful response, indicating either that a name does not exist or that
274 no data of the requested type exists at the name. These negative
275 responses can be cached as described in [RFC2308].
276
277 The remainder of this section describes a number of different
278 conditions that can lead to resolution failure. This section is not
279 exhaustive. Additional conditions may be expected to cause similar
280 resolution failures.
281
282 2.1. SERVFAIL Responses
283
284 Server failure is defined in [RFC1035] as: "The name server was
285 unable to process this query due to a problem with the name server."
286 A server failure is signaled by setting the RCODE field to SERVFAIL.
287
288 Authoritative servers return SERVFAIL when they don't have any valid
289 data for a zone. For example, a secondary server has been configured
290 to serve a particular zone but is unable to retrieve or refresh the
291 zone data from the primary server.
292
293 Recursive servers return SERVFAIL in response to a number of
294 different conditions, including many described below.
295
296 Although the extended DNS errors method exists "primarily to extend
297 SERVFAIL to provide additional information," it "does not change the
298 processing of RCODEs" [RFC8914]. This document operates at the level
299 of resolution failure and does not concern particular causes.
300
301 2.2. REFUSED Responses
302
303 A name server returns a message with the RCODE field set to REFUSED
304 when it refuses to process the query, e.g., for policy or other
305 reasons [RFC1035].
306
307 Authoritative servers generally return REFUSED when processing a
308 query for which they are not authoritative. For example, a server
309 that is configured to be authoritative for only the example.net zone
310 may return REFUSED in response to a query for example.com.
311
312 Recursive servers generally return REFUSED for query sources that do
313 not match configured access control lists. For example, a server
314 that is configured to allow queries from only 2001:db8:1::/48 may
315 return REFUSED in response to a query from 2001:db8:5::1.
316
317 2.3. Timeouts and Unreachable Servers
318
319 A timeout occurs when a resolver fails to receive any response from a
320 server within a reasonable amount of time. Additionally, a DNS
321 transport may more quickly indicate lack of reachability in a way
322 that wouldn't be considered a timeout: for example, an ICMP port
323 unreachable message, a TCP "connection refused" error, or a TLS
324 handshake failure. [RFC2308] refers to these conditions collectively
325 as "dead / unreachable servers".
326
327 Note that resolver implementations may have two types of timeouts: a
328 smaller timeout that might trigger a query retry and a larger timeout
329 after which the server is considered unresponsive. Section 3.1
330 discusses the requirements for resolvers when retrying queries.
331
332 Timeouts can present a particular problem for negative caching,
333 depending on how the resolver handles multiple outstanding queries
334 for the same <query name, type, class> tuple. For example, consider
335 a very popular website in a zone whose name servers are all
336 unresponsive. A recursive resolver might receive tens or hundreds of
337 queries per second for that website. If the recursive server
338 implementation joins these outstanding queries together, then it only
339 sends one recursive-to-authoritative query for the numerous pending
340 stub-to-recursive queries. However, if the implementation does not
341 join outstanding queries together, then it sends one recursive-to-
342 authoritative query for each stub-to-recursive query. If the
343 incoming query rate is high and the timeout is large, this might
344 result in hundreds or thousands of recursive-to-authoritative queries
345 while waiting for an authoritative server to time out.
346
347 A recursive resolver that does not join outstanding queries together
348 is more susceptible to Birthday Attacks ([RFC5452], Section 5),
349 especially when those queries result in timeouts.
350
351 2.4. Delegation Loops
352
353 A delegation loop, or cycle, can occur when one domain utilizes name
354 servers in a second domain, and the second domain uses name servers
355 in the first. For example:
356
357 FOO.EXAMPLE. NS NS1.EXAMPLE.COM.
358 FOO.EXAMPLE. NS NS2.EXAMPLE.COM.
359
360 EXAMPLE.COM. NS NS1.FOO.EXAMPLE.
361 EXAMPLE.COM. NS NS2.FOO.EXAMPLE.
362
363 In this example, no names under foo.example or example.com can be
364 resolved because of the delegation loop. Note that a delegation loop
365 may involve more than two domains. A resolver that does not detect
366 delegation loops may generate DDoS-levels of attack traffic to
367 authoritative name servers, as documented in the TsuNAME
368 vulnerability [TsuNAME].
369
370 2.5. Alias Loops
371
372 An alias loop, or cycle, can occur when one CNAME or DNAME RR refers
373 to a second name, which, in turn, is specified as an alias for the
374 first. For example:
375
376 APP.FOO.EXAMPLE. CNAME APP.EXAMPLE.NET.
377 APP.EXAMPLE.NET. CNAME APP.FOO.EXAMPLE.
378
379 The need to detect CNAME loops has been known since at least
380 [RFC1034], which states in Section 3.6.2:
381
382 | Of course, by the robustness principle, domain software should not
383 | fail when presented with CNAME chains or loops; CNAME chains
384 | should be followed and CNAME loops signalled as an error.
385
386 2.6. DNSSEC Validation Failures
387
388 For zones that are signed with DNSSEC, a resolution failure can occur
389 when a security-aware resolver believes it should be able to
390 establish a chain of trust for an RRset but is unable to do so,
391 possibly after trying multiple authoritative name servers. DNSSEC
392 validation failures may be due to signature mismatch, missing DNSKEY
393 RRs, problems with denial-of-existence records, clock skew, or other
394 reasons.
395
396 Section 4.7 of [RFC4035] already discusses the requirements and
397 reasons for caching validation failures. Section 3.4 of this
398 document strengthens those requirements.
399
400 2.7. FORMERR Responses
401
402 A name server returns a message with the RCODE field set to FORMERR
403 when it is unable to interpret the query [RFC1035]. FORMERR
404 responses are often associated with problems processing Extension
405 Mechanisms for DNS (EDNS(0)) [RFC6891]. Authoritative servers may
406 return FORMERR when they do not implement EDNS(0), or when EDNS(0)
407 option fields are malformed, but not for unknown EDNS(0) options.
408
409 Upon receipt of a FORMERR response, some recursive clients will retry
410 their queries without EDNS(0), while others will not. Nonetheless,
411 resolution failures from FORMERR responses are rare.
412
413 3. Requirements for Caching DNS Resolution Failures
414
415 3.1. Retries and Timeouts
416
417 A resolver MUST NOT retry a given query to a server address over a
418 given DNS transport more than twice (i.e., three queries in total)
419 before considering the server address unresponsive over that DNS
420 transport for that query.
421
422 A resolver MAY retry a given query over a different DNS transport to
423 the same server if it has reason to believe the DNS transport is
424 available for that server and is compatible with the resolver's
425 security policies.
426
427 This document does not place any requirements on how long an
428 implementation should wait before retrying a query (aka a timeout
429 value), which may be implementation or configuration dependent. It
430 is generally expected that typical timeout values range from 3 to 30
431 seconds.
432
433 3.2. Caching
434
435 Resolvers MUST implement a cache for resolution failures. The
436 purpose of this cache is to eliminate repeated upstream queries that
437 cannot be resolved. When an incoming query matches a cached
438 resolution failure, the resolver MUST NOT send any corresponding
439 outgoing queries until after the cache entries expire.
440
441 Implementation details for such a cache are not specified in this
442 document. The implementation might cache different resolution
443 failure conditions differently. For example, DNSSEC validation
444 failures might be cached according to the queried name, class, and
445 type, whereas unresponsive servers might be cached only according to
446 the server's IP address. Developers should document their
447 implementation choices so that operators know what behaviors to
448 expect when resolution failures are cached.
449
450 Resolvers MUST cache resolution failures for at least 1 second.
451 Resolvers MAY cache different types of resolution failures for
452 different (i.e., longer) amounts of time. Consistent with [RFC2308],
453 resolution failures MUST NOT be cached for longer than 5 minutes.
454
455 The minimum cache duration SHOULD be configurable by the operator. A
456 longer cache duration for resolution failures will reduce the
457 processing burden from repeated queries but may also increase the
458 time to recover from transitory issues.
459
460 Resolvers SHOULD employ an exponential or linear backoff algorithm to
461 increase the cache duration for persistent resolution failures. For
462 example, the initial time for negatively caching a resolution failure
463 might be set to 5 seconds and increased after each retry that results
464 in another resolution failure, up to a configurable maximum, not to
465 exceed the 5-minute upper limit.
466
467 Notwithstanding the above, resolvers SHOULD implement measures to
468 mitigate resource exhaustion attacks on the failed resolution cache.
469 That is, the resolver should limit the amount of memory and/or
470 processing time devoted to this cache.
471
472 3.3. Requerying Delegation Information
473
474 Section 2.1 of [RFC4697] identifies circumstances in which:
475
476 | ...every name server in a zone's NS RRSet is unreachable (e.g.,
477 | during a network outage), unavailable (e.g., the name server
478 | process is not running on the server host), or misconfigured
479 | (e.g., the name server is not authoritative for the given zone,
480 | also known as "lame").
481
482 It prohibits unnecessary "aggressive requerying" to the parent of a
483 non-responsive zone by sending NS queries.
484
485 The problem of aggressive requerying to parent zones is not limited
486 to queries of type NS. This document updates the requirement from
487 Section 2.1.1 of [RFC4697] to apply more generally:
488
489 | Upon encountering a zone whose name servers are all non-
490 | responsive, a resolver MUST cache the resolution failure.
491 | Furthermore, the resolver MUST limit queries to the non-responsive
492 | zone's parent zone (and to other ancestor zones) just as it would
493 | limit subsequent queries to the non-responsive zone.
494
495 3.4. DNSSEC Validation Failures
496
497 Section 4.7 of [RFC4035] states:
498
499 | To prevent such unnecessary DNS traffic, security-aware resolvers
500 | MAY cache data with invalid signatures, with some restrictions.
501
502 This document updates [RFC4035] with the following, stronger,
503 requirement:
504
505 | To prevent such unnecessary DNS traffic, security-aware resolvers
506 | MUST cache DNSSEC validation failures, with some restrictions.
507
508 One of the restrictions mentioned in [RFC4035] is to use a small TTL
509 when caching data that fails DNSSEC validation. This is, in part,
510 because the provided TTL cannot be trusted. The advice from
511 Section 3.2 herein can be used as guidance on TTLs for caching DNSSEC
512 validation failures.
513
514 4. IANA Considerations
515
516 This document has no IANA actions.
517
518 5. Security Considerations
519
520 As noted in Section 3.2, an attacker might attempt a resource
521 exhaustion attack by sending queries for a large number of names and/
522 or types that result in resolution failure. Resolvers SHOULD
523 implement measures to protect themselves and bound the amount of
524 memory devoted to caching resolution failures.
525
526 A cache poisoning attack (see Section 2.2 of [RFC7873]) resulting in
527 denial of service may be possible because failure messages cannot be
528 signed. An attacker might generate queries and send forged failure
529 messages, causing the resolver to cease sending queries to the
530 authoritative name server (see Section 2.6 of [RFC4732] for a similar
531 "data corruption attack" and Section 5.2 of [TuDoor] for a "DNSDoS
532 attack"). However, this would require continued spoofing throughout
533 the backoff period and repeated attacks due to the 5-minute cache
534 limit. As in Section 4.1.12 of [RFC4686], this attack's effects
535 would be "localized and of limited duration".
536
537 6. Privacy Considerations
538
539 This specification has no impact on user privacy.
540
541 7. References
542
543 7.1. Normative References
544
545 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
546 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
547 <https://www.rfc-editor.org/info/rfc1034>.
548
549 [RFC1035] Mockapetris, P., "Domain names - implementation and
550 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
551 November 1987, <https://www.rfc-editor.org/info/rfc1035>.
552
553 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
554 Requirement Levels", BCP 14, RFC 2119,
555 DOI 10.17487/RFC2119, March 1997,
556 <https://www.rfc-editor.org/info/rfc2119>.
557
558 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
559 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
560 <https://www.rfc-editor.org/info/rfc2308>.
561
562 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
563 Rose, "Protocol Modifications for the DNS Security
564 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
565 <https://www.rfc-editor.org/info/rfc4035>.
566
567 [RFC4697] Larson, M. and P. Barber, "Observed DNS Resolution
568 Misbehavior", BCP 123, RFC 4697, DOI 10.17487/RFC4697,
569 October 2006, <https://www.rfc-editor.org/info/rfc4697>.
570
571 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
572 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
573 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
574
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.
575 7.2. Informative References
576
577 [BOTNET] Wessels, D. and M. Thomas, "Botnet Traffic Observed at
578 Various Levels of the DNS Hierarchy", May 2021,
579 <https://indico.dns-oarc.net/event/38/contributions/841/>.
580
581 [DNSSEC-ROLLOVER]
582 Michaleson, G., Wallström, P., Arends, R., and G. Huston,
583 "Roll Over and Die?", February 2010,
584 <https://www.potaroo.net/ispcol/2010-02/rollover.html>.
585
586 [FB-OUTAGE]
587 Janardhan, S., "More details about the October 4 outage",
588 October 2021, <https://engineering.fb.com/2021/10/05/
589 networking-traffic/outage-details/>.
590
591 [KSK-ROLLOVER]
592 Müller, M., Thomas, M., Wessels, D., Hardaker, W., Chung,
593 T., Toorop, W., and R. van Rijswijk-Deij, "Roll, Roll,
594 Roll Your Root: A Comprehensive Analysis of the First Ever
595 DNSSEC Root KSK Rollover", IMC '19: Proceedings of the
596 Internet Measurement Conference, Pages 1-14,
597 DOI 10.1145/3355369.3355570, October 2019,
598 <https://doi.org/10.1145/3355369.3355570>.
599
600 [OUTAGE-RESOLVER]
601 Verisign, "Observations on Resolver Behavior During DNS
602 Outages", January 2022,
603 <https://blog.verisign.com/security/facebook-dns-outage/>.
604
605 [RETRY-STORM]
606 Sullivan, A., "Dyn, DDoS, and DNS", March 2017,
607 <https://ccnso.icann.org/sites/default/files/file/field-
608 file-attach/2017-04/presentation-oracle-dyn-ddos-dns-
609 13mar17-en.pdf>.
610
611 [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities",
612 RFC 882, DOI 10.17487/RFC0882, November 1983,
613 <https://www.rfc-editor.org/info/rfc882>.
614
615 [RFC0883] Mockapetris, P., "Domain names: Implementation
616 specification", RFC 883, DOI 10.17487/RFC0883, November
617 1983, <https://www.rfc-editor.org/info/rfc883>.
618
619 [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
620 Identified Mail (DKIM)", RFC 4686, DOI 10.17487/RFC4686,
621 September 2006, <https://www.rfc-editor.org/info/rfc4686>.
622
623 [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
624 Denial-of-Service Considerations", RFC 4732,
625 DOI 10.17487/RFC4732, December 2006,
626 <https://www.rfc-editor.org/info/rfc4732>.
627
628 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More
629 Resilient against Forged Answers", RFC 5452,
630 DOI 10.17487/RFC5452, January 2009,
631 <https://www.rfc-editor.org/info/rfc5452>.
632
633 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
634 for DNS (EDNS(0))", STD 75, RFC 6891,
635 DOI 10.17487/RFC6891, April 2013,
636 <https://www.rfc-editor.org/info/rfc6891>.
637
638 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
639 D. Wessels, "DNS Transport over TCP - Implementation
640 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
641 <https://www.rfc-editor.org/info/rfc7766>.
642
643 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
644 and P. Hoffman, "Specification for DNS over Transport
645 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
646 2016, <https://www.rfc-editor.org/info/rfc7858>.
647
648 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
649 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
650 <https://www.rfc-editor.org/info/rfc7873>.
651
652 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
653 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
654 <https://www.rfc-editor.org/info/rfc8484>.
655
656 [RFC8767] Lawrence, D., Kumari, W., and P. Sood, "Serving Stale Data
657 to Improve DNS Resiliency", RFC 8767,
658 DOI 10.17487/RFC8767, March 2020,
659 <https://www.rfc-editor.org/info/rfc8767>.
660
661 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
662 Lawrence, "Extended DNS Errors", RFC 8914,
663 DOI 10.17487/RFC8914, October 2020,
664 <https://www.rfc-editor.org/info/rfc8914>.
665
666 [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over
667 Dedicated QUIC Connections", RFC 9250,
668 DOI 10.17487/RFC9250, May 2022,
669 <https://www.rfc-editor.org/info/rfc9250>.
670
671 [THUNDERING-HERD]
672 Sivaraman, M. and C. Liu, "The DNS thundering herd
673 problem", Work in Progress, Internet-Draft, draft-muks-
674 dnsop-dns-thundering-herd-00, 25 June 2020,
675 <https://datatracker.ietf.org/doc/html/draft-muks-dnsop-
676 dns-thundering-herd-00>.
677
678 [TsuNAME] Moura, G. C. M., Castro, S., Heidemann, J., and W.
679 Hardaker, "TsuNAME: exploiting misconfiguration and
680 vulnerability to DDoS DNS", IMC '21: Proceedings of the
681 21st ACM Internet Measurement Conference, Pages 398-418,
682 DOI 10.1145/3487552.3487824, November 2021,
683 <https://doi.org/10.1145/3487552.3487824>.
684
685 [TuDoor] Li, X., Xu, W., Liu, B., Zhang, M., Li, Z., Zhang, J.,
686 Chang, D., Zheng, X., Wang, C., Chen, J., Duan, H., and Q.
687 Li, "TuDoor Attack: Systematically Exploring and
688 Exploiting Logic Vulnerabilities in DNS Response Pre-
689 processing with Malformed Packets", IEEE Symposium on
690 Security and Privacy (SP), DOI 10.1109/SP54263.2024.00046,
691 2024, <https://doi.ieeecomputersociety.org/10.1109/
692 SP54263.2024.00046>.
693
694 Acknowledgments
695
696 The authors wish to thank Mukund Sivaraman, Petr Spacek, Peter van
697 Dijk, Tim Wicinksi, Joe Abley, Evan Hunt, Barry Leiba, Lucas Pardue,
698 Paul Wouters, and other members of the DNSOP Working Group for their
699 feedback and contributions.
700
701 Authors' Addresses
702
703 Duane Wessels
704 Verisign
705 12061 Bluemont Way
706 Reston, VA 20190
707 United States of America
708 Phone: +1 703 948-3200
709 Email: dwessels@verisign.com
710 URI: https://verisign.com
711
712
713 William Carroll
714 Verisign
715 12061 Bluemont Way
716 Reston, VA 20190
717 United States of America
718 Phone: +1 703 948-3200
719 Email: wicarroll@verisign.com
720 URI: https://verisign.com
721
722
723 Matthew Thomas
724 Verisign
725 12061 Bluemont Way
726 Reston, VA 20190
727 United States of America
728 Phone: +1 703 948-3200
729 Email: mthomas@verisign.com
730 URI: https://verisign.com
731
[TuDoor] ... DOI 10.1109/SP54263.2024.00046, 2024, <https://doi.ieeecomputersociety.org/10.1109/SP54263.2024.00046>.
[TuDoor] ... DOI 10.1109/SP54263.2024.00172, 2024, <https://doi.ieeecomputersociety.org/10.1109/SP54263.2024.00172>.
The reference link has changed to 10.1109/SP54263.2024.00172 from 10.1109/SP54263.2024.00046