Allowing Nonsecure Dynamic Updates Lets Any Host Hijack an AD-Integrated DNS Zone

Symptom

A workstation joined to the domain registers a DNS host record with the same name as an existing server, and clients begin intermittently resolving that name to the wrong IP address. Helpdesk tickets describe authentication failures, LDAP timeouts against what should be a domain controller, and application connection errors that come and go depending on which client cached which address. Nothing in the DNS console shows an obvious error: the zone loads, replicates and serves answers normally.

False Assumption

The team assumes that because the zone is Active Directory-integrated and replicates only between domain controllers, record writes are implicitly restricted to authenticated, authorised sources. The visible security boundary is domain membership and zone replication scope, not the update mechanism itself. Nobody separately checked the zone’s Dynamic Updates setting, because the default installed years earlier by an unremembered administrator was Nonsecure and secure, a setting that predates hardened defaults and was never revisited.

Root Cause

Windows DNS zones support three dynamic update modes: None, Secure only (Kerberos/SSPI-authenticated updates via GSS-TSIG, effective only on AD-integrated zones), and Nonsecure and secure. The last mode accepts secure updates when offered but will also accept plain, unauthenticated RFC 2136 dynamic updates from any host that can reach the DNS server on UDP/TCP 53, regardless of domain membership. Per Microsoft’s own security guidance, DNS is one of the identity-adjacent control surfaces that benchmark-aligned hardening expects to be explicitly reviewed rather than left at an inherited default (Microsoft cloud security benchmark overview, Microsoft Learn). Any device on the reachable network segment can send an unauthenticated update packet claiming ownership of an existing name; the server will accept it because the zone does not require the update to be secure, it merely permits secure updates in addition to nonsecure ones. There is no authentication challenge, no domain membership check and no audit prompt at the moment of the overwrite.

Impact

Any host that can reach UDP/TCP 53 on an authoritative name server for the zone can register or overwrite records for names it does not own, including names resembling domain controllers, file servers or line-of-business hosts, without ever authenticating to the domain. This is a name resolution integrity failure with follow-on consequences for authentication (Kerberos SPN resolution), certificate issuance workflows that trust DNS for identity, and any client that resolves a service name before connecting. The blast radius extends to every client that queries the affected zone, not just the directly targeted record, and the failure is silent until someone notices resolution behaving unpredictably.

Diagnosis

Confirm the dynamic update setting on the affected zone before assuming any other cause. On the DNS server, open the DNS Manager console, right-click the zone, choose Properties, and read the value of the Dynamic updates dropdown on the General tab; the equivalent PowerShell check is read-only and does not alter server state.

1. Run Get-DnsServerZone -Name '<zonename>' | Select-Object ZoneName,DynamicUpdate,ZoneType,IsDsIntegrated on the authoritative DNS server to confirm the zone is AD-integrated and read its current DynamicUpdate value.
2. Run Get-DnsServerResourceRecord -ZoneName '<zonename>' -Name '<suspect-hostname>' to list every record registered under the contested name, including timestamp and record data, to see whether more than one host has claimed the name.
3. Cross-reference the record’s owning host against DHCP lease logs or the asset inventory to identify whether the registering device is a managed, domain-joined system or an unexpected host.

Correction

The correction is to change the zone’s dynamic update setting from Nonsecure and secure to Secure only, which is a state-changing configuration change and must go through a controlled maintenance path rather than being applied ad hoc. Before changing anything, capture the current setting and record inventory as a baseline, apply the change in a maintenance window, and confirm client update behaviour afterwards. This is a human-executed configuration change made through DNS Manager or an equivalent authenticated management session; no command in this article performs the change itself, because the change must be preceded by a documented approval and baseline capture step that a generic command cannot guarantee. The safe sequencing is: (1) capture baseline zone settings and record state using the read-only diagnosis commands above, (2) during an approved change window, set the zone’s Dynamic updates value to Secure only using DNS Manager (Zone Properties > General > Dynamic updates), (3) confirm no legitimate nonsecure-update-dependent workflow exists (for example, non-Windows devices or scripts relying on unauthenticated RFC 2136 updates), and (4) validate using the steps below.

Validation

Validation confirms the zone now rejects unauthenticated updates while legitimate domain-joined clients continue to register and update their own records without manual intervention.

1. Re-run Get-DnsServerZone -Name '<zonename>' | Select-Object ZoneName,DynamicUpdate and confirm the value now reads Secure.
2. From a domain-joined test client, run ipconfig /registerdns and confirm the client’s own record still registers successfully via secure dynamic update, evidenced by an unchanged or refreshed timestamp in Get-DnsServerResourceRecord for that host.
3. From a non-domain-joined test host on the same segment, attempt an unauthenticated dynamic update against the same zone using a testing tool (for example nsupdate in non-secure mode) and confirm the server returns a refused response and no record is created or altered.

Pass condition: legitimate secure updates succeed, unauthenticated updates are refused, and no unexplained record changes appear in the zone during a 24–48 hour monitoring window following the change.

Rollback

If the change to Secure only breaks a legitimate workflow (commonly a non-Windows appliance or a script-based registration process that cannot perform secure dynamic updates), revert the zone’s Dynamic updates setting back to its captured baseline value using DNS Manager (Zone Properties > General > Dynamic updates), restoring the exact prior value recorded during the baseline capture step. After reverting, re-run the diagnosis commands to confirm the setting matches the pre-change baseline, and open a tracked follow-up to migrate the dependent workflow to an authenticated update path (for example, a scheduled task running under a domain identity, or a proxy service that performs secure updates on the device’s behalf) before attempting the hardening change again. Do not leave the zone rolled back indefinitely without a remediation plan, since that restores the original exposure.

Prevention

Treat DNS dynamic update mode as a reviewable security control on every AD-integrated zone, not a one-time installation default. Include the zone’s DynamicUpdate value in periodic configuration drift checks alongside other identity-adjacent controls referenced in benchmark-aligned hardening guidance, and require an explicit, documented exception with compensating controls (such as network segmentation restricting which hosts can reach port 53) for any zone that cannot move to Secure only. New zones created for AD-integrated DNS should default to Secure only at creation time, with any relaxation requiring named approval rather than being inherited silently from a wizard default.