How to Fix DNS Server Dynamic Update Record Injection: Set DNS Dynamic Updates to Secure Only

DNS Server Dynamic Update Record Injection means a DNS zone accepts RFC 2136 updates without authentication, so any host that can reach the server can add or overwrite records. Fix it by setting DNS dynamic updates to secure only on Active Directory-integrated zones (Set-DnsServerPrimaryZone -DynamicUpdate Secure) and, on BIND, by replacing IP-based allow-update with TSIG keys or none.

What the scanner is actually detecting

Several tools report the same misconfiguration under different names, and they test it in different ways.

Tenable lists plugin 35372 in the DNS family with Medium severity (CVSS v3 base 5.8) and the synopsis that the remote DNS server allows dynamic updates. Its solution is to limit which addresses may send updates (for example with BIND’s allow-update) or to require TSIG or SIG(0), and it notes you can ignore the result if the scanner’s address is inside the range you deliberately allow.

The difference matters. The Nessus result depends on where the scanner sits and which zone it tries. PingCastle reads the configured value straight from the directory, so it fires wherever a zone is set to Nonsecure and secure, whatever the network path. In Windows terms, every one of these findings points at that same zone setting.

Real-world risk, stated honestly

Microsoft’s documentation explains the core problem: by default the Windows DNS Client replaces an existing A record for its name with its own address, and without secure dynamic update nothing stops any machine on the network from doing the same. An attacker who can reach the DNS server can therefore:

• Repoint existing names. A file server, intranet application or proxy name can be moved to a host the attacker controls, which opens the door to credential capture and traffic interception.
• Tamper with Active Directory locator data. PingCastle points out that the _msdcs zones hold the domain controller and global catalog records the whole forest uses for authentication and replication.
• Alter reverse zones. PTR records can be changed to mislead controls that trust reverse lookups.

The limits are real too. The attacker needs network access to an authoritative server for the zone, which for AD DNS usually means a foothold inside the network. The update itself grants no code execution. Still, Microsoft states that AD-integrated zones allow only secure updates by default, so Nonsecure and secure on a domain zone is a deliberate or legacy change, usually made so non-domain devices could register. It is cheap to fix and worth doing promptly.

How to confirm it on the host

Windows DNS

On a domain controller or DNS server with the DnsServer module, list each zone’s update mode:

Get-DnsServerZone | Where-Object { -not $_.IsAutoCreated } |
    Select-Object ZoneName, ZoneType, IsDsIntegrated, DynamicUpdate

# Only the problem zones
Get-DnsServerZone | Where-Object DynamicUpdate -eq 'NonsecureAndSecure'

Add -ComputerName DC02 to check other servers. With dnscmd, dnscmd /zoneinfo corp.example.com allowupdate returns the value as a DWORD: 0 is no updates, 1 is nonsecure and secure, 2 is secure only. If PingCastle names a zone you do not see in DNS Manager, such as RootDNSServers, use the DN and partition in the rule’s detail line to locate it before changing anything.

BIND 9

named-checkconf -p | grep -nE 'zone "|allow-update|update-policy'

BIND denies updates by default, so a flagged BIND server has an allow-update list somewhere. Also look for allow-update-forwarding on secondaries.

From the network with nsupdate

From an authorized, non-domain Linux host, during a change window, try an unsigned update with a throwaway name:

nsupdate
> server 10.0.0.10
> zone corp.example.com
> update add nsupdate-test.corp.example.com. 300 A 192.0.2.55
> send
> quit

dig @10.0.0.10 nsupdate-test.corp.example.com A +short

A protected zone makes nsupdate print update failed: REFUSED. If dig returns 192.0.2.55, the zone accepts unauthenticated updates. Remove the test record with update delete nsupdate-test.corp.example.com. A followed by send.

How to fix it

Windows: set AD-integrated zones to Secure only

In DNS Manager, right-click the zone, choose Properties, confirm on the General tab that the type is Active Directory-integrated, and set Dynamic updates to Secure only. In PowerShell:

# Preview
Get-DnsServerZone | Where-Object { $_.DynamicUpdate -eq 'NonsecureAndSecure' -and $_.IsDsIntegrated } |
    Select-Object ZoneName

# Apply
Get-DnsServerZone | Where-Object { $_.DynamicUpdate -eq 'NonsecureAndSecure' -and $_.IsDsIntegrated } |
    ForEach-Object { Set-DnsServerPrimaryZone -Name $_.ZoneName -DynamicUpdate Secure -PassThru }

The dnscmd equivalent is dnscmd DC01 /Config corp.example.com /AllowUpdate 2. Because the zone lives in Active Directory, the change travels with directory replication; confirm it on each DNS server afterwards.

Windows: file-backed primary zones

Microsoft is explicit that secure dynamic update exists only for AD-integrated zones, so the Secure value is not available for a file-backed zone. Either convert the zone on a domain controller and then secure it:

ConvertTo-DnsServerPrimaryZone -Name "corp.example.com" -ReplicationScope Domain -PassThru
Set-DnsServerPrimaryZone -Name "corp.example.com" -DynamicUpdate Secure

or, if nothing needs to register in that zone, turn updates off with -DynamicUpdate None.

DHCP servers that register records for clients

Devices that cannot authenticate (printers, appliances, many non-Windows hosts) stop self-registering once a zone is secure only. The supported pattern is to let the Windows DHCP server register for them using a dedicated, unprivileged domain account:

Set-DhcpServerDnsCredential -Credential (Get-Credential) -ComputerName "dhcp01.corp.example.com"

Microsoft recommends this especially when DHCP runs on a domain controller, since otherwise the service inherits the DC’s right to change any record. Be careful with the DnsUpdateProxy group: records created by its members are not secured, and the next account to register the name becomes its owner.

BIND 9: no updates, or key-based updates only

ISC’s own guidance is that IP-based allow-update is insecure because UDP source addresses are easily forged. If the zone does not need dynamic updates, close it:

zone "corp.example.com" {
    type primary;
    file "/var/lib/bind/corp.example.com.db";
    allow-update { none; };
};

If a DHCP server or automation must update it, use a TSIG key:

# Generate a key (default algorithm HMAC-SHA256)
tsig-keygen ddns-updater. > /etc/bind/ddns-updater.key
chmod 640 /etc/bind/ddns-updater.key

include "/etc/bind/ddns-updater.key";

zone "dyn.corp.example.com" {
    type primary;
    file "/var/lib/bind/dyn.corp.example.com.db";
    update-policy { grant ddns-updater. zonesub ANY; };
};

You cannot use allow-update and update-policy in the same zone. A simpler keyed form is allow-update { key ddns-updater.; };. ISC also suggests keeping dynamic data in a delegated subdomain, as above, so the zone holding your important records never needs updates. Apply the change with named-checkconf && rndc reconfig, and give the key file to clients over a secure channel (nsupdate -k /etc/bind/ddns-updater.key).

How to verify the fix and rescan

1. Rerun Get-DnsServerZone | Where-Object DynamicUpdate -eq ‘NonsecureAndSecure’ on every DNS server. Expect no AD-integrated zones.
2. Repeat the unsigned nsupdate test. Expect update failed: REFUSED.
3. Confirm legitimate registration still works. On a DHCP client, run ipconfig /renew (Microsoft recommends it over /registerdns for DHCP clients), then check the name with Resolve-DnsName.
4. On BIND, send a signed test update with nsupdate -k and confirm it succeeds.
5. Rerun the PingCastle healthcheck and rescan with Nessus from the same scanner position that raised plugin 35372.

While you are reviewing zone contents, look for records nobody recognizes that may have been added while the zone was open. A passive DNS subdomain inventory is a useful baseline to compare against.

What can break and how to roll back

• Non-domain devices stop updating. Their records go stale or never appear. Move them to DHCP-based registration or static records.
• Record ownership conflicts. In a secure-only zone, a stale A record owned by another account blocks anyone else from registering that name. Microsoft recommends aging and scavenging to prevent this.
• DHCP failover. Without a shared dedicated credential, a partner DHCP server cannot update names the other server registered.
• BIND clients without the key receive REFUSED.

Rollback is a single setting, so treat any rollback as a time-limited, documented exception:

# Windows
Set-DnsServerPrimaryZone -Name "corp.example.com" -DynamicUpdate NonsecureAndSecure

# BIND: restore the previous allow-update line, then
named-checkconf && rndc reconfig

Stale records are a related hygiene issue: names that point at resources you no longer own are covered in our guide to dangling DNS and subdomain takeover.

Common false positive reasons

• Scanner inside the allowed range. Tenable itself says the result can be ignored when the scanner’s IP is authorized to update. That said, ISC considers IP-based update control insecure, so plan to move to keys anyway.
• Flagged on a secondary. A secondary with allow-update-forwarding relays updates to the primary, which sees the secondary’s address. The fix belongs on the primary’s access control, not on the secondary.
• The IP is not the zone’s server. Firewalls and load balancers that proxy port 53 can make the result appear on the wrong address; trace which server actually holds the zone.
• Intentionally dynamic zones for non-domain systems. Document the exception and isolate them in a delegated subdomain.
• Replication lag. PingCastle may report a zone you already fixed if it read from a DC that has not replicated yet.

FAQ

Does Secure only require Active Directory?

Yes. On Windows, secure dynamic update works only for AD-integrated zones. File-backed zones can use None or Nonsecure and secure.

What does dnscmd /AllowUpdate 2 mean?

Secure only. 0 disables dynamic updates and 1 allows nonsecure and secure updates.

Does Secure only stop every rogue record?

It requires an authenticated domain account and enforces record ownership. It does not stop an authenticated account from registering a name nobody owns yet, so keep reviewing new records.

How do I fix Nessus 35372 on BIND?

Replace IP-based allow-update with allow-update { none; }; or a TSIG-based update-policy, reload with rndc reconfig, and rescan.

Tracking this finding across many hosts

Plugin 35372 tends to appear on every domain controller at once, so it helps to keep one list. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners (Nessus results come in by uploading the exported .nessus file), merges duplicates per scanner and can retest an individual Nessus finding to confirm closure after the zone change.

Sources

• Tenable: Nessus plugin 35372, DNS Server Dynamic Update Record Injection
• PingCastle rule descriptions: A-DnsZoneUpdate1 and A-DnsZoneUpdate2
• Microsoft Learn: Dynamic DNS Update in Windows and Windows Server
• Microsoft Learn: Set-DnsServerPrimaryZone
• ISC BIND 9 Administrator Reference Manual: Security Configurations (Dynamic Update Security, TSIG)