Here are two S/NTP-related feature suggestions or change requests with a focus on resiliency and maintaining a high ethical bar.
Currently, the primary and secondary NTP server fields must be set to IP addresses. If both server’s addresses change or they stop providing S/NTP service, time syncing no longer works. Also, if administrators the world over would statically select S/NTP servers, this could unnecessarily skew S/NTP traffic and place an undue burden on a limited number of S/NTP servers. Please allow us to use FQDNs (e.g. 0.north-america.pool.ntp.org) and design the S/NTP client to do real-time DNS queries on these FQDNs prior to polling. Regional FQDNs available from the ntp.pool.org project are designed in a way to distribute S/NTP traffic across pools of servers and to improve resiliency. Server availability in a pool can change transparently and administrators don’t need to worry (as much) that the S/NTP source they’ve selected is still serving S/NTP. Please consider restricting allowable (statically set) IP addresses for primary and secondary S/NTP servers to RFC 1918 addresses.
Make the poll interval adjustable. You may wish to enforce a reasonably high minimum interval (perhaps 900s [the current hard-coded poll interval] is a reasonable minimum interval for possible RouterOS use cases?). But we would like to be able to set a higher poll interval (at least as high as 86400s [24 hours]). In its guidance for vendors (e.g. Mikrotik), ntp.pool.org says, “Don’t send excessively frequent queries. Reasonable query intervals are typically from once or twice a day to a 4-5 times an hour depending on the application. Really consider how often the device will need ‘fresh time’.”
TL;DR refresh time cannot be longer than 15 minutes, it will resolve domain name via internal resolver, so it will be possible to set static domain entry in cacher if you do not have FQDN or want to override an address
This is saying that the client poll interval should be set to the highest possible interval that results in acceptably accurate time.
Further:
and later in section 10:
Again, your comments on DNS resolution seem to be diametrically opposed to the best practices in RFC 4330.
So in 6.15, I can enter FQDNs in the Primary and Secondary NTP Server fields, however, the domain names are apparently statically resolved once (FQDNs are automatically replaced with IP addresses). There is a Dynamic Server field (purpose?) that is disabled.
Furthermore, from the RFC, section 10, Best Practices:
dynamic servers can be acquired over different services that offer automatic interface configuration, like DHCP, that sends NTP server list that can be used by the client.
It is read only as they are set dynamically via other means, but direct user interaction.
No more need to schedule a script to resolve FQDN and then re-set IP.
I never understood why the update interval was so short, at least make it configurable.
focus on resiliency and maintaining a high ethical bar
In my opinion, NO one single vendor MUST impose it’s own “ethic” rules.
Any product that limit, or try to limit, the liberty to do everything I want do, for me are toys or traps, like iOS, OS X, just for example…
The ethical bar must be high on ISP and final user side.
And about this post, the solution for me is very easy, my two DNS are also my two NTP servers.
All my CPE (and obviously all the router, gateway, switch, access-point, web-server, proxy, mail…) syncronize the time only with MY NTP SERVERS.
The two NTP servers are the only device than syncronize the clock with National NTP server, and not other “private” ntp servers like ntp.pool.org
About user pc, how you stop them to check on every way they want the NTP server?
Today almost all device syncronize with (S)NTP the time.
How prevent and force the time interval before check or impose specific ntp servers?
The absurd is how much computer check time on time.apple.com and time.windows.com
Who stop the catastrph if one of the two time servers give false time???..
