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