Active directory dns problems rarely look like DNS problems. Active Directory doesn’t use DNS the way a web browser does — it needs service-location records that tell every client, DC, and application where to find authentication, replication, and Group Policy services. When those records are missing, wrong, or stale, the failure surfaces as “users can’t log in,” “replication is broken,” or “Group Policy isn’t applying.” DNS is the root cause far more often than the symptom suggests.
The single highest-yield first step on any AD failure is ruling out active directory dns problems. Start there before chasing firewalls, permissions, or service failures.
- Run
dcdiag /test:DNS /v /e /f:dns.txtas the first step on any active directory dns problems investigation — read the summary table at the bottom first, then work backward to the failing DC. - Every DC’s NIC primary DNS must point at a partner DC in the same site. External resolvers (8.8.8.8, 1.1.1.1) as primary DNS on a DC breaks SRV discovery entirely.
- AD-integrated zones replicate automatically through AD. Standard Primary zones don’t — a new DC gets an empty zone and can’t register its records.
- DNS scavenging misconfiguration causes two opposite active directory dns problems: disabled means stale records accumulate; overly aggressive means live records get deleted.
- On Windows Server 2025, NetBIOS-based DC discovery is blocked by default — correct DNS is no longer optional.
What Active Directory DNS Problems Start With: DNS Requirements
Active directory dns problems almost always trace back to one of two things: missing or incorrect SRV records, or a DNS server that the DC can’t reach or trust. Active Directory uses DNS as its locator service. Every domain controller registers service records (SRV) via the Netlogon service at startup, on restart, and once per hour to keep them current.
The complete set of required records is documented in %systemroot%\System32\Config\Netlogon.dns on every DC — use it as a reference when verifying registration manually. The authoritative SRV record specification is covered in Microsoft Learn: How Domain Controllers Are Located in Windows.
The critical SRV records AD depends on:
_ldap._tcp.<domain>
_ldap._tcp.dc._msdcs.<domain>
_ldap._tcp.<guid>.domains._msdcs.<forest>
_kerberos._tcp.<domain>
_kerberos._udp.<domain>
_kerberos._tcp.dc._msdcs.<domain>
_kpasswd._tcp.<domain>
_gc._tcp.<forest>
_ldap._tcp.gc._msdcs.<forest>
_ldap._tcp.pdc._msdcs.<domain> (PDC Emulator only)Beyond SRV records: each DC needs an A record, a GUID-based CNAME in _msdcs (used by replication partners to find each other), and PTR records in a reverse lookup zone. The GUID CNAME — <dsa-guid>._msdcs.<forest> — is what replication actually uses. Missing A records break client discovery. Missing GUID CNAMEs break DC-to-DC replication and produce error 1722.
AD-Integrated vs Standard Primary Zones
AD-integrated zones store records in the directory itself — either the DomainDnsZones or ForestDnsZones application partition — and replicate multi-master through AD replication. Every DC running DNS gets a writable, authoritative copy, and dynamic updates use Kerberos authentication. Standard Primary zones are a text file on one server that pushes to read-only secondaries via zone transfer. For AD, Standard Primary zones create a single point of failure, no secured dynamic updates, and no automatic replication to additional DCs.
The _msdcs.<forest root> zone must be forest-wide (ForestDnsZones) so schema and naming master roles resolve everywhere. Most other zones should be domain-scoped (DomainDnsZones).
The DC Self-Pointing Rule
A DC’s NIC primary DNS should point at a partner DC in the same site, with itself as the alternate. Never itself alone as primary, never an external resolver as primary.
A DC pointing only at itself can deadlock on reboot: DNS waits for AD initial sync, AD replication requires DNS to find partners, DNS can’t find partners — the cycle stalls. External resolvers (8.8.8.8, 1.1.1.1) as primary break SRV discovery entirely — public DNS has no knowledge of your AD namespace. Internet resolution belongs in forwarders configured on the DNS server, not on client NICs.
Diagnostic Toolkit for Active Directory DNS Problems
Before working through individual failure scenarios, these are the commands that matter most when diagnosing active directory dns problems. Use them in order on any AD failure before chasing anything else.
# Master DNS health check — all DCs in the enterprise
dcdiag /test:DNS /v /e /f:dns.txt
# Read the summary table at the bottom first:
# Columns: Auth Basc Forw Del Dyn RReg Ext
# Find FAIL/WARN, then search body for DC: <name>The dcdiag /test:DNS sub-tests and their meaning are documented in Microsoft Learn: Verify DNS functionality to support Active Directory. DnsBasic covers client config and zone presence; DnsRecordRegistration validates A, CNAME GUID, and all SRV records.
# SRV record verification
Resolve-DnsName _ldap._tcp.dc._msdcs.corp.local -Type SRV
nslookup -type=srv _ldap._tcp.dc._msdcs.corp.local
# DC discovery test (bypasses cache)
nltest /dsgetdc:corp.local /force
# Force DNS re-registration
net stop netlogon && net start netlogon
ipconfig /registerdns
# Zone status
Get-DnsServerZone | Select ZoneName,ZoneType,IsDsIntegrated,ReplicationScope
# Forwarder check
Get-DnsServerForwarder
# Scavenging configuration
Get-DnsServerScavengingFailure Scenario 1: SRV Records Missing — DC Not Discoverable
- Verify the records exist:
Resolve-DnsName _ldap._tcp.dc._msdcs.corp.local -Type SRV— empty result means SRV records aren’t registered. - Check NIC DNS config:
Get-DnsClientServerAddress— primary DNS must be an internal AD DNS server, not 127.0.0.1 alone, not a public resolver. - Verify the zone exists and is AD-integrated:
Get-DnsServerZone -Name corp.local— confirm IsDsIntegrated = True. - Re-register:
net stop netlogon && net start netlogonthenipconfig /registerdns— Netlogon registers SRV on startup. - Verify: re-run the SRV query; run
dcdiag /test:DNS /vand confirm RReg sub-test passes.
If the zone itself lacks the _msdcs and _sites subzones, dynamic registrations have nowhere to land. This happens when a Standard Primary zone was created manually without the proper delegations — convert to AD-integrated and the subzones appear automatically.
Failure Scenario 2: Clients Cannot Authenticate
Symptoms: logon delays, “no logon servers available,” intermittent authentication failures, Group Policy not applying. This is one of the most common active directory dns problems operators encounter. The misdiagnosis trap is spending time on the DC or network when the actual problem is the client’s NIC pointing at an external DNS server or a decommissioned DC’s IP.
# On the failing client
ipconfig /all # check DNS server addresses
nltest /dsgetdc:corp.local /force # should return a DC with WRITABLE/DNS_DC flags
Resolve-DnsName corp.local # should return DC IP(s)
ipconfig /flushdns
If nltest returns ERROR_NO_SUCH_DOMAIN (1355) and the client DNS is pointing at an external resolver or a dead IP, fix the DNS pointer first. DHCP is the usual delivery mechanism — check the DHCP scope options (006 DNS Servers) before chasing anything else.
Failure Scenario 3: Domain Join Failures
Domain join failures are a classic presentation of active directory dns problems — the machine can’t discover a DC because SRV records are missing or the client is querying the wrong DNS server.
Two common error codes, both DNS-rooted:
0x54B — “The specified domain either does not exist or could not be contacted.” The machine cannot discover a DC at all. Check: does the client resolve _ldap._tcp.dc._msdcs.corp.local? If not, its DNS is wrong.
0x216D — “DNS name does not exist.” The domain name doesn’t resolve. Same root cause — external DNS or missing zone.
# Run from the machine that's failing to join
nltest /dsgetdc:corp.local
Resolve-DnsName _ldap._tcp.dc._msdcs.corp.local -Type SRV
nslookup corp.local
# If DNS resolves but join still fails, check time skew:
w32tm /query /status # Kerberos fails if skew > 5 minutesDomain join failures almost always come down to three things: wrong DNS on the NIC, missing SRV records, or time skew. Rule out DNS first, time sync second, then look at firewall rules for ports 88, 389, 445.
Failure Scenario 4: Event ID 4013 — DNS Waiting for AD Sync
A single Event 4013 at DC startup is normal. DNS hosting AD-integrated zones waits for AD initial sync before loading zone data — this clears within a few minutes on a healthy DC.
Persistent Event 4013 — DNS console unreachable, zone loading stuck for 15–25 minutes — means the DC is islanded. It points only at itself or at an offline DNS partner, can’t complete inbound replication, and DNS can’t finish initialization. Fix: point preferred DNS at a reachable in-site partner DC. Remove stale DNS entries pointing at decommissioned DCs. After fixing pointers, reboot — DNS should start clean.
Failure Scenario 5: Event ID 4015 — DNS Critical Error
Event 4015 with extended error code 00002095: an RODC running DNS can’t reach a writable DC. Run nltest /dsgetdc:corp.local /WRITABLE /AVOIDSELF /TRY_NEXT_CLOSEST_SITE /DS_6 to verify writable DC reachability.
Code 0000051B: DNS can’t access an AD object — usually a permissions issue on the DNS application partition. Check with Get-Acl "AD:\DC=DomainDnsZones,DC=corp,DC=local".
ADMIN_LIMIT_EXCEEDED: orphaned records from demoted DCs accumulated in the zone, pushing a multi-valued attribute over its limit. Clean up stale NS records from decommissioned DCs (see Scenario 10).
Failure Scenario 6: Events 5774 and 5781 — Netlogon Registration Failures
Both are NETLOGON-source events logged when the DC’s SRV registration attempt fails. Event 5774 is the general “dynamic DNS registration failed” — the DC tried to register its records and couldn’t. Event 5781 is a repeated registration failure, usually meaning the DC keeps retrying and keeps failing.
Root causes: dynamic updates disabled on the zone, incorrect permissions on the AD-integrated zone, DNS server unreachable, or the zone isn’t AD-integrated so records can’t be securely written.
# Check zone dynamic update setting
Get-DnsServerZone -Name corp.local | Select DynamicUpdate
# Should be: Secure (for AD-integrated zones)
# Force re-registration and watch Event Viewer
nltest /dsregdns
ipconfig /registerdns
# Then verify
Resolve-DnsName _ldap._tcp.dc._msdcs.corp.local -Type SRVIf the zone shows DynamicUpdate: None, that’s the problem — set it to Secure for AD-integrated zones. If it shows NonSecureAndSecure, that’s a security risk (any host can overwrite DC locator records) — lock it down to Secure.
Failure Scenario 7: Replication Error 1722 Caused by DNS
Error 1722 is “The RPC server is unavailable.” It’s a generic RPC failure, and operators usually chase firewalls and ports first. DNS is the actual root cause roughly half the time.
What happens: the destination DC can’t resolve the source DC’s GUID-based CNAME (<dsa-guid>._msdcs.corp.local) to an A record. RPC connects to nothing, returns 1722.
- Get the source DC’s GUID from repadmin:
repadmin /showrepl— note the source DC name. - Resolve the GUID CNAME:
Resolve-DnsName <dsa-guid>._msdcs.corp.local -Type CNAME— failure here confirms DNS root cause. - Check the A record:
Resolve-DnsName dc02.corp.local— if it returns a wrong IP, DNS has a stale entry. - Re-register on the source DC:
net stop netlogon && net start netlogon, thenipconfig /registerdns. - If DNS resolves correctly: then check time skew (
w32tm /query /status— Kerberos fails if skew exceeds 5 minutes) and RPC port range (49152–65535 TCP). - Verify:
repadmin /syncall /AdePthenrepadmin /replsummary— should show no errors.
Events 2087 and 2088 in the NTDS Replication log are direct DNS signals — they appear when a DC can’t resolve a replication partner’s CNAME and falls back to NetBIOS. On Windows Server 2025, where NetBIOS DC discovery is blocked by default, 2087/2088 with no fallback means replication stops entirely.
Failure Scenario 8: DNS Zone Not Replicating Between DCs
A record created on DC1 never appears on DC2. A newly promoted DC has an empty zone and can’t register its own records.
# Check zone type and replication scope
Get-DnsServerZone | Select ZoneName,ZoneType,IsDsIntegrated,ReplicationScope
# Convert Standard Primary to AD-integrated
# DNS Manager: Zone Properties → Type → Change → Store in AD
# Or PowerShell:
Set-DnsServerPrimaryZone -Name "corp.local" -ReplicationScope "Domain"
Set-DnsServerPrimaryZone -Name "_msdcs.corp.local" -ReplicationScope "Forest"After converting, the zone appears on other DCs on the next AD replication cycle — not instantly. Multi-site environments add inter-site replication latency on top. Don’t conclude the fix failed after 60 seconds; wait for AD replication to complete or force it with repadmin /syncall /AdeP.
Failure Scenario 9: DNS Scavenging Misconfiguration
Scavenging misconfiguration is one of the more insidious active directory dns problems because the failure arrives weeks after the misconfiguration — long after anyone connects it to a DNS change. It produces two opposite failure modes. Disabled: stale records accumulate and clients reach decommissioned DCs or old server IPs. Overly aggressive: live records get deleted and authentication fails across the board.
Scavenging requires all three of these to be enabled: the record itself (timestamp set), the zone (aging configured), and at least one DNS server authorized to scavenge. If any one is missing, nothing gets cleaned. The most common trap is that the zone’s authorized scavenge server is a decommissioned DC — scavenging silently never runs.
# Check current scavenging config
Get-DnsServerScavenging
dnscmd /zoneinfo corp.local # shows ScavengingServers
# Re-point scavenge server to a live DNS server
dnscmd /zoneresetscavengeservers corp.local 192.168.1.10
# Safe defaults: 7 days no-refresh + 7 days refresh
Set-DnsServerScavenging -ScavengingState $true -ScavengingInterval 7.00:00:00
Set-DnsServerZoneAging -Name corp.local -Aging $true -NoRefreshInterval 7.00:00:00 -RefreshInterval 7.00:00:00Never run dnscmd /ageallrecords on an AD-integrated zone. It timestamps every record — including static ones — making them eligible for scavenging. Static DC and server A records created before scavenging was enabled will be deleted at the next scavenge cycle, typically within 14 days. The failure arrives weeks after the command was run and is rarely traced back to it.
Failure Scenario 10: Stale NS Records After DC Demotion
After demoting a DC, its NS records don’t always clean up automatically. If the old DC is still listed as an authoritative name server in the zone or as a delegation target in a parent zone, clients and other DCs periodically try to contact it, wait for timeout, then fall back to a working server. The result is intermittent resolution delays — fast most of the time, then a 15–30 second stall.
# List NS records in the zone
dnscmd /enumrecords corp.local @ /type NS
# List records in _msdcs
dnscmd /enumrecords _msdcs.corp.local @ /type NS
# Remove stale NS record for decommissioned DC
dnscmd /recorddelete corp.local @ NS dc-old.corp.local
# Check delegation NS in parent zone (if subdomain)
# DNS Manager → parent zone → delegations → NS tabAfter cleaning NS records, verify delegations in parent zones. If the decommissioned DC was listed there as a glue NS record, update those too. Event 4015 with ADMIN_LIMIT_EXCEEDED is often triggered by orphaned NS records from multiple decommissioned DCs accumulating in the zone’s multi-valued attribute.
Failure Scenario 11: Global Catalog DNS Problems
Applications that need a Global Catalog — Exchange, Skype for Business, multi-domain logons — discover it via DNS. Missing GC SRV records mean these applications either fail entirely or fall back to trying every DC, producing slow authentication and event log noise.
# Verify GC SRV records exist
Resolve-DnsName _gc._tcp.corp.local -Type SRV
Resolve-DnsName _ldap._tcp.gc._msdcs.corp.local -Type SRV
# Confirm DC is advertising as GC
nltest /dsgetdc:corp.local /gc
# Check GC role on DC
(Get-ADDomainController -Identity DC01).IsGlobalCatalogIf GC SRV records are missing but the DC has the GC role enabled, it’s a Netlogon registration problem — restart Netlogon and re-register DNS. If the GC role is disabled, enable it in Active Directory Sites and Services (DC → NTDS Settings → General → Global Catalog checkbox). GC records won’t register until the role is active, which takes a few minutes and a replication cycle after enabling.
Failure Scenario 12: Conditional Forwarder Misconfiguration
Cross-forest trusts and cross-domain name resolution depend on conditional forwarders. A conditional forwarder pointing at a dead IP, or one that was toggled to “Store in Active Directory” when it shouldn’t be, causes intermittent cross-domain failures that don’t appear in local DNS diagnostics.
# List conditional forwarders
Get-DnsServerZone | Where ZoneType -eq Forwarder | Select ZoneName,MasterServers
# Verify a forwarder resolves the target namespace
Resolve-DnsName _ldap._tcp.dc._msdcs.remote.forest -Type SRV -Server <forwarder-IP>
# Remove and recreate a broken forwarder
Remove-DnsServerZone -Name remote.forest
Add-DnsServerConditionalForwarderZone -Name remote.forest -MasterServers 192.168.2.10A known Windows behavior: toggling “Store this conditional forwarder in Active Directory” can corrupt the forwarder configuration. If conditional forwarders that were previously AD-replicated are behaving erratically, remove them and recreate as non-replicated on each DNS server individually — more maintenance, but more predictable.
Failure Scenario 13: Reverse Lookup Zone Problems
Reverse DNS isn’t strictly required for AD to function, but its absence creates operational pain that compounds over time. Monitoring systems display IP addresses instead of hostnames. PTR-dependent tools produce warnings that distract from real issues. And some AD-aware applications that do reverse lookups on DC IPs fail or degrade silently.
# Test reverse resolution
nslookup 192.168.1.10
Resolve-DnsName 192.168.1.10
# List reverse lookup zones
Get-DnsServerZone | Where ZoneName -like "*.arpa"
# Create reverse lookup zone if missing
Add-DnsServerPrimaryZone -NetworkId "192.168.1.0/24" -ReplicationScope "Domain"
# If zone exists but PTR records are missing, re-register
ipconfig /registerdns # registers PTR if DHCP/DNS is configured to do soDHCP servers handle PTR registration for client machines. DC PTR records should be registered statically or via ipconfig /registerdns on the DC itself. Verify DHCP scope options include the correct DNS server for PTR writes — DHCP registering PTR records against the wrong DNS server creates orphaned records that never appear in the zone you’re checking. The full guidance on DNS dynamic update behavior is at Microsoft Learn: DNS Dynamic Update with DHCP.
Failure Scenario 14: DHCP Overwriting DC Records
DHCP performing dynamic DNS updates with its computer account causes two failure modes. First: the DHCP server becomes the owner of a record that a DC or server should own — the DC can no longer update its own A record because it doesn’t have write permission. Second: DHCP overwrites a static server record with a wrong IP after a scope change.
# Set dedicated credentials for DHCP DNS updates
# Run on each DHCP server:
netsh dhcp server set dnscredentials dhcpdns-update@corp.local *
# Check who owns a DNS record
$record = Get-DnsServerResourceRecord -ZoneName corp.local -Name dc01 -RRType A
# Owner visible via ADSI Edit: CN=dc01,DC=corp,DC=local in DomainDnsZones
# Prevent DHCP from updating static records:
# DHCP scope → DNS tab → uncheck "Enable DNS dynamic updates"
# for records that should be staticDon’t use the DnsUpdateProxy security group with a DHCP server that’s co-located on a DC. DnsUpdateProxy members create records with no security — any authenticated user can overwrite them, including DC locator SRV records. Use a dedicated credential instead.
Event ID Reference for Active Directory DNS Problems
The table below covers the Event IDs most commonly associated with active directory dns problems, across DNS, NETLOGON, replication, and Group Policy sources.
| Event ID | Source | Description | Action |
|---|---|---|---|
| 4013 | DNS | Waiting for AD initial sync — normal at boot | Persistent: fix DC DNS pointers |
| 4015 | DNS | Critical DNS error from AD | Check extended error code — 2095=RODC, 051B=permissions, ADMIN_LIMIT=orphaned NS |
| 4000 | DNS | DNS can’t initialize — AD unavailable | Verify AD services and replication |
| 4007 | DNS | Can’t load AD-integrated zone | Check zone type, AD replication, zone permissions |
| 4010 | DNS | Corrupted or inconsistent DNS record | Run dcdiag /test:dns, clean orphaned records |
| 5774 | NETLOGON | Dynamic DNS registration failed | Check zone dynamic update setting and DNS reachability |
| 5781 | NETLOGON | DNS registration failure (repeated) | Verify zone is AD-integrated and accepts secure updates |
| 2087 | NTDS Replication | Replication partner CNAME unresolvable | Fix GUID CNAME registration on source DC |
| 2088 | NTDS Replication | DNS fallback during replication | Fix DNS; on Server 2025 there is no NetBIOS fallback |
| 1030 | Userenv/GroupPolicy | Cannot query Group Policy objects | Verify DNS, then SYSVOL/DFSR health |
| 1058 | Userenv/GroupPolicy | Cannot read gpt.ini from SYSVOL | Verify DNS and SYSVOL share accessibility |
Events 1030 and 1058 look like Group Policy or SYSVOL failures. DNS is a common root cause — a DC that can’t resolve its own domain name can’t locate SYSVOL either. Always verify DNS health before investigating SYSVOL replication independently.
Windows Server 2025: Active Directory DNS Problems and What Changed
The core AD-DNS structure is unchanged from Server 2019/2022: same SRV records, same Netlogon.dns, same self-pointing rules, same dcdiag workflow. The active directory dns problems you’ll encounter are the same — but Server 2025 removes the fallbacks that used to hide them. What changed:
NetBIOS DC discovery is blocked by default. The BlockNetBIOSDiscovery Net Logon Group Policy setting defaults to TRUE on Server 2025. DC Locator no longer falls back to NetBIOS-based location — DNS is the only path. Events 2087/2088 (DNS fallback to NetBIOS) now mean replication stops rather than degrading gracefully. Correct SRV registration is no longer just best practice.
DC Locator performance counters are new — they expose DC-locator requests per second, success/failure latency, and Netlogon cache hits and misses. Useful for spotting DNS-driven locator failures at scale before they surface as authentication complaints.
wmic.exe is disabled by default and pending full removal. Migrate any DNS management scripts using WMI to PowerShell DNS cmdlets (Get-DnsServerZone, Set-DnsServerPrimaryZone, Get-DnsServerScavenging) and Get-CimInstance.
Server-side DNS over HTTPS (DoH) reached general availability with the June 2026 cumulative update. Enable it with Set-DnsServerEncryptionProtocol -EnableDoh $true -UriTemplate "https://dns.corp.local:443/dns-query". It covers client-to-resolver traffic only — zone transfers, dynamic updates, and forwarder queries remain unencrypted.
Active Directory DNS Problems — Common Misconfigurations Quick Reference
| Misconfiguration | Failure Mode | Fix |
|---|---|---|
| DC primary DNS = 127.0.0.1 only | Deadlock on reboot, Event 4013 persistent | Primary = partner DC, alternate = self |
| DC primary DNS = 8.8.8.8 | SRV records not found, clients can’t discover DC | Primary = internal AD DNS server |
| Zone type = Standard Primary | Zone doesn’t replicate, new DCs get empty zone | Convert to AD-integrated |
| _msdcs zone = Domain scope | Cross-domain replication failures, GC not found forest-wide | Set ReplicationScope = Forest |
| Scavenging disabled | Stale records accumulate, clients hit dead IPs | Enable with 7+7 day intervals |
| Scavenge server is decommissioned DC | Scavenging silently never runs | Reset with dnscmd /zoneresetscavengeservers |
| Dynamic updates = NonSecureAndSecure | Any host can overwrite DC locator records | Set to Secure on AD-integrated zones |
| DHCP using DnsUpdateProxy on co-located DC | DC locator records have no security, overwritable | Use dedicated DHCP credential instead |
| Stale NS records post-demotion | Intermittent timeouts, eventual Event 4015 ADMIN_LIMIT | Clean with dnscmd /recorddelete |
| Conditional forwarder pointing at dead IP | Cross-domain/trust resolution fails intermittently | Update master servers, recreate if corrupt |
Final Thoughts
Most AD troubleshooting guides start with the symptom. Active directory dns problems are worth inverting that approach — start with DNS health on every AD failure, regardless of what the symptom looks like. A clean dcdiag /test:DNS /v /e output narrows the remaining problem space significantly. A failing one usually tells you exactly where to look.
The two misconfigurations that cause disproportionate pain relative to how easily they’re prevented: DC DNS pointers (wrong primary DNS creates islanded DCs) and scavenging (wrong configuration produces active directory dns problems weeks later, long after the misconfiguration is forgotten). Both are trivial to verify and trivial to fix before they become incidents.
For SYSVOL and DFSR failures that appear after DNS is confirmed healthy, see SYSVOL Replication Issues in Active Directory: DFSR Troubleshooting. For AD replication errors beyond DNS root causes, see Active Directory Replication Not Working: How to Diagnose and Fix. When Kerberos authentication fails after DNS is clean, time synchronization is the next check — see Active Directory Time Synchronization: PDC Emulator, w32tm, and Kerberos Failures.
FAQ
How do I know if my active directory dns problems are caused by a missing SRV record or something else?
Run Resolve-DnsName _ldap._tcp.dc._msdcs.<domain> -Type SRV from a client and from the DC itself. If the SRV query returns results from the DC but not from the client, the client is hitting a different DNS server than the DC uses. If it returns nothing from either, SRV records aren’t registered — restart Netlogon on the DC and check the zone exists and is AD-integrated.
Is Event ID 4013 a problem or can I ignore it?
One instance at DC startup is normal and self-resolves within a few minutes. Repeated occurrences, or a DNS console that stays inaccessible for more than 10 minutes after boot, indicate the DC is islanded — it can’t complete initial AD replication because its DNS pointers are wrong. Fix the NIC DNS configuration first.
Why does active directory replication error 1722 keep appearing even after I’ve checked firewall rules?
Because 1722 is an RPC error, not a firewall error. The most common cause is that the destination DC can’t resolve the source DC’s GUID-based CNAME record in _msdcs. Run repadmin /showrepl to get the source DC’s GUID, then Resolve-DnsName <guid>._msdcs.<domain> -Type CNAME. If that fails, DNS is the root cause — fix it before opening firewall tickets.
What’s the correct DNS configuration for a domain controller’s NIC?
Preferred DNS: a partner DC in the same AD site. Alternate DNS: the DC’s own IP (not 127.0.0.1). Internet resolution goes in forwarders configured on the DNS server, not on the NIC. A DC pointing only at itself as primary DNS can deadlock on reboot.
How often should DNS scavenging run?
Standard guidance is No-refresh interval and Refresh interval both set to 7 days, with scavenging running every 7 days. This means a stale record survives at most 21 days (7 no-refresh + 7 refresh + up to 7 days until next scavenge cycle). Intervals should be equal to or less than the DHCP lease duration — if DHCP leases are shorter than the scavenging no-refresh interval, dynamic clients can’t update their records before they’re marked stale.
Can active directory dns problems cause Group Policy failures even if users can log in?
Yes. Group Policy retrieves policy from SYSVOL, which is located via DNS. A DC with degraded DNS can authenticate Kerberos tickets (which are cached) while failing to resolve the path to SYSVOL for policy refresh. Events 1030 and 1058 in the System log indicate this pattern. Verify DNS health on the DC processing the policy before investigating SYSVOL permissions or replication.
Active Directory Series
14 articles — Windows Server 2025 · Forest & Domain · FSMO · GPO · Replication · DNS