change response cache ttl (--enable-cache-ttl)
marka at isc.org
Fri Aug 5 00:37:25 UTC 2016
In message <f6a85647247a48639aaa40cb86b42772 at mxph4chrw.fgremc.it>, "Darcy Kevin (FCA)"
> That's only a problem if the clients are constantly looking up the name,
> right? If they're looking it up only _occasionally_, with some degree of
> entropy, then the query load gets spread out.
Provided there isn't multiple caches involved.
> So, in those cases, implement something on the client side that
> pre-expires the cache entry with some degree of randomness factored in.
> Pre-expiring cache entries is entirely within the standards and the
> original concept of how DNS response caching works (since, after all,
> dumping one's cache can't be prevented if the client restarts or
> reboots). Sure, pre-expiration may result in an overall increase in query
> traffic, but it smooths out the spikes to the intermediate resolvers,
> which is what we're worried about here. In time, the data owners will
> catch on that their cache entries are being pre-expired; if they care
> about that, they'll bump up the TTLs to compensate, eventually we reach a
> point of equilibrium.
Or named reduces the ttl returned so it randomly hits in the prefetch
interval. Or add a counter to the rdataset and once so many queries
for the rdataset have been made just prefetch it. This will cause
the ttl to be renewed and desyncronise down stream caches. Or both.
> - Kevin
> -----Original Message-----
> From: Mark Andrews [mailto:marka at isc.org]
> Sent: Thursday, August 04, 2016 7:47 PM
> To: Darcy Kevin (FCA)
> Cc: bind-users at lists.isc.org
> Subject: Re: change response cache ttl (--enable-cache-ttl)
> In message <de89e87d93dc4c7dad81bcc0ddae343d at mxph4chrw.fgremc.it>, "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 expi
> re the record simultaniously and if it is a popular address then you get a million D
> NS 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 th
> an 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 isc.org
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from t
> his list
> bind-users mailing list
> bind-users at lists.isc.org
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the bind-users