So, fix the TTLs on the RBLs, sheesh! Pathological use cases don't warrant
deviation from standard.
- Kevin
-----Original Message-----
From: Reindl Harald [mailto:[email protected]]
Sent: Thursday, August 04, 2016 2:32 PM
To: Darcy Kevin (FCA); [email protected]
Subject: Re: change response cache ttl (--enable-cache-ttl)
Am 04.08.2016 um 20:27 schrieb Darcy Kevin (FCA):
> "many client have caused a burst DNS traffic" is not much of a problem
> statement, honestly.
>
> What does this patch add, of value, that isn't already covered by
> "max-cache-ttl"?
>
> If you're trying to allow the operators of intermediate resolvers to override
> the intentions of the data owner, by enforcing a *minimum* TTL, then I have
> to say that's a really bad idea. The data owner sets their TTL for a reason,
> and if it's low, it's probably because the infrastructure is very dynamic.
> Forcing data to be kept after the data owners' TTL, risks keeping "stale"
> data in the client, and this will likely have a negative impact on the user
> experience. It might even have security implications, because maybe that
> resource (e.g. IP address) isn't trusted any more. You don't want clients
> connecting to an untrusted resource, do you? Who would have legal or criminal
> liability, if that happened?
no, it is not by definition, it depends as always on the use-case
on a public MX (inbound mail) hence most people are using unbound instead of
named because it *has* such a setting to overcome the sort TTL of 5 secods from
many RBL's and if your resolver has a specific usecase on a specific workload
it's clearly OK to set this to 60 seconds or so
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
