DNS Server That Constantly Refreshes Cache?

Barry Margolin barmar at alum.mit.edu
Fri Feb 22 04:34:20 UTC 2008


In article <fpktfi$13nj$1 at sf1.isc.org>, Kevin Darcy <kcd at chrysler.com> 
wrote:

> Matus UHLAR - fantomas wrote:
> > On 18.02.08 17:52, Will wrote:
> >   
> >> I'm looking for a DNS server that will proactively go out after a cache 
> >> record expires and refresh its cache on its own.   The result would be a 
> >> server with an enormous memory cache of prefetched records, which should 
> >> always have up to date records in its cache, even when the domain has not 
> >> been used internally for weeks or months.   Note, I'm NOT referring to a 
> >> standard DNS server with a large cache setting.    I'm looking for a 
> >> proactive server behavior to prefetch records whose DNS cache is reaching 
> >> expiration.
> >>
> >> Does such a product exist for Windows or Unix?
> >>     
> >
> > this way you will end up having all dns records on the net in the cache and
> > still refresing them even if you don't need them.
> >   
> What an anti-social thing to do.
> 
> If I set the TTL of one of my RRsets to 60 seconds, it doesn't mean I 
> expect you (and everyone like you) to query it *every* 60 seconds 
> *forever*. The 60-second TTL is only for peak usage times, where 
> load-balancing/sharing is necessary. I expect the query traffic to fall 
> off during non-peak times, in parallel with the dropoff of actual 
> production volume.

If this were done adaptively it could work well.

The caching server could keep track of which records it's received 
frequent requests for.  If a record has been accessed numerous times 
since it was last cached, it would be a good idea to prefetch it.  But 
if lookups have dropped off, it shouldn't bother.

The idea is similar to disk prefetching in filesystem and virtual memory 
systems.

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***


More information about the bind-users mailing list