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 ntpd. 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 each association. 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: server pool.ntp.org server pool.ntp.org server pool.ntp.org 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 associations? Cheers, Dave Hart _______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
