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.