North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Slashdot: Providers Ignoring DNS TTL?
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
|