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.