The problem with nscd (was RE: NetworkManager & bind)

[Dan Williams]

Bill & everyone,

Here's the problem.  'nscd -i hosts' isn't adequate for all cases.  
Specifically (and you can argue about its relevance), nscd doesn't 
interrupt in-process resolution calls and return current information 
immediately.  Instead, if /etc/resolv.conf gets changed from underneath 
'nscd' and you call 'nscd -i hosts', an app like Mozilla will sit there 
until it times out because nscd is too dumb to deal with changed 
information in the middle of a gethostbyname().

For example:
1) Stick bogus information in /etc/resolv.conf
2) service nscd start
3) nscd -i hosts (to clear all previous cached hosts)
4) Fire up mozilla, "www.google.com"
	(mozilla will sit there resolving as the DNS servers are incorrect)
5) correct /etc/resolv.conf with good DNS servers
6) nscd -i hosts
7) WAIT FOREVER (15 - 20 seconds)

Using a caching nameserver, and restarting the nameserver, works 
correctly, every time, all the time.  Try getting something (/Anything/) 
past Uli, let alone something with the name resolver.

Note that killing nscd and restarting a fresh copy doesn't work either.  
Server-types and those people who don't actually use a desktop may argue 
that this delay is acceptable, but its not, even if it occurs 10% of the 
time for 10% of the users.

Furthermore, I've run into cases where just 'nscd -i hosts' is inadequate, 
as I did when I was testing to  make sure I knew what I was talking about 
here.  I had an nscd running, copied over a bogus /etc/resolv.conf, and 
did 'nscd -i hosts', but apps could still resolv names when clearly they 
should not have due to the bogus resolv.conf and the invalidated hosts 
cache.  nscd simply doesn't work well enough, caching-nameservers do.

Were these problems in nscd/glibc corrected, we'd love to switch back to 
nscd becacuse its simply less complicated, which is bonus.  But not if it 
doesn't work.

Dan

On Fri, 14 Jan 2005, Bill Nottingham wrote:

> Dan Williams (dcbw at redhat.com) said: 
> > It uses bind in a caching-nameserver functionality and named should
> > _not_ be turned on my default in this configuration.  Use of bind as a
> > caching nameserver was done to work around deficiencies of nscd and
> > glibc and should allow user applications to be aware of changes
> > to /etc/resolv.conf faster, since the applications actually just talk to
> > 127.0.0.1 for the nameserver, and its the caching-nameserver that
> > actually does the heavy lifting when /etc/resolv.conf changes since
> > glibc isn't up to the task.
> 
> Why can't this be solved with nscd and use of 'nscd -i hosts' when
> resolv.conf changes, out of curiousity?
> 
> Bill
> 
> -- 
> fedora-test-list mailing list
> fedora-test-list at redhat.com
> To unsubscribe: 
> http://www.redhat.com/mailman/listinfo/fedora-test-list
>