Is asychronous DNS lookup worth keeping at all?

Eric S. Raymond esr at thyrsus.com
Tue Dec 1 22:26:58 UTC 2015


Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at snark.thyrsus.com said:
> > Is asychronous DNS lookup worth keeping at all?  It's costly in code
> > complexity and dependencies.  I've been thinking about how it affects
> > performance and I'm now doubting that it is effective  in modern conditions.
> 
> I think that is premature.
> 
> I can't put my finger on a good example, but the use-case space is huge.  I 
> think there is too high a chance that we haven't considered an important case 
> yet.
> 
> There is a lot of interest in getting servers restarted quickly.  Telling all 
> those users they can't use any non-local server names seems unwise.

That's not the implication.  If we removed asynchronous lookup, they'd
only incur an additional initial start time cost for using *more than
one* named server.  The cost for using just one wouldn't change.

> How evil are the dependencies?  How many environments don't have pthreads?

pthreads is it, basically.  But we know that has some odd interactions with
memlock, so there'd be a little more gain than the usual from removing a
library dependency.

> Most installations should be using the pool mechanism, but the distros aren't 
> shipping that yet.  They are shipping an old version of ntp classic (with 
> locally applied security fixes) where the pool code didn't quite work.  They 
> use the pool via server directives in ntp.conf.  You see things like:
>   server 0.fedora.pool.ntp.org iburst
>   server 1.fedora.pool.ntp.org iburst
>   server 2.fedora.pool.ntp.org iburst
>   server 3.fedora.pool.ntp.org iburst
> 
> The pool code is likely to do more than one DNS lookup.  It may take more 
> than one DNS lookup (with a TTL timeout in between) to get enough servers.  
> After startup, if a server stops responding, the pool code drops it and uses 
> DNS to find a replacement.

OK, that's a showstopper for removing the asynch lookup then. I
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>


More information about the devel mailing list