DNS Server Service Crashing or Unresponsive — Event 4013 and 4015

Introduction

Power comes back after an outage, a domain controller boots, and it just sits there. Preparing network connections stays on screen for twenty minutes before the logon prompt finally appears, and opening DNSMGMT.MSC during that window fails with “the server could not be contacted.” A different day, a different domain controller, a different symptom: the DNS Server event log is filling up with critical errors every few minutes, the domain still resolves names fine, and nobody can tell whether this is actually broken or just noise.

Both of these trace back to how tightly the DNS Server service and Active Directory depend on each other on a domain controller. Event 4013 is the visible symptom of that dependency working as designed, just slowly. Event 4015 is what gets logged when something in that relationship is actually broken, and the fix depends entirely on which of three distinct causes triggered it.

What You’re Seeing

Event 4013 appears as a warning in the DNS Server event log, usually right after a reboot:

Event Type:  Warning
Event Source: DNS
Event ID:    4013
Description:
The DNS server was unable to open the Active Directory. This DNS server
is configured to use directory service information and can not operate
without access to the directory. The DNS server will wait for the
directory to start. If the DNS server is started but the appropriate
event has not been logged, then the DNS server is still waiting for
the directory to start.
Data:
0000: 000025f5

That trailing data value is a status code. The three you will actually see are 000025f5 (DNS_ERROR_DS_UNAVAILABLE — the directory service is unavailable), 0000232d (DNS_ERROR_RCODE_REFUSED), and 0000232a (DNS_ERROR_RCODE_SERVER_FAILURE). Event 4015 looks different and carries its own extended error string:

Log Name:  DNS Server
Source:    Microsoft-Windows-DNS-Server-Service
Event ID:  4015
Level:     Error
Description:
The DNS server has encountered a critical error from the Active
Directory. Check that the Active Directory is functioning properly.
The extended error debug information (which may be empty) is
"00002095: SvcErr: DSID-03210A6A, problem 5012 (DIR_ERROR), data 16".
The event data contains the error.

That same event ID also fires with an extended error of 0000051B (a permissions problem) or with ADMIN_LIMIT_EXCEEDED in the error text (an orphaned-record limit). All three render as the same generic-looking Event 4015, so the extended error string — not the event ID — is what tells you which of the three problems you actually have.

What It Actually Means

Think of Event 4013 as two people who have each agreed to speak only after the other one starts talking. The DNS Server service will not start until Active Directory has completed its initial inbound replication — its init sync — because the DNS zone data sitting in AD might be stale until that finishes. At the same time, Active Directory needs DNS working to resolve the CNAME GUID record of its replication partner into an IP address before it can pull that replication. If a domain controller points at another domain controller for DNS, and that domain controller points back at the first one, both machines can end up waiting on each other after a simultaneous reboot.

Microsoft’s own testing on this behaviour found the mechanism precisely: with a healthy DNS server already answering queries, resolving a replication partner’s address takes two DNS queries per naming context and returns almost instantly. With DNS unavailable, the same lookup falls back through GUID-based name, then fully qualified name, then NetBIOS name — ten queries per naming context instead of two, each one waiting out the full DNS query timeout (about 12 seconds by default) before giving up. Multiply that by five naming contexts — schema, configuration, domain, and the two DNS application partitions — and a 15 to 25 minute hang is the expected, not exceptional, result.

Event 4015’s three causes are unrelated to each other and unrelated to the 4013 startup delay. A Read-Only Domain Controller running DNS needs to locate a writable DNS-hosting domain controller to keep certain records current; if it can’t find one, it logs 4015 with extended error 00002095 roughly every three minutes. A DNS server that can’t write to its own zone data — usually because the zone object’s owner in Active Directory isn’t SYSTEM, or because the domain’s built-in Users group is missing Authenticated Users — logs 4015 with extended error 0000051B. And a forest where domain controllers have been promoted and demoted repeatedly can accumulate orphaned values in a dnsNode object’s dnsRecord attribute until it hits Active Directory’s per-attribute value limit, logging 4015 with ADMIN_LIMIT_EXCEEDED.

How to Diagnose

Start by reading the exact status code or extended error string in the event — it decides which branch below actually applies.

# 1. Pull recent 4013 and 4015 events from the DNS Server log
Get-WinEvent -FilterHashtable @{ LogName = 'DNS Server'; Id = 4013, 4015 } -MaxEvents 50 |
    Select-Object TimeCreated, Id, Message

# 2. If you're seeing 4015 with error 00002095 (RODC scenario), check what
#    DsGetDC actually returns for a writable DC — run this ON the RODC
nltest /dsgetdc:corp.example.com /WRITABLE /AVOIDSELF /TRY_NEXT_CLOSEST_SITE /DS_6

# 3. If you're seeing 4015 with error 0000051B (permissions scenario), confirm
#    the domain's Users group has the expected built-in members
net localgroup users /domain

# 4. If you're seeing 4015 with ADMIN_LIMIT_EXCEEDED, check how many values
#    a dnsRecord attribute is carrying in each DNS partition
repadmin /showattr . "CN=MicrosoftDNS,CN=System,DC=corp,DC=example,DC=com" /subtree /filter:"(objectclass=dnsnode)" /atts:"dnsRecord" /allvalues

# 5. Confirm whether Active Directory itself is still replicating normally
repadmin /replsummary

Common Causes

Working Through a Fix

For the 4013 startup delay, the honest first answer is to let it finish — it is a symptom of the AD/DNS mutual dependency working as designed, and it self-resolves once initial synchronization completes. If a specific domain controller is known to boot into this exact bad state repeatedly, and the delay itself is the operational problem, Microsoft documents a narrow workaround:

# On the affected domain controller, set the DNS Server service to
# start manually so AD's boot sequence doesn't wait on it
Set-Service -Name DNS -StartupType Manual

# Reboot, then wait for the domain controller to finish advertising
# (repadmin /replsummary and dcdiag /test:advertising both settle)
dcdiag /test:advertising

# Once the DC is advertising normally, start DNS manually
Start-Service -Name DNS

For the 4015 permissions scenario caused by a missing Authenticated Users membership, the fix has to land on every domain controller before it fully resolves, since each one evaluates the Users group locally:

# Confirm current membership first
net localgroup users /domain

# Add the missing built-in group
net localgroup users "NT AUTHORITY\Authenticated Users" /add /domain

# After the change has replicated to all DCs, restart DNS Server
# on each one so it picks up the corrected group membership
Restart-Service -Name DNS

For the ADMIN_LIMIT_EXCEEDED scenario, scope the cleanup to the specific decommissioned domain controller’s records rather than clearing an entire zone:

# List every NS record in the affected zone so you can see which
# entries belong to the domain controller that was demoted
Get-DnsServerResourceRecord -ZoneName "_msdcs.corp.example.com" -RRType "Srv"

# Remove only the records pointing at the retired domain controller
$staleRecords = Get-DnsServerResourceRecord -ZoneName "_msdcs.corp.example.com" -RRType "Srv"
foreach ($record in $staleRecords) {
    if ($record.RecordData.DomainName -like "*old-dc02*") {
        $record | Remove-DnsServerResourceRecord -ZoneName "_msdcs.corp.example.com" -Force
    }
}

How to Prevent It

For 4013, the durable fix is DNS server placement rather than a startup-order workaround. Domain controllers should not point exclusively at each other, or exclusively at themselves, for DNS — that setup is exactly what turns an ordinary reboot into a 15 to 25 minute mutual wait. Hub-site domain controllers should point at other DNS servers in the same site first, with themselves as a fallback; branch-site domain controllers should point at a hub-site DNS server first, then an in-site or nearby-site server, then themselves. Staggering domain controller reboots — never restarting the only DNS server a branch depends on at the same time as its replication partner — avoids triggering the mutual-wait condition at all.

The ADMIN_LIMIT_EXCEEDED cause is entirely preventable with routine hygiene: clean up DNS records for a domain controller as part of its decommission process, not months later. The domain controller not advertising post covers the SRV record side of a domain controller’s DNS footprint in more detail, and the DNS and Active Directory concept post covers how AD-integrated zones actually store and replicate this data, which is worth understanding before assuming a 4015 is a DNS-only problem.

Final Thoughts

Event 4013 and Event 4015 look similar — both are DNS Server log entries that point at Active Directory as the source of the problem — but they need opposite instincts. 4013 usually means wait and check placement, not intervene. 4015 means read the extended error code first, because RODC connectivity, zone ownership, and orphaned record limits share nothing in common except the event ID they happen to log under.

The pattern that causes the most wasted time is treating either event as a reason to restart the DNS Server service repeatedly. Neither 4013 nor any of the three 4015 causes are fixed by a restart — 4013 resolves on its own timeline, and 4015 needs the actual underlying condition addressed first.