Many countries provide an official, legal time through their own NTP servers to be used inside their jurisdictions, oftentimes open to the general public, but sometimes only by permission (using keys). A few of such official public NTP servers are already part of the pool, some of these even by the official departments in charge of managing such NTP servers, though others likely added by rogue users. But not all countries added their official servers to the pool.
I am wondering if such official public NTP servers could be automatically added to the pool and placed ahead of other servers in the DNS replies to queries from their respective countries. I believe that this would address the dearth of NTP pool servers in some countries where there are official public NTP servers.
One assumption here is that such official public NTP servers have plenty of bandwidth to handle a whole country, which is often the case, but likely never put to the test, especially when abused by rogue implementations of NTP.
Thoughts? Were I to develop a proof of concept, would there be volunteers here interested in contributing their official or testbed public NTP servers for the experiment?
I don’t think that would be a good idea. The people running those official NTP servers are probably experts in their field, and I can’t imagine them not being aware of the NTP pool. If they haven’t added their servers to the pool themselves, there’s probably a reason.
I don’t know how the situation is elsewhere, but in .fi the official public servers are already in the pool. In some countries the servers seem to be in the pool, but in “monitoring only” mode.
The “official” servers are an interesting topic.
On the one hand, they are explicitely maintained to offer ntp for the general public. Many countries operate at least one or two. And since they are often connected to prime timing infrastructure like atomic clocks, they give very precise timing information.
On the other hand, they are already prone to be (mis)used as time servers by devices from that region. The origin of the ntp pool itself is a cautionary tale that individual ntp servers should not be oversubscribed. And what matters most to me - I don’t think it is responsible behavior to subscribe ntp servers into an automated system like the pool without explicit operator consent.
In my opinion, official ntp servers are excellent additions to the pool, and excellent time sources for the pool servers from that region. But they should not be promoted above other servers or added automatically.
I think a good project would be to contact the operators of such servers in underserved zones and ask them if they want to join the pool. They will likely have heard about the pool, but they might not be aware of the low effort and large positive impact they can make by joining it.
Also not sure the idea of automatically including official country servers would be a good and workable solution. As you mentioned the bandwidth could easily be flooded and take the server offline.
One question I have had is what is the “quality” of the DNS results that people get from countries with limited servers. For example The Philippines and Malaysia. These countries have 9 and 4 servers in the pool. When you do a DNS lookup in these countries are you just receiving the address within that country (the same 4 servers for Malaysia) or do the results include servers in the wider Asia area such as Singapore.
I have a few servers around Asia and these do regular lookups to “pool.ntp.org” from the hosting companies DNS servers plus to the big providers such as Google, Cloudflare and Quad9. I need to do something like get the NTP RTT from the location to each server returned to see if the DNS results are a good “quality” (close by) or non-good “quality”. For example in the past a DNS lookup to the pool using Cloudflare from NZ use to return server ip addresses in Argentina - poor quality results.
Just a thought
Never add servers to the pool which you do not own/operate (even automatically added)!
It’s a bad idea, with - or even worse - without permission.
As @avij and @Sebhoster said: Everyone in this segment knows about the pool or has heard about it. Making people more aware of this project would be the way to go. I.e. many universities have their own campus ntp/ptp infrastructure and some of them have already joined the pool.
Encouraging them to join the pool would be a better solution.
It is my understanding that the main point of the entire “server verification” feature, and especially the effort that went into realizing it, is to prevent just that: people adding other people’s servers.
I am not so much concerned about someone claiming, e.g., my own servers, they are too insignificant for that. Rather, I think this mainly is about the “well-known” public servers, be it companies operating them, or institutions such as national metrology institutes.
And the text on the management page above where one starts the registration process also seems rather clear about that, I guess not without a reason.
Though other parts on the site are somewhat outdated as well, e.g., still suggesting to use the server keyword rather than pool, so why not revisit the point about registering other people’s “public” servers to double-check whether it is still valid, as this thread does.
Regarding capacity of such servers, I would not draw the conclusion that they are dimensioned to “handle a whole country”, at least not in the general case. Both from the point of view of the owner publishing them, e.g., on their site, potentially assuming the “hurdle” of people having to find them there, or in places where they have been copied to, and people having to manually add them to a client’s configuration would somewhat limit the traffic that they will attract, vs. them being included in the pool and having the whole pool population, with all kinds of systems preconfigured with the pool names, hitting them.
As well as from the point of actually seeing some such public servers being in the pool, voluntarily or not, and showing the typical signs of them, or associated infrastructure, being overloaded (though not operating them myself, it’s obviously hard to diagnose precisely what is going on with them).
Forgot: Looking at old discussions, it is my understanding that the intention was that after some grace period after the introduction of the “server verification” feature, any “old” servers registered but not verified after said grace period would be “handled” somehow, with different thoughts about what that “handling” would entail. E.g., contacting the user having registered such a server to see what is going on, or just dropping them from the pool right away.
Not sure what the status is on that front, I know of at least one account that has such a hodgepodge of somewhat well-known servers in it that I find it unlikely that they are all legitimate (unless that account was officially used to “park” such servers to prevent other users from adding them to the pool - but seeing they are “active” in the pool, I somewhat doubt that).
Please pass along a pointer to their servers page to help@ntppool.org so the appropriate folks can handle it.
This is a bad idea for multiple reasons. First, we should never add servers that are not our own. The people who run these official servers can decide themselves if they want to be part of the pool.
Second, we should not prefer these servers in DNS replies, even if they are in the pool. These official time sources are stratum 1 servers. Clients should rather use stratum 2 servers, or at least not place an unexpected burden on these stratum 1 servers, which would be the case if we just ignored the bandwidth settings chosen by the server operators and always (or very often) replied with these servers.
Third, most operators of stratum 2 pool servers in these countries know about the official servers, and use them as part of their time sources. So clients in these countries will often get their time from the official time servers anyway, only sometimes with an extra hop in between.
And fourth, not every client in these countries has a good connection to these servers. E.g. the official German servers are connected to the academic network in Germany, and from some German providers, there not only is high latency, but even asymmetric routing to and from these servers. This can lead to quite a large offset compared to other servers in Germany.