Limiting memory usage

[Mark_Andrews at isc.org]

> bert hubert <ahu at ds9a.nl> wrote:
> > In article <aa5n2v$1hj at pub3.rc.vix.com>, phn at icke-reklam.ipsec.nu wrote:
> 
> >> I don't think you can (in a reasonable way) limit a nameservers
> >> memory hunger. It's a function of the clients usage and TTL values
> >> set in the RR.  Trying to enforce lower TTL will break the
> >> original RR-publishers suggestion.
> 
> > DJBDNS dnscache does this just fine. You tell it how much memory it should
> > use and it uses exactly that, dropping old entries to store new ones.
> 
> 
> A nameserver is _supposed_ to cache data up to the time given
> in the original TTL. By silently truncationg the cache it breaks
> the function it's supposed to do.

	A nameserver in supposed to cache a RRset *no longer* than
	the ttl.  It's quite alright (though it defeats the purpose
	slightly) to remove the record early.

	All versions of BIND have deleted records earlier than the
	TTL (max-cache-ttl/MAX_CACHE_TTL).  No nameserver should
	blindly honour the received ttls.

	BIND 9.2 has max-cache-size which causes RRsets to be
	randomly removed from the cache once this limit is reached.

> 
> But noone have ever accused djbdns to follow any standards (but db's )

	It's not a error to timeout RRsets early.  There are lots
	of things I disagree about with djbdns but removing RRsets
	early is not one of them.

	Mark

> > Regards,
> 
> > bert
> 
> > -- 
> > http://www.PowerDNS.com/pdns  Try our new database driven nameserver! 
> > http://www.tk                               the dot in .tk
> > http://lartc.org            Linux Advanced Routing & Traffic Control HOWTO
> 
> 
> -- 
> Peter Håkanson         
>         IPSec  Sverige      (At the Riverside of Gothenburg, home of Volvo)
>            Sorry about my e-mail address, but i'm trying to keep spam out.
> 	   Remove "icke-reklam" and it works.
> 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org