Design question Single Grid vs multi grid

Options

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.

Answers

  • RossGibson
    RossGibson Infoblox Technical Expert

    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.