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)