Skip to main content

A Summary of Various Mechanisms Deployed at L-Root for the Identification of Anycast Nodes
draft-jabley-dnsop-anycast-mapping-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7108.
Author Joe Abley
Last updated 2013-03-25
RFC stream (None)
Formats
IETF conflict review conflict-review-jabley-dnsop-anycast-mapping, conflict-review-jabley-dnsop-anycast-mapping, conflict-review-jabley-dnsop-anycast-mapping, conflict-review-jabley-dnsop-anycast-mapping, conflict-review-jabley-dnsop-anycast-mapping, conflict-review-jabley-dnsop-anycast-mapping
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Became RFC 7108 (Informational)
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-jabley-dnsop-anycast-mapping-00
Network Working Group                                           J. Abley
Internet-Draft                                                     ICANN
Intended status: Informational                            March 25, 2013
Expires: September 26, 2013

       A Summary of Various Mechanisms Deployed at L-Root for the
                    Identification of Anycast Nodes
                 draft-jabley-dnsop-anycast-mapping-00

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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 26, 2013.

Copyright Notice

Abley                  Expires September 26, 2013               [Page 1]
Internet-Draft     L-Root Anycast Node Identification         March 2013

   Copyright (c) 2013 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Naming Scheme for L-Root Nodes . . . . . . . . . . . . . . . .  4
   3.  Identification of L-Root Nodes . . . . . . . . . . . . . . . .  5
     3.1.  Use of NSID  . . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  Use of HOSTNAME.BIND/CH/TXT  . . . . . . . . . . . . . . .  6
     3.3.  Use of ID.SERVER/CH/TXT  . . . . . . . . . . . . . . . . .  6
     3.4.  Use of IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT and IN/A . . . .  7
     3.5.  Use of NODES.L.ROOT-SERVERS.ORG/IN/TXT . . . . . . . . . .  8
   4.  Provisioning of IDENTITY.L.ROOT-SERVERS.ORG  . . . . . . . . .  9
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Appendix A.  Editorial Notes . . . . . . . . . . . . . . . . . . . 15
     A.1.  Change History . . . . . . . . . . . . . . . . . . . . . . 15
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16

Abley                  Expires September 26, 2013               [Page 2]
Internet-Draft     L-Root Anycast Node Identification         March 2013

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 <http://www.root-servers.org>.

   [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 AS112 servers [RFC6304] but
   not with any root server.  Modifications were subsequently made to
   the infrastructure of the L-Root service to facilitate this
   technique.

   This document describes all facilities currently provided at L-Root
   to aid node identification.

Abley                  Expires September 26, 2013               [Page 3]
Internet-Draft     L-Root Anycast Node Identification         March 2013

2.  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 [1]; and

   o  <NN> is a two-digit numeric code used to distinguish between two
      different locations in the vicinity of the same airport.

   Where multiple airports exist in the vicinity of a single L-Root
   node, one is arbitrarily chosen.

Abley                  Expires September 26, 2013               [Page 4]
Internet-Draft     L-Root Anycast Node Identification         March 2013

3.  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).  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.

   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.

   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.

3.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 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).

   [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:~]%

Abley                  Expires September 26, 2013               [Page 5]
Internet-Draft     L-Root Anycast Node Identification         March 2013

   [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:~]%

3.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].

   [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:~]%

3.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.

   The ID.SERVER/CH/TXT convention is described in [RFC4892].

   [monster:~]% dig -4 @L.ROOT-SERVERS.NET ID.SERVER CH TXT +short
   "ytz01.l.root-servers.org"
   [monster:~]%

Abley                  Expires September 26, 2013               [Page 6]
Internet-Draft     L-Root Anycast Node Identification         March 2013

   [monster:~]% dig -6 @L.ROOT-SERVERS.NET ID.SERVER CH TXT +short
   "ytz01.l.root-servers.org"
   [monster:~]%

3.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.
   Measurements of this separate service should give results which are
   representative of L-Root.  Further discussion of this service can be
   found in Section 4.

   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.

   The TXT record returned in the response to such queries is structured
   as follows:

   1.  The fully-qualified host name 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;

   4.  The economy in which the node is located; and

   5.  The ICANN region in which the node is located.

   The A record returned in the response to such queries is guaranteed
   to be unique to the responding node.

  [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:~]%

Abley                  Expires September 26, 2013               [Page 7]
Internet-Draft     L-Root Anycast Node Identification         March 2013

3.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.

   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.

   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.

   [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:~]%

Abley                  Expires September 26, 2013               [Page 8]
Internet-Draft     L-Root Anycast Node Identification         March 2013

4.  Provisioning of IDENTITY.L.ROOT-SERVERS.ORG

   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.

   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.

   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.

   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.

Abley                  Expires September 26, 2013               [Page 9]
Internet-Draft     L-Root Anycast Node Identification         March 2013

5.  Security Considerations

   The specification presented in this document presents no additional
   threat to the Internet.

Abley                  Expires September 26, 2013              [Page 10]
Internet-Draft     L-Root Anycast Node Identification         March 2013

6.  IANA Considerations

   This document makes no request of the IANA.

Abley                  Expires September 26, 2013              [Page 11]
Internet-Draft     L-Root Anycast Node Identification         March 2013

7.  Acknowledgements

   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.

   Your name here, etc.

Abley                  Expires September 26, 2013              [Page 12]
Internet-Draft     L-Root Anycast Node Identification         March 2013

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.

   [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.

8.2.  Informative References

   [Fan2013]  Fan, X., Heidemann, J., and R. Govidan, "Evaluating
              Anycast in the Domain Name System", Proceedings of the
              IEEE Infocom Turin, Italy, April 2013.

   [RFC6304]  Abley, J. and W. Maton, "AS112 Nameserver Operations",
              RFC 6304, July 2011.

Abley                  Expires September 26, 2013              [Page 13]
Internet-Draft     L-Root Anycast Node Identification         March 2013

URIs

   [1]  <http://www.iata.org/publications/Pages/coding.aspx>

Abley                  Expires September 26, 2013              [Page 14]
Internet-Draft     L-Root Anycast Node Identification         March 2013

Appendix A.  Editorial Notes

   This section (and sub-sections) to be removed prior to publication.

A.1.  Change History

   00 Initial idea, circulated for the purposes of entertainment.

Abley                  Expires September 26, 2013              [Page 15]
Internet-Draft     L-Root Anycast Node Identification         March 2013

Author's Address

   Joe Abley
   ICANN
   12025 Waterfront Drive
   Suite 300
   Los Angeles, CA  90094-2536
   USA

   Phone: +1 519 670 9327
   Email: joe.abley@icann.org

Abley                  Expires September 26, 2013              [Page 16]