Just a quick question:
Is there a chance that when someone configures the lines below, the DNS responses for 0.pool.ntp.org and 3.pool.ntp.org may partially overlap?
In other words, could one or more A records returned for one FQDN also be returned for the other?
server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server 3.pool.ntp.org
My understanding is that if there’s “enough” servers in the unnumbered zone, there will not be any server in more than one numbered zone. While if the zone is “too small”, there can be duplicates (i.e., servers that appear in more than one numbered zone)
Those four DNS queries are separate ones, the geoDNS server cannot associate them. There might be unknown delay in between the queries. Even, there is a chance that not one, but multiple geoDNS servers will answer them. Depending on the number of NTP servers in the zone, there is chance that the answers will overlap on some NTP servers.
Thanks.
Some background; I was playing with PowerDNS to see if it could replace GeoDNS (the answer appears to be “yes”) and than this question popped up.
Along the way I also learned that Chrony, with the pool directive configured, keeps doing DNS queries until the maxsources count has been reached. I didn’t know that.
I think that was indeed the intention with the original four numbered zones, that while clients didn’t have the pool directive yet (or some simpler ones still do not), they would still be able to obtain up to four distinct upstream servers nonetheless by configuring multiple numbered zones. At least when queried simultaneously, e.g., upon startup or restart, the responses for the different numbered zones will not overlap:
The zone files are generated and reloaded every two minutes. I.e., if the zone is big enough, queries to different numbered zones within those two minutes that a specific iteration of the zone file is loaded in the servers will always yield unique addresses across the numbered zones. Even across different GeoDNS servers, the responses will not overlap during that two minute window.
@MagicNTP’s explanation sounds correct to me.
It’d be easy enough to ensure they’d never overlap, but at the expense of “shuffling” the server IPs and evenly distributing load.
If / when I’d reimplement the DNS implementation it’d more likely be as a AtomDNS “plugin” – https://atomdns.miek.nl
I can only remember one meaningful bug in GeoDNS that affected production (missing padding in ECS responses after the drafts changed many years ago that affected people using Cloudflare DNS). There have probably been others, but very few.
The main missing feature would be to support DNSSEC, but even that mostly/only makes sense if there was a way to deploy NTS that makes sense for a widely distributed pool, I think (and then using the DNSSEC signed data in the NTS setup).
DNSSEC would be valuable also to plain NTP, not just NTS. Given the ubiquitous use of the pool, it’s a prime target for devilry.
Yes, but DNSSEC-validating devices without a battery-backed RTC run into a tricky chicken-and-egg problem during bootstrap.
Discussing this chicken-egg bootstrap issue leads away from the original topic, but I would like to know how the DNSsec resolver works? Does the resolver know that the time did not yet set, so it ignores timestamps of the DNS signature data for validation?
Normally, no. It simply cannot validate the DNSSEC signatures. Special measures would be required to circumvent this deadlock.
Once upon a time I thought this was a reason we shouldn’t add DNSSEC to the NTP Pool domains. I think since .org is signed that doesn’t really make sense anymore. A DNS server or validating client with time so off it can’t validate, wouldn’t resolve the ntp.org or ntppool.org domains either (or .dev if we put a version of the NTP Pool DNS service on ntp.dev or ntppool.dev).
Not only the org gTLD signed, but the root zone as well. But the main difference is that the domain name that client is actually looking for (i.e: 2.pool.ntp.org) is signed or not. The intermediate domains being signed or not does not really matter. Anyhow, we have to check this is very details. In a typical configuration, a client does not check for the DNS signatures, it is the task of the DNS resolver service that executes the recursion.
I think it does. A validating resolver with its clock set to 1970-01-01 would have no way to validate the root zone, .org, or anything below it.
You are right, with wrong time, the recursive DNS resolver cannot validate anything. But neither 2.pool.ntp.org, being signed or not. So the chicken-egg problem does exist without the DNS of the ntppool being signed. So, signing pool.ntp.org, ntppool.org does not make the situation worse.
Just a side note, the actual situation may not be such bad, falling back to epoch. Just an example: on my Raspberry PI, without RTC, and with raspbian version trixie, using systemd-timesyncd, the service sets the modification time of the file /var/lib/systemd/timesync/clock on each successful NTP packet reception. At boot time (no network yet), the service initialize the wall clock based on the modification time of this file.
pi@raspberrypi:~ $ date ; ls -l /var/lib/systemd/timesync/clock
Thu May 21 09:43:23 AM CEST 2026
-rw-r--r-- 1 systemd-timesync systemd-timesync 0 May 21 09:42 /var/lib/systemd/timesync/clock
pi@raspberrypi:~ $
Thanks for sharing.
Yes, this is now a fairly well understood problem. People are being inventive, but the initial bootstrap issue remains.
There’s also the FallbackNTP= option that some people use.
I do not know, did someone thought about not just saving the last wall clock, but the IP address of the last known NTP servers, for setting the time from them, if the DNS resolving is failing. I know, that would just some more tweak, with the original problem remaining, trying a bit more abstract:
You need a monolithicly increasing counter to protect security against replay attack, and you need security to protect the initialization of that counter.
The kernel knows if the time is synchronized or not. Therefore, the NTP client could ignore the lack of the AD flag in the response until the kernel time is synchronized.
I’m afraid that this works require a new NTP client option to the configuration line for the server.
This all depends on how resolving is done. I can imagine scenarios where there is no usable data in the response. So ignoring AD flag won’t do the trick.
Perhaps include CD flags with the query?
Both. Definitely something that the NTP client would have to consider.
Alas, the pool should provide rich features in order to enable rich clients. Copping out of rich features because the clients ignore it is not acceptable.