nanog mailing list archives
Re: Slashdot: Providers Ignoring DNS TTL?
From: Steve Gibbard <scg () gibbard org>
Date: Wed, 20 Apr 2005 12:26:33 -0700 (PDT)
On Wed, 20 Apr 2005 sthaug () 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 someof 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
Current thread:
- Re: Slashdot: Providers Ignoring DNS TTL?, (continued)
- Re: Slashdot: Providers Ignoring DNS TTL? Chris Adams (Apr 20)
- Re: Slashdot: Providers Ignoring DNS TTL? Valdis . Kletnieks (Apr 20)
- Re: Slashdot: Providers Ignoring DNS TTL? Dean Anderson (Apr 22)
- Re: Slashdot: Providers Ignoring DNS TTL? Stephen J. Wilcox (Apr 20)
- Re: Slashdot: Providers Ignoring DNS TTL? Dean Anderson (Apr 22)
- Re: Slashdot: Providers Ignoring DNS TTL? Stephen J. Wilcox (Apr 23)
- Re: Slashdot: Providers Ignoring DNS TTL? Crist Clark (Apr 20)
- Re: Slashdot: Providers Ignoring DNS TTL? Dean Anderson (Apr 20)
- Re: Slashdot: Providers Ignoring DNS TTL? Patrick W. Gilmore (Apr 20)
- Re: Slashdot: Providers Ignoring DNS TTL? sthaug (Apr 20)
- Re: Slashdot: Providers Ignoring DNS TTL? Steve Gibbard (Apr 20)
- Re: Slashdot: Providers Ignoring DNS TTL? sthaug (Apr 20)
- Re: Slashdot: Providers Ignoring DNS TTL? Dean Anderson (Apr 20)
- Re: Slashdot: Providers Ignoring DNS TTL? Patrick W. Gilmore (Apr 20)
- Re: Slashdot: Providers Ignoring DNS TTL? Dean Anderson (Apr 22)
- Re: Slashdot: Providers Ignoring DNS TTL? Christopher L. Morrow (Apr 22)
- Re: Slashdot: Providers Ignoring DNS TTL? Steve Gibbard (Apr 22)
- Re: Slashdot: Providers Ignoring DNS TTL? PPLB is not a good thing Robert M. Enger (Apr 23)
- Re: Slashdot: Providers Ignoring DNS TTL? Patrick W. Gilmore (Apr 22)
- Re: Slashdot: Providers Ignoring DNS TTL? Dean Anderson (Apr 22)
- Re: Slashdot: Providers Ignoring DNS TTL? Patrick W. Gilmore (Apr 22)