doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc7108.txt b/doc/rfc/rfc7108.txt
new file mode 100644
index 0000000..5258829
--- /dev/null
+++ b/doc/rfc/rfc7108.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Independent Submission                                          J. Abley
+Request for Comments: 7108                                     Dyn, Inc.
+Category: Informational                                     T. Manderson
+ISSN: 2070-1721                                                    ICANN
+                                                            January 2014
+
+
+       A Summary of Various Mechanisms Deployed at L-Root for the
+                    Identification of Anycast Nodes
+
+Abstract
+
+   Anycast is a deployment technique commonly employed for
+   authoritative-only servers in the Domain Name System (DNS).  L-Root,
+   one of the thirteen root servers, is deployed in this fashion.
+
+   Various techniques have been used to map deployed anycast
+   infrastructure externally, i.e., without reference to inside
+   knowledge about where and how such infrastructure has been deployed.
+   Motivations for performing such measurement exercises include
+   operational troubleshooting and infrastructure risk assessment.  In
+   the specific case of L-Root, the ability to measure and map anycast
+   infrastructure using the techniques mentioned in this document is
+   provided for reasons of operational transparency.
+
+   This document describes all facilities deployed at L-Root to
+   facilitate mapping of its infrastructure and serves as documentation
+   for L-Root as a measurable service.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This is a contribution to the RFC Series, independently of any other
+   RFC stream.  The RFC Editor has chosen to publish this document at
+   its discretion and makes no statement about its value for
+   implementation or deployment.  Documents approved for publication by
+   the RFC Editor are not a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7108.
+
+
+
+
+
+
+
+Abley & Manderson             Informational                     [Page 1]
+
+RFC 7108           L-Root Anycast Node Identification       January 2014
+
+
+Copyright Notice
+
+   Copyright (c) 2014 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
+   3.  Naming Scheme for L-Root Nodes  . . . . . . . . . . . . . . .   3
+   4.  Identification of L-Root Nodes  . . . . . . . . . . . . . . .   3
+     4.1.  Use of NSID . . . . . . . . . . . . . . . . . . . . . . .   4
+     4.2.  Use of HOSTNAME.BIND/CH/TXT . . . . . . . . . . . . . . .   5
+     4.3.  Use of ID.SERVER/CH/TXT . . . . . . . . . . . . . . . . .   6
+     4.4.  Use of IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT and .../IN/A  .   6
+     4.5.  Use of NODES.L.ROOT-SERVERS.ORG/IN/TXT  . . . . . . . . .   8
+   5.  Provisioning of IDENTITY.L.ROOT-SERVERS.ORG . . . . . . . . .   9
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
+   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
+   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
+     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
+     8.2.  Informative References  . . . . . . . . . . . . . . . . .  11
+
+1.  Introduction
+
+   The Domain Name System (DNS) is described in [RFC1034] and [RFC1035].
+   L-Root, one of the thirteen root servers, is deployed using anycast
+   [RFC4786]; its service addresses, published in the A and AAAA
+   Resource Record (RR) Sets for "L.ROOT-SERVERS.NET", are made
+   available from a substantial number of semi-autonomous servers
+   deployed throughout the Internet.  A list of locations served by
+   L-Root can be found at [ROOT-SERVERS].
+
+   Various techniques have been used to map deployed anycast
+   infrastructure externally, i.e., without reference to inside
+   knowledge about where and how such infrastructure has been deployed.
+   Motivations for performing such measurement exercises include
+   operational troubleshooting and infrastructure risk assessment.  In
+   the specific case of L-Root, the ability to measure and map anycast
+   infrastructure using the techniques mentioned in this document is
+   provided for reasons of operational transparency.
+
+
+
+Abley & Manderson             Informational                     [Page 2]
+
+RFC 7108           L-Root Anycast Node Identification       January 2014
+
+
+   This document describes all facilities currently provided at L-Root
+   to aid node identification.
+
+2.  Conventions Used in This Document
+
+   This document contains several examples of commands typed at a Unix
+   (or Unix-like) command line to illustrate use of the various
+   mechanisms available to identify L-Root nodes.  Such examples are
+   presented in this document with lines typed by the user preceded by
+   the "%" prompt character; a bare "%" character indicates the end of
+   the output resulting from the command.
+
+   In some cases, the output shown in examples is too long to be
+   represented directly in the text.  In those cases, a backslash
+   character ("\") is used to indicate continuation.
+
+3.  Naming Scheme for L-Root Nodes
+
+   Individual L-Root nodes have structured hostnames that are
+   constructed as follows:
+
+      <IATA Code><NN>.L.ROOT-SERVERS.ORG
+
+   where
+
+   o  <IATA Code> is chosen from the list of three-character airport
+      codes published by the International Air Transport Association
+      (IATA) in the IATA Airline Coding Directory [ACD]; and
+
+   o  <NN> is a two-digit numeric code used to distinguish between two
+      different nodes in the vicinity of the same airport.
+
+   Where multiple airports exist in the vicinity of a single L-Root
+   node, one is arbitrarily chosen.
+
+   More granular location data published for L-Root nodes (e.g., see
+   Section 4.4) is derived from the location of the airport, not the
+   actual location of the node.
+
+4.  Identification of L-Root Nodes
+
+   L-Root service is provided using a single IPv4 address (199.7.83.42)
+   and a single IPv6 address (2001:500:3::42).  Note that it is
+   preferable to refer to the service using its DNS name (L.ROOT-
+   SERVERS.NET) rather than literal addresses, since addresses can
+   change from time to time.
+
+
+
+
+
+Abley & Manderson             Informational                     [Page 3]
+
+RFC 7108           L-Root Anycast Node Identification       January 2014
+
+
+   At the time of writing, there are 273 separate name server elements
+   ("nodes") deployed in 143 locations: together, these nodes provide
+   L-Root service.  A DNS query sent to an L-Root service address will
+   be routed towards exactly one of those nodes for processing, and the
+   corresponding DNS response will be originated from the same node.
+   Queries from different clients may be routed to different nodes.
+   Successive queries from the same client may also be routed to
+   different nodes.
+
+   The following sections provide a summary of all mechanisms provided
+   by L-Root to allow a client to identify which L-Root node is being
+   used.
+
+   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) to identify a node for the purposes
+   of reporting a problem is frequently reasonable, but it should be
+   acknowledged that there is potential for re-routing between
+   successive queries: an observed problem might relate to one node,
+   whilst a subsequent query using one of those three techniques could
+   be answered by a different node.  Use of the Name Server Identifier
+   (NSID) option on the precise queries that yield problematic responses
+   can obviate this possibility (see Section 4.1).
+
+4.1.  Use of NSID
+
+   L-Root supports the use of the Name Server Identifier (NSID) option
+   [RFC5001] to return the identity of an L-Root node along with the
+   response to a DNS query.  The NSID payload of such responses is the
+   fully qualified hostname of the responding L-Root node.
+
+   The NSID option allows the identification of a node sending a
+   specific, requested response to the client.  This is of particular
+   use if (for example) there is a desire to identify unequivocally what
+   node is responding with a particularly troublesome response; the
+   output of the diagnostic tool "dig" with NSID requested provides the
+   problem response with the node identification, and its output in that
+   case could form the basis of a useful trouble report.
+
+   NSID is specified as an EDNS(0) option [RFC6891].  Clients that do
+   not support EDNS(0) signaling (or depend on other systems that do not
+   support EDNS0) may find this mechanism unavailable.
+
+   The NSID option can be specified using the widely used diagnostic
+   tool "dig" using the "+nsid" option, as shown below.  Note that long
+   lines have been truncated for the purposes of this document ("\" at
+   the end of a line indicates continuation).
+
+
+
+
+Abley & Manderson             Informational                     [Page 4]
+
+RFC 7108           L-Root Anycast Node Identification       January 2014
+
+
+   % dig -4 @L.ROOT-SERVERS.NET . SOA +nsid \
+     +norec +noall +comments
+   ; <<>> DiG 9.6.-ESV-R3 <<>> -4 @L.ROOT-SERVERS.NET . SOA +nsid \
+     +norec +noall +comments
+   ; (1 server found)
+   ;; global options: +cmd
+   ;; Got answer:
+   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14913
+   ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 23
+
+   ;; OPT PSEUDOSECTION:
+   ; EDNS: version: 0, flags:; udp: 4096
+   ; NSID: 79 74 7a 30 31 2e 6c 2e 72 6f 6f 74 2d 73 65 72 76 65 72 73 \
+     2e 6f 72 67  (y) (t) (z) (0) (1) (.) (l) (.) (r) (o) (o) (t) (-) \
+     (s) (e) (r) (v) (e) (r) (s) (.) (o) (r) (g)
+   %
+
+   % dig -6 @L.ROOT-SERVERS.NET . SOA +nsid \
+     +norec +noall +comments
+   ; <<>> DiG 9.6.-ESV-R3 <<>> -6 @L.ROOT-SERVERS.NET . SOA +nsid \
+     +norec +noall +comments
+   ; (1 server found)
+   ;; global options: +cmd
+   ;; Got answer:
+   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33374
+   ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 23
+
+   ;; OPT PSEUDOSECTION:
+   ; EDNS: version: 0, flags:; udp: 4096
+   ; NSID: 79 74 7a 30 31 2e 6c 2e 72 6f 6f 74 2d 73 65 72 76 65 72 73 \
+     2e 6f 72 67  (y) (t) (z) (0) (1) (.) (l) (.) (r) (o) (o) (t) (-) \
+     (s) (e) (r) (v) (e) (r) (s) (.) (o) (r) (g)
+   %
+
+4.2.  Use of HOSTNAME.BIND/CH/TXT
+
+   L-Root supports the use of HOSTNAME.BIND/CH/TXT queries to return the
+   identity of an L-Root node.  The TXT RDATA returned is the fully
+   qualified hostname of the responding L-Root node.
+
+   The HOSTNAME.BIND/CH/TXT convention is described in [RFC4892].
+
+
+
+
+
+
+
+
+
+
+Abley & Manderson             Informational                     [Page 5]
+
+RFC 7108           L-Root Anycast Node Identification       January 2014
+
+
+   % dig -4 @L.ROOT-SERVERS.NET HOSTNAME.BIND CH TXT +short
+   "ytz01.l.root-servers.org"
+   %
+
+   % dig -6 @L.ROOT-SERVERS.NET HOSTNAME.BIND CH TXT +short
+   "ytz01.l.root-servers.org"
+   %
+
+4.3.  Use of ID.SERVER/CH/TXT
+
+   L-Root supports the use of ID.SERVER/CH/TXT queries to return the
+   identity of an L-Root node.  The TXT RDATA returned is the fully
+   qualified hostname of the responding L-Root node.
+
+   ID.SERVER/CH/TXT functions identically (apart from the QNAME) to
+   HOSTNAME.BIND/CH/TXT, as discussed in Section 4.2.  The discussion
+   there relating to the possibility of re-routing between successive
+   queries also follows for ID.SERVER/CH/TXT.
+
+   The ID.SERVER/CH/TXT convention is described in [RFC4892].
+
+   % dig -4 @L.ROOT-SERVERS.NET ID.SERVER CH TXT +short
+   "ytz01.l.root-servers.org"
+   %
+
+   % dig -6 @L.ROOT-SERVERS.NET ID.SERVER CH TXT +short
+   "ytz01.l.root-servers.org"
+   %
+
+4.4.  Use of IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT and .../IN/A
+
+   The operator of L-Root has distributed a separate DNS service in
+   parallel with L-Root, operating on precisely the same set of nodes
+   but listening on addresses that are different from the L-Root service
+   addresses.  Measurements of this separate service should give results
+   that are representative of L-Root.  Further discussion of this
+   service can be found in Section 5.
+
+   The fully qualified DNS name IDENTITY.L.ROOT-SERVERS.ORG (note the
+   use of ORG, not NET) has associated TXT and A RR Sets that are unique
+   to the responding node.  Clients are hence able to issue queries for
+   IDENTITY.L.ROOT-SERVERS.ORG/IN/A and IDENTITY.L.ROOT-SERVERS.ORG/IN/
+   TXT and use the results both to identify individual nodes and to
+   distinguish between responses generated by different nodes.
+
+
+
+
+
+
+
+Abley & Manderson             Informational                     [Page 6]
+
+RFC 7108           L-Root Anycast Node Identification       January 2014
+
+
+   The TXT record returned in the response to such queries is structured
+   as follows:
+
+   1.  The fully qualified hostname of the node responding to the query;
+
+   2.  The city in which the node is located;
+
+   3.  The region in which the node is located, if applicable;
+
+   4.  The economy in which the node is located (in most cases, the name
+       of a country); and
+
+   5.  The Internet Corporation for Assigned Names and Numbers (ICANN)
+       region in which the node is located.  A list of ICANN regions at
+       the time of writing can be found at <http://meetings.icann.org/
+       regions>.
+
+   The A record returned in the response to such queries is guaranteed
+   to be unique to the responding node.  The A RRType was chosen in an
+   effort to make the use of this mechanism as widely available to
+   client environments as possible, and the ability to map a hostname to
+   an IPv4 address seemed more likely to be widespread than the mapping
+   of a hostname to any other value.  It should be noted that the
+   availability of this mechanism to any particular client is orthogonal
+   to the local availability of IPv4 or IPv6 transport.
+
+   In this case, because identity data is published using IN-class
+   resource records, it is not necessary to send queries directly
+   towards L-Root in order to obtain results.  Responses can be obtained
+   through recursive servers, the responses in those cases being the
+   identity of L-Root as observed through the recursive server used
+   rather than the "closest" L-Root node to the client.  This
+   facilitates some degree of remote troubleshooting, since a query for
+   IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT or IDENTITY.L.ROOT-SERVERS.ORG/IN/
+   A directed a remote recursive resolver can help illustrate which
+   L-Root node is being used by that server (or was used when the cache
+   was populated).
+
+   A related caching effect is that responses to IDENTITY.L.ROOT-
+   SERVERS.ORG/IN/A and IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT may be cached
+   at different times, and may hence persist in a cache for overlapping
+   periods of time.  One possible visible effect is that the responses
+   to IDENTITY.L.ROOT-SERVERS.ORG/IN/A and IDENTITY.L.ROOT-SERVERS.ORG/
+   IN/TXT as presented from a cache may appear to be incoherent (i.e.,
+   refer to different nodes) despite queries against of the cache
+   happening (near) simultaneously.  Caches may also discard the
+   published Times to Live (TTLs) in responses from the authoritative
+
+
+
+
+Abley & Manderson             Informational                     [Page 7]
+
+RFC 7108           L-Root Anycast Node Identification       January 2014
+
+
+   server and replace them with longer TTLs, as a matter of local
+   policy.  Interpretation of responses for these queries from caches
+   should therefore be carried out with these possible effects in mind.
+
+   It has been observed that IDENTITY.L.ROOT-SERVERS.ORG/IN/A queries
+   offer a useful mechanism for troubleshooting DNS problems with non-
+   technical users, since such users can often be walked through the
+   process of looking up an A record (e.g., as a side effect of
+   utilities such as ping) far easier than they can be instructed on how
+   to use DNS-specific tools such as dig.
+
+  % dig IDENTITY.L.ROOT-SERVERS.ORG TXT +short
+  "ytz01.l.root-servers.org" "Toronto" "Ontario" "Canada" "NorthAmerica"
+  %
+
+  % dig IDENTITY.L.ROOT-SERVERS.ORG A +short
+  67.215.199.91
+  %
+
+4.5.  Use of NODES.L.ROOT-SERVERS.ORG/IN/TXT
+
+   The fully qualified DNS name NODES.L.ROOT-SERVERS.ORG (note again the
+   use of ORG, not NET) provides multiple TXT RRs, one per node, and
+   represents the effective concatenation of all possible responses to
+   the query IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT.
+
+   Note that in the example below we have forced dig to send the query
+   over TCP, since we expect the response to be too large for UDP
+   transport to accommodate.  Note also that the list shown is truncated
+   for clarity, and can be expected to change from time to time as new
+   L-Root nodes are provisioned and old ones decommissioned.
+
+   % dig NODES.L.ROOT-SERVERS.ORG TXT +short +tcp | head -10
+   "abj01.l.root-servers.org" "Abidjan" "" "Cote d'Ivoire" "Africa"
+   "abj02.l.root-servers.org" "Abidjan" "" "Cote d'Ivoire" "Africa"
+   "akl01.l.root-servers.org" "Mangere" "" "New Zealand" "AsiaPacific"
+   "akl41.l.root-servers.org" "Mangere" "" "New Zealand" "AsiaPacific"
+   "akl42.l.root-servers.org" "Mangere" "" "New Zealand" "AsiaPacific"
+   "akl43.l.root-servers.org" "Mangere" "" "New Zealand" "AsiaPacific"
+   "akl44.l.root-servers.org" "Mangere" "" "New Zealand" "AsiaPacific"
+   "ams01.l.root-servers.org" "Haarlemmermeer" "" "Netherlands" "Europe"
+   "anc01.l.root-servers.org" "Anchorage" "Alaska" "United States" \
+     "NorthAmerica"
+   %
+
+
+
+
+
+
+
+Abley & Manderson             Informational                     [Page 8]
+
+RFC 7108           L-Root Anycast Node Identification       January 2014
+
+
+5.  Provisioning of IDENTITY.L.ROOT-SERVERS.ORG
+
+   Individual L-Root nodes run a dedicated, separate authority-only DNS
+   server process that serves the IDENTITY.L.ROOT-SERVERS.ORG zone.  The
+   contents of that zone are unique to every node; hence, each
+   responding node will generate a node-specific response.
+
+   The contents of the IDENTITY.L.ROOT-SERVERS.ORG zone are hence
+   deliberately incoherent, the apparent zone contents depending on the
+   node responding to the corresponding query.
+
+   The IDENTITY.L.ROOT-SERVERS.ORG zone is delegated to the single name
+   server BEACON.L.ROOT-SERVERS.ORG, numbered on IPv4 and IPv6 addresses
+   that are covered by the same routing advertisements that cover the
+   L-Root service addresses.  Reachability of BEACON.L.ROOT-SERVERS.ORG
+   is hence well-aligned with the reachability of L.ROOT-SERVERS.NET;
+   therefore, measurement of the IDENTITY service ought to give similar
+   results to measurement of the L-Root service.
+
+   It is considered best practice always to delegate a DNS zone to more
+   than one name server [RFC2182]; however, as described, the IDENTITY.L
+   .ROOT-SERVERS.ORG zone is delegated to just one server.  Ordinarily,
+   this would present a risk of failure if that single server is not
+   available; however, given the purpose of the delegation in this case
+   and that the expected mitigation of a failure in a single node is the
+   routing of a query to a different node, delegation to a single server
+   in this particular use-case is effective.
+
+   At the time of writing, the ROOT-SERVERS.ORG zone is not signed with
+   DNSSEC.  When DNSSEC is deployed in that zone, the L.ROOT-SERVERS.ORG
+   zone will also be signed.  This will facilitate secure responses for
+   queries for BEACON.L.ROOT-SERVERS.ORG and NODES.L.ROOT-SERVERS.ORG.
+
+   Secure responses for IDENTITY.L.ROOT-SERVERS.ORG are unlikely to
+   become available even with the deployment of DNSSEC in the parent,
+   since the implementation of the IDENTITY.L.ROOT-SERVERS.ORG service
+   involves widely distributed static zone data.  Management of key
+   materials distributed to every L-Root node would be impractical to
+   audit, and signatures returned in secure responses would be
+   correspondingly of low value.
+
+6.  Security Considerations
+
+   Some operators of anycast services choose not to disclose locations
+   (or even numbers) of nodes, citing security concerns.  The operator
+   of L-Root considers that none of the published information described
+   in this document is truly secret, since any service element that
+   provides service to the Internet can never truly be obscured from
+
+
+
+Abley & Manderson             Informational                     [Page 9]
+
+RFC 7108           L-Root Anycast Node Identification       January 2014
+
+
+   view.  Given that location information can be found regardless of any
+   conscious, deliberate disclosure, and since easy access to this
+   information has diagnostic value, the operator of L-Root has adopted
+   a policy of operational transparency.
+
+   The information presented in this document presents no new threat to
+   the Internet.
+
+7.  Acknowledgements
+
+   The aspects of the L-Root service that were deployed to facilitate
+   IN-class mapping were discussed and implemented as part of an
+   informal collaboration with Xun Fan, John Heidemann, and Ramesh
+   Govidan, whose contributions are acknowledged.  The motivation to
+   facilitate mapping of L-Root as an anycast service using IN-class
+   queries was inspired by [Fan2013].
+
+   Helpful reviews and comments from Gaurab Upadhaya, Hugo Salgado,
+   Brian Dixon, Bob Harold, Paul Hoffman, Jakob Schlyter, Andrew
+   Sullivan, Bruce Campbell, S. Moonesamy, and Stephane Bortzmeyer on
+   earlier versions of this document were very much appreciated.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2182]  Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
+              and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
+              July 1997.
+
+   [RFC4786]  Abley, J. and K. Lindqvist, "Operation of Anycast
+              Services", BCP 126, RFC 4786, December 2006.
+
+   [RFC4892]  Woolf, S. and D. Conrad, "Requirements for a Mechanism
+              Identifying a Name Server Instance", RFC 4892, June 2007.
+
+   [RFC5001]  Austein, R., "DNS Name Server Identifier (NSID) Option",
+              RFC 5001, August 2007.
+
+   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
+              for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.
+
+
+
+
+Abley & Manderson             Informational                    [Page 10]
+
+RFC 7108           L-Root Anycast Node Identification       January 2014
+
+
+8.2.  Informative References
+
+   [ACD]      International Air Transport Association (IATA), "Airline
+              Coding Directory (ACD)", 2013,
+              <http://www.iata.org/publications/Pages/coding.aspx>.
+
+   [Fan2013]  Fan, X., Heidemann, J., and R. Govidan, "Evaluating
+              Anycast in the Domain Name System", Proceedings of the
+              IEEE Infocom Turin, Italy, April 2013.
+
+   [ROOT-SERVERS]
+              "root-servers.org", <http://www.root-servers.org>.
+
+Authors' Addresses
+
+   Joe Abley
+   Dyn, Inc.
+   470 Moore Street
+   London, ON  N6C 2C2
+   Canada
+
+   Phone: +1 519 670 9327
+   EMail: jabley@dyn.com
+
+
+   Terry Manderson
+   ICANN
+   12025 Waterfront Drive
+   Suite 300
+   Los Angeles, CA  90094-2536
+   USA
+
+   EMail: terry.manderson@icann.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Abley & Manderson             Informational                    [Page 11]
+