AD-Integrated DNS Zones Still Allow Open Transfers
A Windows DNS Server zone left on "Allow zone transfers: To any server" hands out every SRV and host record for a domain controller via a single unauthenticated AXFR query. Active Directory replication does not govern this setting, and standard DC firewall rules and event logging rarely flag the transfer at all.
Operational summary
At a glance
- Symptom
- An unauthenticated dig axfr or nslookup ls query against any domain controller serving the zone.
- Likely cause
- Primary zone SecureSecondaries property left at TransferToAnyServer on one or more domain controllers.
- Impact
- Full zone dump exposes every DC, GC, and PDC emulator plus AD site topology for targeted Kerberos attacks, with no logging to detect it.
- Verification signal
- Re-run the detection test and a controlled negative-path test.
- Safe correction
- Set SecureSecondaries to TransferToSecureServers or TransferNone on every writable DC and enumerate legitimate secondaries explicitly on the Name Servers tab.
- Rollback or recovery
- Restore the exported configuration if the new control blocks required production traffic, then narrow the policy before redeployment.
The Trap
Zone Transfer set to “To any server” on an Active Directory-integrated primary zone hosted on a Windows domain controller.
The Default State
When a zone is created manually through the DNS Manager wizard, or converted from AD-integrated back to standard primary during a migration or forest recovery, the Zone Transfer tab retains its legacy default: “To any server”. Admins assume Active Directory replication itself governs how zone data leaves the domain controller, so nobody opens the Zone Transfer tab to check it. The Name Servers tab often lists only the original DC, but that list is never enforced unless the radio button is switched to “Only to servers listed on the Name Servers tab” or “Only to the following servers”. On multi-DC forests, DCs promoted after the zone’s creation frequently inherit the open setting independently, because SecureSecondaries is a per-server property, not one that replicates cleanly with the zone data itself.
The Blast Radius
Running dig axfr @<DC-IP> corp.local against an exposed DC dumps the entire zone with no authentication. That dump includes SRV records for _ldap._tcp.dc._msdcs, _kerberos._tcp, _gc._tcp and _kpasswd._tcp, revealing every domain controller, global catalog server, PDC emulator, and the AD site each one serves. An attacker now has a complete map of the forest’s authentication infrastructure without a single credentialed request, ready for targeted Kerberoasting or AS-REP roasting against the accounts each DC handles. Because inbound TCP/53 to domain controllers is normally permitted for ordinary DNS resolution, Windows Firewall and network IDS rarely distinguish an AXFR request from routine lookup traffic. DNS debug logging, which would capture the transfer, is disabled by default on Windows DNS Server, so the query leaves no entry in the Security event log and no alert fires.
The Lead Mechanic Fix
Restrict transfers explicitly with Set-DnsServerPrimaryZone -Name corp.local -SecureSecondaries TransferToSecureServers -ComputerName DC01, then populate the Name Servers tab with the exact FQDNs of legitimate secondaries only. For zones with no external secondaries, disable transfers entirely on every writable DC: Get-DnsServerZone | Where-Object {$_.ZoneType -eq “Primary”} | ForEach-Object { Set-DnsServerPrimaryZone -Name $_.ZoneName -SecureSecondaries TransferNone }. Audit the fleet with dnscmd /zoneinfo <zone> on each domain controller individually, since the flag does not reliably propagate to DCs added after initial zone creation, and enable DNS debug logging temporarily to confirm no AXFR traffic is answered from unlisted sources.
Apply the safer control
Before you change production
Confirm the affected scope, export the current configuration, and test the replacement control in a non-production environment first.
Set SecureSecondaries to TransferToSecureServers or TransferNone on every writable DC and enumerate legitimate secondaries explicitly on the Name Servers tab.
Validate the vendor-specific syntax in official documentation before applying it.
Verify, roll back or escalate
Verify
Re-run the detection test and a controlled negative-path test. Confirm the unsafe behaviour is blocked while approved traffic still succeeds.
Rollback
Restore the exported configuration if the new control blocks required production traffic, then narrow the policy before redeployment.
Escalate
Escalate when the blast radius is uncertain, the control cannot be tested safely, or remediation requires an outage or security exception.