4 ms·
The main issue with using DNS for failover is that the name servers of many major ISPs don't respect TTL values, particularly those under 3600 seconds. I've se
by andrewtj 16y ago
The main issue with using DNS for failover is that the name servers of many major ISPs don't respect TTL values, particularly those under 3600 seconds.
I've seen this repeated in many places but never with any concrete examples. This leads me to wonder just how widespread the practice is — can you substantiate the claim?
- abthomson 16y agoI don't know much about ISP DNS configurations, but the problem extends to clients as well. For example, until Java 1.6, the default TTL for DNS lookups was forever.
- andrewtj 16y agoThat's beyond the scope of my question — my concern is solely resolvers extending TTLs.
- forkqueue 16y agoTwo examples I've seen recently are Road Runner in the US and Virgin Media in the UK. There are many, many more.
- andrewtj 16y agoJust to be totally clear — you've explicitly done a lookup against their resolvers for a record that is not in flux and received a TTL higher than what the authoritative servers give out? Any chance you could post their name server addresses?
- forkqueue 16y agoNo, I've altered DNS and seen many thousands of connections continuing from these providers even after low value (300) TTL records have been changed several hours previously. I've observed this on a number of occasions. In the case of Virgin Media, they have transparent proxy caching on some parts of the network I believe, so it's possible this caching was happening there rather than on the DNS servers themselves.
- tricknik 16y agoWell, not much that can be done about caching proxies. Regarding DNS, have you been able to look at whether the IP's from failed requests show up on the new IP shortly after? I.E perhaps browser-pinning from open sessions?