One document matched: draft-jabley-dnsop-anycast-mapping-01.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 rfc2671 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2671.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-01">
<?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="27" 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>
<t>More granular location data published for L-Root nodes
(e.g. see <xref target="useofidentity"/>) is derived from the
lcoation of the airport, not the actual location of the
node.</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" anchor="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 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 unequivocably 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.</t>
<t>NSID is specified as an <xref target="RFC2671">EDNS0
option</xref>. Clients that do not support EDNS0 signalling
(or depend on other systems that do not support EDNS0)
may find this mechanism unavailable.</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" anchor="hostbind">
<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>
<t>Using HOSTNAME.BIND/CH/TXT 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
HOSTNAME.BIND/CH/TXT query could be answered by a different
node. Use of the NSID option can obviate this possiblity
(see <xref target="nsid"/>).</t>
<figure>
<artwork>
[monster:~]% dig -4 @L.ROOT-SERVERS.NET HOSTNAME.BIND CH TXT +short
"ytz01.l.root-servers.org"
[monster:~]%
[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>ID.SERVER/CH/TXT functions identically (apart from the
QNAME) to HOSTNAME.BIND/CH/TXT, as discussed in <xref
target="hostbind"/>. The discussion there relating to
the possibility of re-routing between successive queries
also follows for ID.SERVER/CH/TXT.</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:~]%
[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"
anchor="useofidentity">
<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>
<t>Since in this case 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 .../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).</t>
<t>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 .../IN/A and .../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 TTLs in responses from the authoritative
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.</t>
<t>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 use
DNS-specific tools such as dig.</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>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 node 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>
<t>The L.ROOT-SERVERS.ORG zone is signed using DNSSEC, and
hence secure responses for BEACON.L.ROOT-SERVERS.ORG and
NODES.L.ROOT-SERVERS.ORG are available. IDENTITY.L.ROOT-SERVERS.ORG
is an insecure delegation from the L.ROOT-SERVERS.ORG zone,
however, following the operational preference to serve
static data from each node for that zone, and the disinclination
to distribute key materials and zone signing machinery to
every node.</t>
</section>
<section title="Security Considerations">
<t>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 truely
secret, since any service element which provides service
to the Internet can be can never truly be obscured from
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.</t>
<t>The information presented in this document presents no new
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>Helpful reviews and comments from Gaurab Upadhaya, Hugo
Salgado, Brian Dixon and Bob Harold on earlier versions of
this document were very much appreciated.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc1034;
&rfc1035;
&rfc2671;
&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>
<t hangText="01">Added some commentary of use-cases of NSID
vs various/CH/TXT. Moved discussion of IN-class queries
from the NODES section to the IDENTITY section. Added
a note about DNSSEC for IDENTITY, NODES. Updated
acknowledgements section.</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:21:00 |