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

[SUKMOON LEE]

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