I know that you may be looking for multi-primaries, in my scenario, we have a cold standby master BDDS in our DR location with our secondary BAM in live database replication mode. Now all the necessary network firewall ports are open in the event that this DR BAM and BDDS were to become primaries. Once your standby BDDS takes over the prod master roles, it becomes the primary. There will be some items that you will need to take on once the primary site comes back up concerning the failovers and how to get your original primaries back. 

1. Plan, Primary BAM live replication to Secondary BAM in DR location
2. Process and practice your bam failovers. we run our failover bam for 6mon in each location and the failback and 6mos on the other
3. Practice the process for your cold standby master BDDS to take over the roles of your current production primary. We do this twice a year. Failover then failback.

Having a secondary BAM with a live database makes it easy. If you do not have a secondary BAM, that is fine, you can spin it up a BAM fast, apply your database and go (just make sure you have all your firewall provisions in place for the IP you will be using). Note, when applying a Database to a new deploy of BAM, that BAM assumes all the hostname and network info of the original so watch out. Also, if you do not have a cold BDDS standing by that is fine as well since its simple to spin up a VM on-prem/cloud. Just make sure that you have your IP you need to use and is currently setup in your firewalls. 

There are benefits to the multi-primary process.

Good Luck

Thanks for the reply! We have multiple BAMs in replication across geo-divers datacenters. This new site is to be a mini datacenter but with the goal to prevent it from talking back to the primary for every authoritative answer. This is how I understand where multi-primary will help. In theory making that site’s DNS self-reliant. This promotes the idea of local survivability I dare say….were wanting to test this.

With that being said I understand that the multi-primary may be dependent on the BAM doing the updates across the server group?

A secondary DNS is just as “Authoritative” as the primary DNS.  The only traffic between them would be SOA queries and zone transfers.  If I remember correctly, I think you can force a recursive DNS to make a new query by asking for an ‘authoritative’ answer, but it will go to the servers listed in the NS records, which are either secondary or primary, to get the ‘authoritative’ answer.  So it is simplest to use a ‘secondary’ DNS server at the new site.  Avoid multi-primary unless you have a good reason and understand the trade-offs.

Brian, based on what I read, the BAM and its database become crucial especially when it comes to DDNS, here is a quote from the docs “If dynamic updates are sent to one of the servers for the zone, updates that are accepted will trigger a notification update to Address Manager. Address Manager then updates the records in the DNS zone and synchronizes the changes to the servers within the multi-primary server group.” 

Alot of this extends from our experience with having a UDP port reserved and not available for DNS in Azure. In sort our BDDS in Azure behaved erratically providing lookup failures to the clients as it could not communicate with the primary on prem BDDS. It ended up being something nobody would have planned for. We had to use a custom option on the BDDS to prevent from using this port. 

@rharolde

We had a very close look at the traffic and saw more connections to the primary then thought would be happening.  This caused us to question what your saying about the secondary DNS.

My point from this is to : In theory making that site’s DNS self-reliant. This promotes the idea of local survivability”

Has anyone used multi-primary as I have asked for existing zones?

I would also be interested in hearing how anyone is using multi-primary.  I am not using it.  I have alternate servers that I can switch to if one primary fails.  And all of my recursive servers have copies of all my DNS zones, which increases the zone transfer traffic and memory usage, but has the advantages:

• DNS changes reach the servers and users faster.
• faster lookups for users, because the recursive servers do not have to recurse for my zones.
• Since my zones are not cached, they cannot be ‘cache poisoned’ on my recursive servers.

In my opinion the only useful use case for multi-primary is being able to continue to accept dynamic updates/deploy updates to a zone when one of the primaries have failed without needing to “do anything” like change the deployment roles.    But for me, I’m quite happy to run traditional single primary on xHA.  If I get into a situation where both boxes in the pair are unavailable I can take manual steps to move the primary/hidden primary role.

Also (it occurs to me as I’m dealing with this today) - I don’t like that multi-primary functionality depends on the notification mechanism, which can get back logged some times.  The processing of PNA files by BAM follows a single-threaded FIFO process, as far as I am aware, and that would make multi-primary updates susceptible to any backlogging thereof.