1 Internet Engineering Task Force (IETF)                           P. Koch   
    2 Request for Comments: 8109                                      DENIC eG   
    3 BCP: 209                                                       M. Larson   
    4 Category: Best Current Practice                               P. Hoffman   
    5 ISSN: 2070-1721                                                    ICANN   
    6                                                               March 2017   
    7                                                                            
    8                                                                            
    9             Initializing a DNS Resolver with Priming Queries               
   10                                                                            
   11 Abstract                                                                   
   12                                                                            
   13    This document describes the queries that a DNS resolver should emit     
   14    to initialize its cache.  The result is that the resolver gets both a   
   15    current NS Resource Record Set (RRset) for the root zone and the        
   16    necessary address information for reaching the root servers.            
   17                                                                            
   18 Status of This Memo                                                        
   19                                                                            
   20    This memo documents an Internet Best Current Practice.                  
   21                                                                            
   22    This document is a product of the Internet Engineering Task Force       
   23    (IETF).  It represents the consensus of the IETF community.  It has     
   24    received public review and has been approved for publication by the     
   25    Internet Engineering Steering Group (IESG).  Further information on     
   26    BCPs is available in Section 2 of RFC 7841.                             
   27                                                                            
   28    Information about the current status of this document, any errata,      
   29    and how to provide feedback on it may be obtained at                    
   30    http://www.rfc-editor.org/info/rfc8109.                                 
   31                                                                            
   32 Copyright Notice                                                           
   33                                                                            
   34    Copyright (c) 2017 IETF Trust and the persons identified as the         
   35    document authors.  All rights reserved.                                 
   36                                                                            
   37    This document is subject to BCP 78 and the IETF Trust's Legal           
   38    Provisions Relating to IETF Documents                                   
   39    (http://trustee.ietf.org/license-info) in effect on the date of         
   40    publication of this document.  Please review these documents            
   41    carefully, as they describe your rights and restrictions with respect   
   42    to this document.  Code Components extracted from this document must    
   43    include Simplified BSD License text as described in Section 4.e of      
   44    the Trust Legal Provisions and are provided without warranty as         
   45    described in the Simplified BSD License.                                
   46                                                                            
   47                                                                            
   48                                                                            
   49                                                                            
   50                                                                            
   51                                                                            
   52 Koch et al.               Best Current Practice                 [Page 1]   

   53 RFC 8109                   DNS Priming Queries                March 2017   
   54                                                                            
   55                                                                            
   56 Table of Contents                                                          
   57                                                                            
   58    1. Introduction ....................................................2   
   59    2. Description of Priming ..........................................3   
   60    3. Priming Queries .................................................3   
   61       3.1. Repeating Priming Queries ..................................4   
   62       3.2. Target Selection ...........................................4   
   63       3.3. DNSSEC with Priming Queries ................................4   
   64    4. Priming Responses ...............................................5   
   65       4.1. Expected Properties of the Priming Response ................5   
   66       4.2. Completeness of the Response ...............................5   
   67    5. Security Considerations .........................................6   
   68    6. IANA Considerations .............................................6   
   69    7. Normative References ............................................6   
   70    Acknowledgements ...................................................7   
   71    Authors' Addresses .................................................7   
   72                                                                            
   73 1.  Introduction                                                           
   74                                                                            
   75    Recursive DNS resolvers need a starting point to resolve queries.       
   76    [RFC1034] describes a common scenario for recursive resolvers: they     
   77    begin with an empty cache and some configuration for finding the        
   78    names and addresses of the DNS root servers.  [RFC1034] describes       
   79    that configuration as a list of servers that will give authoritative    
   80    answers to queries about the root.  This has become a common            
   81    implementation choice for recursive resolvers, and is the topic of      
   82    this document.                                                          
   83                                                                            
   84    This document describes the steps needed for this common                
   85    implementation choice.  Note that this is not the only way to start a   
   86    recursive name server with an empty cache, but it is the only one       
   87    described in [RFC1034].  Some implementers have chosen other            
   88    directions, some of which work well and others of which fail            
   89    (sometimes disastrously) under different conditions.  For example, an   
   90    implementation that only gets the addresses of the root name servers    
   91    from configuration, not from the DNS as described in this document,     
   92    will have stale data that could cause slower resolution.                
   93                                                                            
   94    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",     
   95    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this    
   96    document are to be interpreted as described in [RFC2119].               
   97                                                                            
   98    This document only deals with recursive name servers (recursive         
   99    resolvers, resolvers) for the IN class.                                 
  100                                                                            
  101                                                                            
  102                                                                            
  103                                                                            
  104                                                                            
  105                                                                            
  106                                                                            
  107 Koch et al.               Best Current Practice                 [Page 2]   

  108 RFC 8109                   DNS Priming Queries                March 2017   
  109                                                                            
  110                                                                            
  111 2.  Description of Priming                                                 
  112                                                                            
  113    Priming is the act of finding the list of root servers from a           
  114    configuration that lists some or all of the purported IP addresses of   
  115    some or all of those root servers.  A recursive resolver starts with    
  116    no information about the root servers, and ends up with a list of       
  117    their names and their addresses.                                        
  118                                                                            
  119    Priming is described in Sections 5.3.2 and 5.3.3 of [RFC1034].  The     
  120    scenario used in that description, that of a recursive server that is   
  121    also authoritative, is no longer as common.                             
  122                                                                            
  123    The configured list of IP addresses for the root servers usually        
  124    comes from the vendor or distributor of the recursive server            
  125    software.  This list is usually correct and complete when shipped,      
  126    but may become out of date over time.                                   
  127                                                                            
  128    The list of root server operators and the domain name associated with   
  129    each one has been stable since 1997.  However, there are address        
  130    changes for the root server domain names, both for IPv4 and IPv6        
  131    addresses.  However, research shows that after those addresses          
  132    change, some resolvers never get the new addresses.  Therefore, it is   
  133    important that resolvers be able to cope with change, even without      
  134    relying upon configuration updates to be applied by their operator.     
  135    Root server change is the main reason that resolvers need to do         
  136    priming instead of just going from a configured list to get a full      
  137    and accurate list of root servers.                                      
  138                                                                            
  139 3.  Priming Queries                                                        
  140                                                                            
  141    A priming query is a DNS query used to get the root server              
  142    information in a resolver.  It has a QNAME of "." and a QTYPE of NS,    
  143    and is sent to one of the addresses in the configuration for the        
  144    recursive resolver.  The priming query can be sent over either UDP or   
  145    TCP.  If the query is sent over UDP, the source port SHOULD be          
  146    randomly selected (see [RFC5452]).  The Recursion Desired (RD) bit      
  147    MAY be set to 0 or 1, although the meaning of it being set to 1 is      
  148    undefined for priming queries.                                          
  149                                                                            
  150    The recursive resolver SHOULD use EDNS(0) [RFC6891] for priming         
  151    queries and SHOULD announce and handle a reassembly size of at least    
  152    1024 octets [RFC3226].  Doing so allows responses that cover the size   
  153    of a full priming response (see Section 4.2) for the current set of     
  154    root servers.  See Section 3.3 for discussion of setting the DNSSEC     
  155    OK (DO) bit (defined in [RFC4033]).                                     
  156                                                                            
  157                                                                            
  158                                                                            
  159                                                                            
  160                                                                            
  161                                                                            
  162 Koch et al.               Best Current Practice                 [Page 3]   

  163 RFC 8109                   DNS Priming Queries                March 2017   
  164                                                                            
  165                                                                            
  166 3.1.  Repeating Priming Queries                                            
  167                                                                            
  168    The recursive resolver SHOULD send a priming query only when it is      
  169    needed, such as when the resolver starts with an empty cache and when   
  170    the NS RRset for the root zone has expired.  Because the NS records     
  171    for the root are not special, the recursive resolver expires those NS   
  172    records according to their TTL values.  (Note that a recursive          
  173    resolver MAY pre-fetch the NS RRset before it expires.)                 
  174                                                                            
  175    If a priming query does not get a response, the recursive resolver      
  176    needs to retry the query with a different target address from the       
  177    configuration.                                                          
  178                                                                            
  179 3.2.  Target Selection                                                     
  180                                                                            
  181    In order to spread the load across all the root server domain names,    
  182    the recursive resolver SHOULD select the target for a priming query     
  183    randomly from the list of addresses.  The recursive resolver might      
  184    choose either IPv4 or IPv6 addresses based on its knowledge of          
  185    whether the system on which it is running has adequate connectivity     
  186    on either type of address.                                              
  187                                                                            
  188    Note that this recommended method is not the only way to choose from    
  189    the list in a recursive resolver's configuration.  Two other common     
  190    methods include picking the first from the list, and remembering        
  191    which address in the list gave the fastest response earlier and using   
  192    that one.  There are probably other methods in use today.  However,     
  193    the random method listed above SHOULD be used for priming.              
  194                                                                            
  195 3.3.  DNSSEC with Priming Queries                                          
  196                                                                            
  197    The resolver MAY set the DNSSEC OK (DO) bit.  At the time of            
  198    publication, there is little use to performing DNSSEC validation on     
  199    the priming query.  Currently, all root name server names end in        
  200    "root-servers.net" and the AAAA and A RRsets for the root server        
  201    names reside in the "root-servers.net" zone.  All root servers are      
  202    also authoritative for this zone, allowing priming responses to         
  203    include the appropriate root name server A and AAAA RRsets.  But,       
  204    because the "root-servers.net" zone is not currently signed, these      
  205    RRsets cannot be validated.                                             
  206                                                                            
  207    A man-in-the-middle attack on the priming query could direct a          
  208    resolver to a rogue root name server.  Note, however, that a            
  209    validating resolver will not accept responses from rogue root name      
  210    servers if they are different from the real responses because the       
  211                                                                            
  212                                                                            
  213                                                                            
  214                                                                            
  215                                                                            
  216                                                                            
  217 Koch et al.               Best Current Practice                 [Page 4]   

  218 RFC 8109                   DNS Priming Queries                March 2017   
  219                                                                            
  220                                                                            
  221    resolver has a trust anchor for the root and the answers from the       
  222    root are signed.  Thus, if there is a man-in-the-middle attack on the   
  223    priming query, the only result for a validating resolver will be a      
  224    denial of service, not the resolver's accepting the bad responses.      
  225                                                                            
  226    If the "root-servers.net" zone is later signed, or if the root          
  227    servers are named in a different zone and that zone is signed, having   
  228    DNSSEC validation for the priming queries might be valuable.            
  229                                                                            
  230 4.  Priming Responses                                                      
  231                                                                            
  232    A priming query is a normal DNS query.  Thus, a root name server        
  233    cannot distinguish a priming query from any other query for the root    
  234    NS RRset.  Thus, the root server's response will also be a normal DNS   
  235    response.                                                               
  236                                                                            
  237 4.1.  Expected Properties of the Priming Response                          
  238                                                                            
  239    The priming response is expected to have an RCODE of NOERROR, and to    
  240    have the Authoritative Answer (AA) bit set.  Also, it is expected to    
  241    have an NS RRset in the Answer section (because the NS RRset            
  242    originates from the root zone), and an empty Authority section          
  243    (because the NS RRset already appears in the Answer section).  There    
  244    will also be an Additional section with A and/or AAAA RRsets for the    
  245    root name servers pointed at by the NS RRset.                           
  246                                                                            
  247    Resolver software SHOULD treat the response to the priming query as a   
  248    normal DNS response, just as it would use any other data fed to its     
  249    cache.  Resolver software SHOULD NOT expect exactly 13 NS RRs           
  250    because, historically, some root servers have returned fewer.           
  251                                                                            
  252 4.2.  Completeness of the Response                                         
  253                                                                            
  254    There are currently 13 root servers.  All have one IPv4 address and     
  255    one IPv6 address.  Not even counting the NS RRset, the combined size    
  256    of all the A and AAAA RRsets exceeds the original 512-octet payload     
  257    limit from [RFC1035].                                                   
  258                                                                            
  259    In the event of a response where the Additional section omits certain   
  260    root server address information, re-issuing of the priming query does   
  261    not help with those root name servers that respond with a fixed order   
  262    of addresses in the Additional section.  Instead, the recursive         
  263    resolver needs to issue direct queries for A and AAAA RRsets for the    
  264    remaining names.  Currently, these RRsets would be authoritatively      
  265    available from the root name servers.                                   
  266                                                                            
  267                                                                            
  268                                                                            
  269                                                                            
  270                                                                            
  271                                                                            
  272 Koch et al.               Best Current Practice                 [Page 5]   

  273 RFC 8109                   DNS Priming Queries                March 2017   
  274                                                                            
  275                                                                            
  276 5.  Security Considerations                                                
  277                                                                            
  278    Spoofing a response to a priming query can be used to redirect all of   
  279    the queries originating from a victim recursive resolver to one or      
  280    more servers for the attacker.  Until the responses to priming          
  281    queries are protected with DNSSEC, there is no definitive way to        
  282    prevent such redirection.                                               
  283                                                                            
  284    An on-path attacker who sees a priming query coming from a resolver     
  285    can inject false answers before a root server can give correct          
  286    answers.  If the attacker's answers are accepted, this can set up the   
  287    ability to give further false answers for future queries to the         
  288    resolver.  False answers for root servers are more dangerous than,      
  289    say, false answers for Top-Level Domains (TLDs), because the root is    
  290    the highest node of the DNS.  See Section 3.3 for more discussion.      
  291                                                                            
  292    In both of the scenarios above, a validating resolver will be able to   
  293    detect the attack if its chain of queries comes to a zone that is       
  294    signed, but not for those that are unsigned.                            
  295                                                                            
  296 6.  IANA Considerations                                                    
  297                                                                            
  298    This document does not require any IANA actions.                        
  299                                                                            
  300 7.  Normative References                                                   
  301                                                                            
  302    [RFC1034]   Mockapetris, P., "Domain names - concepts and               
  303                facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034,        
  304                November 1987, <http://www.rfc-editor.org/info/rfc1034>.    
  305                                                                            
  306    [RFC1035]   Mockapetris, P., "Domain names - implementation and         
  307                specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,     
  308                November 1987, <http://www.rfc-editor.org/info/rfc1035>.    
  309                                                                            
  310    [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate         
  311                Requirement Levels", BCP 14, RFC 2119,                      
  312                DOI 10.17487/RFC2119, March 1997,                           
  313                <http://www.rfc-editor.org/info/rfc2119>.                   
  314                                                                            
  315    [RFC3226]   Gudmundsson, O., "DNSSEC and IPv6 A6 aware                  
  316                server/resolver message size requirements", RFC 3226,       
  317                DOI 10.17487/RFC3226, December 2001,                        
  318                <http://www.rfc-editor.org/info/rfc3226>.                   
  319                                                                            
  320    [RFC4033]   Arends, R., Austein, R., Larson, M., Massey, D., and S.     
  321                Rose, "DNS Security Introduction and Requirements",         
  322                RFC 4033, DOI 10.17487/RFC4033, March 2005,                 
  323                <http://www.rfc-editor.org/info/rfc4033>.                   
  324                                                                            
  325                                                                            
  326                                                                            
  327 Koch et al.               Best Current Practice                 [Page 6]   

  328 RFC 8109                   DNS Priming Queries                March 2017   
  329                                                                            
  330                                                                            
  331    [RFC5452]   Hubert, A. and R. van Mook, "Measures for Making DNS More   
  332                Resilient against Forged Answers", RFC 5452,                
  333                DOI 10.17487/RFC5452, January 2009,                         
  334                <http://www.rfc-editor.org/info/rfc5452>.                   
  335                                                                            
  336    [RFC6891]   Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms   
  337                for DNS (EDNS(0))", STD 75, RFC 6891,                       
  338                DOI 10.17487/RFC6891, April 2013,                           
  339                <http://www.rfc-editor.org/info/rfc6891>.                   
  340                                                                            
  341 Acknowledgements                                                           
  342                                                                            
  343    This document is the product of the DNSOP WG and benefitted from the    
  344    reviews done there.                                                     
  345                                                                            
  346 Authors' Addresses                                                         
  347                                                                            
  348    Peter Koch                                                              
  349    DENIC eG                                                                
  350    Kaiserstrasse 75-77                                                     
  351    Frankfurt  60329                                                        
  352    Germany                                                                 
  353                                                                            
  354    Phone: +49 69 27235 0                                                   
  355    Email: pk@DENIC.DE                                                      
  356                                                                            
  357    Matt Larson                                                             
  358    ICANN                                                                   
  359                                                                            
  360    Email: matt.larson@icann.org                                            
  361                                                                            
  362    Paul Hoffman                                                            
  363    ICANN                                                                   
  364                                                                            
  365    Email: paul.hoffman@icann.org                                           
  366                                                                            
  367                                                                            
  368                                                                            
  369                                                                            
  370                                                                            
  371                                                                            
  372                                                                            
  373                                                                            
  374                                                                            
  375                                                                            
  376                                                                            
  377                                                                            
  378                                                                            
  379                                                                            
  380                                                                            
  381                                                                            
  382 Koch et al.               Best Current Practice                 [Page 7]   
  383                                                                            

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.