minimum cache times?

Rob Austein sra at isc.org
Tue Oct 5 14:36:27 UTC 2010


At Tue, 5 Oct 2010 09:19:49 -0400, Atkins, Brian (GD/VA-NSOC) wrote:
> 
> I asked a similar question 2 weeks ago and got a non-response (e.g., a
> response with no real information).
> 
> From what I've read, everyone seems to frown on over-riding cache times,
> but I haven't seen any specifics as to why it's bad.

Because it's a protocol violation, deliberately ignores the cache time
set by the owner of the data, and is dangerous.

Eg, you ask me for the address of my web server.  I answer, saying
that the answer is good for a week, after which you need to ask again
because I might have changed something.  You override the TTL time and
cache the data for two weeks.  Meanwhile, I start the process of
moving my server to a different address.  Protocol says I have to wait
the time I set in the TTL, then I can assume that all cached copies of
the old data are dead, at which point it's safe for me to kill the old
address.  But you're ignoring the TTL.  So I go ahead and move my
server, your users still see your past-expiration copy of the old
address, can't reach my server, and my help desk phone starts ringing.
Your fault, but I pay for it, because you violated the protocol.

The above is a simple example.  For some real fun, throw DNSSEC into
the mix and think about signature expiration times.

"min-ttl" is a really bad idea.  I first saw it proposed in the late
'80s.  It was a bad idea then, and it's still a bad idea now.  Every
few years somebody exhumes it, it lurches, undead, into some patch
set, and we replay this discussion again.  Most likely the reason you
didn't get an immediate response is simply that playing whack-a-zombie
gets old after the first decade or so.

The TTL mechanism is part of the protocol for a reason: it's to
control how tightly consistent the data are supposed to be in the
opinion of the publisher of the data.  Nobody but the publisher of the
data has enough information to know how long it's safe to keep the
data.  Some publishers make silly decisions about this setting, which
causes other problems, but keeping data past its expiration time is
not the answer.



More information about the bind-users mailing list