Active Directory DNS Zone Transfer Insecure Dynamic Update Security: Detection and Remediation

Active Directory DNS zone transfer insecure dynamic update security is not a single setting — it's three separate, default-adjacent gaps in how AD-integrated DNS zones are configured, and together they let an attacker map or rewrite your domain's DNS without ever touching Kerberos or LDAP. An Active Directory DNS zone transfer left open, an insecure dynamic update setting, and a default ACL that lets Authenticated Users create DNS records are three separate, low-effort weaknesses — and DNS security in most AD environments still treats them as background noise rather than an attack surface.

None of the three requires a CVE or a fresh exploit. They are default-adjacent settings that ship "workable" out of the box and rarely get revisited once the domain is running. Chained together they let an unauthenticated or low-privileged attacker map the internal network for free, inject records into it, or both.

Active Directory DNS Zone Transfer Insecure Dynamic Update Security: The AD-Integrated DNS Attack Surface

When a DNS zone is Active Directory-integrated, its records live as dnsNode objects inside the directory partition (DomainDnsZones or ForestDnsZones), not in a flat zone file. Microsoft documents this model in Active Directory-Integrated DNS Zones: every writable domain controller running the DNS Server role can accept updates to the zone, and those updates replicate through normal AD replication rather than a separate zone-transfer mechanism between primary and secondaries.

That design has two consequences that matter for security, not just for uptime:

• The zone itself has an ACL, exactly like an OU or a group. Whoever holds write rights on that ACL can create, modify, or delete DNS records — and the default rights are broader than most administrators expect.
• Two independent legacy protections still guard the perimeter of the zone: classic zone transfer (AXFR, for replicating to non-AD secondaries or for reconnaissance) and dynamic update (the mechanism clients use to self-register records). Both predate AD-integration and both default toward permissive.

Kerberos, LDAP, and ACL abuse get most of the attention in AD security writing. DNS is different: it is Network-category, not identity-category, and it is commonly left off hardening checklists entirely — alongside neighbors like LDAP signing left disabled or weak LDAPS TLS and a Print Spooler nobody disabled, covered in this domain controller network hygiene checklist — which is exactly why a domain can pass a Kerberos and ACL review and still leak its entire topology through DNS.

How It Works: Three Chainable Misconfigurations

1. Unrestricted zone transfer (AXFR)

AXFR is the original DNS zone-replication protocol, and it was never designed with authentication in mind. As CISA's advisory on the topic states, if a DNS server is not explicitly configured to restrict transfers, any client that can reach it on TCP/53 can request — and receive — a full copy of the zone. For an AD-integrated zone that means every hostname, IP address, service record (including _ldap._tcp, _kerberos._tcp, and other SRV records that fingerprint domain controllers), and any forgotten subdomain, handed over in one query.

Set-DnsServerPrimaryZone exposes the fix directly: the -SecureSecondaries parameter controls whether transfers are allowed to any server, only to servers listed on the Name Servers tab, or only to an explicit IP list — NoTransfer is the hardened option when no external secondary needs the zone at all.

2. Insecure dynamic update

Dynamic update lets a client register or update its own DNS record without an administrator doing it by hand — normal and necessary for domain-joined workstations. The security boundary is which update mode the zone uses. Microsoft's own documentation on Dynamic DNS Update in Windows and Windows Server and the legacy guidance on Allow Only Secure Dynamic Updates are explicit: secure dynamic update — available only on AD-integrated zones — restricts updates to computers that are authenticated and domain-joined, enforced through the zone's ACLs. A zone left on Nonsecure and secure, by contrast, accepts updates from anyone who can reach the DNS service, authenticated or not — meaning an unauthenticated host on the network segment can create or overwrite records at will.

3. Authenticated Users can create child records outright

This is the one most teams have never looked at directly. By default, the Authenticated Users group holds Create All Child Objects on the AD-integrated zone's ACL — confirmed in Microsoft's own community guidance on DNS record creation permissions and documented in offensive-security research as the foundation of ADIDNS (Active Directory-Integrated DNS) abuse. NetSPI's research on exploiting Active Directory-integrated DNS and ADIDNS Revisited lay out the practical effect: every domain account, including low-privileged users and computer accounts, can register new DNS records in the zone without any elevated rights. The Hacker Recipes' ADIDNS poisoning page and HackTricks' AD DNS Records reference both document this as a standing, well-known technique — not a novel exploit. It sits alongside a broader pattern worth auditing on its own: Authenticated Users and Everyone silently over-membered into privileged scopes across a domain, of which the DNS zone's default ACL is one specific, easy-to-miss instance.

Two record types make this immediately dangerous:

• A record for a name that doesn't exist yet — e.g. registering the hostname of a decommissioned server or a name that a legacy application still queries, then pointing it at an attacker-controlled IP.
• A wildcard record (*) — since a wildcard answers every query that doesn't already have an explicit record in the zone, an attacker who creates one becomes the resolver of last resort for the entire zone. Elastic's own prebuilt detection rule for wildcard ADIDNS poisoning describes exactly this: an attacker positions as adversary-in-the-middle by resolving arbitrary unmatched names, which enables credential interception or NTLM relay, conceptually similar in outcome to LLMNR/NBNS spoofing but persistent and zone-wide instead of a single broadcast.

The Global Query Block List (GQBL) is Microsoft's mitigation for the most infamous target of this technique — WPAD — but NetSPI's follow-up research notes NS records still bypass it on fully patched systems, so the GQBL is a partial control, not a substitute for fixing the underlying ACL.

The two supporting gaps: DNSSEC and wildcard records already present

DNSSEC_NOT_ENABLED and DNS_WILDCARD_RECORDS compound the three misconfigurations above rather than standing alone as independent attack paths:

• Without DNSSEC, nothing about a record's origin is cryptographically verifiable — a poisoned or spoofed response cannot be told apart from a legitimate one. Microsoft covers zone signing in Sign DNS Zones with DNSSEC on Windows Server and the underlying mechanics in the DNSSEC overview — for an AD-integrated zone, the zone-signing keys replicate automatically to primary DNS servers through normal AD replication, which makes DNSSEC comparatively low-friction to deploy on this platform specifically.
• An existing wildcard record found during an audit — as opposed to one an attacker just created — usually indicates the zone's ACL has already been abused, or a legacy application team requested it without security review. Either way, it's worth treating as an incident-response question, not a config cleanup item, until proven otherwise.

The Attack Chain

Step 1 — Recon via zone transfer

An attacker on the network (or, if the zone is externally reachable, from the internet) requests a zone transfer against the DNS server:

dig axfr corp.local @10.10.10.10

If the zone is unrestricted, the response is the full record set: domain controllers, SRV records for Kerberos/LDAP, every workstation and server hostname, and any subdomain that was never meant to be public.

Step 2 — Pick a target name and register a record

Using nothing more than a standard domain account, the attacker registers a DNS record for a name of interest — a decommissioned host, a name a legacy app still resolves, or a wildcard:

# From any domain-joined machine, as any authenticated domain user
Add-DnsServerResourceRecordA -ZoneName "corp.local" -Name "legacy-app" -IPv4Address 10.10.10.50 -ComputerName dc01.corp.local

If the zone still allows nonsecure dynamic update, this step doesn't even require a valid domain credential — an unauthenticated host on the segment can push the same update directly via the dynamic update protocol.

Step 3 — Relay or intercept

With the record live, any traffic destined for that name lands on the attacker's host instead. For SMB/HTTP name resolution this is a direct analogue of LLMNR/NBNS spoofing — except it persists in DNS rather than requiring the attacker to win a race on every broadcast query — and it feeds straight into NTLM relay tooling (Responder, ntlmrelayx) the same way a poisoned broadcast response would. The technique is even more reliable when SMB signing is disabled or not required, since nothing stops the relayed session from being accepted as legitimate.

Detection

Windows Server ships two dedicated DNS log channels, both covered in Microsoft's Enable DNS Logging and Diagnostics documentation: DNS Audit events (enabled by default, low overhead) covering administrative actions — zone creation/deletion, record changes, and DNSSEC signing operations — and DNS Analytical events (off by default, higher volume) covering the query/response/dynamic-update traffic itself. Both live under Applications and Services Logs > Microsoft > Windows > DNS-Server in Event Viewer.

Remediation

1. Restrict zone transfers. Set transfers to trusted secondaries only, or disable them entirely if none exist:

   Set-DnsServerPrimaryZone -Name "corp.local" -SecureSecondaries TransferToSecureServers
   # or, if no external secondary needs this zone at all:
   Set-DnsServerPrimaryZone -Name "corp.local" -SecureSecondaries NoTransfer
   

2. Force secure-only dynamic update on every AD-integrated zone. Nonsecure and secure should not appear on a production zone:

   Set-DnsServerPrimaryZone -Name "corp.local" -DynamicUpdate Secure
   

3. Tighten the zone's default ACL. Removing Authenticated Users' create-child rights entirely will break legitimate self-registration for domain-joined machines, so this needs to be scoped, not just revoked — Microsoft's own guidance on this permission (see the community thread on the topic) confirms the default is broader than most teams realize. Review the zone's security tab (or dsacls against CN=<zone>,CN=MicrosoftDNS,DC=DomainDnsZones,DC=...) and scope create-child rights to the accounts and groups that actually need to self-register — typically domain computers via secure dynamic update, not the full Authenticated Users group unconditionally.

4. Delete unexpected wildcard records found during the audit sweep, and treat any you didn't provision as a potential indicator of prior compromise, not just cleanup.

5. Enable the Global Query Block List for classic high-value name traps (WPAD, ISATAP) as a defense-in-depth layer — dnscmd /config /enableglobalqueryblocklist 1 — while remembering NetSPI's finding that NS records still bypass it, so this is a supplement to fixing the ACL, not a replacement.

6. Enable DNSSEC on AD-integrated zones per Microsoft's zone-signing guide — signing keys replicate automatically through AD, so once the Key Master is configured the rollout is largely hands-off across the rest of the domain controllers hosting the zone.

DNS is one item on a much longer list — for a full walkthrough of what to review first across Tier 0 exposure, ACL abuse, Kerberos, and logging, see Audit Active Directory Security: What to Review First.

How EtcSec Detects This

EtcSec's Network category audit checks AD-integrated DNS zones directly against these five gaps: DNS_ZONE_TRANSFER_UNRESTRICTED and DNS_DYNAMIC_UPDATE_INSECURE flag zones where transfer or update settings are broader than the secure default, DNS_ZONE_AU_CREATE_CHILD flags zones where Authenticated Users still holds create-child rights on the zone ACL, DNSSEC_NOT_ENABLED flags unsigned AD-integrated zones, and DNS_WILDCARD_RECORDS flags existing wildcard entries for manual review.