[ntp:hackers] Asynch resolver

Danny Mayer mayer at ntp.isc.org
Mon May 8 00:46:00 UTC 2006

Frank Kardel wrote:
> David L. Mills wrote:
>> Dany,
>> Simple. I would like the pool scheme to operate like manycast. If a
>> server falls off the wagon or just gets old, the client should honk
>> and expect a pool critter to come back. In fact, the pool management
>> algorithms now are identical to manycast with the exception that the
>> DNS resolution must come at startup. Once the best three truechimers
>> have been found, the rest are tossed away. If one of the good guys is
>> lost, there is no way to get it back. What I'd like to do is every
>> couple of hours or so, honk for a fresh one and remitigate for the
>> best three.
> Maybe it would make sense to make use of the TTL field in the A records.
> Thus we should resolve the name and refresh
> the A record according to its life time. 

You mean of course A and AAAA records. We MUST include IPv6 here.

> A refreshed and changed DNS
> translation could be used as and indication that a re-election
> round might be useful.
> Refreshing names according to TTL (where available) and updating the
> assiciations is a thing I would expect from the new asynch
> resolver code. Unfortunately there are some interfaces to resolve a
> hostname and not all provifr a TTL indication. So this may not be as
> easy as it sounds.
> Frank

Actually it's not easy at all. You are making some fundamental
assumptions here that are not correct. The only APIs that provide the
the TTL are those using the resolver library code in BIND or a similar
library. That makes a fundamental assumption that it needs to get its IP
address information from DNS. However there are other sources including
the hosts file that contain no TTL whatsoever and NIS. We are better off
leaving all that to the local resolver code, whatever that may be. We
should be leaving all of this to the resolver in the hope that it deals
with all of this correctly. If you make a DNS query and it gives you a
different answer and does not include the original value you were using,
it is better to assume that something changed including possibly the
hosts file. The resolver usually caches results until the TTL expires
(if there is one) at which point it has to make the query again so you
would normally get back the same result until the TTL expires. That this
is not always the case would almost certainly a bug in the O/S vendor's
resolver. Please also note that getaddrinfo() returns more than one
answer if there is more than one. We are currently not taking advantage
of that, to our own detriment. I'd like to see us trying one address and
if it fails try a different address in the DNS answers until it gets a
response or exhausts the list. In addition it would be nice to specify
to use more than one address on the server line as it would allow you to
take advantage of more entries in the pool without having to be too


More information about the hackers mailing list