Learn Active Directory - DNS Integration with Active Directory

#Introduction

In episode 3, you understood AD's physical structure — sites, subnets, and replication. Now we touch the component that most often makes AD "not work" without ever breaking: DNS. If clients can't log in, the number one cause is almost always DNS, not AD itself.

Remember the analogy from episode 0: DNS is the phone book. Imagine a phone book that's wrong — the numbers are incorrect or pages are missing. The house (AD) still exists and works, but nobody can find it. Most mysterious AD problems are rooted in something this small.

#Why AD Needs DNS

AD is completely dependent on DNS for two big things:

• Name resolution: clients and DCs must translate computer names and domain names into IP addresses.
• Locating services: clients need to find services like authentication (LDAP and Kerberos) by querying DNS via SRV records.

Unlike other directory services that can run without DNS, AD actually uses DNS as its locator service. The domain controller list, service locations, even AD sites are discovered through DNS. Without correct DNS, a domain controller can be perfectly healthy yet never found by anyone.

#The DC Locator Process

When a computer wants to join a domain or a user wants to log in, a process called DC locator runs. The flow roughly looks like this:

1. The client knows its domain name, e.g. ad.example.com.
2. The client asks DNS: is there a DC serving ad.example.com?
3. DNS answers with a list of SRV records pointing to domain controllers.
4. The client picks the nearest DC based on its site, then contacts that DC for authentication.

This process is "site-aware": with subnets mapped (episode 3), the client first looks for a DC in its own site before going to another site. If DNS is wrong or an SRV record is missing, the client never reaches step 4 — and the errors that appear are often confusing, like "domain not found" while the DC is actually online.

#AD-Integrated Zones

Normal DNS zones are stored in a zone file on a single DNS server. AD introduced AD-integrated zones: zone data is stored in the Active Directory partition instead of a text file. The consequences are significant:

• Multi-master: every DC that's a DNS server holds a copy of the zone and can accept changes.
• Built-in replication: zone data replicates alongside AD data, so no separate secondary zone transfer is needed.
• Secure dynamic updates: only authenticated computers (already domain-joined) may update their records, preventing DNS poisoning by outsiders.

Because replication is automatic, an AD-integrated zone is the right default choice when DNS is installed together with AD.

#The _msdcs Zone and SRV Records

When AD is installed, besides the normal domain zone, a special zone named _msdcs.ad.example.com is created. This is a forest-wide zone that stores all the critical SRV records and must replicate across the entire forest — not just one domain.

SRV records (Service Records) tell clients which services are available and where. Their format is distinctive: the service name followed by _tcp or _udp, then the domain name. Key examples:

Each SRV record contains the service port and the host providing it. Clients use these records to find DCs; if a record is missing or wrong, the DC might as well not exist.

#DNS Records for Domain Controllers

Besides SRV, a DC registers several other records automatically when it joins AD:

This registration is dynamic — DCs and domain-joined computers register their own records. That's why you should never disable dynamic updates in an AD zone; manually frozen records go stale and start pointing to wrong addresses.

#Conditional Forwarders

A conditional forwarder is a DNS setting that answers: for a specific domain, forward queries to a specific DNS server. It's used when your domain needs to resolve names in another domain whose DNS you don't control — for example, another forest's domain or an external vendor.

Unlike a global forwarder (all unknown queries get forwarded), a conditional forwarder is specific per domain, so it's more targeted. It can be configured from DNS Manager or PowerShell:

Set-DnsServerConditionalForwarderZone -Name "partner.example.net" -MasterServers "10.0.0.53" -UseRecursion

Without a correct conditional forwarder, forest trusts or integration with other systems often fail with name-resolution errors that are hard to trace.

#DNS Troubleshooting

Most DNS problems in AD can be traced with two tools: nslookup to inspect records, and dcdiag for a comprehensive diagnosis. Verify DC SRV records:

nslookup -type=SRV _ldap._tcp.dc._msdcs.ad.example.com

Correct output shows one or more DC hosts complete with port and weight. If the answer is "Non-existent domain" or empty, the zone or SRV records are at fault.

For a comprehensive diagnosis, use dcdiag, which runs a suite of tests including DNS:

dcdiag /test:dns

Besides those two tools, watch the DNS Server event log for traces of failed updates, and always start from the most basic question: "Does the SRV record actually exist in the right zone?" The answer is often there. Another effective troubleshooting pattern: force the DC to re-register its records by restarting the Netlogon service on the DC.

#Conclusion

In episode 4 you understand why DNS is AD's lifeline: DNS is the locator service clients use to find DCs, AD-integrated zones replicate DNS data together with AD, the _msdcs zone stores critical service SRV records, and conditional forwarders bridge other namespaces.

Key takeaways:

• AD cannot function without DNS; most login problems are rooted in DNS.
• The _ldap, _kerberos, _gc, and _kpasswd SRV records are the key to the DC locator process.
• AD-integrated zones with dynamic updates are the correct default configuration.
• nslookup -type=SRV and dcdiag /test:dns are the first tools for DNS troubleshooting.

In the next episode, all this theory will be proven: installing Active Directory Domain Services — from prerequisites, installing the AD DS role via PowerShell, promoting the first domain controller with Install-ADDSForest, to verifying with dcdiag and ntdsutil. Make sure your lab's DNS is ready, because this is the episode where your first domain is born!