Fix DNS Error 0x2586: Zone Has No NS Record

When a DNS zone loses its NS record, Windows Server throws 0x2586. This usually happens after a manual delete or failed zone transfer. Here's how to rebuild it fast.

You're staring at Event ID 0x00002586 (that's decimal 9574 for the curious) in the DNS server log, and the zone shows as 'Not Authoritative' or just refuses to load. This error appears when a zone exists but has zero Name Server (NS) records. It's the DNS equivalent of a store with no address sign — clients can't find the authoritative server, so queries fail fast.

I've seen this happen in two real-world scenarios. First, someone in a panic deleted the NS record while trying to 'clean up' old delegation entries. Second, and more insidiously, a zone transfer from a primary server where the NS records were filtered out by a misconfigured firewall or an overzealous security tool. Sometimes it also pops up after a server restore when the AD-integrated zone metadata got corrupted.

The root cause is simple: a zone must have at least one NS record that points to an authoritative name server for that zone. Without it, the DNS service considers the zone incomplete and won't serve answers from it. Windows doesn't automatically recreate NS records — you have to do it manually.

How to fix it (the real fix, not a workaround)

First, figure out whether the zone is AD-integrated or file-backed. In DNS Manager, right-click the zone and go to Properties. If the Type says 'Active Directory-Integrated', you can add the NS record right in the UI. If it's a standard primary zone, you'll still edit it in the UI but changes are safe.

Step 1: Add the NS record via DNS Manager

Open DNS Manager (dnsmgmt.msc).
Expand your server, then expand Forward Lookup Zones.
Right-click the affected zone and select Properties.
Go to the Name Servers tab.
Click Add.
In the dialog, enter the FQDN of your DNS server — e.g., dc01.contoso.com.
Click Resolve to auto-populate the IP address. If it doesn't resolve, enter the IP manually. (You can add multiple servers here if needed.)
Click OK and close the dialog.

That usually clears the error immediately. Give it a few seconds, then refresh the zone. The error should stop appearing in the DNS event log.

Step 2: If the UI won't let you add (rare but possible)

If the Properties dialog errors out or the zone is in a failed state, use dnscmd from an elevated command prompt instead. This is also the way to go when you're scripting or managing multiple servers.

dnscmd ServerName /RecordAdd ZoneName @ NS ServerFQDN

Example:

dnscmd DC01 /RecordAdd contoso.com @ NS dc01.contoso.com

Press Enter, and you should see a 'Command completed successfully.' message. That command adds the NS record for the zone root (@) pointing to your server.

What to check if it still fails

If the error persists after adding the NS record, a few things are probably wrong:

Zone replication is broken. For AD-integrated zones, check that the zone replicates to all DCs that are DNS servers. In DNS Manager, go to the zone properties, then the Replication tab, and confirm the scope matches your AD topology.
Your server's own NS record points to a different name. Maybe your server is called dns01 but the NS record says dc01. That mismatch triggers a different error, but I've seen 0x2586 show up when the glue records are inconsistent.
The zone file is corrupt. If it's a standard primary zone, stop the DNS service, check C:\Windows\System32\dns\ for the zone file (e.g., contoso.com.dns), and verify the NS records are actually in there. If the file looks empty or garbled, restore from backup or recreate the zone.

One more thing — if you deleted the NS record by accident, you might also have deleted the SOA record. The same error code can appear if SOA is missing too. So while you're at it, check the SOA tab in zone properties. If it's empty, add a new SOA record (default settings are fine for most environments).

In my years of running a help desk, this error was a frequent call. The fix is almost always just re-adding the NS record. Don't waste time restarting the DNS service or rebooting the server first — it won't help. Go straight to the NS tab.

If you're dealing with a large environment with many zones, consider scripting a check for all zones that lack NS records. A quick PowerShell one-liner can save you from discovering this the hard way again.

Get-DnsServerZone | Where-Object { -not ($_ | Get-DnsServerResourceRecord -RRType NS) } | Select ZoneName

Run that from an elevated prompt on your DNS server, and it'll list every zone missing an NS record. Catch it before it becomes an outage.