Is asychronous DNS lookup worth keeping at all?

[Joel Sherrill]

I agree with Hal for his reasons and another.

If this is the worker threads, then we should wait for Chris to comment.
He has a simpler replacement in the queue and just needs to debug
it AFAIK.

Plus this could be a feature plus over Classic.

On Tue, Dec 1, 2015 at 2:45 PM, Hal Murray <hmurray at megapathdsl.net> wrote:

>
> 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.
>
> I'd like to be able to do things like have the pool code occasionally
> verify
> that the servers it is using are still in the pool.  The idea is to help
> people remove their servers from the pool.  (The pool DNS side doesn't
> support that check yet.)
>
> I think the code complexity will improve a lot when Joel rewrites that
> area.
> The wart that may not be obvious is the interaction with locking everything
> into memory.  In some environments, the end-of-thread code loads another
> library module which may not fit.
>
> How evil are the dependencies?  How many environments don't have pthreads?
>
> I'd be happy to do the DNS lookups from the main thread if the environment
> doesn't support pthreads.  Or at least do it that way until we discover an
> interesting use case.
>
>
> > Nowadays, 99.9% of all NTP installations are configured to do a single
> pool
> > name lookup.  ...
>
> That's incorrect on two counts.
>
> 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.
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20151201/67d03633/attachment.html>