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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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>


[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]