1 Independent Submission                                          J. Abley   
    2 Request for Comments: 7108                                     Dyn, Inc.   
    3 Category: Informational                                     T. Manderson   
    4 ISSN: 2070-1721                                                    ICANN   
    5                                                             January 2014   
    6                                                                            
    7                                                                            
    8        A Summary of Various Mechanisms Deployed at L-Root for the          
    9                     Identification of Anycast Nodes                        
   10                                                                            
   11 Abstract                                                                   
   12                                                                            
   13    Anycast is a deployment technique commonly employed for                 
   14    authoritative-only servers in the Domain Name System (DNS).  L-Root,    
   15    one of the thirteen root servers, is deployed in this fashion.          
   16                                                                            
   17    Various techniques have been used to map deployed anycast               
   18    infrastructure externally, i.e., without reference to inside            
   19    knowledge about where and how such infrastructure has been deployed.    
   20    Motivations for performing such measurement exercises include           
   21    operational troubleshooting and infrastructure risk assessment.  In     
   22    the specific case of L-Root, the ability to measure and map anycast     
   23    infrastructure using the techniques mentioned in this document is       
   24    provided for reasons of operational transparency.                       
   25                                                                            
   26    This document describes all facilities deployed at L-Root to            
   27    facilitate mapping of its infrastructure and serves as documentation    
   28    for L-Root as a measurable service.                                     
   29                                                                            
   30 Status of This Memo                                                        
   31                                                                            
   32    This document is not an Internet Standards Track specification; it is   
   33    published for informational purposes.                                   
   34                                                                            
   35    This is a contribution to the RFC Series, independently of any other    
   36    RFC stream.  The RFC Editor has chosen to publish this document at      
   37    its discretion and makes no statement about its value for               
   38    implementation or deployment.  Documents approved for publication by    
   39    the RFC Editor are not a candidate for any level of Internet            
   40    Standard; see Section 2 of RFC 5741.                                    
   41                                                                            
   42    Information about the current status of this document, any errata,      
   43    and how to provide feedback on it may be obtained at                    
   44    http://www.rfc-editor.org/info/rfc7108.                                 
   45                                                                            
   46                                                                            
   47                                                                            
   48                                                                            
   49                                                                            
   50                                                                            
   51                                                                            
   52 Abley & Manderson             Informational                     [Page 1]   

   53 RFC 7108           L-Root Anycast Node Identification       January 2014   
   54                                                                            
   55                                                                            
   56 Copyright Notice                                                           
   57                                                                            
   58    Copyright (c) 2014 IETF Trust and the persons identified as the         
   59    document authors.  All rights reserved.                                 
   60                                                                            
   61    This document is subject to BCP 78 and the IETF Trust's Legal           
   62    Provisions Relating to IETF Documents                                   
   63    (http://trustee.ietf.org/license-info) in effect on the date of         
   64    publication of this document.  Please review these documents            
   65    carefully, as they describe your rights and restrictions with respect   
   66    to this document.                                                       
   67                                                                            
   68 Table of Contents                                                          
   69                                                                            
   70    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2   
   71    2.  Conventions Used in This Document . . . . . . . . . . . . . .   3   
   72    3.  Naming Scheme for L-Root Nodes  . . . . . . . . . . . . . . .   3   
   73    4.  Identification of L-Root Nodes  . . . . . . . . . . . . . . .   3   
   74      4.1.  Use of NSID . . . . . . . . . . . . . . . . . . . . . . .   4   
   75      4.2.  Use of HOSTNAME.BIND/CH/TXT . . . . . . . . . . . . . . .   5   
   76      4.3.  Use of ID.SERVER/CH/TXT . . . . . . . . . . . . . . . . .   6   
   77      4.4.  Use of IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT and .../IN/A  .   6   
   78      4.5.  Use of NODES.L.ROOT-SERVERS.ORG/IN/TXT  . . . . . . . . .   8   
   79    5.  Provisioning of IDENTITY.L.ROOT-SERVERS.ORG . . . . . . . . .   9   
   80    6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9   
   81    7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10   
   82    8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10   
   83      8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10   
   84      8.2.  Informative References  . . . . . . . . . . . . . . . . .  11   
   85                                                                            
   86 1.  Introduction                                                           
   87                                                                            
   88    The Domain Name System (DNS) is described in [RFC1034] and [RFC1035].   
   89    L-Root, one of the thirteen root servers, is deployed using anycast     
   90    [RFC4786]; its service addresses, published in the A and AAAA           
   91    Resource Record (RR) Sets for "L.ROOT-SERVERS.NET", are made            
   92    available from a substantial number of semi-autonomous servers          
   93    deployed throughout the Internet.  A list of locations served by        
   94    L-Root can be found at [ROOT-SERVERS].                                  
   95                                                                            
   96    Various techniques have been used to map deployed anycast               
   97    infrastructure externally, i.e., without reference to inside            
   98    knowledge about where and how such infrastructure has been deployed.    
   99    Motivations for performing such measurement exercises include           
  100    operational troubleshooting and infrastructure risk assessment.  In     
  101    the specific case of L-Root, the ability to measure and map anycast     
  102    infrastructure using the techniques mentioned in this document is       
  103    provided for reasons of operational transparency.                       
  104                                                                            
  105                                                                            
  106                                                                            
  107 Abley & Manderson             Informational                     [Page 2]   

  108 RFC 7108           L-Root Anycast Node Identification       January 2014   
  109                                                                            
  110                                                                            
  111    This document describes all facilities currently provided at L-Root     
  112    to aid node identification.                                             
  113                                                                            
  114 2.  Conventions Used in This Document                                      
  115                                                                            
  116    This document contains several examples of commands typed at a Unix     
  117    (or Unix-like) command line to illustrate use of the various            
  118    mechanisms available to identify L-Root nodes.  Such examples are       
  119    presented in this document with lines typed by the user preceded by     
  120    the "%" prompt character; a bare "%" character indicates the end of     
  121    the output resulting from the command.                                  
  122                                                                            
  123    In some cases, the output shown in examples is too long to be           
  124    represented directly in the text.  In those cases, a backslash          
  125    character ("\") is used to indicate continuation.                       
  126                                                                            
  127 3.  Naming Scheme for L-Root Nodes                                         
  128                                                                            
  129    Individual L-Root nodes have structured hostnames that are              
  130    constructed as follows:                                                 
  131                                                                            
  132       <IATA Code><NN>.L.ROOT-SERVERS.ORG                                   
  133                                                                            
  134    where                                                                   
  135                                                                            
  136    o  <IATA Code> is chosen from the list of three-character airport       
  137       codes published by the International Air Transport Association       
  138       (IATA) in the IATA Airline Coding Directory [ACD]; and               
  139                                                                            
  140    o  <NN> is a two-digit numeric code used to distinguish between two     
  141       different nodes in the vicinity of the same airport.                 
  142                                                                            
  143    Where multiple airports exist in the vicinity of a single L-Root        
  144    node, one is arbitrarily chosen.                                        
  145                                                                            
  146    More granular location data published for L-Root nodes (e.g., see       
  147    Section 4.4) is derived from the location of the airport, not the       
  148    actual location of the node.                                            
  149                                                                            
  150 4.  Identification of L-Root Nodes                                         
  151                                                                            
  152    L-Root service is provided using a single IPv4 address (199.7.83.42)    
  153    and a single IPv6 address (2001:500:3::42).  Note that it is            
  154    preferable to refer to the service using its DNS name (L.ROOT-          
  155    SERVERS.NET) rather than literal addresses, since addresses can         
  156    change from time to time.                                               
  157                                                                            
  158                                                                            
  159                                                                            
  160                                                                            
  161                                                                            
  162 Abley & Manderson             Informational                     [Page 3]   

  163 RFC 7108           L-Root Anycast Node Identification       January 2014   
  164                                                                            
  165                                                                            
  166    At the time of writing, there are 273 separate name server elements     
  167    ("nodes") deployed in 143 locations: together, these nodes provide      
  168    L-Root service.  A DNS query sent to an L-Root service address will     
  169    be routed towards exactly one of those nodes for processing, and the    
  170    corresponding DNS response will be originated from the same node.       
  171    Queries from different clients may be routed to different nodes.        
  172    Successive queries from the same client may also be routed to           
  173    different nodes.                                                        
  174                                                                            
  175    The following sections provide a summary of all mechanisms provided     
  176    by L-Root to allow a client to identify which L-Root node is being      
  177    used.                                                                   
  178                                                                            

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.

  179    Using HOSTNAME.BIND/CH/TXT (Section 4.2), ID.SERVER/CH/TXT              
  180    (Section 4.3), or IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT or IDENTITY.L      
  181    .ROOT-SERVERS/IN/A (Section 4.4) to identify a node for the purposes    
  182    of reporting a problem is frequently reasonable, but it should be       
  183    acknowledged that there is potential for re-routing between             
  184    successive queries: an observed problem might relate to one node,       
  185    whilst a subsequent query using one of those three techniques could     
  186    be answered by a different node.  Use of the Name Server Identifier     
  187    (NSID) option on the precise queries that yield problematic responses   
  188    can obviate this possibility (see Section 4.1).                         
  189                                                                            
  190 4.1.  Use of NSID                                                          
  191                                                                            
  192    L-Root supports the use of the Name Server Identifier (NSID) option     
  193    [RFC5001] to return the identity of an L-Root node along with the       
  194    response to a DNS query.  The NSID payload of such responses is the     
  195    fully qualified hostname of the responding L-Root node.                 
  196                                                                            
  197    The NSID option allows the identification of a node sending a           
  198    specific, requested response to the client.  This is of particular      
  199    use if (for example) there is a desire to identify unequivocally what   
  200    node is responding with a particularly troublesome response; the        
  201    output of the diagnostic tool "dig" with NSID requested provides the    
  202    problem response with the node identification, and its output in that   
  203    case could form the basis of a useful trouble report.                   
  204                                                                            
  205    NSID is specified as an EDNS(0) option [RFC6891].  Clients that do      
  206    not support EDNS(0) signaling (or depend on other systems that do not   
  207    support EDNS0) may find this mechanism unavailable.                     
  208                                                                            
  209    The NSID option can be specified using the widely used diagnostic       
  210    tool "dig" using the "+nsid" option, as shown below.  Note that long    
  211    lines have been truncated for the purposes of this document ("\" at     
  212    the end of a line indicates continuation).                              
  213                                                                            
  214                                                                            
  215                                                                            
  216                                                                            
  217 Abley & Manderson             Informational                     [Page 4]   

  218 RFC 7108           L-Root Anycast Node Identification       January 2014   
  219                                                                            
  220                                                                            
  221    % dig -4 @L.ROOT-SERVERS.NET . SOA +nsid \                              
  222      +norec +noall +comments                                               
  223    ; <<>> DiG 9.6.-ESV-R3 <<>> -4 @L.ROOT-SERVERS.NET . SOA +nsid \        
  224      +norec +noall +comments                                               
  225    ; (1 server found)                                                      
  226    ;; global options: +cmd                                                 
  227    ;; Got answer:                                                          
  228    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14913               
  229    ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 23     
  230                                                                            
  231    ;; OPT PSEUDOSECTION:                                                   
  232    ; EDNS: version: 0, flags:; udp: 4096                                   
  233    ; NSID: 79 74 7a 30 31 2e 6c 2e 72 6f 6f 74 2d 73 65 72 76 65 72 73 \   
  234      2e 6f 72 67  (y) (t) (z) (0) (1) (.) (l) (.) (r) (o) (o) (t) (-) \    
  235      (s) (e) (r) (v) (e) (r) (s) (.) (o) (r) (g)                           
  236    %                                                                       
  237                                                                            
  238    % dig -6 @L.ROOT-SERVERS.NET . SOA +nsid \                              
  239      +norec +noall +comments                                               
  240    ; <<>> DiG 9.6.-ESV-R3 <<>> -6 @L.ROOT-SERVERS.NET . SOA +nsid \        
  241      +norec +noall +comments                                               
  242    ; (1 server found)                                                      
  243    ;; global options: +cmd                                                 
  244    ;; Got answer:                                                          
  245    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33374               
  246    ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 23     
  247                                                                            
  248    ;; OPT PSEUDOSECTION:                                                   
  249    ; EDNS: version: 0, flags:; udp: 4096                                   
  250    ; NSID: 79 74 7a 30 31 2e 6c 2e 72 6f 6f 74 2d 73 65 72 76 65 72 73 \   
  251      2e 6f 72 67  (y) (t) (z) (0) (1) (.) (l) (.) (r) (o) (o) (t) (-) \    
  252      (s) (e) (r) (v) (e) (r) (s) (.) (o) (r) (g)                           
  253    %                                                                       
  254                                                                            
  255 4.2.  Use of HOSTNAME.BIND/CH/TXT                                          
  256                                                                            
  257    L-Root supports the use of HOSTNAME.BIND/CH/TXT queries to return the   
  258    identity of an L-Root node.  The TXT RDATA returned is the fully        
  259    qualified hostname of the responding L-Root node.                       
  260                                                                            
  261    The HOSTNAME.BIND/CH/TXT convention is described in [RFC4892].          
  262                                                                            
  263                                                                            
  264                                                                            
  265                                                                            
  266                                                                            
  267                                                                            
  268                                                                            
  269                                                                            
  270                                                                            
  271                                                                            
  272 Abley & Manderson             Informational                     [Page 5]   

  273 RFC 7108           L-Root Anycast Node Identification       January 2014   
  274                                                                            
  275                                                                            
  276    % dig -4 @L.ROOT-SERVERS.NET HOSTNAME.BIND CH TXT +short                
  277    "ytz01.l.root-servers.org"                                              
  278    %                                                                       
  279                                                                            
  280    % dig -6 @L.ROOT-SERVERS.NET HOSTNAME.BIND CH TXT +short                
  281    "ytz01.l.root-servers.org"                                              
  282    %                                                                       
  283                                                                            
  284 4.3.  Use of ID.SERVER/CH/TXT                                              
  285                                                                            
  286    L-Root supports the use of ID.SERVER/CH/TXT queries to return the       
  287    identity of an L-Root node.  The TXT RDATA returned is the fully        
  288    qualified hostname of the responding L-Root node.                       
  289                                                                            
  290    ID.SERVER/CH/TXT functions identically (apart from the QNAME) to        
  291    HOSTNAME.BIND/CH/TXT, as discussed in Section 4.2.  The discussion      
  292    there relating to the possibility of re-routing between successive      
  293    queries also follows for ID.SERVER/CH/TXT.                              
  294                                                                            
  295    The ID.SERVER/CH/TXT convention is described in [RFC4892].              
  296                                                                            
  297    % dig -4 @L.ROOT-SERVERS.NET ID.SERVER CH TXT +short                    
  298    "ytz01.l.root-servers.org"                                              
  299    %                                                                       
  300                                                                            
  301    % dig -6 @L.ROOT-SERVERS.NET ID.SERVER CH TXT +short                    
  302    "ytz01.l.root-servers.org"                                              
  303    %                                                                       
  304                                                                            
  305 4.4.  Use of IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT and .../IN/A               
  306                                                                            
  307    The operator of L-Root has distributed a separate DNS service in        
  308    parallel with L-Root, operating on precisely the same set of nodes      
  309    but listening on addresses that are different from the L-Root service   
  310    addresses.  Measurements of this separate service should give results   
  311    that are representative of L-Root.  Further discussion of this          
  312    service can be found in Section 5.                                      
  313                                                                            
  314    The fully qualified DNS name IDENTITY.L.ROOT-SERVERS.ORG (note the      
  315    use of ORG, not NET) has associated TXT and A RR Sets that are unique   
  316    to the responding node.  Clients are hence able to issue queries for    
  317    IDENTITY.L.ROOT-SERVERS.ORG/IN/A and IDENTITY.L.ROOT-SERVERS.ORG/IN/    
  318    TXT and use the results both to identify individual nodes and to        
  319    distinguish between responses generated by different nodes.             
  320                                                                            
  321                                                                            
  322                                                                            
  323                                                                            
  324                                                                            
  325                                                                            
  326                                                                            
  327 Abley & Manderson             Informational                     [Page 6]   

  328 RFC 7108           L-Root Anycast Node Identification       January 2014   
  329                                                                            
  330                                                                            
  331    The TXT record returned in the response to such queries is structured   
  332    as follows:                                                             
  333                                                                            
  334    1.  The fully qualified hostname of the node responding to the query;   
  335                                                                            
  336    2.  The city in which the node is located;                              
  337                                                                            
  338    3.  The region in which the node is located, if applicable;             
  339                                                                            
  340    4.  The economy in which the node is located (in most cases, the name   
  341        of a country); and                                                  
  342                                                                            
  343    5.  The Internet Corporation for Assigned Names and Numbers (ICANN)     
  344        region in which the node is located.  A list of ICANN regions at    
  345        the time of writing can be found at <http://meetings.icann.org/     
  346        regions>.                                                           
  347                                                                            
  348    The A record returned in the response to such queries is guaranteed     
  349    to be unique to the responding node.  The A RRType was chosen in an     
  350    effort to make the use of this mechanism as widely available to         
  351    client environments as possible, and the ability to map a hostname to   
  352    an IPv4 address seemed more likely to be widespread than the mapping    
  353    of a hostname to any other value.  It should be noted that the          
  354    availability of this mechanism to any particular client is orthogonal   
  355    to the local availability of IPv4 or IPv6 transport.                    
  356                                                                            
  357    In this case, because identity data is published using IN-class         
  358    resource records, it is not necessary to send queries directly          
  359    towards L-Root in order to obtain results.  Responses can be obtained   
  360    through recursive servers, the responses in those cases being the       
  361    identity of L-Root as observed through the recursive server used        
  362    rather than the "closest" L-Root node to the client.  This              
  363    facilitates some degree of remote troubleshooting, since a query for    
  364    IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT or IDENTITY.L.ROOT-SERVERS.ORG/IN/   
  365    A directed a remote recursive resolver can help illustrate which        
  366    L-Root node is being used by that server (or was used when the cache    
  367    was populated).                                                         
  368                                                                            
  369    A related caching effect is that responses to IDENTITY.L.ROOT-          
  370    SERVERS.ORG/IN/A and IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT may be cached   
  371    at different times, and may hence persist in a cache for overlapping    
  372    periods of time.  One possible visible effect is that the responses     
  373    to IDENTITY.L.ROOT-SERVERS.ORG/IN/A and IDENTITY.L.ROOT-SERVERS.ORG/    
  374    IN/TXT as presented from a cache may appear to be incoherent (i.e.,     
  375    refer to different nodes) despite queries against of the cache          
  376    happening (near) simultaneously.  Caches may also discard the           
  377    published Times to Live (TTLs) in responses from the authoritative      
  378                                                                            
  379                                                                            
  380                                                                            
  381                                                                            
  382 Abley & Manderson             Informational                     [Page 7]   

  383 RFC 7108           L-Root Anycast Node Identification       January 2014   
  384                                                                            
  385                                                                            
  386    server and replace them with longer TTLs, as a matter of local          
  387    policy.  Interpretation of responses for these queries from caches      
  388    should therefore be carried out with these possible effects in mind.    
  389                                                                            
  390    It has been observed that IDENTITY.L.ROOT-SERVERS.ORG/IN/A queries      
  391    offer a useful mechanism for troubleshooting DNS problems with non-     
  392    technical users, since such users can often be walked through the       
  393    process of looking up an A record (e.g., as a side effect of            
  394    utilities such as ping) far easier than they can be instructed on how   
  395    to use DNS-specific tools such as dig.                                  
  396                                                                            
  397   % dig IDENTITY.L.ROOT-SERVERS.ORG TXT +short                             
  398   "ytz01.l.root-servers.org" "Toronto" "Ontario" "Canada" "NorthAmerica"   
  399   %                                                                        
  400                                                                            
  401   % dig IDENTITY.L.ROOT-SERVERS.ORG A +short                               
  402   67.215.199.91                                                            
  403   %                                                                        
  404                                                                            
  405 4.5.  Use of NODES.L.ROOT-SERVERS.ORG/IN/TXT                               
  406                                                                            
  407    The fully qualified DNS name NODES.L.ROOT-SERVERS.ORG (note again the   
  408    use of ORG, not NET) provides multiple TXT RRs, one per node, and       
  409    represents the effective concatenation of all possible responses to     
  410    the query IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT.                           
  411                                                                            
  412    Note that in the example below we have forced dig to send the query     
  413    over TCP, since we expect the response to be too large for UDP          
  414    transport to accommodate.  Note also that the list shown is truncated   
  415    for clarity, and can be expected to change from time to time as new     
  416    L-Root nodes are provisioned and old ones decommissioned.               
  417                                                                            
  418    % dig NODES.L.ROOT-SERVERS.ORG TXT +short +tcp | head -10               
  419    "abj01.l.root-servers.org" "Abidjan" "" "Cote d'Ivoire" "Africa"        
  420    "abj02.l.root-servers.org" "Abidjan" "" "Cote d'Ivoire" "Africa"        
  421    "akl01.l.root-servers.org" "Mangere" "" "New Zealand" "AsiaPacific"     
  422    "akl41.l.root-servers.org" "Mangere" "" "New Zealand" "AsiaPacific"     
  423    "akl42.l.root-servers.org" "Mangere" "" "New Zealand" "AsiaPacific"     
  424    "akl43.l.root-servers.org" "Mangere" "" "New Zealand" "AsiaPacific"     
  425    "akl44.l.root-servers.org" "Mangere" "" "New Zealand" "AsiaPacific"     
  426    "ams01.l.root-servers.org" "Haarlemmermeer" "" "Netherlands" "Europe"   
  427    "anc01.l.root-servers.org" "Anchorage" "Alaska" "United States" \       
  428      "NorthAmerica"                                                        
  429    %                                                                       
  430                                                                            
  431                                                                            
  432                                                                            
  433                                                                            
  434                                                                            
  435                                                                            
  436                                                                            
  437 Abley & Manderson             Informational                     [Page 8]   

  438 RFC 7108           L-Root Anycast Node Identification       January 2014   
  439                                                                            
  440                                                                            
  441 5.  Provisioning of IDENTITY.L.ROOT-SERVERS.ORG                            
  442                                                                            
  443    Individual L-Root nodes run a dedicated, separate authority-only DNS    
  444    server process that serves the IDENTITY.L.ROOT-SERVERS.ORG zone.  The   
  445    contents of that zone are unique to every node; hence, each             
  446    responding node will generate a node-specific response.                 
  447                                                                            
  448    The contents of the IDENTITY.L.ROOT-SERVERS.ORG zone are hence          
  449    deliberately incoherent, the apparent zone contents depending on the    
  450    node responding to the corresponding query.                             
  451                                                                            
  452    The IDENTITY.L.ROOT-SERVERS.ORG zone is delegated to the single name    
  453    server BEACON.L.ROOT-SERVERS.ORG, numbered on IPv4 and IPv6 addresses   
  454    that are covered by the same routing advertisements that cover the      
  455    L-Root service addresses.  Reachability of BEACON.L.ROOT-SERVERS.ORG    
  456    is hence well-aligned with the reachability of L.ROOT-SERVERS.NET;      
  457    therefore, measurement of the IDENTITY service ought to give similar    
  458    results to measurement of the L-Root service.                           
  459                                                                            
  460    It is considered best practice always to delegate a DNS zone to more    
  461    than one name server [RFC2182]; however, as described, the IDENTITY.L   
  462    .ROOT-SERVERS.ORG zone is delegated to just one server.  Ordinarily,    
  463    this would present a risk of failure if that single server is not       
  464    available; however, given the purpose of the delegation in this case    
  465    and that the expected mitigation of a failure in a single node is the   
  466    routing of a query to a different node, delegation to a single server   
  467    in this particular use-case is effective.                               
  468                                                                            
  469    At the time of writing, the ROOT-SERVERS.ORG zone is not signed with    
  470    DNSSEC.  When DNSSEC is deployed in that zone, the L.ROOT-SERVERS.ORG   
  471    zone will also be signed.  This will facilitate secure responses for    
  472    queries for BEACON.L.ROOT-SERVERS.ORG and NODES.L.ROOT-SERVERS.ORG.     
  473                                                                            
  474    Secure responses for IDENTITY.L.ROOT-SERVERS.ORG are unlikely to        
  475    become available even with the deployment of DNSSEC in the parent,      
  476    since the implementation of the IDENTITY.L.ROOT-SERVERS.ORG service     
  477    involves widely distributed static zone data.  Management of key        
  478    materials distributed to every L-Root node would be impractical to      
  479    audit, and signatures returned in secure responses would be             
  480    correspondingly of low value.                                           
  481                                                                            
  482 6.  Security Considerations                                                
  483                                                                            
  484    Some operators of anycast services choose not to disclose locations     
  485    (or even numbers) of nodes, citing security concerns.  The operator     
  486    of L-Root considers that none of the published information described    
  487    in this document is truly secret, since any service element that        
  488    provides service to the Internet can never truly be obscured from       
  489                                                                            
  490                                                                            
  491                                                                            
  492 Abley & Manderson             Informational                     [Page 9]   

  493 RFC 7108           L-Root Anycast Node Identification       January 2014   
  494                                                                            
  495                                                                            
  496    view.  Given that location information can be found regardless of any   
  497    conscious, deliberate disclosure, and since easy access to this         
  498    information has diagnostic value, the operator of L-Root has adopted    
  499    a policy of operational transparency.                                   
  500                                                                            
  501    The information presented in this document presents no new threat to    
  502    the Internet.                                                           
  503                                                                            
  504 7.  Acknowledgements                                                       
  505                                                                            
  506    The aspects of the L-Root service that were deployed to facilitate      
  507    IN-class mapping were discussed and implemented as part of an           
  508    informal collaboration with Xun Fan, John Heidemann, and Ramesh         
  509    Govidan, whose contributions are acknowledged.  The motivation to       
  510    facilitate mapping of L-Root as an anycast service using IN-class       
  511    queries was inspired by [Fan2013].                                      
  512                                                                            
  513    Helpful reviews and comments from Gaurab Upadhaya, Hugo Salgado,        
  514    Brian Dixon, Bob Harold, Paul Hoffman, Jakob Schlyter, Andrew           
  515    Sullivan, Bruce Campbell, S. Moonesamy, and Stephane Bortzmeyer on      
  516    earlier versions of this document were very much appreciated.           
  517                                                                            
  518 8.  References                                                             
  519                                                                            
  520 8.1.  Normative References                                                 
  521                                                                            
  522    [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",   
  523               STD 13, RFC 1034, November 1987.                             
  524                                                                            
  525    [RFC1035]  Mockapetris, P., "Domain names - implementation and          
  526               specification", STD 13, RFC 1035, November 1987.             
  527                                                                            
  528    [RFC2182]  Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection    
  529               and Operation of Secondary DNS Servers", BCP 16, RFC 2182,   
  530               July 1997.                                                   
  531                                                                            
  532    [RFC4786]  Abley, J. and K. Lindqvist, "Operation of Anycast            
  533               Services", BCP 126, RFC 4786, December 2006.                 
  534                                                                            
  535    [RFC4892]  Woolf, S. and D. Conrad, "Requirements for a Mechanism       
  536               Identifying a Name Server Instance", RFC 4892, June 2007.    
  537                                                                            
  538    [RFC5001]  Austein, R., "DNS Name Server Identifier (NSID) Option",     
  539               RFC 5001, August 2007.                                       
  540                                                                            
  541    [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms    
  542               for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.            
  543                                                                            
  544                                                                            
  545                                                                            
  546                                                                            
  547 Abley & Manderson             Informational                    [Page 10]   

  548 RFC 7108           L-Root Anycast Node Identification       January 2014   
  549                                                                            
  550                                                                            
  551 8.2.  Informative References                                               
  552                                                                            
  553    [ACD]      International Air Transport Association (IATA), "Airline     
  554               Coding Directory (ACD)", 2013,                               
  555               <http://www.iata.org/publications/Pages/coding.aspx>.        
  556                                                                            
  557    [Fan2013]  Fan, X., Heidemann, J., and R. Govidan, "Evaluating          
  558               Anycast in the Domain Name System", Proceedings of the       
  559               IEEE Infocom Turin, Italy, April 2013.                       
  560                                                                            
  561    [ROOT-SERVERS]                                                          
  562               "root-servers.org", <http://www.root-servers.org>.           
  563                                                                            
  564 Authors' Addresses                                                         
  565                                                                            
  566    Joe Abley                                                               
  567    Dyn, Inc.                                                               
  568    470 Moore Street                                                        
  569    London, ON  N6C 2C2                                                     
  570    Canada                                                                  
  571                                                                            
  572    Phone: +1 519 670 9327                                                  
  573    EMail: jabley@dyn.com                                                   
  574                                                                            
  575                                                                            
  576    Terry Manderson                                                         
  577    ICANN                                                                   
  578    12025 Waterfront Drive                                                  
  579    Suite 300                                                               
  580    Los Angeles, CA  90094-2536                                             
  581    USA                                                                     
  582                                                                            
  583    EMail: terry.manderson@icann.org                                        
  584                                                                            
  585                                                                            
  586                                                                            
  587                                                                            
  588                                                                            
  589                                                                            
  590                                                                            
  591                                                                            
  592                                                                            
  593                                                                            
  594                                                                            
  595                                                                            
  596                                                                            
  597                                                                            
  598                                                                            
  599                                                                            
  600                                                                            
  601                                                                            
  602 Abley & Manderson             Informational                    [Page 11]   
  603                                                                            
line-179 Mauricio Vergara Ereche(Editorial Erratum #4135) [Verified]
based on outdated version
   Using HOSTNAME.BIND/CH/TXT (Section 4.2), ID.SERVER/CH/TXT
   (Section 4.3), or IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT or IDENTITY.L
   .ROOT-SERVERS/IN/A (Section 4.4)
It should say:
   Using HOSTNAME.BIND/CH/TXT (Section 4.2), ID.SERVER/CH/TXT
   (Section 4.3), or IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT or IDENTITY.L
   .ROOT-SERVERS.ORG/IN/A (Section 4.4)

Fixing missing .ORG in FQDN