Slashdot: Providers Ignoring DNS TTL?

Wed Apr 20 09:28:44 UTC 2005

I'd rather expect this sort of behavior with anycasted servers... 

With a cache, the behavior is confusing, but also harms DNS TCP support, 
just like that described for authoritative servers.

Further there isn't a good reason to have anycasted caches. Indeed, with
DHCP-learned nameservers, there is negative reasons to have anycast.  
Anycast balancing will never be as good as random selection from the 
appropriate set given by DHCP.

Frequently, [judging by the questions asked on DNSOP about setting up
anycast caches, anyway], the goal of such gyration is high availability.  
However, its [been] fairly easilly shown that this goal isn't achieved.

		--Dean

On Tue, 19 Apr 2005, Crist Clark wrote:

> FWIW, I did some 'dig'ing on my Comcast home service. The DHCP is handing
> out 204.127.198.4 and 63.240.76.4 for DNS at the moment.
> 
> I ran a query for a name in a zone I control that has a five minute TTL
> on 204.127.198.4. The first query came up with 5 minutes. I quickly made
> a change to the zone. hirty seconds after the initial query, I try again...
> err... and come up with the change. Hmm... Not caching at all? Another
> 30 seconds and I get the change, with 5m TTL. Thirty seconds later, I
> get the original response with appropriately decremented TTL. Another
> thirty seconds, I get the change, with 4m TTL.
> 
> My findings: Comcast is now using some kind of load balancing that messes
> with this kind of testing. 204.127.198.4 is not a single resolver. However,
> as far as I could tell, they were obeying the TTL. After 5 minutes, all
> of the responses were coming back with the change. The TTL values in the
> responses were decrementing as expected.
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   