At this moment the vendor zones are mapped into DNS names the following way: {0,1,2,3}.<vendor_zone>.pool.ntp.org.
I suggest to introduce the following format: <vendor_zone>.{0,1,2,3}.pool.ntp.org.
What advantage would this have relative to the current format?
In the DNS, wildcard name can only be on the leaf position. For example: *.a.mydomain.org. However, a.*.mydomain.org is invalid. So it is not possible to have 0.*.pool.ntp.org.
For the actual implementation, the following records are required to put into the pool.ntp.org zone:
The IP address assignment to these records would be the same as with the already existing geoDNS logic of the actual vendor zone format.
What all of that would allow? It means that if I am a vendor XYZ, and if I want to ship a preconfigured product, I can ship the software with the following NTP configuration:
server XYZ.0.pool.ntp.org
server XYZ.1.pool.ntp.org
server XYZ.2.pool.ntp.org
server XYZ.3.pool.ntp.org
The important thing that this action does not require any interaction with the NTP pool maintenance, the vendor zone is automatic.
In case there is a misconfiguration, for example the software instead of querying an NTP server every 2 seconds it quieries every 2 msec, it is still possible to create explicit records in the DNS to direct the traffic to dedicated server(s) in order to save the rest of the pool.
This sounds like a very sensible development suggestion.
Rather than bottleneck vendors into waiting for someone to setup a vendor zone, they can preconfigure a zone and ship product. If the product is faulty, then dedicated records can be added to redirect traffic away from the general pool – perhaps toward servers the vendor supplies.
My only suggestion would be to suggest that vendors notify the pool maintainers – perhaps via a specific topic on this discussion board – of the vendor ID they intend to use so that there is no inadvertent vendor ID re-use by unrelated companies. (That would NEVER happen, right?)
I am very strongly in favour of this proposal. Given how much of a headache it is for vendors to get any kind of progress at all when requesting vendor zones, this seems like an extremely pragmatic solution, and seems (although I have not actually examined the relevant code) like one that would not take too much backend work to get running.
I suspect this is the best available option to hopefully prevent vendors from just using the main pool records in order to allow them to ship something - which currently is the only option if they decide to make use of the pool, but are unable to get a vendor zone in a timely manner.
I am generally opposed to the proposed solution. My ridiculous notion is that a more automated process be arranged for vendor tags, and everything inside pool.ntp.org functions as a search restriction basically. V4, v6, and vany could request by address family; (near) nation/continent; single or quad replies; nts or autokey; or other stuff. Low stratum would only be deliberately available by web form or such and nts would get srv records. Oh, and an experimental tag that restricts to subpool x as a default for part and in development libraries.
It could be automatic too. It is enough to analyze the DNS queries that the geo-DNS servers are receiving, to get a picture about the vendor zones actually in use.