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

[Bill Nottingham]

Dan Williams (dcbw at redhat.com) said: 
> 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)

OK, I'd argue that this isn't a particularly relevant usage case.
How often do people really change their DNS servers *in the
middle of a lookup?*

> 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,

Nice strawman there. 

> even if it occurs 10% of the time for 10% of the users.

... which I highly doubt.

> 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.

Then that's bugs in nscd that should be fixed, not a reason to install
*bind* on all desktops. 

Bill