Slashdot: Providers Ignoring DNS TTL?

Steve Gibbard scg at gibbard.org
Wed Apr 20 19:26:33 UTC 2005


On Wed, 20 Apr 2005 sthaug at nethelp.no wrote:

> Our recursive name service, using anycast servers, is setup with 3
> name servers at 3 different physical locations, with each server
> connected to a router at the same physical location. Each server
> handles two different anycast addresses. There is no per-packet load
> balancing involved.
>
> I can't speak for the rest of the net, of course - but our recursive
> anycast service has worked well for several years.

While that setup may have worked well, it's not an anycast implementation 
I would suggest that others follow.  Having the same set of servers 
announcing multiple IP addresses (assuming those addresses are both in the 
same set of addresses given out to those doing dns lookups) leaves you 
open to a failure mode where a single server stops responding to queries 
but doesn't withdraw its routing announcement.  If a user sees that server 
as the closest instance of both DNS server IP addresses, they will see 
that as a failure of "both" of their DNS servers.

A more reliable way of doing this is to have multiple anycast clouds with 
their own servers, each serving a single service address.  That way, an 
incomplete failure (on query response but no route withdrawl) of a local 
server for one service address won't have any effect on access to the 
second service address.

I should note that what I describe as an "incomplete failure" here is the 
standard failure mode for non-anycasted servers, so this isn't a new 
problem created by anycast.

In the case of the roots, there are 13 of those "clouds," although some
of those clouds still consist of just a single server.  For less critical 
infrastructure, like an ISP's local recursive name service, a considerably 
smaller number of clouds should be just fine.

-Steve



More information about the NANOG mailing list