1 Internet Engineering Task Force (IETF)                         W. Kumari   
    2 Request for Comments: 8806                                        Google   
    3 Obsoletes: 7706                                               P. Hoffman   
    4 Category: Informational                                            ICANN   
    5 ISSN: 2070-1721                                                June 2020   
    8                Running a Root Server Local to a Resolver                   
   10 Abstract                                                                   
   12    Some DNS recursive resolvers have longer-than-desired round-trip        
   13    times to the closest DNS root server; those resolvers may have          
   14    difficulty getting responses from the root servers, such as during a    
   15    network attack.  Some DNS recursive resolver operators want to          
   16    prevent snooping by third parties of requests sent to DNS root          
   17    servers.  In both cases, resolvers can greatly decrease the round-      
   18    trip time and prevent observation of requests by serving a copy of      
   19    the full root zone on the same server, such as on a loopback address    
   20    or in the resolver software.  This document shows how to start and      
   21    maintain such a copy of the root zone that does not cause problems      
   22    for other users of the DNS, at the cost of adding some operational      
   23    fragility for the operator.                                             
   25    This document obsoletes RFC 7706.                                       
   27 Status of This Memo                                                        
   29    This document is not an Internet Standards Track specification; it is   
   30    published for informational purposes.                                   
   32    This document is a product of the Internet Engineering Task Force       
   33    (IETF).  It represents the consensus of the IETF community.  It has     
   34    received public review and has been approved for publication by the     
   35    Internet Engineering Steering Group (IESG).  Not all documents          
   36    approved by the IESG are candidates for any level of Internet           
   37    Standard; see Section 2 of RFC 7841.                                    
   39    Information about the current status of this document, any errata,      
   40    and how to provide feedback on it may be obtained at                    
   41    https://www.rfc-editor.org/info/rfc8806.                                
   43 Copyright Notice                                                           
   45    Copyright (c) 2020 IETF Trust and the persons identified as the         
   46    document authors.  All rights reserved.                                 
   48    This document is subject to BCP 78 and the IETF Trust's Legal           
   49    Provisions Relating to IETF Documents                                   
   50    (https://trustee.ietf.org/license-info) in effect on the date of        
   51    publication of this document.  Please review these documents            
   52    carefully, as they describe your rights and restrictions with respect   
   53    to this document.  Code Components extracted from this document must    
   54    include Simplified BSD License text as described in Section 4.e of      
   55    the Trust Legal Provisions and are provided without warranty as         
   56    described in the Simplified BSD License.                                
   58 Table of Contents                                                          
   60    1.  Introduction                                                        
   61      1.1.  Changes from RFC 7706                                           
   62      1.2.  Requirements Notation                                           
   63    2.  Requirements                                                        
   64    3.  Operation of the Root Zone on the Local Server                      
   65    4.  Security Considerations                                             
   66    5.  IANA Considerations                                                 
   67    6.  References                                                          
   68      6.1.  Normative References                                            
   69      6.2.  Informative References                                          
   70    Appendix A.  Current Sources of the Root Zone                           
   71      A.1.  Root Zone Services                                              
   72    Appendix B.  Example Configurations of Common Implementations           
   73      B.1.  Example Configuration: BIND 9.12                                
   74      B.2.  Example Configuration: Unbound 1.8                              
   75      B.3.  Example Configuration: BIND 9.14                                
   76      B.4.  Example Configuration: Unbound 1.9                              
   77      B.5.  Example Configuration: Knot Resolver                            
   78      B.6.  Example Configuration: Microsoft Windows Server 2012            
   79    Acknowledgements                                                        
   80    Authors' Addresses                                                      
   82 1.  Introduction                                                           
   84    DNS recursive resolvers have to provide answers to all queries from     
   85    their clients, even those for domain names that do not exist.  For      
   86    each queried name that is within a top-level domain (TLD) that is not   
   87    in the recursive resolver's cache, the resolver must send a query to    
   88    a root server to get the information for that TLD or to find out that   
   89    the TLD does not exist.  Research shows that the vast majority of       
   90    queries going to the root are for names that do not exist in the root   
   91    zone.                                                                   
   93    Many of the queries from recursive resolvers to root servers get        
   94    answers that are referrals to other servers.  Malicious third parties   
   95    might be able to observe that traffic on the network between the        
   96    recursive resolver and root servers.                                    
   98    The primary goals of this design are to provide more reliable answers   
   99    for queries to the root zone during network attacks that affect the     
  100    root servers and to prevent queries and responses from being visible    
  101    on the network.  This design will probably have little effect on        
  102    getting faster responses to the stub resolver for good queries on       
  103    TLDs, because the TTL for most TLDs is usually long-lived (on the       
  104    order of a day or two) and is thus usually already in the cache of      
  105    the recursive resolver; the same is true for the TTL for negative       
  106    answers from the root servers.  (Although the primary goal of the       
  107    design is for serving the root zone, the method can be used for any     
  108    zone.)                                                                  
  110    This document describes a method for the operator of a recursive        
  111    resolver to have a complete root zone locally and to hide queries for   
  112    the root zone from outsiders.  The basic idea is to create an up-to-    
  113    date root zone service on the same host as the recursive server and     
  114    use that service when the recursive resolver looks up root              
  115    information.  The recursive resolver validates all responses from the   
  116    root service on the same host, just as it would validate all            
  117    responses from a remote root server.                                    
  119    This design explicitly only allows the new root zone service to be      
  120    run on the same server as the recursive resolver in order to prevent    
  121    the server from serving authoritative answers to any other system.      
  122    Specifically, the root service on the local system MUST be configured   
  123    to only answer queries from resolvers on the same host and MUST NOT     
  124    answer queries from any other resolver.                                 
  126    At the time that RFC 7706 [RFC7706] was published, it was considered    
  127    controversial, because there was not consensus on whether this was a    
  128    "best practice".  In fact, many people felt that it is an excessively   
  129    risky practice, because it introduced a new operational piece to        
  130    local DNS operations where there was not one before.  Since then, the   
  131    DNS operational community has largely shifted to believing that local   
  132    serving of the root zone for an individual resolver is a reasonable     
  133    practice.  The advantages listed above do not come free: if this new    
  134    system does not work correctly, users can get bad data, or the entire   
  135    recursive resolution system might fail in ways that are hard to         
  136    diagnose.                                                               
  138    This design uses an authoritative service running on the same machine   
  139    as the recursive resolver.  Common open source recursive resolver       
  140    software does not need to add new functionality to act as an            
  141    authoritative server for some zones, but other recursive resolver       
  142    software might need to be able to talk to an authoritative server       
  143    running on the same host.  Some resolver software supports being both   
  144    an authoritative server and a resolver but separated by logical         
  145    "views", allowing a local root to be implemented within a single        
  146    process; examples of this can be seen in Appendix B.                    
  148    A different approach to solving some of the problems discussed in       
  149    this document is described in [RFC8198].                                
  151    Readers are expected to be familiar with [RFC8499].                     
  153 1.1.  Changes from RFC 7706                                                
  155    RFC 7706 explicitly required that a root server instance be run on      
  156    the loopback interface of the host running the validating resolver.     
  157    However, RFC 7706 also had examples of how to set up common software    
  158    that did not use the loopback interface.  This document loosens the     
  159    restriction on using the loopback interface and in fact allows the      
  160    use of a local service, not necessarily an authoritative server.        
  161    However, the document keeps the requirement that only systems running   
  162    on that single host be able to query that authoritative root server     
  163    or service.                                                             
  165    This document changes the use cases for running a local root service    
  166    to be more consistent with the reasons operators said they had for      
  167    using RFC 7706:                                                         
  169    *  Removed the prohibition on distribution of recursive DNS servers,    
  170       including configurations for this design because some already do     
  171       and others have expressed an interest in doing so.                   
  173    *  Added the idea that a recursive resolver using this design might     
  174       switch to using the normal (remote) root servers if the local root   
  175       server fails.                                                        
  177    *  Refreshed the list of where one can get copies of the root zone.     
  179    *  Added examples of other resolvers and updated the existing           
  180       examples.                                                            
  182 1.2.  Requirements Notation                                                
  184    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",     
  186    "OPTIONAL" in this document are to be interpreted as described in       
  187    BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all      
  188    capitals, as shown here.                                                
  190 2.  Requirements                                                           
  192    In order to implement the mechanism described in this document:         
  194    *  The system MUST be able to validate every signed record in a zone    
  195       with DNSSEC [RFC4033].                                               
  197    *  The system MUST have an up-to-date copy of the public part of the    
  198       Key Signing Key (KSK) [RFC4033] used to sign the DNS root.           
  200    *  The system MUST be able to retrieve a copy of the entire root zone   
  201       (including all DNSSEC-related records).                              
  203    *  The system MUST be able to run an authoritative service for the      
  204       root zone on the same host.  The authoritative root service MUST     
  205       only respond to queries from the same host.  One way to ensure       
  206       that the authoritative root service does not respond to queries      
  207       from other hosts is to run an authoritative server for the root      
  208       that responds only on one of the loopback addresses (that is, an     
  209       address in the range 127/8 for IPv4 or ::1 in IPv6).  Another        
  210       method is to have the resolver software also act as an               
  211       authoritative server for the root zone, but only for answering       
  212       queries from itself.                                                 
  214    A corollary of the above list is that authoritative data in the root    
  215    zone used on the local authoritative server MUST be identical to the    
  216    same data in the root zone for the DNS.  It is possible to change the   
  217    unsigned data (the glue records) in the copy of the root zone, but      
  218    such changes could cause problems for the recursive server that         
  219    accesses the local root zone, and therefore any changes to the glue     
  220    records SHOULD NOT be made.                                             
  222 3.  Operation of the Root Zone on the Local Server                         
  224    The operation of an authoritative server for the root in the system     
  225    described here can be done separately from the operation of the         
  226    recursive resolver, or it might be part of the configuration of the     
  227    recursive resolver system.                                              
  229    The steps to set up the root zone are:                                  
  231    1.  Retrieve a copy of the root zone.  (See Appendix A for some         
  232        current locations of sources.)                                      
  234    2.  Start the authoritative service for the root zone in a manner       
  235        that prevents any system other than a recursive resolver on the     
  236        same host from accessing it.                                        
  238    The contents of the root zone MUST be refreshed using the timers from   
  239    the SOA record in the root zone, as described in [RFC1035].  This       
  240    inherently means that the contents of the local root zone will likely   
  241    be a little behind those of the global root servers, because those      
  242    servers are updated when triggered by NOTIFY messages.                  
  244    There is a risk that a system using a local authoritative server for    
  245    the root zone cannot refresh the contents of the root zone before the   
  246    expire time in the SOA.  A system using a local authoritative server    
  247    for the root zone MUST NOT serve stale data for the root zone.  To      
  248    mitigate the risk that stale data is served, the local root server      
  249    MUST immediately switch to using non-local root servers when it         
  250    detects that it would be serving state data.                            
  252    In a resolver that is using an internal service for the root zone, if   
  253    the contents of the root zone cannot be refreshed before the expire     
  254    time in the SOA, the resolver MUST immediately switch to using non-     
  255    local root servers.                                                     
  257    In the event that refreshing the contents of the root zone fails, the   
  258    results can be disastrous.  For example, sometimes all the NS records   
  259    for a TLD are changed in a short period of time (such as 2 days); if    
  260    the refreshing of the local root zone is broken during that time, the   
  261    recursive resolver will have bad data for the entire TLD zone.          
  263    An administrator using the procedure in this document SHOULD have an    
  264    automated method to check that the contents of the local root zone      
  265    are being refreshed; this might be part of the resolver software.       
  266    One way to do this is to have a separate process that periodically      
  267    checks the SOA of the local root zone and makes sure that it is         
  268    changing.  At the time that this document is published, the SOA for     
  269    the root zone is the digital representation of the current date with    
  270    a two-digit counter appended, and the SOA is changed every day even     
  271    if the contents of the root zone are unchanged.  For example, the SOA   
  272    of the root zone on January 2, 2019 was 2019010201.  A process can      
  273    use this fact to create a check for the contents of the local root      
  274    zone (using a program not specified in this document).                  
  276 4.  Security Considerations                                                
  278    A system that does not follow the DNSSEC-related requirements given     
  279    in Section 2 can be fooled into giving bad responses in the same way    
  280    as any recursive resolver that does not do DNSSEC validation on         
  281    responses from a remote root server.  Anyone deploying the method       
  282    described in this document should be familiar with the operational      
  283    benefits and costs of deploying DNSSEC [RFC4033].                       
  285    As stated in Section 1, this design explicitly requires the local       
  286    copy of the root zone information to be available only from resolvers   
  287    on that host.  This has the security property of limiting damage to     
  288    clients of any local resolver that might try to rely on an altered      
  289    copy of the root.                                                       
  291 5.  IANA Considerations                                                    
  293    This document has no IANA actions.                                      
  295 6.  References                                                             
  297 6.1.  Normative References                                                 
  299    [RFC1035]  Mockapetris, P., "Domain names - implementation and          
  300               specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,      
  301               November 1987, <https://www.rfc-editor.org/info/rfc1035>.    
  303    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate          
  304               Requirement Levels", BCP 14, RFC 2119,                       
  305               DOI 10.17487/RFC2119, March 1997,                            
  306               <https://www.rfc-editor.org/info/rfc2119>.                   
  308    [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.      
  309               Rose, "DNS Security Introduction and Requirements",          
  310               RFC 4033, DOI 10.17487/RFC4033, March 2005,                  
  311               <https://www.rfc-editor.org/info/rfc4033>.                   
  313    [RFC7706]  Kumari, W. and P. Hoffman, "Decreasing Access Time to Root   
  314               Servers by Running One on Loopback", RFC 7706,               
  315               DOI 10.17487/RFC7706, November 2015,                         
  316               <https://www.rfc-editor.org/info/rfc7706>.                   
  318    [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC       
  319               2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,     
  320               May 2017, <https://www.rfc-editor.org/info/rfc8174>.         
  322    [RFC8499]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS             
  323               Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,       
  324               January 2019, <https://www.rfc-editor.org/info/rfc8499>.     
  326 6.2.  Informative References                                               
  328    [Manning2013]                                                           
  329               Manning, W., "Client Based Naming", May 2013,                
  330               <http://www.sfc.wide.ad.jp/dissertation/bill_e.html>.        
  332    [RFC5936]  Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol    
  333               (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,          
  334               <https://www.rfc-editor.org/info/rfc5936>.                   
  336    [RFC8198]  Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of    
  337               DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,     
  338               July 2017, <https://www.rfc-editor.org/info/rfc8198>.        
  340 Appendix A.  Current Sources of the Root Zone                              
  342    The root zone can be retrieved from anywhere as long as it comes with   
  343    all the DNSSEC records needed for validation.  Currently, one can get   
  344    the root zone from ICANN by zone transfer AXFR [RFC5936] over TCP       
  345    from DNS servers at xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org.    
  346    The root zone file can be obtained using methods described at           
  347    <https://www.iana.org/domains/root/files>.                              
  349    Currently, the root can also be retrieved by AXFR over TCP from the     
  350    following root server operators:                                        
  352    *  b.root-servers.net                                                   
  354    *  c.root-servers.net                                                   
  356    *  d.root-servers.net                                                   
  358    *  f.root-servers.net                                                   
  360    *  g.root-servers.net                                                   
  362    *  k.root-servers.net                                                   
  364    It is crucial to note that none of the above services are guaranteed    
  365    to be available.  It is possible that ICANN or some of the root         
  366    server operators will turn off the AXFR capability on the servers       
  367    listed above.  Using AXFR over TCP to addresses that are likely to be   
  368    anycast (as the ones above are) may conceivably have transfer           
  369    problems due to anycast, but current practice shows that to be          
  370    unlikely.                                                               

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.

  372 A.1.  Root Zone Services                                                   
  374    At the time that this document is published, there is one root zone     
  375    service that is active and one that has been announced as in the        
  376    planning stages.  This section describes all known active services.     
  378    LocalRoot (<https://localroot.isi.edu/>) is an experimental service     
  379    that embodies many of the ideas in this document.  It distributes the   
  380    root zone by AXFR and also offers DNS NOTIFY messages when the          
  381    LocalRoot system sees that the root zone has changed.                   
  383 Appendix B.  Example Configurations of Common Implementations              
  385    This section shows fragments of configurations for some popular         
  386    recursive server software that is believed to correctly implement the   
  387    requirements given in this document.  The examples have been updated    
  388    since the publication of [RFC7706].                                     
  390    The IPv4 and IPv6 addresses in this section were checked in March       
  391    2020 by testing for AXFR over TCP from each address for the known       
  392    single-letter names in the root-servers.net zone.                       
  394 B.1.  Example Configuration: BIND 9.12                                     
  396    BIND 9.12 acts both as a recursive resolver and an authoritative        
  397    server.  Because of this, there is "fate-sharing" between the two       
  398    servers in the following configuration.  That is, if the root server    
  399    dies, it is likely that all of BIND is dead.                            
  401    Note that a future version of BIND will support a much more robust      
  402    method for creating a local mirror of the root or other zones; see      
  403    Appendix B.3.                                                           
  405    Using this configuration, queries for information in the root zone      
  406    are returned with the Authoritative Answer (AA) bit not set.            
  408    When slaving a zone, BIND 9.12 will treat zone data differently if      
  409    the zone is slaved into a separate view (or a separate instance of      
  410    the software) versus slaved into the same view or instance that is      
  411    also performing the recursion.                                          
  413    Validation:  When using separate views or separate instances, the DS    
  414       records in the slaved zone will be validated as the zone data is     
  415       accessed by the recursive server.  When using the same view, this    
  416       validation does not occur for the slaved zone.                       
  418    Caching:  When using separate views or instances, the recursive         
  419       server will cache all of the queries for the slaved zone, just as    
  420       it would using the traditional "root hints" method.  Thus, as the    
  421       zone in the other view or instance is refreshed or updated,          
  422       changed information will not appear in the recursive server until    
  423       the TTL of the old record times out.  Currently, the TTL for DS      
  424       and delegation NS records is two days.  When using the same view,    
  425       all zone data in the recursive server will be updated as soon as     
  426       it receives its copy of the zone.                                    
  428    view root {                                                             
  429        match-destinations {; };                               
  430        zone "." {                                                          
  431            type slave;                                                     
  432            file "rootzone.db";                                             
  433            notify no;                                                      
  434            masters {                                                       
  435      ;         # b.root-servers.net                  
  436      ;          # c.root-servers.net                  
  437      ;          # d.root-servers.net                  
  438      ;          # f.root-servers.net                  
  439      ;         # g.root-servers.net                  
  440      ;         # k.root-servers.net                  
  441      ;         # xfr.cjr.dns.icann.org               
  442      ;         # xfr.lax.dns.icann.org               
  443                2001:500:200::b;      # b.root-servers.net                  
  444                2001:500:2::c;        # c.root-servers.net                  
  445                2001:500:2d::d;       # d.root-servers.net                  
  446                2001:500:2f::f;       # f.root-servers.net                  
  447                2001:500:12::d0d;     # g.root-servers.net                  
  448                2001:7fd::1;          # k.root-servers.net                  
  449                2620:0:2830:202::132; # xfr.cjr.dns.icann.org               
  450                2620:0:2d0:202::132;  # xfr.lax.dns.icann.org               
  451            };                                                              
  452        };                                                                  
  453    };                                                                      
  455    view recursive {                                                        
  456        dnssec-validation auto;                                             
  457        allow-recursion { any; };                                           
  458        recursion yes;                                                      
  459        zone "." {                                                          
  460            type static-stub;                                               
  461            server-addresses {; };                             
  462        };                                                                  
  463    };                                                                      
  465 B.2.  Example Configuration: Unbound 1.8                                   
  467    Similar to BIND, Unbound, starting with version 1.8, can act both as    
  468    a recursive resolver and an authoritative server.                       
  470    auth-zone:                                                              
  471        name: "."                                                           
  472        master:         # b.root-servers.net                   
  473        master:          # c.root-servers.net                   
  474        master:          # d.root-servers.net                   
  475        master:          # f.root-servers.net                   
  476        master:         # g.root-servers.net                   
  477        master:         # k.root-servers.net                   
  478        master:         # xfr.cjr.dns.icann.org                
  479        master:         # xfr.lax.dns.icann.org                
  480        master: 2001:500:200::b      # b.root-servers.net                   
  481        master: 2001:500:2::c        # c.root-servers.net                   
  482        master: 2001:500:2d::d       # d.root-servers.net                   
  483        master: 2001:500:2f::f       # f.root-servers.net                   
  484        master: 2001:500:12::d0d     # g.root-servers.net                   
  485        master: 2001:7fd::1          # k.root-servers.net                   
  486        master: 2620:0:2830:202::132 # xfr.cjr.dns.icann.org                
  487        master: 2620:0:2d0:202::132  # xfr.lax.dns.icann.org                
  488        fallback-enabled: yes                                               
  489        for-downstream: no                                                  
  490        for-upstream: yes                                                   
  492 B.3.  Example Configuration: BIND 9.14                                     
  494    BIND 9.14 can set up a local mirror of the root zone with a small       
  495    configuration option:                                                   
  497    zone "." {                                                              
  498        type mirror;                                                        
  499    };                                                                      
  501    The simple "type mirror" configuration for the root zone works for      
  502    the root zone because a default list of primary servers for the IANA    
  503    root zone is built into BIND 9.14.  In order to set up mirroring of     
  504    any other zone, an explicit list of primary servers needs to be         
  505    provided.                                                               
  507    See the documentation for BIND 9.14 for more detail about how to use    
  508    this simplified configuration.                                          
  510 B.4.  Example Configuration: Unbound 1.9                                   
  512    Recent versions of Unbound have an "auth-zone" feature that allows      
  513    local mirroring of the root zone.  Configuration looks as follows:      
  515    auth-zone:                                                              
  516        name: "."                                                           
  517        master: "b.root-servers.net"                                        
  518        master: "c.root-servers.net"                                        
  519        master: "d.root-servers.net"                                        
  520        master: "f.root-servers.net"                                        
  521        master: "g.root-servers.net"                                        
  522        master: "k.root-servers.net"                                        
  523            fallback-enabled: yes                                           
  524        for-downstream: no                                                  
  525        for-upstream: yes                                                   
  526        zonefile: "root.zone"                                               
  528 B.5.  Example Configuration: Knot Resolver                                 
  530    Knot Resolver uses its "prefill" module to load the root zone           
  531    information.  This is described at <https://knot-                       
  532    resolver.readthedocs.io/en/v5.0.1/modules-rfc7706.html>.                
  534 B.6.  Example Configuration: Microsoft Windows Server 2012                 
  536    Windows Server 2012 contains a DNS server in the "DNS Manager"          
  537    component.  When activated, that component acts as a recursive          
  538    server.  The DNS Manager can also act as an authoritative server.       
  540    Using this configuration, queries for information in the root zone      
  541    are returned with the AA bit set.                                       
  543    The steps to configure the DNS Manager to implement the requirements    
  544    in this document are:                                                   
  546    1.  Launch the DNS Manager GUI.  This can be done from the command      
  547        line ("dnsmgmt.msc") or from the Service Manager (the "DNS"         
  548        command in the "Tools" menu).                                       
  550    2.  In the hierarchy under the server on which the service is           
  551        running, right-click on the "Forward Lookup Zones", and select      
  552        "New Zone".  This brings up a succession of dialog boxes.           
  554    3.  In the "Zone Type" dialog box, select "Secondary zone".             
  556    4.  In the "Zone Name" dialog box, enter ".".                           
  558    5.  In the "Master DNS Servers" dialog box, enter                       
  559        "b.root-servers.net".  The system validates that it can do a zone   
  560        transfer from that server.  (After this configuration is            
  561        completed, the DNS Manager will attempt to transfer from all of     
  562        the root zone servers.)                                             
  564    6.  In the "Completing the New Zone Wizard" dialog box, click           
  565        "Finish".                                                           
  567    7.  Verify that the DNS Manager is acting as a recursive resolver.      
  568        Right-click on the server name in the hierarchy, choosing the       
  569        "Advanced" tab in the dialog box.  See that "Disable recursion      
  570        (also disables forwarders)" is not selected and that "Enable        
  571        DNSSEC validation for remote responses" is selected.                
  573 Acknowledgements                                                           
  575    The authors fully acknowledge that running a copy of the root zone on   
  576    the loopback address is not a new concept and that we have chatted      
  577    with many people about that idea over time.  For example, Bill          
  578    Manning described a similar solution to the problems in his doctoral    
  579    dissertation in 2013 [Manning2013].                                     
  581    Evan Hunt contributed greatly to the logic in the requirements.         
  582    Other significant contributors include Wouter Wijngaards, Tony Hain,    
  583    Doug Barton, Greg Lindsay, and Akira Kato.  The authors also received   
  584    many offline comments about making the document clear that this is      
  585    just a description of a way to operate a root zone on the same host     
  586    and not a recommendation to do so.                                      
  588    People who contributed to this update to [RFC7706] include Florian      
  589    Obser, nusenu, Wouter Wijngaards, Mukund Sivaraman, Bob Harold, and     
  590    Leo Vegoda.                                                             
  592 Authors' Addresses                                                         
  594    Warren Kumari                                                           
  595    Google                                                                  
  597    Email: Warren@kumari.net                                                
  600    Paul Hoffman                                                            
  601    ICANN                                                                   
  603    Email: paul.hoffman@icann.org                                           

The LocalRootLocalRoot project is marked in this document as experimental, even though the author was informed that the project was being placed into a fully supported service at USC/ISI as part of their root server infrastructure