Active Directory — Part 8 — DNS & Active Directory

Introduction

Throughout this series, we have quietly assumed that clients can find their Domain Controllers. Workstations authenticate, Group Policy applies, replication partners connect. But nothing in a domain is configured with a Domain Controller’s IP address.

So how does a freshly booted workstation, which knows nothing except its own network settings and the name of its domain, find a Domain Controller to log into?

The answer is DNS. Active Directory does not just use DNS — it is structurally built on it. The domain name itself is a DNS name. Every service AD offers is advertised in DNS. Remove DNS, and Active Directory does not degrade. It stops.

Why AD Is Completely Dependent on DNS

When Microsoft designed Active Directory for Windows 2000, it replaced the old NetBIOS-based discovery of NT 4.0 with DNS. The domain corp.example.com is simultaneously an AD domain and a DNS zone, and that is not a coincidence — it is the design.

Every significant AD operation begins with a DNS lookup. A workstation logging on queries DNS to find a Domain Controller. Kerberos, covered in Part 5, queries DNS to find a KDC. Replication partners from Part 7 resolve each other through DNS records. Domain joins, Group Policy processing, and trust authentication all start the same way.

The Switchboard Analogy

Think of DNS in an AD environment like the switchboard operator in an old office building.

You do not know anyone’s extension number. You pick up the phone and say: connect me to someone in payroll. The operator keeps the directory, knows which desks belong to payroll, knows who is in today, and connects you to the nearest available person.

SRV records are that directory. A client never asks for a server by name — it asks for a service: give me a Domain Controller for this domain, give me a Kerberos KDC, give me a Global Catalog. DNS answers with the list of servers currently offering that service.

SRV Records: The Service Directory

When a Domain Controller starts, its Netlogon service registers a set of SRV records in DNS, advertising every service it offers. These records live under special subdomains of the zone, and their names follow a strict pattern.

The _msdcs subdomain also holds one record per DC that Part 7 quietly depends on: a CNAME named after the DC’s replication GUID. When one Domain Controller replicates from another, it resolves that CNAME first. Broken _msdcs records mean broken replication.

Step 1: The Client Asks DNS

A workstation needing a Domain Controller — at boot, at logon, or when its cached DC stops responding — queries DNS for the SRV records of its domain. If it already knows which site it is in, it asks for the site-specific records first.

Step 2: DNS Returns Candidates

DNS answers with the list of Domain Controllers advertising the service, each with a hostname, port, priority, and weight. This is a list of candidates, not a final answer — DNS only knows who registered, not who is currently healthy.

Step 3: The LDAP Ping

The client sends a small probe, called an LDAP ping, to the candidates. The first healthy DC that responds also tells the client which site it belongs to, based on the client’s IP subnet — using the site and subnet definitions from Part 7.

Step 4: Affinity and Caching

If the responding DC says a closer one exists in the client’s own site, the client re-queries for that site and settles on a nearby DC. The result is cached, and the workstation now has its Domain Controller — found entirely through DNS, with no configuration on the client beyond its DNS server address.

The Flow at a Glance

[Client]  ─── SRV query: _ldap._tcp.corp.example.com ──▶ [DNS Server]
[Client]  ◀── list: DC1, DC2, DC3 (ports + priority) ─── [DNS Server]

[Client]  ─── LDAP ping (are you alive? which site?) ──▶ [DC1]
[Client]  ◀── "alive - your subnet belongs to Mangalore" ─ [DC1]

[Client]  ─── SRV query: _ldap._tcp.Mangalore._sites... ▶ [DNS Server]
[Client]  ◀── nearest DC ─────────────────────────────── [DNS Server]
[Client]  ─── authenticate (Kerberos, Part 5) ─────────▶ [Nearest DC]

AD-Integrated Zones

DNS for an AD domain is almost always hosted on the Domain Controllers themselves, using AD-integrated zones. Instead of living in a text file on one primary server, the zone data is stored inside the directory database and replicated through the same machinery covered in Part 7 — typically in an application partition that reaches every DNS-hosting DC.

This buys three things. Every DC running DNS holds a writable copy of the zone, so there is no single point of failure for DNS updates. Zone data rides existing AD replication instead of needing separate zone transfers. And it enables secure dynamic updates — machines register and refresh their own records, but only after authenticating, which stops a rogue device from overwriting the record of a real server.

What Happens When DNS Breaks

DNS failures almost never announce themselves as DNS failures. They surface as symptoms scattered across everything that sits above DNS.

Logons turn slow or fall back to cached credentials. Domain joins fail with “domain could not be contacted”. Group Policy stops applying because the client cannot find SYSVOL. Replication starts logging DNS lookup failures — as we saw in Part 7’s troubleshooting table. Kerberos falls back to NTLM or fails outright. Each symptom points at a different subsystem; the cause is one layer down.

The failure modes are mundane: a DC pointing at the wrong DNS server, missing SRV records after a zone was rebuilt, stale records for a decommissioned DC that clients still try to reach, or firewall rules blocking UDP and TCP port 53.

How DCs Themselves Should Point at DNS

The Domain Controllers’ own DNS client settings matter more than any other machine’s. The widely used pattern: each DC lists another DC as its primary DNS server and itself second — commonly as the loopback address 127.0.0.1. Pointing a DC only at itself can slow directory startup after reboots and hide replication problems; pointing it at a partner first keeps discovery working even while its own DNS service is still starting.

For names outside the company — the internet — internal DNS servers use forwarders to a chosen upstream resolver. Clients never talk to public DNS directly; they ask internal DNS, and internal DNS forwards what it cannot answer.

Scripts / Commands

Use the commands below to verify SRV records exist, test DC discovery, and check DNS health on Domain Controllers. All are read-only except ipconfig /registerdns and dcdiag /fix.

# Verify the critical SRV record for DC discovery
nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example.com

# Verify Kerberos KDC records
nslookup -type=SRV _kerberos._tcp.corp.example.com

# Ask the DC locator to find a DC right now - the end-to-end test
nltest /dsgetdc:corp.example.com

# Find a DC in a specific site
nltest /dsgetdc:corp.example.com /site:Mangalore

# Run the DNS-specific health tests on a DC
dcdiag /test:dns

# Re-register this machine's DNS records
ipconfig /registerdns

# Re-register a DC's SRV records by restarting Netlogon
net stop netlogon && net start netlogon

# PowerShell: resolve the SRV records
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example.com

# PowerShell: list zones hosted on a DC and how they are stored
Get-DnsServerZone | Select-Object ZoneName, ZoneType, IsDsIntegrated

# PowerShell: check which DNS servers a DC's own NIC points at
Get-DnsClientServerAddress -AddressFamily IPv4

Troubleshooting Cheat Sheet

Quick Reference Summary

Final Thoughts

DNS is the least glamorous dependency Active Directory has, and the most absolute. Kerberos can fall back to NTLM, a failed DC can be covered by another — but nothing covers for DNS, because DNS is how everything else is found in the first place.

The good news is that DNS problems are cheap to detect. Two commands — an SRV lookup and nltest /dsgetdc: — prove the discovery chain end to end, and they belong at the top of every AD troubleshooting session, before anything more exotic is considered.