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