Caching only servers

[Kevin Darcy]

I'm not sure what you mean by "overwritten by the zone file values". Do you
mean the contents of the SOA record? The only effect that that has on caching
is in the form of a negative caching TTL, and implementations are free to
pre-expire negative caching entries just as they can pre-expire regular cache
entries.

Whether a 2-hour max-cache-ttl is appropriate is hard to answer without knowing
your DNS clients' query profile. If, for example, many of the records that get
into your cache have a TTL of 2 hours or less, then the value of setting
max-cache-ttl to 2 hours is reduced commensurately, because they won't even be
hitting the cap. If, to take another example, a lot of your clients are
cyclically querying a particular name every 125 minutes, and assuming the TTL
on the relevant records is significantly longer than that, then with a 2-hour
max-cache-ttl you're going to take a hit because you'll be resolving the name
"from scratch" -- which is more expensive overall -- much of the time instead
of just answering from cache. Where a small TTL cap will gain you a lot of
memory conservation, without severely penalizing query latency or CPU usage, is
if you're getting relatively-infrequent queries for a wide range of names whose
records have long TTLs. In that scenario, the TTL cap will flush out records
that aren't helping you much anyway and maybe as a result your box won't need
to swap and/or page as much.

The long term solution, of course, is to get the extra memory installed.


- Kevin

"Georgeson, Evan [NCSUS Non J&J]" wrote:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Kevin,
>
>         Sounds good, will do. The very last question I have on this is...the
> options max-cache ttl and max-ncache ttl are both overwritten by the
> zone file values. Does adjusting these really have a noticable
> impact? Note: my previous max-ncache ttl value was 1 day, I've since
> changed that to 1 hour. Would the max-cache value of 2 hrs be
> appropriate in your opinion (absolute last question...unless your
> response inspires me.)? Thanks again for your advice.
>
> - -----Original Message-----
> From: Kevin Darcy [mailto:kcd at daimlerchrysler.com]
> Sent: Tuesday, July 16, 2002 8:49 PM
> To: bind-users at isc.org
> Subject: Re: Caching only servers
>
> If you're that short of memory, then it's going to be a narrow margin
> between being too aggressive and keeping too much data resident, on
> the one hand, plus hitting up the CPU all the time to do cleaning,
> versus, on the other hand, not cleaning aggressively enough and
> having your virtual memory fill up with unused or little-used cache.
> You could play with it and try to hit the "sweet spot" between those
> 2 extremes. You could also try playing with max-cache-ttl (the evil
> twin of max-ncache-ttl), which will give your nameserver more
> cleaning opportunities, at the expense, of course, of increasing
> query latency times for data that were cleaned out of the cache
> prematurely.
>
> - - Kevin
>
> "Georgeson, Evan [NCSUS Non J&J]" wrote:
>
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Thanks Kevin...I've since uncovered these wonderful little tidbits.
> >  See, we use QIP and in so doing we have some systems with ISC BIND
> >  with the majority using Lucent-BIND. Now, 2 weeks ago our
> > deployment  dept removed 9.1.3 and went to Lucent-BIND. These
> > serving problems  just started last week so I suspect
> > this...considering our caching  servers only have, don't laugh, 256
> > MB of RAM (my laptop has 512!) I  believe the Lucent BIND added
> > some memory overhead that pushed an  already overtaxed system(s)
> > over the edge. Today we've since reverted  to 9.1.3. We will be
> > adding more memory, of course, but do you think  that there is any
> > reason to re-visit my cleaning-interval? Do you have  a suggestion
> > on a new value? Also, is there a Lucent-BIND support  group similar
> > to this? Thank you again for your time and advice.
> >
> > Evan
> >
> > - -----Original Message-----
> > From: Kevin Darcy [mailto:kcd at daimlerchrysler.com]
> > Sent: Tuesday, July 16, 2002 5:19 PM
> > To: BIND Users (bind-users at isc.org)
> > Subject: Re: Caching only servers
> >
> > "Georgeson, Evan [NCSUS Non J&J]" wrote:
> >
> > >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Hi,
> > >
> > >         I'm suffering some bizarre symptoms on my two cache
> > > servers.   For some reason, they stop servicing internal requests
> > > and then restart after a few minutes. Could there be a load
> > > issue?
> >
> > Yes :-)
> >
> > > I'm going to give
> > > you a list of the named.conf options can I get someone to check
> > > them   for validity and confirm correct or no?? Thank you very
> > > much if you   can help or advise.
> >
> > Your cleaning-interval is set to 4 minutes. That seems a little
> > rabid.  Did you increase the frequency to try to keep your memory
> > usage down?  If you have sufficient memory, I'd relax the cleaning
> > interval. By  touching your memory pages this frequently, you may
> > be forcing them to  be resident more often and actually *hurting*
> > your memory situation.
> >
> > > Also, is it logged when nslookup queries return nxdomain or
> > > servfail,  e.g., queries.log??
> >
> > No, I do not believe this is available in the query log.
> >
> > NXDOMAIN is a fairly routine reponse code; clients ask for
> > non-existent names all of the time (especially when they are
> > configured with searchlists, grrrrr....)
> >
> > SERVFAIL is not so common, but in general, whatever is causing the
> > SERVFAIL condition is being logged by your nameserver in some other
> >  way. Unfortunately, there are many different things which can give
> >  rise to a SERVFAIL -- it's kind of a catch-all category.
> >
> > You can try turning up the logging for various categories and/or
> > turning on debugging, if you want more information on these
> > conditions, but be aware that this will drive up your resource
> > consumption, which you may not want to do at this time.
> >
> > - - Kevin
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: PGP 7.1
> >
> > iQA/AwUBPTSirmcmEMqSL6AwEQLoDwCeKrL/8OI/ZhooWvgKMU4judIoUmcAoPRq
> > AeYE+efm9Mkvg55imC9kCJSe
> > =U/mb
> > -----END PGP SIGNATURE-----
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 7.1
>
> iQA/AwUBPTTCzWcmEMqSL6AwEQKjKACfYxIGviCNpWD0dkZ9x/G3QUa/dnwAn3qF
> uFTTu4ZL5xUSENN8E5Dz7STN
> =kexJ
> -----END PGP SIGNATURE-----