Hi all
We have been trying for months to get a vendor pool up and running through the documented process. We have even reached out directly through email to @ask - neither without any reply whatsoever.
It also seems that others are having similar issues.
Any idea how we should progress from here? or should we look at alternatives instead?
I’d suggest proceeding anyway, and simply using the global pool. You’ve tried to do the right thing, and it’s not reasonable for you to continue waiting with no response.
With that said - please make absolutely certain that you have some way of automatically updating the DNS hostnames that your clients are looking up, without requiring any manual intervention at the client end. Mistakes & bugs do unfortunately happen, and given that you won’t be using a vendor zone (which is the usual way to protect the pool from accidental abuse), it’s important that you have an alternative way of mitigating this should it occur.
Hi earyd
Thanks for the reply and advice - much appreciated.
The devices we deploy will mostly come preconfigured with the global pool for the NTP client. The DNS client on the devices are doing DNS compliant resolution so that the IPs behind the hostnames are correctly cycled / randomized for each NTP sync.
If we at some point needs to change those hostnames, we have methods for doing so. For some classes of devices, we will eventually also support customer defined NTP servers (if the customer wishes to do so).
I guess that’s a perfectly fine method going forward?
Provided you have the ability to unilaterally change those hostnames without requiring any action from your customers (i.e. you aren’t relying on them changing a setting, accepting a firmware update etc) then that sounds fine 
. Basically, if you accidentally ship something like this, or this, you need to be able to get it the heck away from pool infrastructure and servers reasonably promptly (e.g. by temporarily diverting it to your own servers, or to another time source, or turning NTP off entirely, until the issue is rectified).
A caveat to watch out for - HTTPS isn’t a reliable provisioning method for devices that may have an incorrect clock at boot. Whatever you use needs to work regardless of what it thinks the time might be, which rules out most of the usual X509 certificate-based tools, including anything involving TLS.
As an example of why this is so important - we are still seeing bursts to servers of well in excess of 10,000 requests per second from many individual Fortigate devices, even over a year later. They weren’t using a vendor zone, and had no way of changing the hostnames used for NTP other than via a firmware update which must be installed by the firewall owner - so the pool is stuck having to simply cope with the abusive load, as there’s no way for either pool operators or the vendor to promptly mitigate it.