Re: [dnsop] DNS Anycast revisited

[Bruce Campbell <bc-dnsop at vicious.dropbear.id.au>]

On Mon, 28 Mar 2005, Dean Anderson wrote:

> On Mon, 28 Mar 2005, David Conrad wrote:
>
> > In my experience, shared unicast DNS provides quite a few benefits,
> > particularly in the context of ISPs or services that need to be highly
> > available, at the cost of some additional routing configuration
> > complexity.
>
> Anicast servers offer no benefits for high availability which aren't
> offered by simple failover.

Simple failover does not scale.

The traffic requirement for each nameserver is 1/number-of-listed-servers .
The traffic requirement for each (BGP) anycasted site of an anycasted
nameserver is ( 1/number-of-listed-servers ) / number-of-anycast-sites ,
several orders of magnitude lower than the non-anycasted situation.

As more anycast sites are added to a given name, the traffic requirement
per site goes down.  With simple failover, the limit is the number of
listed nameservers that can be added.  With anycast, the limit is how much
pollution you wish to add to the routing tables.

( The above is simplified, as it assumes careful placement of anycast
  sites within a non-complex mesh.  In any anycast deployment, certain
  anycast sites will receive more traffic than the above, but always less
  than 1/number-of-listed-servers . )

> Remember that anycast has two different paths
> to the same IP address, frequently in different physical locations,
> whereas simple failover has a single path to a same ethernet where there
> are two servers which can take over the same IP address.  If an anycast
> server fails, it won't respond for that packets using that path, forcing a
> lookup against a different server.

So, you're saying that in the simple failover situation, the local
administrators have configured all the checking required to detect the
failure of a given machine, and initiate the subsequent takeover ?

How is this different from the anycast site administrators configuring
checks to detect the failure of the site, and to initiate the withdrawal
of the route from that site ?

The only valid point you have in the above is that when a serious failure
occurs and the replacement/route withdrawal is done by the heartbeat
timers of the other machines/peering routers, the interval for anycast is
very likely to be greater (BGP keepalive) than for simple failover.

I will also point out that you've implied that simple failover has
TCP-state preservation, avoiding TCP session reset and clients trying
their lookup against other servers.  Preserving TCP state between machines
even at the same site is expensive juju; I would not bother doing it with
DNS as the client side will retry.

--==--
Bruce.

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html