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.
At a glance
- Unsafe setting
- Primary zone SecureSecondaries property left at TransferToAnyServer on one or more domain controllers.
- Failure trigger
- An unauthenticated dig axfr or nslookup ls query against any domain controller serving the zone.
- Blast radius
- Full zone dump exposes every DC, GC, and PDC emulator plus AD site topology for targeted Kerberos attacks, with no logging to detect it.
- Recommended control
- Set SecureSecondaries to TransferToSecureServers or TransferNone on every writable DC and enumerate legitimate secondaries explicitly on the Name Servers tab.
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.