Slashdot: Providers Ignoring DNS TTL?

Wed Apr 20 16:54:07 UTC 2005

Dean Anderson wrote:
> I'd rather expect this sort of behavior with anycasted servers... 

I would not expect this kind of behavior from an anycasted address.
You'd need a LOT of routing churn to see different caches every few
seconds. It's much more likely some kind of load balancer in front
of a DNS server farm.

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

I verified it wasn't anycast by trying to exploit this very issue. I
did a query that fell back to TCP while doing multiple small queries.
I ran a network capture to pick out the short quries that occurred while
the TCP query was going on. Short quries during the TCP connection
came back with verying TTLs indicating that I was talking to different
caches, i.e. different servers. Yet the TCP query continued without
any hiccups. This indicates there is some type of per-session load
balancing going on, not anycast routing.

> 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.

Since this isn't anycast routing, can we save the religious diatribes
for another thread?

> 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.
>>
> 
> 

-- 
Crist J. Clark                               crist.clark at globalstar.com
Globalstar Communications                                (408) 933-4387

The information contained in this e-mail message is confidential,
intended only for the use of the individual or entity named above.
If the reader of this e-mail is not the intended recipient, or the
employee or agent responsible to deliver it to the intended recipient,
you are hereby notified that any review, dissemination, distribution or
copying of this communication is strictly prohibited.  If you have
received this e-mail in error, please contact postmaster at globalstar.com