Minor improvement suggestion for pool DNS selection

Right now, 2.*.pool.ntp.org domains sometimes return both IPv4 and IPv6 addresses of the same server. I realize the internal implementation is nearly entirely name-agnostic, but it would be spiffy if this were avoided as NTP clients will treat the two as distinct sources when they obviously are not. Two options come to mind.

My first thought was to carry any given available DNS name along with the IP address in the per-server record, so the DNS selection code could explicitly avoid returning IPv4 and IPv6 addresses derived from the same hostname. Equally effective, and perhaps more efficient, would be to carry the other-IP-family address with each server entry, so that the DNS code could avoid including in a single response a record whose other-family address has already been included. Given we’re unlikely to have a successor to IPv6 in our lifetimes, this could be further optimized to carry only IPv4-equivalent addresses with IPv6 server records, assuming the DNS code continues to select IPv4 responses first, as it would mean only 32 bits of additional data per server entry.

This may not be architecturally clean as I gather the geodns code is intended to be general-purpose despite being developed as part of the pool code, but that depends on interface details I’m unfamiliar with.

2 Likes

The following configuration is also possible: two distinct servers each with single IP address family, one with IPv4 only the other one with IPv6 only, but covered under the same domain name.

In this context, “address family” refers to IPv6 vs. IPv4, so strike “with a single IP address family”.

Clearly, one could have two distinct servers sharing a hostname. It’s still likely a win to not include both in a single DNS response, as even if they’re different servers they’re more likely to be on the same IP route from the client, so less diversity. Even if they’re not, the impact of avoiding including both in a given response is negligible.

There is a script for detecting duplicated addresses of NTP servers by checking the NTP fields without any assumptions about hostnames:

The pool system could repeatedly run this on all servers per pool account and avoid giving duplicated addresses in one DNS response.

There is also a question whether duplicated addresses should split the server speed settings. Some servers seem to have many addresses in the pool. I suspect the owners do this to get more traffic. In the current data I see a server which has 1 IPv4 address and 12 IPv6 addresses!

1 Like

Nice. Which fields? I’m guessing reference time, but a quick glance over the code and I’m still wondering.

The fields are version, stratum, precision, reference ID, and reference timestamp.

There’s a fundamental problem with this idea: DNS requests for IPv4 and IPv6 addresses are separate. A typical client will make one request for records of type “A” at 2.pool.ntp.org, and a second request for records of type “AAAA” at the same name. Either or both of these requests might be satisfied by an intermediate caching resolver, and they might not even end up being handled by the same authoritative server. This makes it close to impossible for an authoritative server to ensure that any particular client doesn’t get the same NTP server in both address families.

I can think of a couple of ways that an authoritative DNS server could work around this problem, but they’re nasty hacks and probably not a good idea, especially in the presence of NTP clients that re-resolve names occasionally.

1 Like

Not necessarily:

;; QUESTION SECTION:
;2.pool.ntp.org.                        IN      ANY

;; ANSWER SECTION:
2.pool.ntp.org.         130     IN      A       162.159.200.123
2.pool.ntp.org.         130     IN      A       85.220.190.246
2.pool.ntp.org.         130     IN      A       81.172.225.142
2.pool.ntp.org.         130     IN      A       89.111.47.130
2.pool.ntp.org.         130     IN      MX      0 .
2.pool.ntp.org.         130     IN      AAAA    2a01:b2e0:2::61
2.pool.ntp.org.         130     IN      AAAA    2a10:8247:0:1013::11
2.pool.ntp.org.         130     IN      AAAA    2001:770:101::2
2.pool.ntp.org.         130     IN      AAAA    2001:41d0:700:49bc::6

True.

Perfection isn’t a requirement here, but anything to reduce the odds a given client will associate twice with the same server improves pool client timekeeping. Don’t let the perfect be the enemy of the better.

One man’s nasty hack is another’s clever fine-tuning. I don’t know the GeoDNS code enough to judge, but this might be straightforward (if a given server hands out the same selection to every auth query for a period of time).

1 Like

Good point: the entire Pool system is kind of probabilistic anyway, so doing things to sway the probabilities is quite reasonable.

(Personally, I think deduplication would be best done by the NTP client, which can see the reference ID and timestamp for all its servers anyway, but that’s not a strong reason not to do it elsewhere as well.)

I agree. If Harlan Stenn finally resumes releasing ntp-dev builds each day there are fixes, I have work in progress to automatically refine pool server selection based on the actual quality of service measured by the client that I’d like to get merged with over a year’s intervening changes and out for wider testing.

Along the same lines, I would love to see the pool monitoring switched to using ntpd to do the actual monitoring, rather than custom SNTP code. That’s a non-trivial project and my plate is still overflowing with just ntpd maintenance, however.

4 Likes

Hey @davehart ,
Interesting suggestion… Avoiding duplicate IPv4/IPv6 entries could definitely streamline client operations… hope the team considers it for future updates.