Dan Williams (dcbw@xxxxxxxxxx) 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