possible ORG problems, maybe?

Thu Oct 16 15:25:52 UTC 2003

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.