One document matched: draft-jabley-dnsop-anycast-mapping-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1034 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml'>
<!ENTITY rfc1035 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'>
<!ENTITY rfc4786 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4786.xml'>
<!ENTITY rfc4892 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4892.xml'>
<!ENTITY rfc5001 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5001.xml'>
<!ENTITY rfc6304 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6304.xml'>
]>
<rfc category="info" ipr="trust200902"
docName="draft-jabley-dnsop-anycast-mapping-00">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="L-Root Anycast Node Identification">
A Summary of Various Mechanisms Deployed at L-Root for
the Identification of Anycast Nodes</title>
<author initials='J.' surname="Abley" fullname='Joe Abley'>
<organization>ICANN</organization>
<address>
<postal>
<street>12025 Waterfront Drive</street>
<street>Suite 300</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90094-2536</code>
<country>USA</country>
</postal>
<phone>+1 519 670 9327</phone>
<email>joe.abley@icann.org</email>
</address>
</author>
<date day="25" month="March" year="2013"/>
<abstract>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The Domain Name System (DNS) is described in <xref
target="RFC1034"/> and <xref target="RFC1035"/>. L-Root,
one of the thirteen root servers, is deployed using <xref
target="RFC4786">anycast</xref>; 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 <eref target="http://www.root-servers.org"/>.</t>
<t><xref target="Fan2013"/> describes a technique using open
DNS resolvers to distribute mapping queries to the service
addresses of authoritative-only servers. This technique
relies upon the ability to acquire meaningful information
about individual anycast nodes by means of an IN-class
query. At the time the experiments described in that paper
were conducted, such ability existed with <xref
target="RFC6304">AS112 servers</xref> but not with any
root server. Modifications were subsequently made to the
infrastructure of the L-Root service to facilitate this
technique.</t>
<t>This document describes all facilities currently provided
at L-Root to aid node identification.</t>
</section>
<section title="Naming Scheme for L-Root Nodes">
<t>Individual L-Root nodes have structured hostnames that
are constructed as follows:
<list style="empty">
<t><IATA Code><NN>.L.ROOT-SERVERS.ORG</t>
</list>
where
<list style="symbols">
<t><IATA Code> is chosen from the list of three-character
airport codes published by the International Air Transport
Association (IATA) in the <eref
target="http://www.iata.org/publications/Pages/coding.aspx">IATA
Airline Coding Directory</eref>; and</t>
<t><NN> is a two-digit numeric code used to distinguish
between two different locations in the vicinity of the same
airport.</t>
</list>
Where multiple airports exist in the vicinity of a single
L-Root node, one is arbitrarily chosen.</t>
</section>
<section title="Identification of L-Root Nodes">
<t>L-Root service is provided using a single IPv4 address
(199.7.83.42) and a single IPv6 address (2001:500:3::42).
It should be noted 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.</t>
<t>At the time of writing there are 273 separate name server
elements ("nodes") deployed in 143 locations which together
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.</t>
<t>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.</t>
<section title="Use of NSID">
<t>L-Root supports the use of the <xref target="RFC5001">Name
Server Identifier (NSID) Option</xref> 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.</t>
<t>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).</t>
<figure>
<artwork><![CDATA[
[monster:~]% 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)
[monster:~]%]]>
</artwork>
</figure>
<figure>
<artwork><![CDATA[
[monster:~]% 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)
[monster:~]%]]>
</artwork>
</figure>
</section>
<section title="Use of HOSTNAME.BIND/CH/TXT">
<t>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.</t>
<t>The HOSTNAME.BIND/CH/TXT convention is described in
<xref target="RFC4892"/>.</t>
<figure>
<artwork>
[monster:~]% dig -4 @L.ROOT-SERVERS.NET HOSTNAME.BIND CH TXT +short
"ytz01.l.root-servers.org"
[monster:~]%
</artwork>
</figure>
<figure>
<artwork>
[monster:~]% dig -6 @L.ROOT-SERVERS.NET HOSTNAME.BIND CH TXT +short
"ytz01.l.root-servers.org"
[monster:~]%
</artwork>
</figure>
</section>
<section title="Use of ID.SERVER/CH/TXT">
<t>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.</t>
<t>The ID.SERVER/CH/TXT convention is described in
<xref target="RFC4892"/>.</t>
<figure>
<artwork>
[monster:~]% dig -4 @L.ROOT-SERVERS.NET ID.SERVER CH TXT +short
"ytz01.l.root-servers.org"
[monster:~]%
</artwork>
</figure>
<figure>
<artwork>
[monster:~]% dig -6 @L.ROOT-SERVERS.NET ID.SERVER CH TXT +short
"ytz01.l.root-servers.org"
[monster:~]%
</artwork>
</figure>
</section>
<section title="Use of IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT and IN/A">
<t>The operator of L-Root has distributed a separate DNS
service in parallel with L-Root, operating on precisely
the same set of nodes. Measurements of this separate
service should give results which are representative of
L-Root. Further discussion of this service can be found
in <xref target="identity"/>.</t>
<t>The fully-qualified DNS name IDENTITY.L.ROOT-SERVERS.ORG
(note the use of ORG, not NET) has associated TXT and A
RR Sets which 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.</t>
<t>The TXT record returned in the response to such queries
is structured as follows:
<list style="numbers">
<t>The fully-qualified host name of the node responding
to the query;</t>
<t>The city in which the node is located;</t>
<t>The region in which the node is located;</t>
<t>The economy in which the node is located; and</t>
<t>The ICANN region in which the node is located.</t>
</list>
</t>
<t>The A record returned in the response to such queries
is guaranteed to be unique to the responding node.</t>
<figure>
<artwork>
[monster:~]% dig IDENTITY.L.ROOT-SERVERS.ORG TXT +short
"ytz01.l.root-servers.org" "Toronto" "Ontario" "Canada" "NorthAmerica"
[monster:~]%
[monster:~]% dig IDENTITY.L.ROOT-SERVERS.ORG A +short
67.215.199.91
[monster:~]%
</artwork>
</figure>
</section>
<section title="Use of NODES.L.ROOT-SERVERS.ORG/IN/TXT">
<t>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.</t>
<t>Since the 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.</t>
<t>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.</t>
<figure>
<artwork>
[monster:~]% 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"
[monster:~]%
</artwork>
</figure>
</section>
</section>
<section title="Provisioning of IDENTITY.L.ROOT-SERVERS.ORG"
anchor="identity">
<t>Individual L-Root nodes run a dedicated, separate
authority-only DNS server process which serves the
IDENTITY.L.ROOT-SERVERS.ORG zone. The contents of that
zone are unique to every node, and hence each responding
node will generate a node-specific response.</t>
<t>The contents of the IDENTITY.L.ROOT-SERVERS.ORG zone are
hence deliberately incoherent, the apparent zone contents
depending on the ndoe responding to the corresponding
query.</t>
<t>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, and hence measurement of the IDENTITY
service ought to give similar results to measurement of
the L-Root service.</t>
<t>It is considered best practice always to delegate a
DNS zone to more than one name server; 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.</t>
</section>
<section title="Security Considerations">
<t>The specification presented in this document presents no
additional threat to the Internet.</t>
</section>
<section title="IANA Considerations">
<t>This document makes no request of the IANA.</t>
</section>
<section title="Acknowledgements">
<t>The aspects of the L-Root service that were deployed to
facilitate IN-class mapping were discussed and implementated
as part of an informal collaboration with Xun Fan, John
Heidemann and Ramesh Govidan, whose contributions are
acknowledged.</t>
<t>Your name here, etc.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc1034;
&rfc1035;
&rfc4786;
&rfc4892;
&rfc5001;
</references>
<references title="Informative References">
&rfc6304;
<reference anchor="Fan2013">
<front>
<title>Evaluating Anycast in the Domain Name System</title>
<author initials="X." surname="Fan" fullname="Xun Fan">
<organization abbrev="ISI">University of California
Information Sciences Institute</organization>
<address/>
</author>
<author initials="J." surname="Heidemann" fullname="John Heidemann">
<organization abbrev="ISI">University of California
Information Sciences Institute</organization>
<address/>
</author>
<author initials="R." surname="Govidan" fullname="Ramesh Govidan">
<organization abbrev="ISI">University of California
Information Sciences Institute</organization>
<address/>
</author>
</front>
<seriesInfo name="Proceedings of the IEEE Infocom"
value="Turin, Italy, April 2013"/>
<format type="PDF" target="http://www.isi.edu/~johnh/PAPERS/Fan13a.pdf"/>
</reference>
</references>
<section title="Editorial Notes">
<t>This section (and sub-sections) to be removed prior to
publication.</t>
<section title="Change History">
<t>
<list style="hanging">
<t hangText="00">Initial idea, circulated for the purposes of
entertainment.</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:21:47 |