Best DNS Settings for Domain Controllers in Windows Server

DNS is the foundation Active Directory stands on. Domain controllers find each other, clients find DCs, and replication partners locate one another entirely through DNS records. Get the DNS configuration on your DCs wrong and you get problems that look like everything except DNS: failed logons, broken replication, Group Policy that won’t apply.

Most of those problems trace back to a couple of small misconfigurations — usually how a DC points its own DNS client settings, or a DC that’s been left pointing only at itself. Both are easy to fix once you understand why the recommended layout exists.

This guide covers what each DC should use for its own DNS, how AD-integrated zones and secure updates should be set, where forwarders fit, and the classic islanding problem that catches people who configure DNS the “obvious” way.

The core rule: partner first, loopback second#

Here’s the single most important setting, and the one most often done wrong. A domain controller that also runs DNS should set:

• Primary DNS → a different DC running DNS (a replication partner)
• Secondary DNS → its own loopback (127.0.0.1) or its own static IP

The instinct is to make a DC point at itself first — it is a DNS server, after all. That instinct causes islanding, which we’ll get to. Pointing at a partner first means that during startup, when the DC needs DNS before its own DNS service is fully ready, it can still resolve records from a healthy partner.

You can set this in PowerShell rather than clicking through the NIC properties:

# On DC01: point primary at DC02 (10.0.0.12), secondary at loopback
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" `
  -ServerAddresses ("10.0.0.12","127.0.0.1")

The islanding problem#

Islanding is what happens when a DC points its primary DNS only at itself. It’s worth understanding because the fix is the rule above, and because the symptom is confusing.

When a DC boots, several things happen close together: the OS starts services, the DNS Server service comes up, AD DS starts, and Netlogon tries to register the DC’s SRV records and locate replication partners. If the DC is configured to resolve DNS only through itself, there’s a window where AD needs DNS but the local DNS service isn’t ready yet, or the local zone data is stale because this DC hasn’t replicated since it rebooted. The DC can fail to find its partners and effectively isolate itself — an island — until something forces it to re-resolve.

flowchart TD
A["DC reboots"] --> B{"Primary DNS<br/>points where?"}
B -->|"Only itself"| C["AD needs DNS before<br/>local DNS is ready"]
C --> D["Can't locate partners<br/>= ISLANDED"]
B -->|"A partner DC first"| E["Resolves records<br/>from healthy partner"]
E --> F["Finds partners,<br/>replicates normally"]

Use AD-integrated zones#

For the zones that hold your AD records, use Active Directory-integrated zones rather than traditional file-based primary/secondary zones. The difference matters:

• Replication with AD. Zone data lives in the directory and replicates along with AD, so you don’t maintain a separate zone-transfer topology.
• Multi-master updates. Any DC running DNS can accept updates, so there’s no single primary zone to lose. A traditional standard primary zone is a single point of failure.
• Secure dynamic updates. AD-integrated zones can require secure only dynamic updates, so only authenticated domain members can register or change records. This is the recommended setting and blocks unauthenticated machines from hijacking records.

Set dynamic updates to Secure only on your AD zones, and choose a sensible replication scope — to all DNS servers in the forest or in the domain, depending on whether other domains need the zone.

Forwarders and external resolution#

DCs are authoritative for your internal AD zones, but they still need to resolve internet names (Windows Update, certificate revocation lists, Microsoft 365 endpoints, and so on). That’s what forwarders are for.

Configure forwarders in the DNS Server role to point at a reliable upstream resolver:

• Your ISP’s DNS servers, or
• A public resolver such as 1.1.1.1 or 8.8.8.8.

# Configure DNS forwarders to public resolvers
Set-DnsServerForwarder -IPAddress "1.1.1.1","8.8.8.8" -UseRootHint $true

If you don’t set forwarders, DNS falls back to root hints, which work but are slower and less predictable for general internet resolution. Most environments prefer explicit forwarders.

For resolving names in another internal domain (a partner company, a separate forest, or a non-AD internal zone), use conditional forwarders so only queries for that namespace go to its DNS servers, while everything else still follows your normal forwarders.

Verify the configuration#

Once it’s set, confirm the DC’s DNS is healthy:

ipconfig /all
dcdiag /test:dns /v

ipconfig /all confirms the client-side server list (partner first, loopback second, no public resolvers). dcdiag /test:dns checks record registration, forwarders, delegation, and dynamic update health across the board. Clean results here prevent a long list of downstream AD problems.

Wrapping up#

Good DC DNS comes down to a few habits. Point each DC’s primary DNS at a partner and keep loopback as the secondary so you never island a DC at boot. Keep your AD zones AD-integrated with secure-only updates so DNS replicates with the directory and resists tampering. Send external lookups through forwarders rather than stuffing public resolvers into the client settings. Then verify it all with dcdiag /test:dns.

None of this is complicated, but the cost of getting it wrong is high and the symptoms rarely point at DNS directly. Set it correctly once, audit it whenever you inherit a domain, and re-check it any time you add or retire a domain controller.