[time] ntpd 4.2.7 DNS and the pool
Sun Feb 7 21:28:29 UTC 2010
The 4.2.7 (ntp-dev) releases of ntpd have gutted the old "intres"
forked resolver code in favor of a replacement implementation that is
more functional. The prior implementation was able to resolve
hostnames without blocking ntpd's main I/O loop only when looking for
a single IP address (so not for the "pool" command), and only when
initially reading ntp.conf (so ntpq -c ":config server pool.ntp.org"
would result in blocking the I/O loop as long as the pool.ntp.org
lookup required). Now ntpd can resolve hostnames at any time it wants
and get multiple addresses for each.
The next steps are both relevant to pool.ntp.org time server operators:
1. Re-resolve hostnames at some interval to (at least grossly) honor
DNS TTLs and pick up on IP address changes.
2. Implement the "pool" directive as envisioned, which is to say,
very much along the lines of "manycastclient" If you haven't played
around with manycast/manycastclient, I encourage you to check it out.
You do need to configure a symmetric key (MD5 typically) to
authenticate the servers to the clients and have it installed on all
clients and servers involved. The beauty of the scheme is all clients
and most/all servers can use manycastclient to automatically discover
and use servers via multicast solicitations from the clients and
unicast responses from listening servers. Notably, servers
automatically age out and new servers are added without restarting
The issues are related because currently the implementation of ntpd
doesn't keep track of hostnames at all -- they are resolved to a
single numeric addresses which are used in the "struct peer" held for
The first part should be relatively straightforward, but there are
still decisions to be made. In particular, once these changes are in
place, I would expect those using "server *.pool.ntp.org" in ntp.conf
would most often see the association switch to a new IP address nearly
every time ntpd re-resolves the hostnaame, assuming no overlap between
the initial set of addresses returned and the re-query results. Also,
it is not yet clear to me if Dr. Mills will want association IDs to
change with each address change, or if we will be reusing the same
association ID for multiple addresses over time resolved from the same
name. When this is done, I would expect one currently-working
configuration to be degraded:
Once ntpd is keeping hostnames around I would expect duplicates to be
ignored. Using 0.pool.ntp.org and 1.pool.ntp.org etc would still
operate essentially the same.
The pool directive is more interesting. Conceptually there's a good
model to follow in the manycast server discovery scheme. Presumably
there would be a persistent, configured "pool client" association
responsible for spinning off DNS queries and mobilizing ephemeral
associations as required. It's not clear to me if the ephemeral
associations would have any record of the "parent" association. I
think currently for manycastclient, they don't, as there's no need.
The manycastclient code will not spin up additional associations once
maxclock is reached, and the decision to demobilize ephemeral
associations does not care about how the association was spun up. At
least initially, as with manycastclient, there will not be
fine-grained control to say, for example, use up to 5 servers from
us.pool.ntp.org and 3 servers from europe.pool.ntp.org. Instead,
there is a single "maxclock" knob which limits the sum of configured
and ephemeral associations. I suspect that will be enough, at least
until someone comes up with a good reason to mix multiple automatic
server discovery schemes in one configuration with separate limits.
Is once a day often enough to re-resolve non-pool hostnames? I don't
want to create unnecessary DNS query load, and for ntpd, it seems like
re-resolving more frequently would offer little additional benefit.
Is that still too often to re-examine the addresses of working
More information about the pool