[SunRescue] Solaris 8 DNS?

[Greg A. Woods]

[ On Thursday, May 17, 2001 at 22:57:14 (-0700), Devin L. Ganger wrote: ]
> Subject: Re: [SunRescue] Solaris 8 DNS?
>
> On Thu, May 17, 2001 at 11:06:40PM -0500, William Barnett-Lewis wrote:
>  
> > Obviously this is a night for learning things. I'll lay myself open for
> > laughter perhaps, but I have never heard of negative caching. What I
> > would think of as caching - saving data for near future reuse - would be
> > positive, yes? So what then is negative? 

Negative caching, generally speaking, is what lets you remember that the
last time you looked for something it wasn't there so this time you
don't have to look again.  I.e. you're caching the fact that you have no
valid information to cache.  It's just a silly contraction of the phrase
"negative response caching".

> I do a hosts lookup for a host that hasn't been added to the naming service
> yet.  nscd will cache that negative result (NXDOMAIN is it's DNS, etc.) for
> some indeterminate period of time, even though the record could be added
> just a few seconds later and subsequent lookups should succeed.

You've got the basic idea right, but I think you should have said
"named", not "nscd".

A DNS zone administrator now controls the length of time a negative
response might cached by a querying nameserver with the fifth value of
the final sub-field of the SOA record, i.e. what was once used as the
"default TTL".  (The default TTL is now set with a "$TTL" directive.)

Nscd can't do negative caching, from what I understand, and that's a
real problem sometimes, especially with a busy server running many
internet services.  Often the most serious problem is with the target
nameserver getting hammered, not the server doing the hammering, of
course.  However even the server doing the querying will experience far
more erratic timeouts if the non-existant name it's trying to get is
served by a distant and/or busy nameserver.

Obviously if the information you've cached (be it a valid record or just
a negative response) might change at some time in the future then you
don't want to keep that information infinitely and so you have to have a
"time to live" on the cached information.  From what I understand nscd
also just has a fixed-length TTL for everything it caches, thus it
violates the DNS semantics for TTL.

So, all in all nscd is just too brain-dead simple to be very intelligent
about caching and it can cause real problems even in a NIS/NIS+
environment if the source data changes frequently.  For example you
probably do not ever want to run it on the NIS server itself.

I suspect Sun made nscd the default because they "knew" that there'd be
more clients out there than servers and in their idea of how clients
should be configured the presence of nscd is generally an OK thing
because it helps reduce the query load on the server.  Obviously a
server administrator should be smart enough to turn off nscd on the few
machines that don'd need it.

As for the relative stability and reliability fo nscd, well it's
implemented using an experimental facility that Sun would never have
even documented if they hadn't been forced to by their customers.  They
still say that this underlying facility may change or go away without
any warning whatsoever.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods at acm.org>     <woods at robohack.ca>
Planix, Inc. <woods at planix.com>;   Secrets of the Weird <woods at weird.com>