DNS_ERROR_ZONE_HAS_NO_SOA_RECORD (0X00002585) - Missing SOA Record Fix

Cause 1: Corrupt or truncated zone file on the primary DNS server

What's actually happening here is the zone file on disk got corrupted—maybe from a hard crash, disk write error during a zone update, or a bad registry tweak. The DNS service loads the zone, finds the serial number header but no actual SOA record data, and throws 0x00002585. I've seen this after a power loss on a Windows Server 2016 box running DNS. The zone file was there but truncated at exactly the wrong byte.

The fix: Restore the zone from a known-good backup. If you don't have one—and you really should—you can rebuild it from a secondary server's zone transfer.

1. Stop the DNS service on the primary server: net stop dns
2. Navigate to %systemroot%\system32\dns
3. Find your zone file (e.g., example.com.dns)
4. Rename it to example.com.dns.corrupt
5. On a secondary server that has a good copy, do a zone transfer again: dnscmd /ZoneResetSecondaries example.com /SecureList 192.168.1.10 (adjust IP to your primary)
6. Copy the zone file from the secondary's %systemroot%\system32\dns to the primary
7. Start DNS: net start dns

The reason step 3 works is that Windows DNS writes zones to disk as plain text files in the dns folder. A corrupt file won't parse correctly. Replacing it with a clean copy from a secondary forces the primary to load the zone fresh. If you don't have a secondary, you're looking at manually crafting the SOA record—not fun, but doable if you know the zone's serial number and refresh settings.

Cause 2: Failed zone transfer left an incomplete zone on a secondary server

This one's subtler. The secondary server initiated an AXFR (full zone transfer), but the primary sent a partial response—maybe network timeout, maybe the primary's zone was itself corrupt. What you end up with is a zone with some records but no SOA. The error fires when the secondary tries to load the zone.

I hit this on a Server 2019 box where the primary had a misconfigured notify list. It only sent the SOA record—nothing else—so the secondary had a zone with one record that wasn't even a proper SOA. The error code was the same: 0x00002585.

The fix: Force a fresh full zone transfer.

1. On the secondary, open DNS Manager
2. Right-click your zone, go to Properties > Zone Transfers
3. Check "Allow zone transfers" > "Only to servers listed on the Name Servers tab"
4. Add the primary server's IP if it's not there
5. Right-click the zone again, select "Transfer from Master"

If that fails with a different error, you've got a communication problem—check firewall ports 53 (TCP for zone transfers, UDP for queries). Use dnscmd /ZoneResetSecondaries with the /Full flag to force a full transfer:

dnscmd /ZoneResetSecondaries example.com /Full /SecureList 192.168.1.10

The key detail: zone transfers use TCP, not UDP. If your firewall blocks TCP/53 between DNS servers, you'll get partial transfers or silent failures. Always test with nslookup -type=soa example.com on the secondary before blaming the zone file.

Cause 3: Someone (or something) manually deleted the SOA record

Yes, this happens. A junior admin clicks "Delete" on the SOA record thinking it's a normal record. Or a migration script botches the import. The zone exists, it has other records—A, CNAME, MX—but no SOA. The DNS server won't serve the zone without it. The error fires on any query.

The fix: Recreate the SOA record manually. You can do this through the GUI or PowerShell.

GUI method:

1. Open DNS Manager
2. Right-click the zone, select Properties
3. Go to the SOA tab
4. Fill in: Primary Server (FQDN), Responsible Person (email-like format, e.g., admin.example.com with a dot instead of @), Serial Number (start at 1), Refresh interval (15 min), Retry (10 min), Expires after (1 day), Minimum TTL (1 hour)
5. Click OK

PowerShell method (cleaner for scripting):

$zoneName = "example.com"
$primaryServer = "ns1.example.com"
$responsiblePerson = "admin.example.com"
$serial = 1
$refresh = 900
$retry = 600
$expire = 86400
$minimumTtl = 3600

Add-DnsServerResourceRecordSoa -ZoneName $zoneName -PrimaryServer $primaryServer `
  -ResponsiblePerson $responsiblePerson -SerialNumber $serial `
  -RefreshInterval $refresh -RetryInterval $retry `
  -ExpireLimit $expire -MinimumTimeToLive $minimumTtl

The gotcha: the responsible person field must use a dot for the @ symbol—so admin.example.com not admin@example.com. The DNS server expects that format. Get it wrong and the record looks valid but breaks email-based zone notifications later.

After adding the SOA, reload the zone: dnscmd /ZoneReload example.com. Then test: nslookup -type=soa example.com. You should see the SOA record returned.

Quick-reference summary table