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   
    8               Negative Caching of DNS Resolution Failures                  
   10 Abstract                                                                   
   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.                                        
   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.                           
   26    RFC 4035 allows DNSSEC validation failure caching.  This document       
   27    updates RFC 4035 to require caching for DNSSEC validation failures.     
   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.               
   33 Status of This Memo                                                        
   35    This is an Internet Standards Track document.                           
   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.               
   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.                                
   47 Copyright Notice                                                           
   49    Copyright (c) 2023 IETF Trust and the persons identified as the         
   50    document authors.  All rights reserved.                                 
   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.                                             
   62 Table of Contents                                                          
   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                                                      
   90 1.  Introduction                                                           
   92    Caching has always been a fundamental component of DNS resolution on    
   93    the Internet.  For example, [RFC0882] states:                           
   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.                                      
   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.                                                  
  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.                                                            
  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.                     
  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.               
  125 1.1.  Motivation                                                           
  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.                                           
  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.                 
  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:                                                            
  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     
  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.             
  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.                             
  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].                           
  183 1.2.  Related Work                                                         
  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.                         
  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".                       
  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.                                    
  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.                                   
  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:                                    
  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.                                    
  227 1.3.  Terminology                                                          
  229    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",     
  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.                                                
  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.                           
  245 2.  Conditions That Lead to DNS Resolution Failures                        
  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.                 
  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.                                                         
  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.                                    
  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.                           
  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].                      
  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.                                                    
  282 2.1.  SERVFAIL Responses                                                   
  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.    
  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.                                      
  293    Recursive servers return SERVFAIL in response to a number of            
  294    different conditions, including many described below.                   
  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.           
  301 2.2.  REFUSED Responses                                                    
  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].                                                      
  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.              
  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.               
  317 2.3.  Timeouts and Unreachable Servers                                     
  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".                                        
  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.         
  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.                  
  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.                       
  351 2.4.  Delegation Loops                                                     
  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:                                             
  357    FOO.EXAMPLE.    NS      NS1.EXAMPLE.COM.                                
  358    FOO.EXAMPLE.    NS      NS2.EXAMPLE.COM.                                
  360    EXAMPLE.COM.    NS      NS1.FOO.EXAMPLE.                                
  361    EXAMPLE.COM.    NS      NS2.FOO.EXAMPLE.                                
  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].                                                
  370 2.5.  Alias Loops                                                          
  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:                                                    
  376    APP.FOO.EXAMPLE.        CNAME   APP.EXAMPLE.NET.                        
  377    APP.EXAMPLE.NET.        CNAME   APP.FOO.EXAMPLE.                        
  379    The need to detect CNAME loops has been known since at least            
  380    [RFC1034], which states in Section 3.6.2:                               
  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.            
  386 2.6.  DNSSEC Validation Failures                                           
  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.                                                                
  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.                                
  400 2.7.  FORMERR Responses                                                    
  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.       
  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.                    
  413 3.  Requirements for Caching DNS Resolution Failures                       
  415 3.1.  Retries and Timeouts                                                 
  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.                                               
  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.                                                      
  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.                                                                
  433 3.2.  Caching                                                              
  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.                  
  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.                             
  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.       
  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.                                 
  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.                                        
  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.                                  
  472 3.3.  Requerying Delegation Information                                    
  474    Section 2.1 of [RFC4697] identifies circumstances in which:             
  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").                                               
  482    It prohibits unnecessary "aggressive requerying" to the parent of a     
  483    non-responsive zone by sending NS queries.                              
  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:                     
  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.                 
  495 3.4.  DNSSEC Validation Failures                                           
  497    Section 4.7 of [RFC4035] states:                                        
  499    |  To prevent such unnecessary DNS traffic, security-aware resolvers    
  500    |  MAY cache data with invalid signatures, with some restrictions.      
  502    This document updates [RFC4035] with the following, stronger,           
  503    requirement:                                                            
  505    |  To prevent such unnecessary DNS traffic, security-aware resolvers    
  506    |  MUST cache DNSSEC validation failures, with some restrictions.       
  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.                                                    
  514 4.  IANA Considerations                                                    
  516    This document has no IANA actions.                                      
  518 5.  Security Considerations                                                
  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.                          
  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".                           
  537 6.  Privacy Considerations                                                 
  539    This specification has no impact on user privacy.                       
  541 7.  References                                                             
  543 7.1.  Normative References                                                 
  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>.                   
  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>.    
  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>.                   
  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>.                   
  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>.                   
  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>.     
  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>.         

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                                               
  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/>.   
  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>.      
  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/>.                         
  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>.                   
  600    [OUTAGE-RESOLVER]                                                       
  601               Verisign, "Observations on Resolver Behavior During DNS      
  602               Outages", January 2022,                                      
  603               <https://blog.verisign.com/security/facebook-dns-outage/>.   
  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>.                                             
  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>.                    
  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>.              
  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>.   
  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>.                   
  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>.                   
  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>.                   
  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>.                   
  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>.             
  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>.                   
  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>.                   
  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>.                   
  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>.                   
  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>.                   
  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>.                                     
  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>.                   
  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>.                                         
  694 Acknowledgments                                                            
  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.                                             
  701 Authors' Addresses                                                         
  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                                             
  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                                             
  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                                             
section-7.2 Xiang Li(Editorial Erratum #7838) [Reported]
based on outdated version
DOI 10.1109/SP54263.2024.00046, 2024, 

It should say:
DOI 10.1109/SP54263.2024.00172, 2024, 

The reference link has changed to 10.1109/SP54263.2024.00172 from