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