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.

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.

                                                                                
                                - Kevin




-----Original Message-----
From: Mark Andrews [mailto:ma...@isc.org] 
Sent: Thursday, August 04, 2016 7:47 PM
To: Darcy Kevin (FCA)
Cc: bind-users@lists.isc.org
Subject: Re: change response cache ttl (--enable-cache-ttl)


In message <de89e87d93dc4c7dad81bcc0ddae3...@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 
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: ma...@isc.org
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to