Obtaining a vendor zone at pool.ntp.org is a task which has been collecting dust for ages. And not just on my desk – several predecessors at the company attempted it and failed. In goodwill, we went far and beyond to adhere to the best practices outlined on the NTP pool project web. The task became a living instalment of a retelling of Kafka’s Castle.
Will 2024 be the year the vendor zone is registered? I don’t know. It might be a year since the NTP pool project finally adjusted its web pages to conform to reality and stop requiring vendors to register one.
Some posts suggest that it has always been this way – apart from specific projects, which didn’t even exist when we applied for a vendor zone for the first time. These projects did get their vendor zone registered swiftly. This priority handling of some projects and ghosting of others leaves a bitter aftertaste and hint of a complete lack of transparency of what’s going behind the curtains at the NTP pool project.
I would suggest setting up a proper process (not sure if there’s already a process in place but based on vendor zone applicant’s feedback such process (if any) probably doesn’t include a standard length for each step to be completed) and ticket system to track and handle vendor zone applications as well as long-term management.
I can’t speak for the pool project, but I assume there is no practical issue with adding many vendor zones, as most queries are cached only briefly and the DNS servers are running custom code. From my perspective it would be a shame to lose the ability to manage problematic clients which are compliant enough to use a vendor zone. On the other hand, I wouldn’t be shocked if such management has never been deemed useful.
The vast majority of abusive clients are probably not using vendor zones, and even those that are using vendor zones most likely are a tiny minority of the total number of users of those zones.
I’m glad Amazon is making an effort to push more of their AWS clients to their much better time service in the same data centers as the VMs, as my US-based pool servers see most traffic from AWS clients, likely most using bespoke .iso images, not those provided by Amazon. Even better would be to see Amazon start providing pool servers in each DC.
I mentioned that recently and someone said it’s actually only used on Windows and Amazon Linux by default so far.
That would be neat! They run time.aws.com (with leap smearing, and IP addresses that have changed a few times) in some regions but it’s not in the Pool (I assume).
If you’re interested in Amazon’s latest innovation in time synchronization, watch a few minutes from the middle of the keynote at their recent annual AWS conference:
You can stop when they start talking about caching. If I understand correctly, this means newer AWS hardware synchronizes the hypervisor clock to within a handful of microseconds, meaning no time sync software is needed in the VMs other than whatever Amazon in-VM drivers/daemons AWS uses to tighten integration with the hypervisor.
Right, and with leap seconds potentially with us until 2035 and no standard for leap smearing, this would be a big ask of Amazon. If there were a standard for leap smearing Amazon and the pool could agree on, it would be much less of an ask.
As a vendor, this has also been on my list to look into seriously, and after a brief search today I found this post… making me consider what other options I can/should do… can I create my own DNS records under my own domain name, as CNAMEs to the ntp pool records, and then if/when I get a vendor zone I can repoint to the new vendor dns records instead?
That is a very good option. It may even allow to use your own ntppool independent NTP servers for the systems you maintain, if one day you decide to do so.
Amazon can’t force customers to use the Amazon Time Sync Service at 169.254.169.123, all we can do is offer the service to them and bake that into the official Amazon images that we provide. Same with building in the configuration for using time.aws.com – we can’t force people to use it.
So, I guess I can’t post any links to the official Amazon public documentation on this stuff?
That is right, the NTPpool is clearly not hidden on the technical level, since the end customer system is resolving the ntppool.org domain name. Still, you may not want to forget about the vendor contribution.
If you’re going to use the pool anyway, then IMO it would be much better to do so with the CNAME records, than to just use the naked pool records. That way if something goes wrong, the problem can be managed.
Vendor zones are supposed to provide that safety valve in a way that can be managed by the pool project, but given how long it takes @ask to get around to issuing them, using your own CNAME records is a good interim workaround that both allows future migration to a vendor zone, and ensures that your clients can be redirected to other servers in the event of significant problems.
I don’t speak for the project, but from my perspective your solution is to be encouraged, not frowned upon - it provides useful gains, adds minimal risk, and is clearly acting responsibly with the use of pool resources. I appreciate your effort.
As far as I know, the vendor contribution is a ruse similar to the vendor zone requirement. I’ve exchanged several e-mails with @ask and never got a number I could present to the management.
I hope someone will approve your post later.
