Subject: [DNSOP] reviewers wanted for draft-jabley-dnsop-anycast-mapping-02

From: Joe Abley <[email-masked]>
Date: Tue, 24 Sep 2013 12:16:17 -0400

Hi all,

Nevil Brownlee is graciously considering this document for the independent-submission stream:

  http://tools.ietf.org/html/draft-jabley-dnsop-anycast-mapping-02

It's an informational document that describes the various mechanisms provided at L-Root to identify what anycast node you see from your special place in the network. The goals are (a) publication of details about a particular Internet infrastructure service (L-Root), and (b) providing a worked example that might serve as useful input to design exercises carried out by other people with anycast DNS infrastructure.

Nevil needs some additional reviews before he can make progress. There's only about 8 pages of text here (many of which are filled with example output from dig, etc). If you have a spare 10 minutes to be able to give your impressions, it would be appreciated.

Please send reviews to Nevil at [email-masked], ideally cc'ing me so I can know when to stop asking people for reviews. :-)

Joe

>        A Summary of Various Mechanisms Deployed at L-Root for the
>                     Identification of Anycast Nodes
>                  draft-jabley-dnsop-anycast-mapping-02
> 
> 
> 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.
> 
>

---

From: ice jew <[email-masked]>
Date: Wed, 25 Sep 2013 14:10:38 +0800

I've made such test:
My_Dev_Test:~/bind-9.9.3-P1/bin/dig # dig IDENTITY.L.ROOT-SERVERS.ORG -t
txt +short
"lax06.l.root-servers.org" "Los Angeles" "California" "United States"
"NorthAmerica"
My_Dev_Test:~/bind-9.9.3-P1/bin/dig # dig lax06.l.root-servers.org  +short
199.7.94.6
My_Dev_Test:~/bind-9.9.3-P1/bin/dig # dig IDENTITY.L.ROOT-SERVERS.ORG +short
199.7.94.5

And which result should I trust under this situation?  Both queries were
sent to the same resolver.

On Wed, Sep 25, 2013 at 12:16 AM, Joe Abley <[email-masked]> wrote:

> It's an informational document that describes the various mechanisms
> provided at L-Root to identify what anycast node you see from your special
> place in the network. The goals are (a) publication of details about a
> particular Internet infrastructure service (L-Root), and (b) providing a
> worked example that might serve as useful input to design exercises carried
> out by other people with anycast DNS infrastructure.
>
> Nevil needs some additional reviews before he can make progress. There's
> only about 8 pages of text here (many of which are filled with example
> output from dig, etc). If you have a spare 10 minutes to be able to give
> your impressions, it would be appreciated.
>
> Please send reviews to Nevil at [email-masked], ideally cc'ing me
> so I can know when to stop asking people for reviews. :-)
>
>
> Joe
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Xun Fan <[email-masked]>
Date: Wed, 25 Sep 2013 01:20:21 -0700

Your TXT query and A query may be responded by different servers. There
seems to be some load balancing behind. I just ran three times the query,
and was directed to different servers:

-bash-4.2$ dig @beacon.l.root-servers.org
IDENTITY.L.ROOT-SERVERS.ORG<http://identity.l.root-servers.org/> txt
+short
"lax03.l.root-servers.org" "Los Angeles" "California" "United States"
"NorthAmerica"
-bash-4.2$ dig @beacon.l.root-servers.org
IDENTITY.L.ROOT-SERVERS.ORG<http://identity.l.root-servers.org/> txt
+short
"lax01.l.root-servers.org" "Los Angeles" "California" "United States"
"NorthAmerica"
-bash-4.2$ dig @beacon.l.root-servers.org
IDENTITY.L.ROOT-SERVERS.ORG<http://identity.l.root-servers.org/> txt
+short
"lax08.l.root-servers.org" "Los Angeles" "California" "United States"
"NorthAmerica"
-bash-4.2$ dig @beacon.l.root-servers.org
IDENTITY.L.ROOT-SERVERS.ORG<http://identity.l.root-servers.org/> A
+short
199.7.94.8
-bash-4.2$ dig @beacon.l.root-servers.org
IDENTITY.L.ROOT-SERVERS.ORG<http://identity.l.root-servers.org/> A
+short
199.7.94.16
-bash-4.2$ dig @beacon.l.root-servers.org
IDENTITY.L.ROOT-SERVERS.ORG<http://identity.l.root-servers.org/> A
+short
199.7.94.7

On Wed, Sep 25, 2013 at 12:58 AM, Xun Fan <[email-masked]> wrote:

> Your TXT query and A query may be responded by different servers. There
> seems to be some load balancing behind. I just ran three times the query,
> and was directed to different servers:
>
> -bash-4.2$ dig @beacon.l.root-servers.org IDENTITY.L.ROOT-SERVERS.ORG txt
> +short
> "lax03.l.root-servers.org" "Los Angeles" "California" "United States"
> "NorthAmerica"
> -bash-4.2$ dig @beacon.l.root-servers.org IDENTITY.L.ROOT-SERVERS.ORG txt
> +short
> "lax01.l.root-servers.org" "Los Angeles" "California" "United States"
> "NorthAmerica"
> -bash-4.2$ dig @beacon.l.root-servers.org IDENTITY.L.ROOT-SERVERS.ORG txt
> +short
> "lax08.l.root-servers.org" "Los Angeles" "California" "United States"
> "NorthAmerica"
> -bash-4.2$ dig @beacon.l.root-servers.org IDENTITY.L.ROOT-SERVERS.ORG A
> +short
> 199.7.94.8
> -bash-4.2$ dig @beacon.l.root-servers.org IDENTITY.L.ROOT-SERVERS.ORG A
> +short
> 199.7.94.16
> -bash-4.2$ dig @beacon.l.root-servers.org IDENTITY.L.ROOT-SERVERS.ORG A
> +short
> 199.7.94.7
>
>
>
> On Tue, Sep 24, 2013 at 11:10 PM, ice jew <[email-masked]> wrote:
>
>> I've made such test:
>> My_Dev_Test:~/bind-9.9.3-P1/bin/dig # dig IDENTITY.L.ROOT-SERVERS.ORG+short
>> 199.7.94.5
>>
>>> Please send reviews to Nevil at [email-masked], ideally cc'ing
>>> me so I can know when to stop asking people for reviews. :-)
>>>
>>>
>>> Joe
>>>

---

From: ice jew <[email-masked]>
Date: Wed, 25 Sep 2013 16:33:53 +0800

I think it's related to the real load balancing strategy of L-root's back
end nodes.
Joe more details?

On Wed, Sep 25, 2013 at 4:20 PM, Xun Fan <[email-masked]> wrote:

> -bash-4.2$ dig @beacon.l.root-servers.org IDENTITY.L.ROOT-SERVERS.ORG<http://identity.l.root-servers.org/> txt
> +short
> -bash-4.2$ dig @beacon.l.root-servers.org IDENTITY.L.ROOT-SERVERS.ORG<http://identity.l.root-servers.org/> txt
> +short
> -bash-4.2$ dig @beacon.l.root-servers.org IDENTITY.L.ROOT-SERVERS.ORG<http://identity.l.root-servers.org/> txt
> +short
> -bash-4.2$ dig @beacon.l.root-servers.org IDENTITY.L.ROOT-SERVERS.ORG<http://identity.l.root-servers.org/> A
> +short
> 199.7.94.8
> -bash-4.2$ dig @beacon.l.root-servers.org IDENTITY.L.ROOT-SERVERS.ORG<http://identity.l.root-servers.org/> A
> +short
> 199.7.94.16
> -bash-4.2$ dig @beacon.l.root-servers.org IDENTITY.L.ROOT-SERVERS.ORG<http://identity.l.root-servers.org/> A
> +short
> 199.7.94.7
>
>
>> -bash-4.2$ dig @beacon.l.root-servers.org IDENTITY.L.ROOT-SERVERS.ORGtxt +short
>> -bash-4.2$ dig @beacon.l.root-servers.org IDENTITY.L.ROOT-SERVERS.ORGtxt +short
>> -bash-4.2$ dig @beacon.l.root-servers.org IDENTITY.L.ROOT-SERVERS.ORGtxt +short
>>> My_Dev_Test:~/bind-9.9.3-P1/bin/dig # dig IDENTITY.L.ROOT-SERVERS.ORG-t txt +short
>>>> Nevil needs some additional reviews before he can make progress.
>>>> There's only about 8 pages of text here (many of which are filled with
>>>> example output from dig, etc). If you have a spare 10 minutes to be able to
>>>> give your impressions, it would be appreciated.
>>>>

---

From: Joe Abley <[email-masked]>
Date: Wed, 25 Sep 2013 08:45:11 -0400

On 2013-09-25, at 04:33, ice jew <[email-masked]> wrote:

> I think it's related to the real load balancing strategy of L-root's back end nodes. 
> Joe more details?

It's always possible for successive queries to be directed at different anycast nodes. This is described in the text:

4.  Identification of L-Root Nodes

   [...]

   Using HOSTNAME.BIND/CH/TXT (Section 4.2), ID.SERVER/CH/TXT
   (Section 4.3) or IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT or .../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 NSID option can obviate this possibility (see
   Section 4.1).

Many locations with local L-Root nodes have more than one node deployed. The heaviest deployments in a single location are in Los Angeles and Prague. In both of those locations we have multiple L-Root nodes deployed behind a single router; an inbound query towards L-Root's service address will be forwarded towards one of those servers. The router uses a hash of a tuple that includes source and destination port as well as addresses to select from the candidate next-hops; since successive queries are generally expected to have different source ports, it's normal and likely that they'll be answered by different nameservers.

Joe