That is right. But only towards the verification monitoring station(s). That is greatly reduced surface attack relative to the traditional amplification attack, which is most of the case the whole Internet. In addition too, no need the verification configuration to stay in place after the verification succeeded, it is possible to clean-up.
I do not like that idea. The NTP service administrator may not have the necessary privilege to make arbitrary interaction with the network stack of the server. For example when the NTP service is running in a container. I belive that the verification process should be implemented within the realm of NTP protocol itself.
With the excellent idea of using the “version” restriction of @alica, I may go even further.
There could be a dedicated time server, let’s call it server-ip-peer-verify.ntppool.org .
Every NTP service administrator supposed to add the a statement like:
peer server-ip4-peer-verify.ntppool.org noselect minpoll 13 maxpoll 13
peer server-ip6-peer-verify.ntppool.org noselect minpoll 13 maxpoll 13
into the configuration when (s)he intend to add the new server into the NTP pool. The first or both the two statement, depending on having IPv4 or dual-stack configuration.
Then, it is sufficient to monitor the NTP traffic towards this verification monitoring server to know the intention of a given NTP server (identified by its IP) to be part of the NTP pool, or not.
The server-ip-peer-verify server may not run NTP on it, or run with low stratum, high stratum, doesn’t matter. Referring with a name to it, its IPv4 and IPv6 addresses change management is easy, if required.