You are right that priorities must be taken into account to decide where to put resources when the time comes to implement something. However, this discussion thread is just brainstorming, not a pilot to force implementing anything. Not having enough resource to implement should not stop us thinking about how to do.
You are absolutely right. There is no one single verification scheme which fulfills all possible legitimate scenarios, so multiple schemes are needed.
Let me recapitulate here where we are now:
- a well-defined peer to be added to the server configuration. The verification process checks that the peer association is fully established. Limitations:
- certain servers has no client function library in the code
- certain NTP server appliance may not have appropriate configuration option
- Use different protocol other the NTP to the same IP address as the NTP server to be verified, for example: http://22.214.171.124/.well-known/ntppool-verification must return a predefined challenge. Limitations:
- other protocol then NTP is not always available from the NTP server (for example enterprise security policy)
- certain NTP server appliance may not have appropriate configuration option to allow other service then the NTP
- configuring reverse DNS entry with well-known string in it, for example myserver.ntppool.mydomain.org
- even if the user long term rented the IP address, the upstream IP address provider is bastard enough to refuse updating reverse DNS entry.
- Manual verification, the last resort escape. Limitations:
- resource intensive due to the lack of automatization
- it may be unreliable