How to override too-short TTL?
Brad Knowles
brad.knowles at skynet.be
Tue Aug 21 22:04:19 UTC 2001
At 6:32 PM -0700 8/20/01, Daemeon Reiydelle wrote:
> Perhaps you would be more appreciated if you read the email and your
> reply before you hit send.
You would be likely to get answers that you find more meaningful
if you provided more information initially and did not respond in
such negative manner to the initial answers you do get.
> Unless you are the final arbiter for all things BIND, it seems that this
> may be a topic for discussion.
No, Joe isn't quite "the final arbiter for all things BIND", but
he is knowledgeable on the subject, and I would rate him as probably
one of the top ten or even top five most knowledgeable people on this
list.
It is not in your best interests to antagonize Joe, or the other
knowledgeable people on this list, especially when doing so serves no
good purpose.
> Is there any justification to include a minimal ttl override in
> ns_cache's storage of the data? This would override ALL TTL's, even my
> own. It seems to me that this is a good idea, since the TTL override is
> a bozo filter, even for my own bozoness (like forgetting to put a ttl
> stanza in, which I have of course NEVER done ;{)
I think you could make the argument that some minimal TTL filter
could be put in place, indeed I believe that there used to be such a
filter in the earlier versions of BIND, but has since been removed.
Certainly, there are times when you know that you're going to be
replacing a critical piece of machinery and you want to make sure
that the old record times out just as quickly as possible, and even
five minutes or even just one minute may be too long. Therefore, any
such filter would have to be configurable, over-rideable from the
command-line, and changeable via rndc once the program is already
running.
And even then, I imagine that you could very easily find yourself
getting very seriously bitten by such a thing.
--
Brad Knowles, <brad.knowles at skynet.be>
H4sICIFgXzsCA2RtYS1zaWcAPVHLbsMwDDvXX0H0kkvbfxiwVw8FCmzAzqqj1F4dy7CdBfn7
Kc6wmyGRFEnvvxiWQoCvqI7RSWTcfGXQNqCUAnfIU+AT8OZ/GCNjRVlH0bKpguJkxiITZqes
MxwpSucyDJzXxQEUe/ihgXqJXUXwD9ajB6NHonLmNrUSK9nacHQnH097szO74xFXqtlbT3il
wMsBz5cnfCR5cEmci0Rj9u/jqBbPeES1I4PeFBXPUIT1XDSOuutFXylzrQvGyboWstCoQZyP
dxX4dLx0eauFe1x9puhoi0Ao1omEJo+BZ6XLVNaVpWiKekxN0VK2VMpmAy+Bk7ZV4SO+p1L/
uErNRS/qH2iFU+iNOtbcmVt9N16lfF7tLv9FXNj8AiyNcOi1AQAA
More information about the bind-users
mailing list