One document matched: draft-jabley-dnsop-anycast-mapping-03.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 rfc2182 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2182.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 rfc6891 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6891.xml'>
]>
<rfc category="info" ipr="trust200902"
docName="draft-jabley-dnsop-anycast-mapping-03">
<?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="15" month="October" 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>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 currently provided
at L-Root to aid node identification.</t>
</section>
<section title="Conventions Used in this Document">
<t>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.</t>
<t>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.</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
location of the airport, not the actual location of the
node.</t>
</section>
<section title="Identification of L-Root Nodes" anchor="identification">
<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. Successive
queries from the same client may also 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>
<t>Using <xref target="hostbind">HOSTNAME.BIND/CH/TXT</xref>,
<xref target="idserver">ID.SERVER/CH/TXT</xref> or
<xref target="useofidentity">IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT
or .../IN/A</xref> 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 NSID option on the precise queries that yield
problematic responses can obviate this possibility (see
<xref target="nsid"/>).</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 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.</t>
<t>NSID is specified as an <xref target="RFC6891">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[
% 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)
%]]>
</artwork>
</figure>
<figure>
<artwork><![CDATA[
% 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)
%]]>
</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>
<figure>
<artwork>
% 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"
%
</artwork>
</figure>
</section>
<section title="Use of ID.SERVER/CH/TXT" anchor="idserver">
<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>
% 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"
%
</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 but listening on addresses which
are different from the L-Root service addresses. 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, if applicable;</t>
<t>The economy in which the node is located (in most cases,
tne name of a country); and</t>
<t>The ICANN region in which the node is located. A list
of ICANN regions at the time of writing can be found
at <eref target="http://meetings.icann.org/regions"/>.</t>
</list>
</t>
<t>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.</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>
% 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
%
</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>
% 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"
%
</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 <xref target="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.</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 truly
secret, since any service element which provides service
to the Internet 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 implemented
as part of an informal collaboration with Xun Fan, John
Heidemann and Ramesh Govidan, whose contributions are
acknowledged. The motivation to faciitate mapping of L-Root
as an anycast service using IN-class queries was inspired
by <xref target="Fan2013"/>.</t>
<t>Helpful reviews and comments from Gaurab Upadhaya, Hugo
Salgado, Brian Dixon, Bob Harold, Paul Hoffman, Jakob
Schlyter, Andrew Sullivan, Bruce Campbell and S. Moonesamy
on earlier versions of this document were very much
appreciated.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc1034;
&rfc1035;
&rfc2182;
&rfc4786;
&rfc4892;
&rfc5001;
&rfc6891;
</references>
<references title="Informative References">
<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>
<t hangText="02">Clarified re-routing impact on HOSTNAME.BIND,
ID.SERVER, LOCATION.L queries vs. NSID as not just applying
to HOSTNAME.BIND. Fixed typos and absurd malapropisms.
Cleaned up prompts in command-line examples and added text
to clarify how such examples should be interpreted.</t>
<t hangText="03">Added reference to <xref target="RFC2182"/>
at the suggestion of Andrew Sullivan. Made edits to
<xref target="identification"/> in response
to comments from Bruce Campbell. Incorporated changes
following review from SM.</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:21:36 |