At Tue, 5 Oct 2010 10:45:04 -0400, Nicholas Wheeler wrote: > > 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).
max-ttl is (very) different from min-ttl. max-ttl might (or might not) be a waste of bandwidth, but it can't be a violation of the protocol, because nobody can require you to cache at all, or to preserve your cache across reboots, etc. max-ttl has been around since at least, um, 1985, when I implemented it in a non-BIND iterative resolver to cope with the 99999999 TTLs that we were receiving from certain badly configured authoritative nameservers. It's not something to use blindly, but it's definitely legal, and is sometimes necessary. The trick with max-ttl is to set it to a sane value for your situation. Eg, an iterative resolver associated with a busy MTA might use a max-ttl setting equal to half of the MTA's queue lifetime, to insure that it tried looking for an updated MX RR at least once before giving up on a message. _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
