> > In message <f6a85647247a48639aaa40cb86b42...@mxph4chrw.fgremc.it>, "Darcy > Kevin (FCA)" > writes: > > 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.
Thanks for answer. I think that a prefetch cache is a good idea. A prefetch cache will be update a cache TTL. So it is split to a client query. But I find a prefetch option over BIND 9.10. BIND 9.9 is not found prefetch option. Under BIND 9.10, I will test to do it. (prefetch vs --enable-cache-ttl) Sukmoon Lee > > > - 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 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: ma...@isc.org > > _______________________________________________ > > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > > unsubscribe from t his list > > > > bind-users mailing list > > bind-users@lists.isc.org > > https://lists.isc.org/mailman/listinfo/bind-users > -- > 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 _______________________________________________ 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