DNS and Active Directory: How They Work Together
SRV Records, DC Locator, Site Awareness, and the Symbiotic Relationship That Makes AD Work
1. Objective – Understanding the AD-DNS Symbiosis
In Part 1, we learned DNS fundamentals. In Part 2, we deployed DNS on Windows Server. Now, we’ll explore the deep, inseparable relationship between DNS and Active Directory.
By the end of this lab, you’ll understand:
- How AD uses DNS for service discovery via SRV records
- The DC Locator process – how clients find domain controllers
- How site awareness works and why it matters
- How to troubleshoot AD DNS issues like a pro
2. The Heart of AD: SRV Records
AD depends on Service Location (SRV) records to locate critical services. Without these records, clients cannot find domain controllers, Kerberos services, or Global Catalog servers.
2.1 The Critical SRV Records
LDAP
_ldap._tcp.dc._msdcs.<domain>
Finds domain controllers for LDAP queries (port 389).
Kerberos
_kerberos._tcp.dc._msdcs.<domain>
Finds domain controllers for Kerberos authentication (port 88).
Global Catalog
_gc._tcp.<domain>
Finds Global Catalog servers (port 3268).
LDAP SSL
_ldap._tcp.<domain>
Finds domain controllers for secure LDAP (port 636).
Site-Aware
_ldap._tcp.<sitename>._sites.dc._msdcs.<domain>
Finds domain controllers in a specific AD site.
PDC Emulator
_ldap._tcp.pdc._msdcs.<domain>
Finds the Primary Domain Controller Emulator.
2.2 View SRV Records in DNS Manager
Open DNS Manager → Expand your zone → _msdcs.corp.lab → dc → _tcp. You’ll see all the SRV records.
2.3 Query SRV Records with PowerShell
# Find all domain controllers
Resolve-DnsName -Name _ldap._tcp.dc._msdcs.corp.lab -Type SRV
# Find Global Catalog servers
Resolve-DnsName -Name _gc._tcp.corp.lab -Type SRV
# Find Kerberos services
Resolve-DnsName -Name _kerberos._tcp.dc._msdcs.corp.lab -Type SRV
3. The _msdcs Zone – AD’s Special Namespace
When you promote a server to a domain controller, a special subdomain is created: _msdcs.<domain>. This zone contains all critical AD SRV records and replicates via Active Directory.
3.1 Understanding the _msdcs Zone
- It’s a forest‑wide zone – replicated to all domain controllers in the forest.
- It contains records for LDAP, Kerberos, Global Catalog, and other AD services.
- The zone is automatically created during domain promotion.
- It’s stored in the ForestDnsZones AD partition.
3.2 Inspect the _msdcs Zone
# List all DNS zones
Get-DnsServerZone
# Export _msdcs records
Get-DnsServerResourceRecord -ZoneName "_msdcs.corp.lab" | Select-Object RecordName, RecordType, RecordData
_msdcs zone is missing or corrupted, AD will fail. Never manually delete this zone. To fix, restart the Netlogon service or run netdiag /fix.
4. The DC Locator Process – How Clients Find Domain Controllers
When a client needs to authenticate, it must find a domain controller. The DC Locator process handles this in a specific sequence.
4.1 The DC Locator Steps
- Check Cache – The client first checks its local cache for a previously discovered DC.
- DNS Query (Site‑Aware) – Queries
_ldap._tcp.<sitename>._sites.dc._msdcs.<domain>. - DNS Query (Domain‑Wide) – Queries
_ldap._tcp.dc._msdcs.<domain>. - DNS Query (GC) – If needed, queries
_gc._tcp.<domain>. - Fallback – If DNS fails, the client may try NetBIOS or use a cached DC.
DC Locator process – client finds a domain controller via DNS SRV records
4.2 Lab – Trace the DC Locator
# Use nltest to see the DC discovery process in real-time
nltest /dsgetdc:corp.lab
# Detailed output with site awareness
nltest /dsgetdc:corp.lab /FORCE
# See all DCs in the domain
nltest /dclist:corp.lab
5. Site Awareness – Optimizing Authentication
AD sites are logical groupings of subnets. DNS helps clients find domain controllers in their own site, reducing WAN traffic and improving performance.
5.1 How Site Awareness Works
- Each domain controller registers SRV records for every site it belongs to.
- Clients query
_ldap._tcp.<sitename>._sites.dc._msdcs.<domain>. - If no DC exists in the client’s site, it falls back to domain‑wide SRV records.
5.2 Lab – View Site‑Specific SRV Records
# Replace 'Default-First-Site-Name' with your actual site name
Resolve-DnsName -Name _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.corp.lab -Type SRV
# List all sites
Get-ADReplicationSite -Filter *
6. DNS and AD Replication
AD replication relies on DNS to locate replication partners. Each domain controller registers records that other DCs use to initiate replication.
6.1 Replication SRV Records
# Find replication partners for a DC
Resolve-DnsName -Name _ldap._tcp.<domain> -Type SRV
# View replication topology
repadmin /showrepl
6.2 Lab – Check Replication Health
# Run replication diagnostic
repadmin /replsum
# Force replication and watch DNS lookups
repadmin /syncall /A /e /P
7. Troubleshooting AD DNS Issues
7.1 Common Issues and Fixes
Issue: “The specified domain either does not exist or could not be contacted.”
- Cause: Client cannot resolve SRV records for the domain.
- Fix: Check DNS resolution, ensure the client uses the correct DNS server.
Issue: SRV records missing from DNS
- Cause: Netlogon service may not have registered the records.
- Fix: Restart Netlogon:
net stop netlogon && net start netlogon.
Issue: DC not responding to site‑aware queries
- Cause: Site‑specific SRV records not registered.
- Fix: Verify the site name in AD Sites and Services matches the DNS query.
7.2 Lab – Run Comprehensive DNS Diagnostics
# DNS test with dcdiag
dcdiag /test:DNS /v
# Focus on specific DNS issues
dcdiag /test:RegisterInDNS /v
# Check DNS registration status
Get-DnsServerResourceRecord -ZoneName "corp.lab" -RRType A | Where-Object { $_.RecordName -like "*dc*" }
8. Lab: AD DNS Hardening
Apply these DNS security settings to protect your AD environment.
8.1 Secure Dynamic Updates
Ensure only AD‑authenticated users can update DNS records:
# Check current zone update settings
Get-DnsServerZone -Name "corp.lab" | Select-Object Name, DynamicUpdate
# Set to secure updates only
Set-DnsServerZone -Name "corp.lab" -DynamicUpdate Secure
8.2 Restrict Zone Transfers
# Allow transfers only to specific DNS servers
Set-DnsServerZoneTransfer -Name "corp.lab" -Type "OnlyToSpecificServers" -Server 10.10.10.97
8.3 Protect _msdcs Zone
# Ensure _msdcs zone is AD‑integrated and secured
Get-DnsServerZone -Name "_msdcs.corp.lab" | Select-Object Name, ZoneType, DynamicUpdate
_msdcs zone to “None” – this will break AD.
9. Emergency Rollback Procedures
9.1 Force Register AD Records
# Stop and restart Netlogon to re-register all SRV records
net stop netlogon
net start netlogon
# Force registration immediately
nltest /dsregdns /force
9.2 Manually Add a Missing SRV Record
# Add a missing LDAP SRV record for a DC
Add-DnsServerResourceRecord -ZoneName "_msdcs.corp.lab" -Name "_ldap._tcp.dc._msdcs" -SRV -DomainName "dc01.corp.lab" -Port 389 -Priority 0 -Weight 100
9.3 Rebuild the _msdcs Zone (Last Resort)
# If the _msdcs zone is completely missing:
# 1. Demote and re-promote the DC, or
# 2. Run: dcdiag /fix
# 3. Then restart Netlogon
_msdcs zone should be a last resort. If you must, ensure you have a full AD backup and understand the risks.
10. Key Takeaways
- SRV records are the foundation of AD service discovery.
- The _msdcs zone is critical – it contains all AD service records.
- The DC Locator process uses DNS in a specific, site‑aware sequence.
- Site awareness optimises authentication and reduces WAN traffic.
- dcdiag, nltest, and repadmin are your go‑to tools for AD DNS troubleshooting.
- Secure dynamic updates protect your AD DNS from unauthorised changes.
🔄 Next Steps – Dynamic DNS, Secure Updates & Scavenging
You now understand how DNS and AD work together. Next, we’ll dive into how clients register their own records and how to keep your zone clean.
👉 Part 4 – Dynamic DNS, Secure Updates & Scavenging
We’ll explore client registration, secure updates, scavenging configurations, and how to troubleshoot registration failures.