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@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@globalstar.com