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 protected] wrote: > Message: 1 > Date: Wed, 25 Sep 2013 16:33:53 +0800 > From: ice jew <[email protected]> > To: Xun Fan <[email protected]> > Cc: "[email protected] WG" <[email protected]>, Joe Abley > <[email protected]>, Nevil Brownlee <[email protected]> > Subject: Re: [DNSOP] reviewers wanted for > draft-jabley-dnsop-anycast-mapping-02 > Message-ID: > <cab3zd+nvlvloiybh9psthgm+6bthb3t7iafl4cfy8_q7ask...@mail.gmail.com> > 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 protected]> 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 protected]> 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 protected]> 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 protected]> 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 protected], 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 protected] >>>>> https://www.ietf.org/mailman/listinfo/dnsop >>>>> >>>> >>>> >>>> _______________________________________________ >>>> DNSOP mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/dnsop >>>> >>>> >>> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
