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

Mark Andrews marka at
Thu Aug 4 23:47:00 UTC 2016

In message <de89e87d93dc4c7dad81bcc0ddae343d at>, "Darcy Kevin (FCA)" writes:
> "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?
> 						- Kevin

The problem is when you have a million clients each with a local
cache they all expire the record simultaniously and if it is a
popular address then you get a million DNS queries in the second
after the ttl has expired as all those local caches refresh.

This is a attempt to distribute the query load from those caches
uniformly rather than have a peak load every ttl seconds.

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at

More information about the bind-users mailing list