On 17 Oct 2003, at 03:47, Randy Bush wrote:
Incidentally, there is a similar mechanism available for the F root nameserver, in case people are not aware:
dig @f.root-servers.net hostname.bind chaos txt
For most people this will reveal a nameserver hostname with a "PAO" or an SFO in it. People within the catchment of a local anycast node of F will see different site codes.
but one has little assurance that the response is from the same server as the one from which one had the dns response one is debugging.
In general, that is correct. F is served by local clusters of nameservers, each arranged within a node. If successive queries use the same source port they will land on the same server, since nameserver selection within a node is done using a CEF-style (src_*, dst_*) hash (it's exactly CEF in a node which uses cisco routers, and it's "forwarding-table export per-packet-load-balance" in a node which uses Juniper routers). It is usually unlikely that two successive queries will be answered by different local nodes of F. Certainly if you do dig @f.root-servers.net hostname.bind chaos txt dig @f.root-servers.net ${some_other_query} dig @f.root-servers.net hostname.bind chaos txt and the first and last queries indicate your query is being answered by a particular node, it is extrordinarily unlikely that the middle query is answered somewhere else (since that would indicate abnormally swift BGP reconvergence on the selected path to 192.5.5.0/24, the covering route for F's v4 address). So the answer to "hostname.bind chaos txt" can give a high-confidence identity of the node answering the query, a low-confidence identity of the server within the node answering the query in the case where source ports on successive queries are different, and a higher confidence identity of the server if care is taken (for the purposes of specific measurement exercises) to keep source ports the same and execute the two queries in quick succession. Joe