change response cache ttl (--enable-cache-ttl)

[Darcy Kevin (FCA)]

So, fix the TTLs on the RBLs, sheesh! Pathological use cases don't warrant deviation from standard.

									- Kevin


-----Original Message-----
From: Reindl Harald [mailto:h.reindl at thelounge.net] 
Sent: Thursday, August 04, 2016 2:32 PM
To: Darcy Kevin (FCA); bind-users at lists.isc.org
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