[dns-operations] Who Ignores TTLs ?

[Colm MacCárthaigh]

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
level.

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. [1] But for a java daemon, there might easily be 6 or more.
[2]

So the efficacy of GSLB can vary depending on the nature of the clients.

[1] In-browser cache, home-router cache, ISP cache
[2] 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
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>



-- 
Colm