Oracle Linux vendor zone: request for a clear decision and a usable vendor-zone process

Client Configuration and Development
1

I would like to start a new topic to summarize the long-running Oracle Linux vendor-zone request and ask for a clear way forward.

This is not meant as a personal attack on anyone. I appreciate that the NTP Pool is largely volunteer-run and that keeping the infrastructure running is a significant amount of work. I am raising this because the current situation leaves vendors who are trying to follow the published guidance with no reliable way to do so.

Short version

Oracle Linux has been trying to obtain a vendor zone since at least 2018. The request has been raised publicly multiple times by @jch and later by me. In 2023, @ask acknowledged the Oracle Linux request publicly and followed up by email. I provided the requested information, including the reason why ol is the preferred identifier and an internal estimate of expected usage. I also asked what contribution amount or range would be appropriate so that I could take it back internally.

The zone still has not been created, and we still do not have actionable terms, a formal rejection, or a documented next step.

Meanwhile, other RHEL-family distributions created after the CentOS change appear to have received vendor zones quickly. From the outside, this no longer looks like a simple backlog. It looks like a vendor-zone process that works for some requests but not for others, without published criteria, timeline, escalation path, or fallback guidance.

Public timeline

The Oracle Linux request predates my involvement. @jch wrote in January 2020 that he had requested a vendor zone around September 2018, followed up several times, and heard nothing back. He also pointed out that Oracle Linux was using rhel.pool.ntp.org, which was not right for Oracle Linux, and that a vendor zone would identify Oracle Linux users in the same way as the rhel, fedora, and centos zones:

In February 2020, in a discussion about the purpose of vendor zones, @ask explained that vendor zones help protect the pool from poorly behaved clients, establish a contact relationship with vendors, and give the project tools to manage load. In the same topic, @jch again asked whether vendor zones were still alive, because the Oracle Linux request had been pending since September 2018:

In June 2020, in a thread about Vodafone Germany using the pool without a vendor zone, @jch again said that he had requested a vendor zone in September 2018, followed up a few times, and still had no response:

In October 2020, when another user asked whether waiting 1.5 months for a vendor zone was expected, @jch replied that he had been waiting since September 2018:

In March 2023, I opened a new topic because I was trying to get Oracle Linux aligned with the vendor-zone guidance. I explained that we had tried the documented process, that @jch had attempted the same years earlier, and that Rocky Linux and AlmaLinux had vendor zones even though those projects did not exist when the Oracle Linux request was first made:

There is also a related follow-up topic which is unlisted and accessible only by direct link. The topic records another public attempt to get the Oracle Linux vendor-zone issue unstuck: on April 18, 2023 I wrote that we had been trying to rectify the client configuration for years, literally, but had not been able to even initiate a conversation with anyone from the NTP Pool project; @ebahapo replied that projects needing accurate time should plan for their own NTP servers; @paulgear tagged @ask and later said that, to his knowledge, Ask should receive a notification for every @ask mention. The topic page indicates that it was unlisted by @ask on July 21, 2023. I am including it here to make the forum record complete, not to rely on it as the main public evidence:

In the March 2023 topic, @ask replied that he would follow up by email, and later wrote “Sent, finally!” after a reminder:

After that private follow-up, I provided the requested information and asked what contribution amount or range would be appropriate. I did not receive actionable terms or a completed zone.

In January 2024, I opened another topic asking whether the vendor-zone requirement should be dropped or updated if the project could not actually provide a functioning process:

That discussion included a practical suggestion from @erayd: if vendors are going to use the pool anyway, using vendor-controlled CNAME records is a better interim workaround than using the naked pool records, because it allows later migration and emergency redirection:

In December 2024, @n1zyy independently mentioned the Oracle Linux situation in a broader discussion about pool management transparency, saying that Oracle still appeared to be trying to be a good netizen and register a vendor zone but was not getting a response:

In April 2025 and May 2025 I again followed up in the 2023 topic:

Why this matters

I do not think the vendor-zone idea is wrong. On the contrary, the technical rationale still makes sense: vendor zones give the pool project a way to identify client populations, maintain contact with vendors, and manage traffic if a client population misbehaves.

The problem is that the requirement is not usable if there is no reliable way to complete it.

When a vendor follows the documented path and gets no response, the release still happens. The practical outcome is exactly what the vendor-zone policy is supposed to avoid: products end up shipping with the wrong zone, the default pool names, or some other workaround that the pool project cannot manage as well.

The Oracle Linux case is especially hard to explain as an ordinary backlog because the request has existed since at least 2018, was acknowledged publicly in 2023, continued privately after that, and still has not produced either a zone, a rejection, or actionable contribution terms.

What I am asking for

Could the project please provide one of the following?

  1. Create an Oracle Linux vendor zone, preferably ol, matching the ID=ol value in /etc/os-release; or oraclelinux if ol is still technically problematic.

  2. If the Oracle Linux request is not acceptable, say so explicitly and explain the reason.

  3. If vendor zones are still required for distributions and vendors, publish a process that includes:

    • who owns vendor-zone approvals,
    • expected response time,
    • what information is required,
    • how contribution expectations are calculated,
    • how to escalate or get a formal rejection,
    • and what a responsible fallback is when no answer is received.

  4. If the project does not currently have capacity to operate this process, update the vendor guidance to say so and recommend an interim pattern, such as vendor-controlled DNS indirection, instead of leaving vendors in limbo.

A clear “no” would be better than years of uncertainty. A clear documented fallback would be better than forcing every vendor to rediscover the same workaround through forum archaeology.

Again, I am not trying to blame volunteers for having limited time. I am asking for the written policy and the actual process to match reality, so vendors trying to do the right thing have a practical way to do it.

2 Likes
2

I admire your persistence and professionalism. Too bad that neither is taken into consideration by the pool administrators.

2 Likes
3

The two letter labels are typically used for the country zones, like us.pool.ntp.org, uk.pool.ntp.org, fr.pool.ntp.org and so on. As far as I know, there is no country exists at this moment of time with the ‘ol’ two letter code, but that label string length might be already reserved for countries.

I have three questions, the first one is not important:

What kind of enterprise category does belong the Oracle Linux’s supporting organization? (like AlmaLinux to 501(c) organization. This question is just for my personal curiosity, I was searching but did not found the answer. )

Do you have an agreement on what is the contribution of Oracle Linux to the NTP pool project for the requested vendor zone?

What are the domains currently used in the NTP configuration of the recently shipping Oracle Linux distributions?

4

Thanks, these are fair questions.

On the ol name: yes, I understand the concern about two-letter labels being used for country zones. That concern also came up in the 2023 email follow-up. My understanding from that exchange was that two-letter vendor identifiers had been technically problematic in the old system because they could be mistaken for country-code zones, but that this was being worked on as part of the newer naming scheme. So I did not understand ol to be a fundamental policy objection.

The reason I suggested ol is that it matches ID=ol in /etc/os-release, and that matters because some downstream packaging can derive the vendor/pool identifier from the OS ID. That said, ol is not the main point here. If two-letter vendor labels are still technically problematic, oraclelinux would also be acceptable. The important part is having a designated Oracle Linux zone rather than using another distribution’s zone or the generic pool names.

Oracle Linux is developed and supported by Oracle Corporation. For the purposes of this discussion, I would assume this is a commercial-vendor case unless the NTP Pool project classifies Linux distributions differently. I am not claiming that Oracle Linux is backed by a non-profit foundation like AlmaLinux.

There is no agreement yet on Oracle’s contribution to the NTP Pool. That is part of the problem I am trying to describe here.

When the topic moved to email in 2023, I was asked whether Oracle would have budget to contribute. I took that question internally and asked what amount or range would be appropriate so that it could be evaluated, but I did not receive actionable terms.

In 2025 the discussion shifted to whether OCI credits might be possible. I replied that Oracle would need at least a rough description of the required resources, such as number and size of VMs, bandwidth, storage, regions, and expected duration, so that the right people could assess it. I have not received that information either.

So I would not say Oracle has refused to contribute. The current state is that we do not have a concrete contribution request, estimate, invoice amount, or infrastructure requirement that I can take through the appropriate internal channel.

For the currently shipped configuration: the Oracle Linux 10 chrony package currently ships /etc/chrony.conf with the generic pool:

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (https://www.pool.ntp.org/join.html).
pool 2.pool.ntp.org iburst
5 Likes