On Thu, 16 Oct 2003, Rodney Joffe wrote:
Randy Bush wrote:
and what assurance do you have that the traceroute is to the same server to which the original query failed?
difficulty debugging anycast dns was the major reason for sceptisim re anycast auth servers.
However as the dns was walked, if indeed a server had a problem, in a non-anycast implementation you could tell which server ip address had the problem. But you could not always tell which actual machine had a problem if it was behind a load balancer of any kind, something increasingly common in large installations.
Anycast is no different.
Anycast is subtly different, as effectively the internal workings of the load balancer are spread around the world for all to marvel at, rather than at one end site.
In terms of UltraDNS, we try to make it easier by having the following two records on every server:
dig @[UltraDNS Anycast name or ip address] whoareyou.ultradns.net A and dig @[UltraDNS Anycast name or ip address] whoami.ultradns.net A
For the end-user, where is this documented ? I know to look for 'version.bind', 'id.server', 'version.server' and a few others, but I hadn't considered asking for 'whoareyou.arbitary.domain'. Why would other people consider it? Also, did the query that I'm debugging really go to the same host that I just got the real IP address from? Does the nameserver on the 'real' IP address function the same way as the anycasted virtual IP address? ( Incidentally, exposing the actual IP address of the back-end server is good for debugging, but really, really bad if the point of using anycast is to protect from attacks. You only want to expose an identifier thats only useful in-house. )
I believe that there is an anycast tutorial or session in Chicago, if anyone wants to weigh in.
I'll be there. --==-- Bruce.