DNS SRV records for NTP and NTS

Ntp Pool isn’t running thousand of Ntp Server all over the World,if i understand IT correctly. NtpPool runs a registry for Ntp Server from Company, communities, private… To get registry entries you run a special dns Server which Response to A and AAAA requests. At the Moment this registry isn’t capable to answer on SRV requests. This enforces the community which stands behind Ntp pool with their Ntp Server to use Standard ports and provide a non encrypted interface.

Of course you can build Workarounds for everything. For example you could install Hardware clocks or use GPS to provide your own ntp Server. But it would be really cool if the dns interface from ntp Pool Supports SRV requests. This is independent from nts. This would also allow to use non Standard ports for ntp. If the community behind ntp Pool would decide to enable nts on their Server and add them to the registry or not this will Show the future. But to prevent them to register the Service isn’t the right way after my opinion.

Chickeaterbanana

I’d add SRV records in the DNS system if any of the common NTP clients / daemons supported it. I don’t believe any of them do. As others said, NTS is complicated in the context of the pool (and I don’t believe the current standard supports “pool systems” particularly well).

2 Likes

IIRC the pool is only ever mentioned in RFC 4330 and some BCPs. I have a toy that will query a static list (at say _nts._tcp.jaesb192.com) and print out some targets. From there, it should be a short bit of prep work to get it working in NTPsec or chrony. The toy could be simpler if the priorities and weights were all the same.

RFC8915 assumes that the pool operator will be gifted and burdened with running KE for any servers it fronts. I don’t feel ecstatic about that.

Edit: I think why SRV records are less supported is; that they require a second call to get an address for socket() calls, and C language libraries believe anything beyond A and AAAA records don’t need to be fully implemented.