[dns-operations] Who Ignores TTLs ?
colm at stdlib.net
Thu Feb 17 02:34:48 UTC 2011
It depends on your definition of "caching software". Recursive
resolvers are only part of the picture.
At other layers, there are real problems. The various DNS caching
implementations in Java are probably the worst offenders. Prior to
1.6, where it was systematically fixed, many JVM implementations of
the DNS lookup APIs would cache answers indefinitely.
Other languages and implementations have had similar issues - I think
a version of Flash cached indefinitely too. The nscd family and their
equivalents have also been sources of caching staleness at the system
If you imagine a modern browser running on a home-network, there are
probably only 3 or 4 caches between you and the authoritative DNS
server.  But for a java daemon, there might easily be 6 or more.
So the efficacy of GSLB can vary depending on the nature of the clients.
 In-browser cache, home-router cache, ISP cache
 Tier one caching resolver, Tier two caching resolver,
NSCD/lwresd/lookupd/dscacheutil, JVM dns cache, JVM object
cache/memoizer, application-level cache
On Wed, Feb 16, 2011 at 6:01 PM, Simon Lyall <simon at darkmere.gen.nz> wrote:
> I keep seeing a persistent complaint that some DNS caching operators ignore
> TTLs or otherwise keep records for longer than the TTL would indicate.
> I suspect this might be an urban legend since most DNS caching software
> doesn't even offer this as an option last time I checked.
> Does anybody actually do this? Because it keep being brought up by some
> peopel as to why things like GSLB don't work.
> Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/
> "To stay awake all night adds a day to your life" - Stilgar | eMT.
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
More information about the dns-operations