Design question Single Grid vs multi grid

Question

Hi everyone,

We currently have an Infoblox environment with:

A single Grid, hosted at HQ

Domain Controllers (DCs) at HQ

AD-integrated DNS zones managed by the HQ Grid (Primary)

Dynamic DNS updates from domain-joined clients (via Kerberos)

We’re planning to deploy two new remote sites, each with its own Domain Controller pair, and we’re considering adding a new Infoblox Grid per site (two new Grids in total) for local resiliency in case of WAN failure.

My questions

Should we join the new remote site appliances as members of the existing Grid, or is it better to create separate Grids (multi-Grid architecture) for full autonomy?

The key goal is: If WAN is down, the site must still resolve and register AD records locally.

The AD DNS zone (corp.local) is currently managed as Primary on the existing Grid.

If we set it as Secondary on the new Grids:

Will that prevent dynamic updates from remote site clients and DCs?

And if WAN is down, the zone won’t sync between Grids — how do we handle that?

Looking for best practices or similar setups.

ajrobertsx · Answer

I would agree with Ross. Multiple grids is almost always not the right answer.

All of the options you have lead to other pitfalls. Moving the zone back to AD is one way to go and then you would need to secondary the zone from Infoblox and use multi-master with a complex transfer solution. Each location would use the local AD as it's primary. This isn't the right answer as multi-master is a poor solution, it's just an example of something you might try.

RossGibson · Answer

This is a very nuanced discussion beyond what can be covered appropriately in a discussion forum.  You should contact your Infoblox Solutions Architect.

In general, multiple grids would likely make this situation worse, not better.  Without creating independent namespaces (e.g., subdomains such as site1.corp.local) per site, you aren't going to have full independence of dynamic update per site.  For dynamic updates clients query for the SOA record and use the MNAME field in that record to determine where to send the DDNS updates.  Secondaries are not able to process updates for a zone, by their nature they are read only, only the primary for a zone has a writable copy.