On Sun, 2005-01-16 at 23:47 -0500, Dan Williams wrote: > 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(). > The number and percentage of name resolution requests that fail because the name servers were changed IN THE MIDDLE OF the query is, statistically, zero. Or so close to it as to make the difference irrelevant. In whatever tiny, minuscule fraction of cases this would actually be a problem, I'll note that this problem has always existed on Linux and on Windows as well. Any time you change the nameservers, whatever queries you had in process would time out waiting for the old nameservers, or return a value (correct or incorrect) from the old nameservers. In- process queries have never yet, in any OS in which I have personal experience, magically caught a nameserver change in mid-query. Furthermore, I submit that such an ability to change direction in midair is not important. Desirable, yes. Important, not at all! It is CERTAINLY not a reason to install BIND on all desktops. Bloat, increased resource requirements, increased security risk, slower system response, pick your reasons... all of these are applicable and true to some degree. Something is *VERY* wrong if you need to install BIND on a desktop just to switch from home to office networks, and if you do this just to save the case where a DNS query times out because the nameserver info was changed. This is *not* a good move, guys... no no no no no. Dan, you have done amazing work with NetworkManager and it's moving forward very well; but this idea is a mistake! Pure and simple. > 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. > I use a Linux notebook as my primary work machine, and I move between four or five different networks every day. I think I have approximately one DNS query time out due to changed nameserver or network information about once or twice a month. And for this, you want to require BIND??? 10% of the time for 10% of the users is *ridiculously* high. If, in a month, I work only 8 hours a day (ha!) for 22 days, that's 10,560 minutes. And if this happened ONCE A DAY and I lost a WHOLE MINUTE, then I'd be losing 22 minutes a month or 0.2% of the time. And I doubt like hell that 10% of the users move around as much as I do. There must, repeat must, be a better simpler easier way. Or you might need to accept the status quo that historically in-process queries *aren't* smart enough to see a change in nameservers, and that this single query will time out. > 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. > This cure is worse than the disease. Substantially so. Cheers, and keep up the good work! -- Rodolfo J. Paiz <rpaiz@xxxxxxxxxxxxxx>