Recommendations for the Steps in Migrating AD DNS to Infoblox DNS

Question

Hello I hope you folks can assist me with this question I have formulated the following steps to migrate from AD to DNS: Windows DNS to Infoblox Migration High Level Plan PHASE 0 – Preparation Inventory Current Environment * List all DNS zones (forward & reverse). * Document zone types, forwarders, recursion, TTL. * Export zone list from Windows: Windows AD/DNS Team PHASE 1 - Prepare Infoblox * Join appliances to Grid. * Configure management/data IPs, NTP, DNS, SNMP, syslog. * Match recursion and forwarders from Windows. PHASE 1 – Zone Transfer Setup On Windows DNS: Windows AD/DNS Team On Infoblox: * Create zone as Secondary. * Set Windows DNS as Master. * Initiate Transfer Now. Verify: Windows AD/DNS Team * Compare serials with Windows. PHASE 2 – Testing & Parallel Run * Point a test client to Infoblox: Windows AD/DNS Team * Test A, PTR, CNAME, SRV lookups. * Validate forwarders and recursion. * If AD-integrated zones are in use:* Enable GSS-TSIG on Infoblox. * Join Infoblox to AD domain. PHASE 3 – Flip Primary/Secondary (FOR TEST DEVICES ONLY) * Infoblox → Primary. * Windows → Secondary. * Allow zone transfers from Infoblox to Windows. * Refresh on Windows: Windows AD/DNS Team * If using dynamic DNS updates:* Make Infoblox part of the AD replication scope for dynamic updates. PHASE 4 – Gradual Client Migration * Lower TTL to 300–900 seconds at least 24–48 hrs before cutover. * Change DHCP scopes in small batches to point to Infoblox: Set-DhcpServerv4OptionValue -ScopeId -DnsServer * Release/renew on clients. * Monitor logs and query rates. PHASE 5 – Final Cutover & Decommission * Update all DHCP scopes to Infoblox only. * Remove Windows from static configs. * Update NS records at registrars if public zones are hosted. * Keep Windows as hidden secondary for 2–4 weeks. * Stop and disable DNS service when safe: Stop-Service DNS Set-Service DNS -StartupType Disabled Rollback Plan * Switch DHCP/DNS back to Windows. * Make Infoblox Secondary again.

Don Smith · Answer

Infoblox doesn't have a single recommendation on whether to use GSS-TSIG or use other available options. Each provides specific pros and cons and the ideal solution depends on your desired outcomes and risk tolerance.

The main point is that GSS-TSIG is not required and it is not always the best solution for every problem.

dot_sec · Answer

Is this the official Infoblox recommendation, to avoid using GSS-TSIG with AD integrated zones?

Don Smith · Answer

Mark,

In step 2, you mention making Infoblox support GSS/TSIG. In general, this is not a best practice for a managed DDI platform. Can you do it? Yes. Should you do it? Probably not. That said, there are times where it does make sense…the "underscore" zones where the SRV records are. By default, Microsoft will delegate "_msdcs" at the forest root. In the UI, you will see what may look like additional zones but they are only folders. In Infoblox, you would delete all underscore zones since you can change the security per zone, but not per "folder" (or "label" in pure DNS terms).

GSS/TSIG would be fine to use for SERVERs that need to manage their own SRV records in the underscore zones. The forward mapping and reverse mapping zones should not allow DDNS updates by clients. Clients do not clean up their records gracefully and can't when they are shut down. This is why scavenging becomes important. Instead, A/AAAA and PTR records should be either manually assigned, managed via automation, or managed by the DHCP server. You would still use DNS scavenging for stale entries using the advanced options available in Infoblox.

In step 3, given the nature of multi-master DNS in AD, simply changing a zone from secondary to primary in Infoblox isn't just swapping out the primary/secondary name servers. This is a migration event and requires many more steps to ensure all AD servers are online and are being changed as well. Depending on your architecture, this could be fairly straight forward or it could be very complex.

In step 4, you mention lowering the TTL. Since this step is related to DHCP, I assume you actually mean lease time. TTLs are for DNS records being cached by other DNS servers. I'm not sure if your intent is to start up Infoblox DHCP at this point or continue to use MS DHCP. Leaving the MS DHCP configuration alone and just shutting down the service while starting up the Infoblox DHCP service gives you a back out plan in case you missed something. Just make sure you update all of your IP helpers/relays on your routers beforehand.

In step 5, I would also recommend just shutting down MS DNS without making significant changes so you have your backout plan for that as well. Nothing is worse than realizing half way through a migration, after you've made a bunch of changes, that you missed something significant. You generally can't abort midstream without ending up in an unknown configuration state.

Infoblox PS has done thousands of these migrations. I would recommend talking to your sales team to see if there's a PS package that would fit your needs. With their success rate, you would likely end up having a lot less stress come cutover time.

Don