Infoblox as Authoritative DNS Provider for Active Directory

In an enterprise environment, Microsoft DNS integrated with Active Directory (AD) has traditionally been the default and Microsoft-recommended choice. It provides secure Dynamic DNS (DDNS) updates using GSS-TSIG, multi-master replication, and automatic domain controller registration capabilities that are essential for proper Active Directory operation.

As networks grow in size and complexity, however, organisations increasingly adopt other DNS, DHCP, and IP Address Management (commonly referred to as DDI) platforms that offer more features and centralised management. One such provider of DDI solutions is Infoblox.

Replacing Microsoft DNS with Infoblox requires careful planning. DNS is a foundational service, and any disruption can directly impact Active Directory authentication, service discovery, and policy processing.

In this article, I explain how Microsoft DNS integrated with Active Directory can be fully replaced with Infoblox DDI. I also highlight the key technical considerations before, during, and after migration to Infoblox.

How Microsoft DNS Works with Active Directory

Before diving into the migration process, it is important to understand how Microsoft DNS operates within an Active Directory environment.

Active Directory–Integrated DNS Zones

In a typical AD deployment:

• DNS zones are stored directly in the Active Directory database (NTDS.dit).

• Zone data is replicated using AD multi-master replication.

• Domain controllers dynamically register critical DNS records, including SRV, A, AAAA, PTR, and CNAME records.

This tight integration ensures high availability and consistency across all domain controllers.

Dynamic DNS Updates

Microsoft DNS supports three types of Dynamic DNS updates:

• Nonsecure (unauthenticated) updates: not recommended, as they allow any client to create or modify DNS records without authentication.

• Secure updates (GSS-TSIG): rely on Kerberos authentication and are available only for AD-integrated DNS zones.

• Nonsecure and secure: a combination of the above types where Nonsecure is the default method.

  
  

If Dynamic DNS updates fail, core Active Directory functionality breaks, including:

• Domain controller discovery (SRV records)

• Kerberos authentication and referrals

• Group Policy processing

• Client computer name registration

How to Replace Microsoft DNS with Infoblox

To migrate DNS services from Microsoft DNS to Infoblox while preserving the authenticated and secure dynamic DNS updates, you need to follow this four-stage approach designed to minimise risk and downtime.

Stage 1: DNS Zone Replication and Client Redirection

The first step is about synchronising DNS data and redirecting clients to Infoblox. It includes these activities:

• Creating an Active Directory service account with read-only permissions on Microsoft DNS.

• Replicating existing DNS zones and configuring them as primary zones on Infoblox.

• Reconfiguring DHCP scopes to provide Infoblox DNS servers to client devices.

• Temporarily allowing domain controllers to update DNS records in Infoblox by adding them to Infoblox ACLs. This step is required until secure GSS-TSIG updates are enabled.

• Updating TCP/IP settings of systems using static IP addresses including all domain controllers to point to Infoblox.

  
  

At the end of this stage, both Infoblox and Microsoft DNS are authoritative for all DNS zones, and clients can query Infoblox for name resolution of AD records.

With most Infoblox implementations this is where things usually end and even Infoblox support might tell you that this is good enough. You have partial secure dynamic updates because the existing domain controllers are added to the Infoblox ACLs. But what about new domain controllers or all other servers/clients with static IPs? And what about having two authoritative DNS providers at the same time - Microsoft and Infoblox?

That is why it is imperative to complete the whole process and to enable Kerberos authentication in Infoblox.

Stage 2: Enabling GSS-TSIG for Secure Dynamic DNS

Secure Dynamic DNS updates are critical for Active Directory. Before implementation, it is important to understand the authentication flow and the concept of Service Principal Names (SPNs). The diagram below illustrates the basic Kerberos mechanism:

1. The client receives ticket-granting ticket (TGT) from the Kerberos Distribution Centre (KDC), which is part of AD, upon successful computer authentication against AD.

2. The client then requests a service ticket (TGS) for Infoblox from KDC.

3. KDC checks and locates in AD the principal providing the service the client needs access to (in this case Infoblox) by searching for a matching service principal name.

4. KDC then creates the TGS, encrypts it with the service principal’s password and sends it to the client.

5. The client sends the ticket to Infoblox where the ticket is decrypted and verified.

Service Principal Names (SPNs)

An SPN is a Kerberos identifier that uniquely represents a service instance. It allows the Kerberos Key Distribution Centre to determine which secret key to use when issuing service tickets. SPNs are stored in Active Directory in the servicePrincipalName attribute. They are typically associated with computer accounts, or with user objects when services run under dedicated service accounts.

The general SPN format is:

serviceclass/hostname[:port|:instancename][/servicename]

In our case, the SPN used for DNS is the start of authority (SOA) resource record for the DNS zone. For example:

DNS/ns.b1ddi.domain.com@DOMAIN.COM

Keytab Files

To enable GSS-TSIG authentication, you need a keytab file which allows a non-Windows client like Infoblox to decrypt Kerberos tickets issued by AD. To create it, use the following command:

ktpass -princ DNS/ns.b1ddi.domain.com@DOMAIN.COM -mapuser ddi-infoblox-svc@DOMAIN.COM -pass * -out domain.tab -ptype krb5_nt_principal -crypto AES256-SHA1

The keytab file is used during the initial bootstrap process and contains the necessary credentials (including SALT and hashed password) to decrypt Kerberos tickets issued to clients.

Key elements of the ktpass command are:

• For the princ switch specify the exact SPN you created in AD. It should correspond to the SOA name server configured in the Infoblox Global DNS settings. The domain name must be in uppercase.

• You can use the service account used for the DNS replication or create a new one.

• AES256-SHA1 encryption is recommended per the current acceptable security recommendations.

• ktpass is case sensitive.

• Either an existing or a randomly generated password can be used.

Infoblox Configuration

To enable Kerberos AES 256 bit encryption, select this checkbox:

Once done, you need to perform these steps in Infoblox:

• Enable “Allow GSS-TSIG-signed updates” in Infoblox under Global DNS Configuration.

• Upload the generated keytab file and associate it with the correct domain.

• Remove the temporary ACL entries that allowed domain controllers to update DNS records manually.

At this point, secure Dynamic DNS updates should be based on Kerberos authentication.

Stage 3: Validation

After enabling GSS-TSIG, you can validate Dynamic DNS functionality using multiple methods.

Domain Controller Validation

On a domain controller, run:

dcdiag /test:dns /e /v

If it works, you should receive this output:

Client Validation

On a domain-joined machine, execute:

ipconfig /registerdns

Then check the Windows Event Logs for these events:

• Event ID 8013 indicates successful DNS registration.

• Event ID 8019 indicates a failure.

  
  

Finally, verify in Infoblox that the newly created DNS records are marked as dynamic, not static.

Stage 4: Cleanup

To complete the migration, perform these cleanup steps:

• Identify AD-related SRV records that are created as static during the initial replication and delete them.

• Restart the Netlogon service on each domain controller to force re-registration of DNS records.

• Confirm that all newly created SRV records are dynamic.

• Uninstall the DNS Server role from all domain controllers.

Conclusion

Replacing Microsoft DNS in an Active Directory environment requires careful handling of Dynamic DNS, secure updates, and domain controller integration. When properly configured, Infoblox fully supports GSS-TSIG, Kerberos authentication, and authoritative hosting of AD-related DNS zones.

With thorough planning and validation, migration can be seamless, enabling DNS services to be operated reliably on an alternative DDI platform in modern enterprise, hybrid, and multi-cloud environments.