What breaks when you migrate AD-integrated DNS to Infoblox

Moving zones from Microsoft DNS to Infoblox is straightforward. Moving the Active Directory dependencies along with them is where migrations go wrong. These are the problems I check for on every Microsoft-to-Infoblox migration, in roughly the order they cause outages.

Domain controllers stop registering their records

Domain controllers register their own SRV and A records, such as _ldap._tcp.dc._msdcs, through secure dynamic updates. If Infoblox now hosts the zone and isn’t set up to accept those updates, nothing fails immediately. Days later a domain controller restarts, can’t re-register, and clients start failing to find it.

There are two workable approaches:

• Infoblox hosts the AD zones and accepts secure updates from the domain controllers using GSS-TSIG. This needs a service account, a keytab on the grid members and the zone configured to accept GSS-TSIG updates.
• The domain controllers keep the AD-specific zones, typically _msdcs and sometimes the AD forest zone itself, and Infoblox delegates or forwards to them. Simpler to set up, but it leaves Microsoft DNS in the design.

Either is fine. What isn’t fine is not deciding.

The _msdcs zone gets forgotten

In many forests _msdcs.<forest> is a separate zone, replicated forest-wide. It’s easy to migrate the parent zone and miss it, because it doesn’t appear where people expect it. Inventory every zone on every DC, including ones replicated at forest scope.

Conditional forwarders and stub zones vanish

Microsoft DNS servers accumulate conditional forwarders over years: partner domains, cloud private zones, acquired companies. These don’t live in any zone file. Export them separately and recreate them on Infoblox, or name resolution for those domains quietly stops after cutover.

Aging and scavenging behave differently

If the Microsoft side had scavenging turned on, stale dynamic records were being cleaned up. If Infoblox doesn’t have equivalent record scavenging configured, those records accumulate. If it does and the settings are more aggressive, records for machines that are offline for a while disappear. Match the behavior deliberately.

DHCP options only one scope used

Microsoft DHCP scopes and server-level options carry settings nobody remembers: option 43 for wireless controllers or phones, option 66 and 67 for PXE boot, vendor classes. Export options per scope and per server, not just the ranges and reservations, and check them against Infoblox after import.

DHCP clients still point at the old DNS servers

Option 6 tells clients which DNS servers to use. If DHCP moves before DNS, or option 6 still lists the old domain controllers, clients keep querying the old servers. Plan the order: usually DNS first with the old servers forwarding to Infoblox, then DHCP with option 6 pointing at Infoblox.

TTLs not lowered before cutover

Lower TTLs on key records a few days before cutover, so any record that changes during the migration propagates quickly. Raise them again afterward.

A cutover that can be undone

Every migration I run moves in stages with a written rollback at each step: DHCP scope by scope, DNS resolver by resolver. If something unexpected appears, you step back one stage instead of rolling back the whole project.