I think Brian's OP was about a max-ttl override ... Which is the opposite. The only disadvantages I see is a potential waste of bandwidth (and it violates the protocol).
----- Original Message ----- From: bind-users-bounces+nwheeler=devis....@lists.isc.org <bind-users-bounces+nwheeler=devis....@lists.isc.org> To: bind-users@lists.isc.org <bind-users@lists.isc.org> Sent: Tue Oct 05 10:36:27 2010 Subject: Re: minimum cache times? 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. _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
