The _msdcs zone is how Active Directory finds itself — the forest-wide DNS zone that holds the SRV, CNAME, and NS records domain controllers use to locate each other, Global Catalogs, KDCs, the PDC, and replication partners. When a DC is demoted, seized, rebuilt, or lost, it leaves that zone dirty with orphaned records — and sometimes the zone itself ends up missing or misconfigured. AD DNS Cleanup diagnoses, cleans, and repairs it, on one DC or across the whole forest. This guide explains every button and exactly what it does to your DNS.
OverviewWhat the tool does
AD DNS Cleanup works on the _msdcs zone — the AD-integrated, forest-wide locator zone that was split out as its own zone in Windows Server 2003 — and on what a removed domain controller leaves behind in your forward lookup zones. It does three jobs:
- Diagnose. A read-only
dcdiag /test:DNShealth check parsed into a clean PASS / FAIL report, plus a check of every DC’s own network-adapter DNS settings — the most common reason records stop registering, and the recommended first step. - Clean. Find the stale CNAME, SRV, and NS records that point at hosts which no longer exist, review them, and remove the ones you approve — optionally reading every DC’s copy of the zone to catch records that have diverged across the forest. It also finds the NS and A records a removed DC left in the forward zone, which hide the problem rather than showing it: while that A record survives, the dead DC’s
_msdcsrecords still resolve and an ordinary scan reports the zone clean. - Repair. Force domain controllers to re-register their DNS records, or — for the worst case — rebuild the entire
_msdcszone when it is missing or misconfigured: re-created AD-integrated and forest-wide, repopulated, and verified per DC. A zone whose only fault is its replication scope is corrected in place, with nothing deleted.
It is a single signed Windows executable — no installer, no agents, no PowerShell modules to import.
The dcdiag test, the DC NIC DNS check and the scan are read-only, but Remove, Re-register, and Rebuild all make real changes — removing records from the _msdcs zone and, with Dead-DC leftovers enabled, from your forward lookup zones, deleting and re-creating a zone, and restarting Netlogon. These are forest-wide operations. Before a removal the existing data is written out to a CSV file, and the run aborts if that file cannot be written — but that file is for review only. It is not a backup and not a recovery service. Every changing action asks you to confirm. Keep your own current, tested full system backup of the affected domain controllers — a DNS zone export alone will not undo an Active Directory change — and review every change.
SetupBefore you begin
Requirements
_msdcs zone). Actions that reach other DCs need admin rights on those machines.Installing the AD & DNS tools (RSAT) on a workstation
You can run AD DNS Cleanup on a domain-joined Windows 10/11 admin workstation instead of a DC. It needs Microsoft’s Remote Server Administration Tools (RSAT) — the ActiveDirectory and DnsServer PowerShell modules the tool uses. From an elevated PowerShell:
Add-WindowsCapability -Online -Name Rsat.Dns.Tools~~~~0.0.1.0
Add-WindowsCapability -Online -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0They pull from Windows Update, take a minute or two, and need no reboot. On a domain controller both modules are already present. Querying AD still needs domain credentials — sign in as a domain user with admin rights.
What’s in the box
AD-DNS-Cleanup.exe— the application (published by KW Tech Solutions LLC).LICENSE.txt,README.txt, and this manual.
Copy the folder onto a domain controller (or an RSAT-equipped admin box), extract it, and run AD-DNS-Cleanup.exe. Approve the UAC prompt. On first launch you’re shown the license agreement; the tool won’t proceed until you accept it.
_msdcs zone, and restart Netlogon — that a license key is required, and that it is provided as-is.ActivationLicensing & activation
AD DNS Cleanup is licensed to run — a valid license key is required before any action will work. There is no free-run mode. You enter your key once and it’s remembered on that host.
On launch, the license state is shown at the top-right. Until you activate it reads Unlicensed — activate to use, an Activate button is shown, and every action in the window is disabled. Click Activate and paste the license key from your purchase confirmation.
On success the status turns to a green Licensed, the Activate button disappears, and every feature unlocks.
Activation is a one-time online step; after it succeeds the tool doesn’t phone home again. Each license includes 2 activations (up to two machines). Because the license is bound to the host, renaming a domain controller after activation requires re-activating on it. To move a license or reset activations, email [email protected]. You can buy AD DNS Cleanup at kingwerx.com.
LayoutThe main window
The console is one screen. A read-only DNS health test sits at the top; the _msdcs zone scan and its actions fill the middle, with the stale-record grid below them; and a live activity log runs across the bottom. The domain the tool detected is shown near the top.
dsregdns)._msdcs zone. The red button and the double confirmation reflect its blast radius.WorkflowCleaning up after a dead DC
The order matters more than any single button. This is one job, start to finish; each step links to the detail that follows.
_msdcs or your forward zone — they are not the same risk. The Why it’s stale reason differs per row. Read every one.Have a current, tested full system backup of the domain controllers you are about to touch. A DNS zone export alone will not undo an Active Directory change, and the file this tool writes is a record of what it removed — not a backup and not a recovery service.
Every line you see is written to %ProgramData%\KWTechSolutions\ADDnsCleanup\logs\ as it happens, so you have the record of what you did without having to remember to save anything (see Exports & the activity log).
ActionChecking each DC’s own DNS settings
Click Check DC NIC DNS before anything else. It is labelled Recommended 1st Step for a reason: when DNS records won’t register or won’t stay registered, the cause is usually not a stale record at all — it is the domain controller’s own network adapter pointing at the wrong DNS server. No amount of record cleanup fixes that.
The check is read-only. It reads every domain controller in the forest — the local one directly,
remote ones over Windows PowerShell remoting — and reports each DC’s first and second DNS servers
with each address labelled so you can read it at a glance: (itself), the DC’s short name, or
(external).
8.8.8.8. A DC must point only at AD DNS; let a DNS forwarder handle internet names.Every finding is paired with the fix, and a DC can report more than one at once.
Pointing a domain controller’s first DNS entry at a partner DC instead of itself is a legacy
habit — the Windows 2000 / 2003 anti-islanding advice. On modern Windows Server it drags logons and
delays the DC registering its own records, and it is a common cause of a persistent
dcdiag RReg failure. Put the DC itself first and a partner second.
If every DC reports OK and records still look out of sync, it is almost certainly just replication timing rather than configuration. Give it several minutes and re-scan.
ReferenceThe DNS health test
Click Run dcdiag /test:DNS /v for a read-only DNS health snapshot. The tool runs Microsoft’s dcdiag DNS test suite and parses each sub-test — Connectivity, Authentication, Basic, Forwarders, Delegations, Dynamic update, Records registration — into a color-coded PASS / FAIL / OMITTED window. There’s a summary line, toggles to show skipped tests and the raw output, and Copy / Export buttons. A 10-minute hard timeout guards against a hang. It makes no changes.
ActionScanning the _msdcs zone
Click Scan _msdcs Zone. The tool walks every CNAME, SRV, and NS record in the zone and flags a record as stale when both are true: the target host has no A record in the parent zone, and it is not a live domain controller (checked forest-wide). Live DCs are never flagged, so the tool won’t propose removing something in active use.
The “All DCs” option
Because _msdcs is AD-integrated, every DC holds a replicated copy of the zone — identical in a healthy forest. But this tool is for the messy case, where replication may be broken and the copies diverge. With All DCs ticked (the default), the scan reads every reachable DC’s copy, merges the results, and flags any record found on some DCs but not others as [DIVERGENT: on N/M DCs].
A stale record that’s on one DC but not another means replication is out of sync — a red flag worth chasing on its own. Unreachable DCs are skipped and logged, never fatal. Untick All DCs to scan only the local DNS server (faster, and complete when replication is healthy).
ActionDead-DC leftovers outside _msdcs
A removed domain controller leaves more behind than _msdcs records. It usually still has an
NS record in the forward lookup zone and its own A record — and those are what clients and
resolvers keep trying to reach long after the server is gone. The Dead-DC leftovers checkbox, on by
default, finds them.
The ordinary staleness rule flags a record when its target has no A record and is not a live DC. So
while a removed DC’s A record is still there, all of its _msdcs records resolve
perfectly — and a plain scan reports the zone clean. Nothing looks wrong, while DNS quietly hands
clients the address of a server that no longer exists. With leftovers enabled, the dead DC is identified from
its NS and _msdcs presence instead, and all of its records surface together —
including the ones the plain rule could not see.
Results land in the same grid, and the Zone column is what tells them apart: leftovers carry your
forward zone name (e.g. lab.local) rather than _msdcs.<domain>. One removal run
clears both zones.
How a host is judged
A host is listed as a removed domain controller only when all four of these are true:
_msdcs._msdcs.The four tests are there to exclude hosts that are not decommissioned domain controllers: an ordinary member
server has no NS or _msdcs presence and so does not meet the first test, and an in-domain appliance
that legitimately serves a delegated zone has an A record and no _msdcs presence and so does not
meet the last.
These tests describe how the tool chooses what to put in the grid. They are not a guarantee that a record
is safe to delete, and no software can know what your environment actually depends on. Read the
“Why it’s stale” reason on every row, untick anything you are unsure of, and keep a current
full system backup of the affected domain controllers. Nothing is removed unless you select it and confirm, and
verifying the outcome remains yours. See
LICENSE.txt for the full terms.
Only the forest’s domain zones are read — not every zone hosted on the server, and not reverse
(PTR) zones. Forward zones can be large, so A records are read once from the first domain controller that
answers rather than from all of them; removal still clears every DC. Expect the scan to take noticeably
longer on a production-sized zone than on _msdcs alone.
ActionPreview & remove
Always preview first. Click Preview Removal for a plain, read-only list of exactly what would be deleted — nothing changes. Use Select All / Select None or untick individual rows, and read the “Why it’s stale” column on each. When satisfied, click REMOVE SELECTED and confirm. Before anything is deleted the tool stores the existing data for every record it is about to remove in a file for later review; each record is then cleared from every reachable DC in the forest, and the tool re-scans automatically.
The stored-data file — what it is, and what it is not
It is a written record of what was removed, kept so you can see afterwards exactly what changed. It is not a backup, not a restore point, and not a recovery service, and it must not be relied on as one. Taking and verifying your own full system backup of the affected domain controllers before you run anything is your responsibility — a DNS zone export alone will not undo an Active Directory change.
Before the first record is touched, the tool writes a CSV to
C:\ProgramData\KWTechSolutions\ADDnsCleanup\stored-data\, named
removed-<zone>-<timestamp>.csv. The path is logged twice — once as it is written, and
again on the final line of the run. If that file cannot be written, nothing is removed at all and the run
aborts without touching DNS.
The CSV holds the full record data, not just the columns the grid showed: zone, record name, type, target, TTL, and for SRV records the priority, weight and port. That is all it is — a written record of what was removed, so you can see afterwards exactly what changed. It is not a backup and not a recovery service. The tool deliberately does not hand you a ready-to-run command to put anything back: deciding whether a record should exist again, recreating it, and verifying the result are entirely yours to plan and carry out.
The stored file is a record of what was deleted, not a licence to guess. If you’re unsure about a record, leave it unchecked and investigate first. And if a record is divergent because replication is broken, the tool removes it everywhere it can reach but cannot repair the underlying replication problem — that’s a bigger issue to address separately.
ActionRe-register DNS
Re-register DNS forces every live DC’s Netlogon service to re-register its own DNS records right now (it runs nltest /dsregdns on each DC, locally and via PowerShell remoting). Use it to fill gaps when records are missing from an existing zone — the same refresh Netlogon performs at boot.
dsregdns can only write records into a zone that already exists; it cannot recreate a deleted _msdcs zone. For that, use Rebuild _msdcs Zone (next). Allow several minutes for DNS to update and replicate — 15+ minutes in larger or slow-replicating forests — before re-scanning to verify.
ActionRebuild the _msdcs zone
This is the recovery tool for the worst case: the _msdcs zone itself is missing (deleted) or misconfigured (not AD-integrated, or replicating only domain-wide instead of forest-wide). A deleted or broken _msdcs zone breaks DC location, authentication, and AD replication forest-wide — and dsregdns can’t bring the zone back, only its records. Rebuild _msdcs Zone does the full recovery in one guarded sequence:
MISSING, MISCONFIGURED, EMPTY, or HEALTHY. If it’s already healthy, it does nothing.%ProgramData%\KWTechSolutions\ADDnsCleanup\stored-data\ (for review only — not a backup) and refuses to continue if the backup fails.Because it is high-impact, it is gated behind a double confirmation. The first warning spells out the full effect; the second is a final check before anything changes.
Ideally on the forest root DC, with your own current, tested full system backup in hand. What the tool writes is a CSV record for reference only — not a backup and not a restore path. Deleting and re-creating the zone is a forest-wide change: any manual (non-Netlogon) records are lost, Netlogon is restarted on each DC (a brief authentication blip), and service location is briefly unavailable while the zone rebuilds and replicates — often several minutes, 15+ in larger forests.
Watch the per-DC block in the log. A DC showing PENDING is simply still replicating — give it time and re-scan, or run Re-register DNS if any alias stays missing.
Forest scope vs domain scope — the quiet one
The _msdcs.<forest root> zone is meant to be forest-replicated. It became its own
AD-integrated, forest-wide zone in Windows Server 2003 precisely because every domain in the forest has to be
able to find every domain controller in it. If the zone is instead scoped to a single domain, it still
looks perfectly healthy from inside that domain — records resolve, dcdiag is happy, a
record scan finds nothing wrong — while domain controllers in the other domains simply cannot see
it. Cross-domain DC location, Global Catalog lookups and replication break, and nothing in the zone itself
points at why.
The scan reports the zone’s replication scope on every run, and grades it by your topology: in a
multi-domain forest a domain-scoped _msdcs is an error; in a single-domain forest it is a
warning — no visible effect today, and a forest-wide outage the day a second domain is added or you
migrate.
When the zone exists and is AD-integrated and only the scope is wrong, Rebuild _msdcs Zone takes a gentle path: it changes the replication scope in place. No deletion, no Netlogon restart, no authentication blip, and every record is preserved. You get a calm single confirmation rather than the double danger warning — the destructive rebuild is reserved for a zone that is missing or not AD-integrated.
OutputExports & the activity log
Everything the tool does is visible and saveable:
- The activity log across the bottom narrates every action live, color-coded — green for success, amber for warnings, red for errors — each line stamped with the time.
- Export List saves the stale entries found (with selection state and reasons) to a CSV.
- Every session is logged to disk automatically. As each line appears on screen it is also appended to
%ProgramData%\KWTechSolutions\ADDnsCleanup\logs\session-<timestamp>.log, headed with the version, the machine and the user who ran it. It is written line by line, so the record survives closing the app or a crash mid-run. Nothing is sent anywhere — the file stays on that machine. - Save Log also writes the on-screen log to a text file wherever you choose — useful for handing a copy to someone else.
- The dcdiag window exports the raw diagnostic output.
- The stored-data CSV of any re-created zone lands in
%ProgramData%\KWTechSolutions\ADDnsCleanup\stored-data\.
Run a scan and Export List before a cleanup, do the work, then scan and export again. Side by side, the two files show exactly what you removed — a tidy record for a change ticket or a client.
ReferenceTroubleshooting
| Symptom | Cause & fix |
|---|---|
| Every action button is greyed out | The tool isn’t activated. Click Activate (top right) and paste your license key (see Licensing & activation). |
| “ActiveDirectory / DnsServer module not available” | Run on a domain controller, or install the RSAT AD and DNS Server tools (see Installing the AD & DNS tools). |
| Domain shows “(could not detect)” | The host isn’t domain-joined or you lack rights — run on a DC as a domain administrator. |
| A DC shows “could not read records — skipped” during an All-DCs scan | That DC is temporarily unreachable (often mid-registration). It is skipped and reported in the log; re-scan shortly. |
| Re-register / Rebuild leaves a DC alias “PENDING” | Replication hasn’t caught up. Allow several minutes (15+ in larger forests), re-check, or run Re-register DNS. |
| “Couldn’t reach the licensing server” | The first activation needs internet access from that host. Check connectivity and retry. |
| Rebuild reports “zone already exists” / create failed | A zone deletion hasn’t replicated across the forest yet. Wait for the forest to converge, then run it again — the tool aborts and changes nothing on that error. |
| “Required PowerShell module(s) not available” | You are running it somewhere it cannot work — a member server or a workstation without the matching RSAT feature. The message names exactly which module is missing. Run it on a domain controller, or install RSAT: DNS Server Tools and RSAT: AD DS Tools. Nothing is changed when this appears. |
A persistent dcdiag RReg failure that record cleanup never fixes | Nearly always a domain controller whose first DNS server is a partner DC rather than itself — the legacy 2000/2003 anti-islanding habit. It delays the DC registering its own records. Run Check DC NIC DNS: self-first is current best practice. |
| A record you removed comes back on the next scan | Look for not present yet on: <DC> in the removal log. That DC did not have the record at removal time, then received the original addition afterwards and replicated it back. It is a timing race, not a failed removal — let the forest settle, then re-scan and remove again. |
| Scanning got much slower | Dead-DC leftovers reads your forward lookup zone, which on a production domain can hold thousands of records. Untick it for a quick _msdcs-only pass. |
LegalLicensing & notices
Your use of the software is governed by the End User License Agreement (LICENSE.txt, shown on first run). In short: AD DNS Cleanup changes DNS — it can remove records from the _msdcs zone and, with Dead-DC leftovers enabled, NS and A records from your forward lookup zones, re-register DNS on DCs, and delete and re-create the _msdcs zone (restarting Netlogon forest-wide). Each changing action is confirmed first, and the dcdiag test, the DC NIC DNS check and Preview are read-only. The existing data is written to a CSV file beforehand and the run aborts if it cannot be written, but that file is for review only — it is not a backup and not a recovery service, and the tool’s stale determination is advisory, not a guarantee that a record is safe to delete. A valid license key is required to run it, and it is provided “AS IS,” without warranty of any kind; KW Tech Solutions LLC is not liable for data loss, deleted or misconfigured DNS records, service disruption, or authentication issues arising from its use — including the removal of records from your forward lookup zones. You remain responsible for your environment and your own tested backups. All sales are final.
Microsoft, Windows, Windows Server, and Active Directory are trademarks of Microsoft Corporation. AD DNS Cleanup is an independent product of KW Tech Solutions LLC and is not affiliated with, authorized, sponsored, or endorsed by Microsoft.