What are the differences between X.pool.ntp. org pools (Eg: au.pool.ntp. org) and N.X.pool.ntp.org (Eg: 0.au.pool.ntp. org, 1.au.pool.ntp. org etc.)?
When would you use one or another?
I’m assuming it’s functionally the same service side but is for querying clients benefit if they support multiple NTP server failovers but also cache DNS responses?
Hi Viajaz and welcome!
If i’m correct there is no major difference between the two except for their intended use case. In other words; this is primarily a cosmetic thing. Please read this explanation for further information:
https://kb.meinbergglobal.com/kb/time_sync/ntp/configuration/ntp_pool_usage
In short; with the ‘pool’-directive you can use ‘au.pool.ntp.org’ and with the ‘server’-directive is is best to use ‘[0123].au.pool.ntp.org’, in your example.
There is one notable difference though, that I would like to mention. Only 2[.X].pool.ntp.org provides IPv6-addresses (AAAA-records). So, if you want IPv6 and also prefer to use the recommended ‘pool’-directive, just put 2.au.pool.ntp.org there, not au.pool.ntp.org. Some software does this by default nowadays.
Hope this helped!
Thanks for the information.
In regards to X.pool.ntp .org versus N.X.pool.ntp .org is there still a use-case for clients that wish to have additional NTP entries, doesn’t support choosing a different DNS A record when multiple are available and also caches DNS responses?
If the client has no support for the ‘pool’-directive, then it would make sense to add multiple ‘server’-directive lines in the configuration, which implies the usage of [0123].X.pool.ntp.org, in order to avoid the client ignoring multiple lines with the same entry.
But if the client has support for the ‘pool’-directive (in some implementations referred to as ‘servers’ with an ‘s’ at the end), which most modern implementations have nowadays, just a single line would do (but it’s okay to add a few more). When using such a single line it doesn’t matter what name you use, unless you like IPv6, in which case you should configure 2.X.pool.ntp.org or even 2.pool.ntp.org.
Please note that the instructions on the website still mention the ‘server’-directives, but it my mind those instructions are a little outdated.
There is no difference as DNS-cache is on your side and not on the pool-side.
If you have DNS-speed problems, you better change the DNS server you query on your side.
My favourites are 1.1.1.1 and 1.0.0.1, they are the fastest DNS-servers on the planet.
What ever pool you use, if your DNS server (from your provider or so) is slow, it will query slow.
DNS-cache got nothing to do with this. Try better DNS-servers to resolve your queries.
I was specifically referring to local client side DNS cache in the situation where a client doesn’t support choosing a different DNS A record when multiple are available, which is where using multiple N.X.pool.ntp .org entries would be useful if the server at the cached response X.pool.ntp .org happens to go down and the client isn’t smart enough to pick another address in the pool.
I don’t actually have a problem, this was a theoretical question in regards to which entries should be configured for a NTP client under which circumstances.
I think what @marco.davids was correct regarding pool and server (equivalent) implementations, that was what I thought too and is the main scenario for why you’d pick N.X.pool.ntp .org instead of X.pool.ntp .org as far as I was aware, what I didn’t know for sure was if there was actually any service side differences.
I think you miss the point of what a DNS does.
It does nothing else then convert a domain to IP’s and back.
If your ISP’s DNS is overloaded it doesn’t matter what pool you take or use, it will still resolve very slowly.
A DNS got nothing to do with time-keeping.
Nor does your local DNS-cache help much, as most entries are kept for a few hours and then refreshed anyway.
You’re client doesn’t need to be smart as a DNS-request always offers 4 servers, your client will connect them one after the other when a connection isn’t possible.
Server and Pool tokens in NTPD do basically the same.
pool
For server addresses, this command mobilizes a persistent client mode association with a number of remote servers. In this mode the local clock can synchronized to the remote server, but the remote server can never be synchronized to the local clock.server
For server addresses, this command mobilizes a persistent client mode association with the specified remote server or local radio clock. In this mode the local clock can synchronized to the remote server, but the remote server can never be synchronized to the local clock.
Only difference the pool tokes tries to access them all at the same time to determine the fastest, server uses them one by one unless one is unstable of wrong-time. (if I’m not mistaken).
In the end the result is the same, it will only select servers with the correct time.
In my NTPd there is a major difference, I tested it myself - but is also well documented in various places.
The DNS will return 4 answers for a ‘pool.ntp.org’ query, but only one will be picked when the ‘server pool.ntp.org iburst’ directive is used.
NTPD won’t re-resolve the name at runtime, nor is an unreachable server kicked out.
The ‘pool pool.ntp.org iburst’ directive will use all (4) answers (depending on the ‘tos maxclock’ directive value) and acts more dynamically. When servers become unreachable, they are discarded and new servers are added on the fly.
Correct, it picks the first server that connects and doesn’t fail.
With the pool directive it tries all 4.
That is true.
However, normally you do not use a pool as an NTP-server solution.
Typical you select stratum1 or 2 servers near you…
For a client you use the pool, for a server you do not unless you are a lazy operator 
Yes. And it uses all of them. And it is able to change to different IP addresses on the fly when one of them becomes unreachable (‘server’ directive won’t do that) .
Not sure about that, but in any case… something tells me there are a lot of lazy operators. 