summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7108.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7108.txt')
-rw-r--r--doc/rfc/rfc7108.txt619
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]
+