Hi everyone, Happy New Year to all! I hope you all had a great holiday season and are starting 2026 on a positive note. I'm following up on my question from December about the restriction on updating NS records for root zones in a multi-region PRIMARY/SECONDARY setup. To recap briefly: I have 3 independent Designate deployments (separate APIs, databases, and pools), and I need to configure certain zones with PRIMARY/SECONDARY replication across all three regions. The challenge is that I cannot update the NS recordset on the primary zone to include all three nameservers (ns.region1.net, ns.region2.net, ns.region3.net), as I get the error "Updating a root zone NS record is not allowed". As Omer mentioned in his response, this feature dates back about 9-10 years, and the original design rationale may not be well documented today. I'm wondering if anyone has insights into: 1. Why this restriction exists in the first place 2. Whether there are alternative approaches for this use case 3. If there would be interest in making this configurable (e.g., via policy or a configuration flag) This seems like a fairly standard DNS architecture pattern for high availability, so I'm curious if others have encountered this limitation and how they've worked around it. Thanks again for any guidance or suggestions! Best regards, Sylvain Le mar. 16 déc. 2025 à 21:09, Omer Schwartz <oschwart@redhat.com> a écrit :

Hi Sylvain,

Thank you for the detailed description of your use case. When you say "3 independent Designate instances", do you mean 3 sets of API endpoints + db etc? Or e.g. one pools.yaml file with 3 different pools, one db, etc?

If you mean the second option, won't specifying the 3 NS records in each pool work for you?

As this feature (NS records support) was implemented about 9/10 years ago, I don't think the people who designed it work on designate today. If I understand correctly, you are getting this issue because those NS records that are specified in the pool.yaml file are being copied to each associated zone, are managed by designate, and therefore cannot be changed by the user (?)

As we are in the second half of December, some of the core reviewers might be on holidays already. IMO it would be better to ask about it in a few weeks, but tbh I don't know why NS records were designed this way (without an ability to modify those). I am probably missing something.

Best regards,

Omer.

On Tue, Dec 16, 2025 at 12:56 PM Sylvain <artpej@gmail.com> wrote:

...

Hi everyone,

I hope this email finds you well. I'm reaching out to the community because I'm encountering a limitation with Designate that I don't fully understand, and I'm hoping someone can shed some light on the reasoning behind it or suggest alternative approaches. My Setup

I'm running a multi-region Designate deployment with:

- 3 independent Designate instances (one per region) - Each instance has its own pool with a single nameserver: - Region 1: ns.region1.net. - Region 2: ns.region2.net. - Region 3: ns.region3.net.

This default configuration works perfectly for most of our use cases where zones are region-specific. What I'm Trying to Achieve

For certain domains, I need to set up a PRIMARY/SECONDARY configuration across all three regions:

- Region 1: PRIMARY zone for example.com - Region 2: SECONDARY zone for example.com - Region 3: SECONDARY zone for example.com

For this to work correctly, the PRIMARY zone needs to have NS records pointing to all three nameservers so that:

1. DNS clients can query any of the three nameservers 2. Zone transfers are properly configured between primary and secondaries

The Problem

When I try to update the NS recordset on the primary zone, I get the error:

Updating a root zone NS record is not allowed

Steps I'm following:

# List recordsets to get the NS recordset ID openstack recordset list example.com. # Attempt to update the NS recordset openstack recordset set example.com. <ns-recordset-id> \ --record ns.region1.net. \ --record ns.region2.net. \ --record ns.region3.net.

This happens even when authenticated as an admin user. Why the Default Workaround Doesn't Work

I understand that one typical solution is to modify the pool configuration to include all three nameservers. However, this doesn't work in my case because:

- I don't want to change the default pool settings since most zones should only use their local regional nameserver - Modifying the pool in Region 1 would affect *all zones* created there, not just the ones I want to replicate

My Questions

I'm trying to understand the design decisions here, and I'd really appreciate any insights:

1. What's the reasoning behind blocking NS record updates on root zones? I'm not seeing the security or technical concern that this protects against. 2. Is this restriction something that could potentially be made configurable via policy? For example, allowing zone owners to update their own NS records when they have legitimate multi-region or high-availability requirements. 3. Are there any alternative approaches I should be considering for this multi-region PRIMARY/SECONDARY setup that I might be missing? 4. Would the community be open to discussing a potential enhancement that makes this more flexible? I understand if there are concerns, but I'd love to understand them better.

Use Case Context

This is a fairly standard DNS architecture for high availability and geographic distribution. Many organizations need to run primary and secondary nameservers across different regions or datacenters, and being able to configure the NS records accordingly seems like it should be a supported use case.

Thank you very much for taking the time to read this, and I appreciate any guidance or feedback the community can provide!

Best regards,

Sylvain.