First off, I'm sure Infoblox professional services would be happy to help you with this process (albeit for a cost that you may or may not be willing to pay).

In any case, here's a high level outline that I've used successfully in the past. (Note: You didn't mention what your grid topology looks like, so I'm just going to assume you have at least a couple dedicated grid members that will be hosting the AD zone(s). In the outline below, assume I'm only referring to those specific grid members rather than all members in your grid.)

Prep Work (No Clients Affected)

1. Enable the DNS service on the grid members that will be hosting your zone(s) if it's not already.
2. Create a GSS-TSIG account for each grid member in AD and associated keytab files.
3. Import the keytabs into the grid and assign them to their associated grid member.
4. Enable GSS-TSIG updates on each member's DNS properties (the GSS-TSIG advanced tab, not the Updates tab).
5. Create an appropriate nameserver group for your AD zones.
   • If you want them to act like DCs where each one responds with itself as the primary nameserver for a zone, make each nameserver a grid primary. Otherwise, standard grid primary and one or more secondaries is fine.
6. If your AD DCs were recursive resolvers for your clients, make sure you have recursion enabled at the DNS View or member level as appropriate.
7. Configure the DCs to allow zone transfers to the grid members.
8. (Optional) If you have DHCP servers that point clients to the DCs for DNS, shorten the lease times so when you make changes later they apply more quickly.

Primary DNS Cutover

1. For each zone (don't forget your reverse zones):
   • Create an empty authoritative zone and assign it to the nameserver group.
   • Enable Allow GSS-TSIG signed updates in the zone properties if appropriate. You shouldn't need any IP based ACLs if GSS-TSIG is working.
   • Enable Automatically create underscore zones and Allow GSS-TSIG-signed updates to underscore zones in the zone properties if appropriate. You shouldn't need to allow unsigned updates from any DCs.
   • With the zone selected, click Import Zone from the toolbar to do a one-time zone transfer from one of the DCs. I don't usually enable any of the options to auto convert/create associated records.
   • Using dig or nslookup, verify you can now resolve things you just imported against the grid members. In particular if you're using multiple grid primaries, make sure the querying the SOA on each member returns itself as primary.
   • You may notice in the GUI that most of the records that were imported are "static" rather than "dynamic". This will change as things dynamically re-register over time.
2. Configure the DCs to use the grid members as forwarders. This will allow anyone using the DCs for DNS to still resolve things properly when the zones are eventually removed from the DCs.
3. Update the DNS configuration in the TCP/IP Properties on the DCs to point to the appropriate grid members.
   • ipconfig /registerdns to re-register the DC's A/PTR records
   • Restart the netlogon service to have AD re-register all of the domain related SRV records.
   • Check DC event logs for registration errors
   • You can also check Infoblox syslog. Don't panic if you see errors though. Windows always attempts unsigned updates before retrying with GSS-TSIG. So the logs will show update failures followed by update successes.
   • dcdiag /test:dns is also your friend here.
   • Another positive indication is seeing DC related records convert from "static" to "dynamic" in the Infoblox GUI

At this point, it's still pretty easy to roll back. The only things that have been re-pointed are the DCs. But as long as the DCs can dynamically register their records and you can successfully run queries against the grid members, you're good to continue.

4. If you have DHCP servers that point clients to the DCs for DNS, update them to point to the appropriate grid members instead. If your lease times are reasonably short, you should soon see some client records start changing from "static" to "dynamic".

At this point, we've reached the point of no return and we're going to start deleting zones from the DCs. (Recovering the zones is obviously not impossible. But it's annoying enough that you wouldn't want to be forced to do it in a maintenance window.) If you configured forwarding correctly, anyone still pointed at the DCs for DNS should still resolve things properly after a zone is deleted. But you can't really know for sure until the zone is gone because the DC will just return its own copy as long as it's still there.

5. For each zone (don't forget your reverse zones and maybe prioritize less important or non-AD specific zones first):

   • Delete the zone from AD and wait for the changes to replicate
   • Clear the DNS cache on the DCs and maybe restart the DNS service for good measure.
   • Test an SOA query on the zone against a DC. It should return the same serial you see in Infoblox for that zone. If it's an old one, the DC might still be returning its own old cached copy. If you get cached results, try clearing the DNS service cache again. Try ipconfig /flushdns on the DC and your client.

When you're done, the DCs should have no more zones and are effectively caching servers. All that remains is to find the remaining hosts with static DNS configuration and re-point them to the grid members.

Once you're sure no more clients are trying to use the DCs for DNS, you can stop and remove the DNS Role on them.