Open Stack

Hello,

On Thu, Mar 10, 2022, at 22:25, Michael Johnson wrote:
> Personally, if it was my deployment, I would probably go down the path
> of a Designate deployment for each region. This would mean that any
> one DNS zone could not (automatically) be managed from multiple
> regions, but aligns to my understanding of the spirit of a "region" in
> OpenStack.

Yes, that's what I was leaning towards. It makes it very clear.
In a way, anything that's "region specific" belongs to "region designate".

> For non-bring-your-own-domain scenarios, this can be easily managed in
> the DNS hierarchy by creating regional parent zones. I.e.
> west.example.com., east.example.com., moon.example.com., etc. Since
> it's also likely that routable IP address space will be unique per
> region, the reverse zones would naturally be unique.

Yes, that's what we thought of doing too. It's pretty easy for our domains and for many operational aspects.

> In the case of bring-your-own-domain, you would need a policy that any
> one domain can only exist in one region. However, there would be
> nothing stopping users from doing a similar regional breakdown of
> sub-domains if they would like.
That's where we were stopping. Is there a way to _technically enforce_ such kind of policy in an automated fashion?
That's the most important part for me, and (sadly) the part that's very fuzzy.

> As for the synchronization question, I think that is more of an issue
> that a customer would need to address if they feel they want a
> multiple primary scenario. Technically there would be no reason they
> could not create the zone in multiple regions, keep it in sync
> themselves, and add the DNS servers for both regions as authoritative
> for the zone.

I had the same argument, glad to see we are aligned :)
I still think this is more of a "hack".

> If you want to provide a "premium" service where DNS HA is provided
> across regions, this can be done using the Designate pools
> configuration or via the normal secondary DNS server model configured
> in your DNS servers. This would maintain DNS resolution should a
> region go down, but if the zone was created in a specific region that
> is unavailable, you would be unable to update it until the region is
> restored.

We were only thinking of secondary + anycast, and only in the case of a "central" model.
I will have a look at pools. Thanks for the pointer.


> Just some thoughts, please feel free to reach out if you want to chat
> about it more or bounce ideas around,

It's all what I was looking for, so really _thank you_ for doing that :)
I am more and more thinking about a "central model" + "region model" mixed together for covering all use cases, now.

Regards,
JP (evrardjp)