1 Internet Engineering Task Force (IETF)                     S. Bortzmeyer   
    2 Request for Comments: 8020                                         AFNIC   
    3 Updates: 1034, 2308                                             S. Huque   
    4 Category: Standards Track                                  Verisign Labs   
    5 ISSN: 2070-1721                                            November 2016   
    6                                                                            
    7                                                                            
    8               NXDOMAIN: There Really Is Nothing Underneath                 
    9                                                                            
   10 Abstract                                                                   
   11                                                                            
   12    This document states clearly that when a DNS resolver receives a        
   13    response with a response code of NXDOMAIN, it means that the domain     
   14    name which is thus denied AND ALL THE NAMES UNDER IT do not exist.      
   15                                                                            
   16    This document clarifies RFC 1034 and modifies a portion of RFC 2308:    
   17    it updates both of them.                                                
   18                                                                            
   19 Status of This Memo                                                        
   20                                                                            
   21    This is an Internet Standards Track document.                           
   22                                                                            
   23    This document is a product of the Internet Engineering Task Force       
   24    (IETF).  It represents the consensus of the IETF community.  It has     
   25    received public review and has been approved for publication by the     
   26    Internet Engineering Steering Group (IESG).  Further information on     
   27    Internet Standards is available in Section 2 of RFC 7841.               
   28                                                                            
   29    Information about the current status of this document, any errata,      
   30    and how to provide feedback on it may be obtained at                    
   31    http://www.rfc-editor.org/info/rfc8020.                                 
   32                                                                            
   33 Copyright Notice                                                           
   34                                                                            
   35    Copyright (c) 2016 IETF Trust and the persons identified as the         
   36    document authors.  All rights reserved.                                 
   37                                                                            
   38    This document is subject to BCP 78 and the IETF Trust's Legal           
   39    Provisions Relating to IETF Documents                                   
   40    (http://trustee.ietf.org/license-info) in effect on the date of         
   41    publication of this document.  Please review these documents            
   42    carefully, as they describe your rights and restrictions with respect   
   43    to this document.  Code Components extracted from this document must    
   44    include Simplified BSD License text as described in Section 4.e of      
   45    the Trust Legal Provisions and are provided without warranty as         
   46    described in the Simplified BSD License.                                
   47                                                                            
   48                                                                            
   49                                                                            
   50                                                                            
   51                                                                            
   52 Bortzmeyer & Huque           Standards Track                    [Page 1]   

   53 RFC 8020                      NXDOMAIN Cut                 November 2016   
   54                                                                            
   55                                                                            
   56 Table of Contents                                                          
   57                                                                            
   58    1. Introduction and Background .....................................2   
   59       1.1. Terminology ................................................3   
   60    2. Rules ...........................................................3   
   61    3. Updates to RFCs .................................................5   
   62       3.1. Updates to RFC 1034 ........................................5   
   63       3.2. Updates to RFC 2308 ........................................5   
   64    4. Benefits ........................................................5   
   65    5. Possible Issues .................................................6   
   66    6. Implementation Considerations ...................................6   
   67    7. Security Considerations .........................................7   
   68    8. References ......................................................7   
   69       8.1. Normative References .......................................7   
   70       8.2. Informative References .....................................8   
   71    Appendix A. Why can't we just use the owner name of the returned        
   72                SOA? ...................................................9   
   73    Appendix B. Related Approaches .....................................9   
   74    Acknowledgments ....................................................9   
   75    Authors' Addresses ................................................10   
   76                                                                            
   77 1.  Introduction and Background                                            
   78                                                                            
   79    The DNS protocol [RFC1035] defines response code 3 as "Name Error",     
   80    or "NXDOMAIN" [RFC2308], which means that the queried domain name       
   81    does not exist in the DNS.  Since domain names are represented as a     
   82    tree of labels ([RFC1034], Section 3.1), nonexistence of a node         
   83    implies nonexistence of the entire subtree rooted at this node.         
   84                                                                            
   85    The DNS iterative resolution algorithm precisely interprets the         
   86    NXDOMAIN signal in this manner.  If it encounters an NXDOMAIN           
   87    response code from an authoritative server, it immediately stops        
   88    iteration and returns the NXDOMAIN response to the querier.             
   89                                                                            
   90    However, in most known existing resolvers today, a cached               
   91    nonexistence for a domain is not considered "proof" that there can be   
   92    no child domains underneath.  This is due to an ambiguity in            
   93    [RFC1034] that failed to distinguish Empty Non-Terminal (ENT) names     
   94    ([RFC7719]) from nonexistent names (Section 3.1).  The distinction      
   95    became especially important for the development of DNSSEC, which        
   96    provides proof of nonexistence.  [RFC4035], Section 3.1.3.2,            
   97    describes how security-aware authoritative name servers make the        
   98    distinction, but no existing RFCs describe the behavior for recursive   
   99    name servers.                                                           
  100                                                                            
  101                                                                            
  102                                                                            
  103                                                                            
  104                                                                            
  105                                                                            
  106                                                                            
  107 Bortzmeyer & Huque           Standards Track                    [Page 2]   

  108 RFC 8020                      NXDOMAIN Cut                 November 2016   
  109                                                                            
  110                                                                            
  111    This document specifies that an NXDOMAIN response for a domain name     
  112    means that no child domains underneath the queried name exist either;   
  113    furthermore, it means that DNS resolvers should interpret cached        
  114    nonexistence in this manner.  Since the domain names are organized in   
  115    a tree, it is a simple consequence of the tree structure:               
  116    nonexistence of a node implies nonexistence of the entire subtree       
  117    rooted at this node.                                                    
  118                                                                            
  119 1.1.  Terminology                                                          
  120                                                                            
  121    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",     
  122    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this    
  123    document are to be interpreted as described in [RFC2119].               
  124                                                                            
  125    "QNAME": defined in [RFC1034] and in [RFC1035], Section 4.1.2, but,     
  126    because [RFC2308] provides a different definition, we repeat the        
  127    original one here: the QNAME is the domain name in the question         
  128    section.                                                                
  129                                                                            
  130    "Denied name": the domain name whose existence has been denied by a     
  131    response RCODE of NXDOMAIN.  In most cases, it is the QNAME but,        
  132    because of [RFC6604], it is not always the case.                        
  133                                                                            
  134    Other terms are defined in [RFC1034], [RFC1035], and (like NXDOMAIN     
  135    itself) in the more recent [RFC7719].                                   
  136                                                                            
  137    The domain name space is conceptually defined in terms of a tree        
  138    structure.  The implementation of a DNS resolver/cache MAY use a tree   
  139    or other data structures.  The cache being a subset of the data in      
  140    the domain name space, it is much easier to reason about it in terms    
  141    of that tree structure and to describe things in those terms (names     
  142    under/above, descendant names, subtrees, etc.).  In fact, the DNS       
  143    algorithm description in [RFC1034] even states an assumption that the   
  144    cache is a tree structure, so the precedent is already well             
  145    established: see its Section 4.3.2, which says "The following           
  146    algorithm assumes that the RRs are organized in several tree            
  147    structures, one for each zone, and another for the cache..." So, in     
  148    this document, each time we talk about a tree or tree operations,       
  149    we're referring to the model, not to the actual implementation.         
  150                                                                            
  151 2.  Rules                                                                  
  152                                                                            
  153    When an iterative caching DNS resolver receives an NXDOMAIN response,   
  154    it SHOULD store it in its cache and then all names and resource         
  155    record sets (RRsets) at or below that node SHOULD be considered         
  156    unreachable.  Subsequent queries for such names SHOULD elicit an        
  157    NXDOMAIN response.                                                      
  158                                                                            
  159                                                                            
  160                                                                            
  161                                                                            
  162 Bortzmeyer & Huque           Standards Track                    [Page 3]   

  163 RFC 8020                      NXDOMAIN Cut                 November 2016   
  164                                                                            
  165                                                                            
  166    But, if a resolver has cached data under the NXDOMAIN cut, it MAY       
  167    continue to send it as a reply (until the TTL of this cached data       
  168    expires), since this may avoid additional processing when a query is    
  169    received.  Section 6 provides more information about this.              
  170                                                                            
  171    Another exception is that a validating resolver MAY decide to           
  172    implement the "NXDOMAIN cut" behavior (described in the first           
  173    paragraph of this section) only when the NXDOMAIN response has been     
  174    validated with DNSSEC.  See Section 7 for the rationale.                
  175                                                                            
  176    The fact that a subtree does not exist is not forever: [RFC2308],       
  177    Section 3, already describes the amount of time that an NXDOMAIN        
  178    response may be cached (the "negative TTL").                            
  179                                                                            
  180    If the NXDOMAIN response due to a cached nonexistence is from a         
  181    DNSSEC-signed zone, then it will have accompanying NSEC or NSEC3        
  182    records that authenticate the nonexistence of the name.  For a          
  183    descendant name of the original NXDOMAIN name, the same set of NSEC     
  184    or NSEC3 records proves the nonexistence of the descendant name.  The   
  185    iterative, caching resolver MUST return these NSEC or NSEC3 records     
  186    in the response to the triggering query if the query had the DNSSEC     
  187    OK (DO) bit set.                                                        
  188                                                                            
  189    Warning: if there is a chain of CNAME (or DNAME), the name that does    
  190    not exist is the last of the chain ([RFC6604]) and not the QNAME.       
  191    The NXDOMAIN stored in the cache is for the denied name, not always     
  192    for the QNAME.                                                          
  193                                                                            
  194    As an example of the consequence of these rules, consider two           
  195    successive queries to a resolver with a nonexisting domain              
  196    'foo.example': the first is for 'foo.example' (which results in an      
  197    NXDOMAIN) and the second for 'bar.foo.example' (which also results in   
  198    an NXDOMAIN).  Many resolvers today will forward both queries.          
  199    However, following the rules in this document ("NXDOMAIN cut"), a       
  200    resolver would cache the first NXDOMAIN response, as a sign of          
  201    nonexistence, and then immediately return an NXDOMAIN response for      
  202    the second query, without transmitting it to an authoritative server.   
  203                                                                            
  204    If the first request is for 'bar.foo.example' and the second for        
  205    'baz.foo.example', then the first NXDOMAIN response won't tell          
  206    anything about 'baz.foo.example'; therefore, the second query will be   
  207    transmitted as it was before the use of "NXDOMAIN cut" optimization     
  208    (see Appendix A).                                                       
  209                                                                            
  210                                                                            
  211                                                                            
  212                                                                            
  213                                                                            
  214                                                                            
  215                                                                            
  216                                                                            
  217 Bortzmeyer & Huque           Standards Track                    [Page 4]   

  218 RFC 8020                      NXDOMAIN Cut                 November 2016   
  219                                                                            
  220                                                                            
  221 3.  Updates to RFCs                                                        
  222                                                                            
  223 3.1.  Updates to RFC 1034                                                  
  224                                                                            
  225    This document clarifies possible ambiguities in [RFC1034] that did      
  226    not clearly distinguish Empty Non-Terminal (ENT) names ([RFC7719])      
  227    from nonexistent names, and it refers to subsequent documents that      
  228    do.  ENTs are nodes in the DNS that do not have resource record sets    
  229    associated with them but have descendant nodes that do.  The correct    
  230    response to ENTs is NODATA (i.e., a response code of NOERROR and an     
  231    empty answer section).  Additional clarifying language on these         
  232    points is provided in Section 7.16 of [RFC2136] and in Sections 2.2.2   
  233    and 2.2.3 of [RFC4592].                                                 
  234                                                                            
  235 3.2.  Updates to RFC 2308                                                  
  236                                                                            
  237    The second paragraph of Section 5 in [RFC2308] states the following:    
  238                                                                            
  239       A negative answer that resulted from a name error (NXDOMAIN)         
  240       should be cached such that it can be retrieved and returned in       
  241       response to another query for the same <QNAME, QCLASS> that          
  242       resulted in the cached negative response.                            
  243                                                                            
  244    This document revises that paragraph to the following:                  
  245                                                                            
  246       A negative answer that resulted from a name error (NXDOMAIN)         
  247       should be cached such that it can be retrieved and returned in       
  248       response to another query for the same <QNAME, QCLASS> that          
  249       resulted in the cached negative response, or where the QNAME is a    
  250       descendant of the original QNAME and the QCLASS is the same.         
  251                                                                            
  252    Section 2 above elaborates on the revised rule and specifies when it    
  253    may be reasonable to relax or ignore it.                                
  254                                                                            
  255 4.  Benefits                                                               
  256                                                                            
  257    The main benefit is a better efficiency of the caches.  In the          
  258    example above, the resolver sends only one query instead of two, the    
  259    second one being answered from the cache.  This will benefit the        
  260    entire DNS ecosystem, since the authoritative name servers will have    
  261    less unnecessary traffic to process.                                    
  262                                                                            
  263    The correct behavior (in [RFC1034] and made clearer in this document)   
  264    is especially useful when combined with QNAME minimization [RFC7816]    
  265    since it will allow a resolver to stop searching as soon as an          
  266    NXDOMAIN is encountered.                                                
  267                                                                            
  268                                                                            
  269                                                                            
  270                                                                            
  271                                                                            
  272 Bortzmeyer & Huque           Standards Track                    [Page 5]   

  273 RFC 8020                      NXDOMAIN Cut                 November 2016   
  274                                                                            
  275                                                                            
  276    "NXDOMAIN cut" may also help mitigate certain types of random QNAME     
  277    attacks [joost-dnsterror] and [balakrichenan-dafa888], where there is   
  278    a fixed suffix that does not exist.  In these attacks against the       
  279    authoritative name server, queries are sent to resolvers for a QNAME    
  280    composed of a fixed suffix ("dafa888.wf" in one of the articles         
  281    above), which is typically nonexistent, and a random prefix,            
  282    different for each request.  A resolver receiving these requests has    
  283    to forward them to the authoritative servers.  With "NXDOMAIN cut", a   
  284    system administrator would just have to send to the resolver a query    
  285    for the fixed suffix, the resolver would get a NXDOMAIN and then        
  286    would stop forwarding the queries.  (It would be better if the SOA      
  287    record in the NXDOMAIN response were sufficient to find the             
  288    nonexisting domain, but this is not the case, see Appendix A.)          
  289                                                                            
  290 5.  Possible Issues                                                        
  291                                                                            
  292    Let's assume that the Top-Level Domain (TLD) example exists, but        
  293    foobar.example is not delegated (so the example's name servers will     
  294    reply NXDOMAIN for a query about anything.foobar.example).  A system    
  295    administrator decides to name the internal machines of his              
  296    organization under office.foobar.example and uses a trick of his        
  297    resolver to forward requests about this zone to his local               
  298    authoritative name servers.  "NXDOMAIN cut" would create problems       
  299    here; depending on the order of requests to the resolver, it may have   
  300    cached the nonexistence from example and therefore "deleted"            
  301    everything under it.  This document assumes that such a setup is rare   
  302    and does not need to be supported.                                      
  303                                                                            
  304    Today, another possible issue exists; we see authoritative name         
  305    servers that reply to ENT ([RFC7719], Section 6) with NXDOMAIN          
  306    instead of the normal NODATA ([RFC7719], Section 3).                    
  307                                                                            
  308    Such name servers are definitely wrong and have always been.  Their     
  309    behaviour is incompatible with DNSSEC.  Given the advantages of         
  310    "NXDOMAIN cut", there is little reason to support this behavior.        
  311                                                                            
  312 6.  Implementation Considerations                                          
  313                                                                            
  314    This section is non-normative and is composed only of various things    
  315    that may be useful for implementors.  A recursive resolver may          
  316    implement its cache in many ways.  The most obvious one is a tree       
  317    data structure, because it fits the data model of domain names.  But,   
  318    in practice, other implementations are possible, as well as various     
  319    optimizations (such as a tree, augmented by an index of some common     
  320    domain names).                                                          
  321                                                                            
  322                                                                            
  323                                                                            
  324                                                                            
  325                                                                            
  326                                                                            
  327 Bortzmeyer & Huque           Standards Track                    [Page 6]   

  328 RFC 8020                      NXDOMAIN Cut                 November 2016   
  329                                                                            
  330                                                                            
  331    If a resolver implements its cache as a tree (without any               
  332    optimization), one way to follow the rules in Section 2 is as           
  333    follows: when receiving the NXDOMAIN, prune the subtree of positive     
  334    cache entries at that node or delete all individual cache entries for   
  335    names below that node.  Then, when searching downward in its cache,     
  336    this iterative caching DNS resolver will stop searching if it           
  337    encounters a cached nonexistence.                                       
  338                                                                            
  339    Some resolvers may have a cache that is NOT organized as a tree (but,   
  340    for instance, as a dictionary); therefore, they have a reason to        
  341    ignore the rules of Section 2.  So these rules use SHOULD and not       
  342    MUST.                                                                   
  343                                                                            
  344 7.  Security Considerations                                                
  345                                                                            
  346    The technique described in this document may help against a denial-     
  347    of-service attack named "random qnames" described in Section 4.         
  348                                                                            
  349    If a resolver does not validate the answers with DNSSEC, or if the      
  350    zone is not signed, the resolver can of course be poisoned with a       
  351    false NXDOMAIN, thus, "deleting" a part of the domain name tree.        
  352    This denial-of-service attack is already possible without the rules     
  353    of this document (but "NXDOMAIN cut" may increase its effects).  The    
  354    only solution is to use DNSSEC.                                         
  355                                                                            
  356 8.  References                                                             
  357                                                                            
  358 8.1.  Normative References                                                 
  359                                                                            
  360    [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",   
  361               STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,       
  362               <http://www.rfc-editor.org/info/rfc1034>.                    
  363                                                                            
  364    [RFC1035]  Mockapetris, P., "Domain names - implementation and          
  365               specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,      
  366               November 1987, <http://www.rfc-editor.org/info/rfc1035>.     
  367                                                                            
  368    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate          
  369               Requirement Levels", BCP 14, RFC 2119,                       
  370               DOI 10.17487/RFC2119, March 1997,                            
  371               <http://www.rfc-editor.org/info/rfc2119>.                    
  372                                                                            
  373    [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,      
  374               "Dynamic Updates in the Domain Name System (DNS UPDATE)",    
  375               RFC 2136, DOI 10.17487/RFC2136, April 1997,                  
  376               <http://www.rfc-editor.org/info/rfc2136>.                    
  377                                                                            
  378                                                                            
  379                                                                            
  380                                                                            
  381                                                                            
  382 Bortzmeyer & Huque           Standards Track                    [Page 7]   

  383 RFC 8020                      NXDOMAIN Cut                 November 2016   
  384                                                                            
  385                                                                            
  386    [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS           
  387               NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,        
  388               <http://www.rfc-editor.org/info/rfc2308>.                    
  389                                                                            
  390    [RFC4592]  Lewis, E., "The Role of Wildcards in the Domain Name         
  391               System", RFC 4592, DOI 10.17487/RFC4592, July 2006,          
  392               <http://www.rfc-editor.org/info/rfc4592>.                    
  393                                                                            
  394    [RFC6604]  Eastlake 3rd, D., "xNAME RCODE and Status Bits               
  395               Clarification", RFC 6604, DOI 10.17487/RFC6604, April        
  396               2012, <http://www.rfc-editor.org/info/rfc6604>.              
  397                                                                            
  398 8.2.  Informative References                                               
  399                                                                            
  400    [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.      
  401               Rose, "Protocol Modifications for the DNS Security           
  402               Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,     
  403               <http://www.rfc-editor.org/info/rfc4035>.                    
  404                                                                            
  405    [RFC7719]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS             
  406               Terminology", RFC 7719, DOI 10.17487/RFC7719, December       
  407               2015, <http://www.rfc-editor.org/info/rfc7719>.              
  408                                                                            
  409    [RFC7816]  Bortzmeyer, S., "DNS Query Name Minimisation to Improve      
  410               Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,        
  411               <http://www.rfc-editor.org/info/rfc7816>.                    
  412                                                                            
  413    [DNSRRR]   Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS     
  414               Resolvers for Resiliency, Robustness, and Responsiveness",   
  415               Work in Progress, draft-vixie-dnsext-resimprove-00, June     
  416               2010.                                                        
  417                                                                            
  418    [NSEC]     Fujiwara, K., Kato, A., and W. Kumari, "Aggressive use of    
  419               NSEC/NSEC3", Work in Progress, draft-ietf-dnsop-nsec-        
  420               aggressiveuse-04, September 2016.                            
  421                                                                            
  422    [joost-dnsterror]                                                       
  423               Joost, M., "About DNS Attacks and ICMP Destination           
  424               Unreachable Reports", December 2014,                         
  425               <http://www.michael-joost.de/dnsterror.html>.                
  426                                                                            

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.

  427    [balakrichenan-dafa888]                                                 
  428               Balakrichenan, S., "Disturbance in the DNS - "Random         
  429               qnames", the dafa888 DoS attack"", October 2014,             
  430               <https://indico.dns-oarc.net/event/20/session/3/             
  431               contribution/3>.                                             
  432                                                                            
  433                                                                            
  434                                                                            
  435                                                                            
  436                                                                            
  437 Bortzmeyer & Huque           Standards Track                    [Page 8]   

  438 RFC 8020                      NXDOMAIN Cut                 November 2016   
  439                                                                            
  440                                                                            
  441 Appendix A.  Why can't we just use the owner name of the returned SOA?     
  442                                                                            
  443    In this document, we deduce the nonexistence of a domain only for       
  444    NXDOMAIN answers where the denied name was the exact domain.  If a      
  445    resolver sends a query to the name servers of the TLD example, asking   
  446    for the mail exchange (MX) record for www.foobar.example, and           
  447    subsequently receives a NXDOMAIN, it can only register the fact that    
  448    www.foobar.example (and everything underneath) does not exist.  This    
  449    is true regardless of whether or not the accompanying SOA record is     
  450    for the domain example only.  One cannot infer that foobar.example is   
  451    nonexistent.  The accompanying SOA record indicates the apex of the     
  452    zone, not the closest existing domain name.  So, using the owner name   
  453    of the SOA record in the authority section to deduce "NXDOMAIN cuts"    
  454    is currently definitely not OK.                                         
  455                                                                            
  456    Deducing the nonexistence of a node from the SOA in the NXDOMAIN        
  457    reply may certainly help with random qnames attacks, but this is out-   
  458    of-scope for this document.  It would require addressing the problems   
  459    mentioned in the first paragraph of this section.  A possible           
  460    solution is, when receiving a NXDOMAIN with a SOA that is more than     
  461    one label up in the tree, to send requests for the domains that are     
  462    between the QNAME and the owner name of the SOA.  (A resolver that      
  463    does DNSSEC validation or QNAME minimization will need to do it         
  464    anyway.)                                                                
  465                                                                            
  466 Appendix B.  Related Approaches                                            
  467                                                                            
  468    The document [NSEC] describes another way to address some of the same   
  469    concerns (decreasing the traffic for nonexisting domain names).         
  470    Unlike "NXDOMAIN cut", it requires DNSSEC, but it is more powerful      
  471    since it can synthesize NXDOMAINs for domains that were not queried.    
  472                                                                            
  473 Acknowledgments                                                            
  474                                                                            
  475    The main idea in this document is taken from [DNSRRR], Section 3,       
  476    "Stopping Downward Cache Search on NXDOMAIN".  Thanks to its authors,   
  477    Paul Vixie, Rodney Joffe, and Frederico Neves.  Additionally, Tony      
  478    Finch, Ted Lemon, John Levine, Jinmei Tatuya, Bob Harold, and Duane     
  479    Wessels provided valuable feedback and suggestions.                     
  480                                                                            
  481                                                                            
  482                                                                            
  483                                                                            
  484                                                                            
  485                                                                            
  486                                                                            
  487                                                                            
  488                                                                            
  489                                                                            
  490                                                                            
  491                                                                            
  492 Bortzmeyer & Huque           Standards Track                    [Page 9]   

  493 RFC 8020                      NXDOMAIN Cut                 November 2016   
  494                                                                            
  495                                                                            
  496 Authors' Addresses                                                         
  497                                                                            
  498    Stephane Bortzmeyer                                                     
  499    AFNIC                                                                   
  500    1, rue Stephenson                                                       
  501    Montigny-le-Bretonneux  78180                                           
  502    France                                                                  
  503                                                                            
  504    Phone: +33 1 39 30 83 46                                                
  505    Email: bortzmeyer+ietf@nic.fr                                           
  506    URI:   https://www.afnic.fr/                                            
  507                                                                            
  508                                                                            
  509    Shumon Huque                                                            
  510    Verisign Labs                                                           
  511    12061 Bluemont Way                                                      
  512    Reston, VA  20190                                                       
  513    United States of America                                                
  514                                                                            
  515    Email: shuque@verisign.com                                              
  516    URI:   http://www.verisignlabs.com/                                     
  517                                                                            
  518                                                                            
  519                                                                            
  520                                                                            
  521                                                                            
  522                                                                            
  523                                                                            
  524                                                                            
  525                                                                            
  526                                                                            
  527                                                                            
  528                                                                            
  529                                                                            
  530                                                                            
  531                                                                            
  532                                                                            
  533                                                                            
  534                                                                            
  535                                                                            
  536                                                                            
  537                                                                            
  538                                                                            
  539                                                                            
  540                                                                            
  541                                                                            
  542                                                                            
  543                                                                            
  544                                                                            
  545                                                                            
  546                                                                            
  547 Bortzmeyer & Huque           Standards Track                   [Page 10]   
  548                                                                            
line-427 Ángel(Editorial Erratum #6079) [Held for Document Update]
based on outdated version
   [balakrichenan-dafa888]
              Balakrichenan, S., "Disturbance in the DNS - "Random
              qnames", the dafa888 DoS attack"", October 2014,
              <­https://indico.dns-oarc.net/event/20/session/3/contribution/3>.
It should say:
   [balakrichenan-dafa888]
              Balakrichenan, S., "Disturbance in the DNS - "Random
              qnames", the dafa888 DoS attack"", October 2014,
              <­https://indico.dns-oarc.net/event/20/session/3/contribution/3contributions/278/>.

The url for [balakrichenan-dafa888] returns «Not Found The page you are looking for doesn't exist.», and seems to have done so for some time: https://web.archive.org/web/20180615000000*/https://indico.dns-oarc.net/event/20/session/3/contribution/3/

The referenced content was found at https://indico.dns-oarc.net/event/20/contributions/278/