On 2013-09-25, at 04:33, ice jew <[email protected]> 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 _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
