1 Internet Engineering Task Force (IETF)                         R. Arends   
    2 Request for Comments: 9567                                     M. Larson   
    3 Category: Standards Track                                          ICANN   
    4 ISSN: 2070-1721                                               April 2024   
    5                                                                            
    6                                                                            
    7                           DNS Error Reporting                              
    8                                                                            
    9 Abstract                                                                   
   10                                                                            
   11    DNS error reporting is a lightweight reporting mechanism that           
   12    provides the operator of an authoritative server with reports on DNS    
   13    resource records that fail to resolve or validate.  A domain owner or   
   14    DNS hosting organization can use these reports to improve domain        
   15    hosting.  The reports are based on extended DNS errors as described     
   16    in RFC 8914.                                                            
   17                                                                            
   18    When a domain name fails to resolve or validate due to a                
   19    misconfiguration or an attack, the operator of the authoritative        
   20    server may be unaware of this.  To mitigate this lack of feedback,      
   21    this document describes a method for a validating resolver to           
   22    automatically signal an error to a monitoring agent specified by the    
   23    authoritative server.  The error is encoded in the QNAME; thus, the     
   24    very act of sending the query is to report the error.                   
   25                                                                            
   26 Status of This Memo                                                        
   27                                                                            
   28    This is an Internet Standards Track document.                           
   29                                                                            
   30    This document is a product of the Internet Engineering Task Force       
   31    (IETF).  It represents the consensus of the IETF community.  It has     
   32    received public review and has been approved for publication by the     
   33    Internet Engineering Steering Group (IESG).  Further information on     
   34    Internet Standards is available in Section 2 of RFC 7841.               
   35                                                                            
   36    Information about the current status of this document, any errata,      
   37    and how to provide feedback on it may be obtained at                    
   38    https://www.rfc-editor.org/info/rfc9567.                                
   39                                                                            
   40 Copyright Notice                                                           
   41                                                                            
   42    Copyright (c) 2024 IETF Trust and the persons identified as the         
   43    document authors.  All rights reserved.                                 
   44                                                                            
   45    This document is subject to BCP 78 and the IETF Trust's Legal           
   46    Provisions Relating to IETF Documents                                   
   47    (https://trustee.ietf.org/license-info) in effect on the date of        
   48    publication of this document.  Please review these documents            
   49    carefully, as they describe your rights and restrictions with respect   
   50    to this document.  Code Components extracted from this document must    
   51    include Revised BSD License text as described in Section 4.e of the     
   52    Trust Legal Provisions and are provided without warranty as described   
   53    in the Revised BSD License.                                             
   54                                                                            
   55 Table of Contents                                                          
   56                                                                            
   57    1.  Introduction                                                        
   58    2.  Requirements Notation                                               
   59    3.  Terminology                                                         
   60    4.  Overview                                                            
   61      4.1.  Example                                                         
   62    5.  EDNS0 Option Specification                                          
   63    6.  DNS Error Reporting Specification                                   
   64      6.1.  Reporting Resolver Specification                                
   65        6.1.1.  Constructing the Report Query                               
   66      6.2.  Authoritative Server Specification                              
   67      6.3.  Monitoring Agent Specification                                  
   68    7.  IANA Considerations                                                 
   69    8.  Operational Considerations                                          
   70      8.1.  Choosing an Agent Domain                                        
   71      8.2.  Managing Caching Optimizations                                  
   72    9.  Security Considerations                                             
   73    10. References                                                          
   74      10.1.  Normative References                                           
   75      10.2.  Informative References                                         
   76    Acknowledgements                                                        
   77    Authors' Addresses                                                      
   78                                                                            
   79 1.  Introduction                                                           
   80                                                                            
   81    When an authoritative server serves a stale DNSSEC-signed zone, the     
   82    cryptographic signatures over the resource record sets (RRsets) may     
   83    have lapsed.  A validating resolver will fail to validate these         
   84    resource records.                                                       
   85                                                                            
   86    Similarly, when there is a mismatch between the Delegation Signer       
   87    (DS) records at a parent zone and the key signing key at the child      
   88    zone, a validating resolver will fail to authenticate records in the    
   89    child zone.                                                             
   90                                                                            
   91    These are two of several failure scenarios that may go unnoticed for    
   92    some time by the operator of a zone.                                    
   93                                                                            
   94    Today, there is no direct relationship between operators of             
   95    validating resolvers and authoritative servers.  Outages are often      
   96    noticed indirectly by end users and reported via email or social        
   97    media (if reported at all).                                             
   98                                                                            
   99    When records fail to validate, there is no facility to report this      
  100    failure in an automated way.  If there is any indication that an        
  101    error or warning has happened, it may be buried in log files of the     
  102    resolver or not logged at all.                                          
  103                                                                            
  104    This document describes a method that can be used by validating         
  105    resolvers to report DNSSEC validation errors in an automated way.       
  106                                                                            
  107    It allows an authoritative server to announce a monitoring agent to     
  108    which validating resolvers can report issues if those resolvers are     
  109    configured to do so.                                                    
  110                                                                            
  111    The burden to report a failure falls on the validating resolver.  It    
  112    is important that the effort needed to report failure is low, with      
  113    minimal impact to its main functions.  To accomplish this goal, the     
  114    DNS itself is utilized to report the error.                             
  115                                                                            
  116 2.  Requirements Notation                                                  
  117                                                                            
  118    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",     
  119    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and    
  120    "OPTIONAL" in this document are to be interpreted as described in       
  121    BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all      
  122    capitals, as shown here.                                                
  123                                                                            
  124 3.  Terminology                                                            
  125                                                                            
  126    This document uses DNS terminology defined in BCP 219 [RFC9499].        
  127    This document also defines and uses the following terms:                
  128                                                                            
  129    Reporting resolver:  A validating resolver that supports DNS error      
  130       reporting.                                                           
  131                                                                            
  132    Report query:  The DNS query used to report an error.  A report query   
  133       is for a DNS TXT resource record type.  The content of the error     
  134       report is encoded in the QNAME of a DNS request to the monitoring    
  135       agent.                                                               
  136                                                                            
  137    Monitoring agent:  An authoritative server that receives and responds   
  138       to report queries.  This facility is indicated by a domain name,     
  139       referred to as the "agent domain".                                   
  140                                                                            
  141    Agent domain:  A domain name that is returned in the EDNS0 Report-      
  142       Channel option and indicates where DNS resolvers can send error      
  143       reports.                                                             
  144                                                                            
  145 4.  Overview                                                               
  146                                                                            
  147    An authoritative server indicates support for DNS error reporting by    
  148    including an EDNS0 Report-Channel option with OPTION-CODE 18 and the    
  149    agent domain in the response.  The agent domain is a fully qualified,   
  150    uncompressed domain name in DNS wire format.  The authoritative         
  151    server MUST NOT include this option in the response if the configured   
  152    agent domain is empty or is the null label (which would indicate the    
  153    DNS root).                                                              
  154                                                                            
  155    The authoritative server includes the EDNS0 Report-Channel option       
  156    unsolicited.  That is, the option is included in a response despite     
  157    the EDNS0 Report-Channel option being absent in the request.            
  158                                                                            
  159    If the authoritative server has indicated support for DNS error         
  160    reporting and there is an issue that can be reported via extended DNS   
  161    errors, the reporting resolver encodes the error report in the QNAME    
  162    of the report query.  The reporting resolver builds this QNAME by       
  163    concatenating the "_er" label, the QTYPE, the QNAME that resulted in    
  164    failure, the extended DNS error code (as described in [RFC8914]), the   
  165    label "_er" again, and the agent domain.  See the example in            
  166    Section 4.1 and the specification in Section 6.1.1.  Note that a        
  167    regular RCODE is not included because the RCODE is not relevant to      
  168    the extended DNS error code.                                            
  169                                                                            
  170    The resulting report query is sent as a standard DNS query for a TXT    
  171    DNS resource record type by the reporting resolver.                     
  172                                                                            
  173    The report query will ultimately arrive at the monitoring agent.  A     
  174    response is returned by the monitoring agent, which in turn can be      
  175    cached by the reporting resolver.  This caching is essential.  It       
  176    dampens the number of report queries sent by a reporting resolver for   
  177    the same problem (that is, with caching, one report query per TTL is    
  178    sent).  However, certain optimizations, such as those described in      
  179    [RFC8020] and [RFC8198], may reduce the number of error report          
  180    queries as well.                                                        
  181                                                                            
  182    This document gives no guidance on the content of the RDATA in the      
  183    TXT resource record.                                                    
  184                                                                            
  185 4.1.  Example                                                              
  186                                                                            
  187    A query for "broken.test.", type A, is sent by a reporting resolver.    
  188                                                                            
  189    The domain "test." is hosted on a set of authoritative servers.  One    
  190    of these authoritative servers serves a stale version of the "test."    
  191    zone.  This authoritative server has an agent domain configured as      
  192    "a01.agent-domain.example.".                                            
  193                                                                            
  194    The authoritative server with the stale "test." zone receives the       
  195    request for "broken.test.".  It returns a response that includes the    
  196    EDNS0 Report-Channel option with the domain name "a01.agent-            
  197    domain.example.".                                                       
  198                                                                            
  199    The reporting resolver is unable to validate the "broken.test."         
  200    RRset for type A (an RR type with value 1), due to an RRSIG record      
  201    with an expired signature.                                              
  202                                                                            
  203    The reporting resolver constructs the QNAME                             
  204    "_er.1.broken.test.7._er.a01.agent-domain.example." and resolves it.    
  205    This QNAME indicates extended DNS error 7 occurred while trying to      
  206    validate "broken.test." for a type A (an RR type with value 1)          
  207    record.                                                                 
  208                                                                            
  209    When this query is received at the monitoring agent (the operators of   
  210    the authoritative server for "a01.agent-domain.example."), the agent    
  211    can determine the "test." zone contained an expired signature record    
  212    (extended DNS error 7) for type A for the domain name "broken.test.".   
  213    The monitoring agent can contact the operators of "test." to fix the    
  214    issue.                                                                  
  215                                                                            
  216 5.  EDNS0 Option Specification                                             
  217                                                                            
  218    This method uses an EDNS0 [RFC6891] option to indicate the agent        
  219    domain in DNS responses.  The option is structured as follows:          
  220                                                                            
  221                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3        
  222     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1        
  223    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       
  224    |        OPTION-CODE = 18       |       OPTION-LENGTH           |       
  225    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+       
  226    /                         AGENT DOMAIN                          /       
  227    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+       
  228                                                                            
  229    Field definition details:                                               
  230                                                                            
  231    OPTION-CODE:  2 octets; an EDNS0 code that is used in an EDNS0 option   
  232       to indicate support for error reporting.  The name for this EDNS0    
  233       option code is Report-Channel.                                       
  234                                                                            
  235    OPTION-LENGTH:  2 octets; contains the length of the AGENT DOMAIN       
  236       field in octets.                                                     
  237                                                                            
  238    AGENT DOMAIN:  A fully qualified domain name [RFC9499] in               
  239       uncompressed DNS wire format.                                        
  240                                                                            
  241 6.  DNS Error Reporting Specification                                      
  242                                                                            
  243    The various errors that a reporting resolver may encounter are listed   
  244    in [RFC8914].  Note that not all listed errors may be supported by      
  245    the reporting resolver.  This document does not specify what is or is   
  246    not an error.                                                           
  247                                                                            
  248    The DNS class is not specified in the error report.                     
  249                                                                            
  250 6.1.  Reporting Resolver Specification                                     
  251                                                                            
  252    Care should be taken when additional DNS resolution is needed to        
  253    resolve the QNAME that contains the error report.  This resolution      
  254    itself could trigger another error report to be created.  A maximum     
  255    expense or depth limit MUST be used to prevent cascading errors.        
  256                                                                            
  257    The EDNS0 Report-Channel option MUST NOT be included in queries.        
  258                                                                            
  259    The reporting resolver MUST NOT use DNS error reporting if the          
  260    authoritative server returned an empty AGENT DOMAIN field in the        
  261    EDNS0 Report-Channel option.                                            
  262                                                                            
  263    For the monitoring agent to gain more confidence that the report is     
  264    not spoofed, the reporting resolver SHOULD send error reports over      
  265    TCP [RFC7766] or other connection-oriented protocols or SHOULD use      
  266    DNS Cookies [RFC7873].  This makes it harder to falsify the source      
  267    address.                                                                
  268                                                                            
  269    A reporting resolver MUST validate responses received from the          
  270    monitoring agent.  There is no special treatment for responses to       
  271    error-reporting queries.  Section 9 ("Security Considerations")         
  272    contains the rationale behind this.                                     
  273                                                                            
  274 6.1.1.  Constructing the Report Query                                      
  275                                                                            
  276    The QNAME for the report query is constructed by concatenating the      
  277    following elements:                                                     
  278                                                                            
  279    *  A label containing the string "_er".                                 
  280                                                                            
  281    *  The QTYPE that was used in the query that resulted in the extended   
  282       DNS error, presented as a decimal value, in a single DNS label.      
  283       If additional QTYPEs were present in the query, such as described    
  284       in [MULTI-QTYPES], they are represented as unique, ordered decimal   
  285       values separated by a hyphen.  As an example, if both QTYPE A and    
  286       AAAA were present in the query, they are presented as the label      
  287       "1-28".                                                              
  288                                                                            
  289    *  The list of non-null labels representing the query name that is      
  290       the subject of the DNS error report.                                 
  291                                                                            
  292    *  The extended DNS error code, presented as a decimal value, in a      
  293       single DNS label.                                                    
  294                                                                            
  295    *  A label containing the string "_er".                                 
  296                                                                            
  297    *  The agent domain.  The agent domain as received in the EDNS0         
  298       Report-Channel option set by the authoritative server.               
  299                                                                            
  300    If the QNAME of the report query exceeds 255 octets, it MUST NOT be     
  301    sent.                                                                   
  302                                                                            
  303    The "_er" labels allow the monitoring agent to differentiate between    
  304    the agent domain and the faulty query name.  When the specified agent   
  305    domain is empty, or is a null label (despite being not allowed in       
  306    this specification), the report query will have "_er" as a top-level    
  307    domain, and not the top-level domain from the query name that was the   
  308    subject of this error report.  The purpose of the first "_er" label     
  309    is to indicate that a complete report query has been received instead   
  310    of a shorter report query due to query minimization.                    
  311                                                                            
  312 6.2.  Authoritative Server Specification                                   
  313                                                                            
  314    The authoritative server MUST NOT include more than one EDNS0 Report-   
  315    Channel option in a response.                                           
  316                                                                            
  317    The authoritative server includes the EDNS0 Report-Channel option       
  318    unsolicited in responses.  There is no requirement that the EDNS0       
  319    Report-Channel option be present in queries.                            
  320                                                                            
  321 6.3.  Monitoring Agent Specification                                       
  322                                                                            
  323    It is RECOMMENDED that the authoritative server for the agent domain    
  324    reply with a positive response (i.e., not with NODATA or NXDOMAIN)      
  325    containing a TXT record.                                                
  326                                                                            
  327    The monitoring agent SHOULD respond to queries received over UDP that   
  328    have no DNS Cookie set with a response that has the truncation bit      
  329    (TC bit) set to challenge the resolver to requery over TCP.             
  330                                                                            
  331 7.  IANA Considerations                                                    
  332                                                                            
  333    IANA has assigned the following in the "DNS EDNS0 Option Codes (OPT)"   
  334    registry:                                                               
  335                                                                            
  336              +=======+================+==========+===========+             
  337              | Value | Name           | Status   | Reference |             
  338              +=======+================+==========+===========+             
  339              | 18    | Report-Channel | Standard | RFC 9567  |             
  340              +-------+----------------+----------+-----------+             
  341                                                                            
  342                                   Table 1                                  
  343                                                                            
  344    IANA has assigned the following in the "Underscored and Globally        
  345    Scoped DNS Node Names" registry:                                        
  346                                                                            
  347                    +=========+============+===========+                    
  348                    | RR Type | _NODE NAME | Reference |                    
  349                    +=========+============+===========+                    
  350                    | TXT     | _er        | RFC 9567  |                    
  351                    +---------+------------+-----------+                    
  352                                                                            
  353                                  Table 2                                   
  354                                                                            
  355 8.  Operational Considerations                                             
  356                                                                            
  357 8.1.  Choosing an Agent Domain                                             
  358                                                                            
  359    It is RECOMMENDED that the agent domain be kept relatively short to     
  360    allow for a longer QNAME in the report query.  The agent domain MUST    
  361    NOT be a subdomain of the domain it is reporting on.  That is, if the   
  362    authoritative server hosts the foo.example domain, then its agent       
  363    domain MUST NOT end in foo.example.                                     
  364                                                                            
  365 8.2.  Managing Caching Optimizations                                       
  366                                                                            
  367    The reporting resolver may utilize various caching optimizations that   
  368    inhibit subsequent error reporting to the same monitoring agent.        
  369                                                                            
  370    If the monitoring agent were to respond with NXDOMAIN (name error),     
  371    [RFC8020] states that any name at or below that domain should be        
  372    considered unreachable, and negative caching would prohibit             
  373    subsequent queries for anything at or below that domain for a period    
  374    of time, depending on the negative TTL [RFC2308].                       
  375                                                                            
  376    Since the monitoring agent may not know the contents of all the zones   
  377    for which it acts as a monitoring agent, the monitoring agent MUST      
  378    NOT respond with NXDOMAIN for domains it is monitoring because that     
  379    could inhibit subsequent queries.  One method to avoid NXDOMAIN is to   
  380    use a wildcard domain name [RFC4592] in the zone for the agent          
  381    domain.                                                                 
  382                                                                            
  383    When the agent domain is signed, a resolver may use aggressive          
  384    negative caching (described in [RFC8198]).  This optimization makes     
  385    use of NSEC and NSEC3 (without opt-out) records and allows the          
  386    resolver to do the wildcard synthesis.  When this happens, the          
  387    resolver does not send subsequent queries because it will be able to    
  388    synthesize a response from previously cached material.                  
  389                                                                            
  390    A solution is to avoid DNSSEC for the agent domain.  Signing the        
  391    agent domain will incur an additional burden on the reporting           
  392    resolver, as it has to validate the response.  However, this response   
  393    has no utility to the reporting resolver other than dampening the       
  394    query load for error reports.                                           
  395                                                                            
  396 9.  Security Considerations                                                
  397                                                                            
  398    Use of DNS error reporting may expose local configuration mistakes in   
  399    the reporting resolver, such as stale DNSSEC trust anchors, to the      
  400    monitoring agent.                                                       
  401                                                                            
  402    DNS error reporting SHOULD be done using DNS query name minimization    
  403    [RFC9156] to improve privacy.                                           
  404                                                                            
  405    DNS error reporting is done without any authentication between the      
  406    reporting resolver and the authoritative server of the agent domain.    
  407                                                                            
  408    Resolvers that send error reports SHOULD send them over TCP [RFC7766]   
  409    or SHOULD use DNS Cookies [RFC7873].  This makes it hard to falsify     
  410    the source address.  The monitoring agent SHOULD respond to queries     
  411    received over UDP that have no DNS Cookie set with a response that      
  412    has the truncation bit (TC bit) set to challenge the resolver to        
  413    requery over TCP.                                                       
  414                                                                            
  415    Well-known addresses of reporting resolvers can provide a higher        
  416    level of confidence in the error reports and potentially enable more    
  417    automated processing of these reports.                                  
  418                                                                            
  419    Monitoring agents that receive error reports over UDP should consider   
  420    that the source of the reports and the reports themselves may be        
  421    false.                                                                  
  422                                                                            
  423    The method described in this document will cause additional queries     
  424    by the reporting resolver to authoritative servers in order to          
  425    resolve the report query.                                               
  426                                                                            
  427    This method can be abused by intentionally deploying broken zones       
  428    with agent domains that are delegated to victims.  This is              
  429    particularly effective when DNS requests that trigger error messages    
  430    are sent through open resolvers [RFC9499] or widely distributed         
  431    network monitoring systems that perform distributed queries from        
  432    around the globe.                                                       
  433                                                                            
  434    An adversary may create massive error report flooding to camouflage     
  435    an attack.                                                              
  436                                                                            
  437    Though this document gives no guidance on the content of the RDATA in   
  438    the TXT resource record, if the RDATA content is logged, the            
  439    monitoring agent MUST assume the content can be malicious and take      
  440    appropriate measures to avoid exploitation.  One such method could be   
  441    to log in hexadecimal.  This would avoid remote code execution          
  442    through logging string attacks, such as the vulnerability described     
  443    in [CVE-2021-44228].                                                    
  444                                                                            
  445    The rationale behind mandating DNSSEC validation for responses from a   
  446    reporting agent, even if the agent domain is proposed to remain         
  447    unsigned, is to mitigate the risk of a downgrade attack orchestrated    
  448    by adversaries.  In such an attack, a victim's legitimately signed      
  449    domain could be deceptively advertised as an agent domain by            
  450    malicious actors.  Consequently, if the validating resolver treats it   
  451    as unsigned, it is exposed to potential cache poisoning attacks.  By    
  452    enforcing DNSSEC validation, this vulnerability is preemptively         
  453    addressed.                                                              
  454                                                                            
  455 10.  References                                                            
  456                                                                            
  457 10.1.  Normative References                                                
  458                                                                            
  459    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate          
  460               Requirement Levels", BCP 14, RFC 2119,                       
  461               DOI 10.17487/RFC2119, March 1997,                            
  462               <https://www.rfc-editor.org/info/rfc2119>.                   
  463                                                                            
  464    [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC       
  465               2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,     
  466               May 2017, <https://www.rfc-editor.org/info/rfc8174>.         
  467                                                                            
  468 10.2.  Informative References                                              
  469                                                                            
  470    [CVE-2021-44228]                                                        
  471               CVE, "CVE-2021-44228", 26 November 2021,                     
  472               <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-         
  473               2021-44228>.                                                 
  474                                                                            
  475    [MULTI-QTYPES]                                                          
  476               Bellis, R., "DNS Multiple QTYPEs", Work in Progress,         
  477               Internet-Draft, draft-ietf-dnssd-multi-qtypes-00, 4          
  478               December 2023, <https://datatracker.ietf.org/doc/html/       
  479               draft-ietf-dnssd-multi-qtypes-00>.                           
  480                                                                            
  481    [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS           
  482               NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,        
  483               <https://www.rfc-editor.org/info/rfc2308>.                   
  484                                                                            
  485    [RFC4592]  Lewis, E., "The Role of Wildcards in the Domain Name         
  486               System", RFC 4592, DOI 10.17487/RFC4592, July 2006,          
  487               <https://www.rfc-editor.org/info/rfc4592>.                   
  488                                                                            
  489    [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms    
  490               for DNS (EDNS(0))", STD 75, RFC 6891,                        
  491               DOI 10.17487/RFC6891, April 2013,                            
  492               <https://www.rfc-editor.org/info/rfc6891>.                   
  493                                                                            
  494    [RFC7766]  Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and    
  495               D. Wessels, "DNS Transport over TCP - Implementation         
  496               Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,   
  497               <https://www.rfc-editor.org/info/rfc7766>.                   
  498                                                                            
  499    [RFC7873]  Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)   
  500               Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,          
  501               <https://www.rfc-editor.org/info/rfc7873>.                   
  502                                                                            
  503    [RFC8020]  Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is      
  504               Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,         
  505               November 2016, <https://www.rfc-editor.org/info/rfc8020>.    
  506                                                                            
  507    [RFC8198]  Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of    
  508               DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,     
  509               July 2017, <https://www.rfc-editor.org/info/rfc8198>.        
  510                                                                            
  511    [RFC8914]  Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.       
  512               Lawrence, "Extended DNS Errors", RFC 8914,                   
  513               DOI 10.17487/RFC8914, October 2020,                          
  514               <https://www.rfc-editor.org/info/rfc8914>.                   
  515                                                                            
  516    [RFC9156]  Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query      
  517               Name Minimisation to Improve Privacy", RFC 9156,             
  518               DOI 10.17487/RFC9156, November 2021,                         
  519               <https://www.rfc-editor.org/info/rfc9156>.                   
  520                                                                            
  521    [RFC9499]  Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,     
  522               RFC 9499, DOI 10.17487/RFC9499, March 2024,                  
  523               <https://www.rfc-editor.org/info/rfc9499>.                   
  524                                                                            
  525 Acknowledgements                                                           
  526                                                                            
  527    This document is based on an idea by Roy Arends and David Conrad.       
  528    The authors would like to thank Peter van Dijk, Stephane Bortzmeyer,    
  529    Shane Kerr, Vladimir Cunat, Paul Hoffman, Philip Homburg, Mark          
  530    Andrews, Libor Peltan, Matthijs Mekking, Willem Toorop, Tom Carpay,     
  531    Dick Franks, Ben Schwartz, Yaron Sheffer, Viktor Dukhovni, Wes          
  532    Hardaker, James Gannon, Tim Wicinski, Warren Kumari, Gorry Fairhurst,   
  533    Benno Overeinder, Paul Wouters, and Petr Spacek for their               
  534    contributions.                                                          
  535                                                                            
  536 Authors' Addresses                                                         
  537                                                                            
  538    Roy Arends                                                              
  539    ICANN                                                                   
  540    Email: roy.arends@icann.org                                             
  541                                                                            
  542                                                                            
  543    Matt Larson                                                             
  544    ICANN                                                                   
  545    Email: matt.larson@icann.org                                            
  546                                                                            

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.