Subject: Re: [DNSOP] DNSOP Digest, Vol 82, Issue 14

From: Mehmet Akcin <[email-masked]>
Date: Thu, 26 Sep 2013 10:16:50 -0700

Hello

below behavior where you see different servers are answering is due to the way some of the nodes we have setup.

If a single L-root physical location has more than one server providing l-root service we enable per-packet-load-balance and multipath (where possible) to balance the load between servers. Hence you see such behavior on the LAX node you are connecting to.

mehmet

On Sep 25, 2013, at 12:00 PM, [email-masked] wrote:

> Message: 1
> Date: Wed, 25 Sep 2013 16:33:53 +0800
> From: ice jew <[email-masked]>
> To: Xun Fan <[email-masked]>
> Cc: "[email-masked] WG" <[email-masked]>, Joe Abley
> 	<[email-masked]>,	Nevil Brownlee <[email-masked]>
> Subject: Re: [DNSOP] reviewers wanted for
> 	draft-jabley-dnsop-anycast-mapping-02
> Message-ID:
> 	<[email-masked]>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> 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:
> 
>> 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.ORGtxt +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.ORGtxt +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.ORGtxt +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-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:
>>>> 
>>>>> 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.
>>>>>> 
>>>>>> 
>>>>> _______________________________________________
>>>>> DNSOP mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> DNSOP mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>> 
>>>> 
>>> 
>