DNS Dynamic Update Failed: Client, DHCP, and ACL Fixes

A Windows DNS dynamic update fails for one of four reasons: it was never triggered, the updater couldn’t discover or reach the writable authoritative server, the zone doesn’t accept the update type, or the record’s security descriptor doesn’t allow that principal. Identify whether the client or DHCP attempted the update, then record the exact event message, error code, zone, record owner/ACL, and SOA target.

Don’t delete records, force registration, change DHCP ownership, or loosen a Secure-only zone until the intended owner is known. On a DHCP client, prefer ipconfig /renew after fixing the root cause – /registerdns bypasses DHCP and can create a record DHCP can’t modify later.

Quick diagnosis: DNS dynamic update failed by symptom

How Windows chooses the client or DHCP as updater

A failed update traces back to one of two mechanisms: either the DNS client or DHCP server never successfully sent it, or the DNS server received it and refused it. Which mechanism is in play determines the entire fix path. Microsoft documents the protocol and its failure modes in the Dynamic DNS Update documentation and the dynamic update troubleshooting guide. For DHCP-side behavior specifically, see registration behavior when DHCP manages dynamic updates.

For a Windows DHCP client using Option 81, the default negotiation has the client update its own A/AAAA record and DHCP update the PTR record – but it’s not a fixed rule. DHCP can be configured to update both, older clients may need DHCP to register both, and Windows 8.1+ can keep registering its own A record even when DHCP is set to “Always dynamically update,” unless configured to honor the override – a documented source of competing ownership in Secure-only zones.

Microsoft’s current guidance generally prefers domain-joined clients to register their own records rather than DHCP owning them – but don’t treat one model as universally correct. Align the DHCP DNS tab, Option 81 behavior, client settings, and record ownership to the design you actually intend, then verify it.

Ownership is a strong diagnostic clue in Secure-only zones, since the creator normally controls the record – but the real authorization decision comes from the dnsNode security descriptor, inherited permissions, and explicit Deny entries, not the owner field alone. Check both Owner and effective permissions before blaming ownership itself.

One client: DNS dynamic update failed

Stale record owned by a different principal

The most common cause of single-client DNS dynamic update failed in an established AD environment: the existing DNS record’s ACL doesn’t permit the current computer account. The update is refused at the DNS server, but the client gets no useful error at the prompt.

This happens when:

• A computer account was deleted and recreated – the new account has a new SID, and the record’s ACL still reflects the old one
• The machine was rejoined to the domain – same SID-change effect
• The DHCP server created the record first, so the DHCP identity owns it and the client can’t overwrite it
• A different DHCP server created the record under a different identity

Event IDs: DNS Client System log – Event 8018 (“the DNS server contacted refused the update request”). DHCP server – Events 20317/20318 (IPv4 forward record) with error 9005 (DNS_ERROR_RCODE_REFUSED). 9005 means the server refused the operation – it doesn’t by itself prove the record is owned by the client; check the record/zone ACL, the intended updater, a Secure-only ownership conflict, or update being disabled before assuming the cause.

Before fixing anything, confirm the name isn’t a static infrastructure, cluster, service, or manually managed record, and record the current values, timestamp, owner, and ACL. Identify the intended updater, delete only the confirmed stale record, then trigger the appropriate client or DHCP workflow and verify both forward and reverse records under the new owner. Don’t delete every same-name A/AAAA record without checking for multihomed or load-balanced use.

For scripted ACL inspection: Get-DnsServerResourceRecord returns record data and timestamps but doesn’t expose the AD security descriptor. To query ownership programmatically, access the underlying dnsNode object in Active Directory using ADSI or Get-Acl on the AD path.

What ipconfig /registerdns actually does

ipconfig /registerdns forces direct client registration, bypassing DHCP’s ownership workflow – depending on configuration, this can include A and possibly PTR records. It returns to the prompt regardless of server acceptance; a refusal is silent unless you check the DNS Client event channel.

It’s useful only when direct client ownership is the intended design. For a Windows DHCP client, correct the root cause and use ipconfig /renew instead – this preserves the negotiated DHCP/DNS workflow rather than resetting a record’s ownership to the client.

Verify via the System log (provider Microsoft-Windows-DNS-Client) for Events 8015/8018, and the DNS server’s own audit Event 519 where enabled – not the client channel alone.

What ipconfig /registerdns does not do:

• Register SRV or Netlogon records – that’s nltest /dsregdns on a DC
• Guarantee PTR registration – PTR behavior depends on adapter/DHCP configuration
• Confirm the server accepted the update – the prompt returns regardless

Every client: DNS dynamic update failed

Zone not configured for dynamic updates

The simplest zone-wide cause of DNS dynamic update failed across every client: the zone is set to None, and all dynamic registrations are refused. Some newly created reverse lookup zones default to None and accept no PTR registrations.

Check: DNS Manager -> zone -> Properties -> General tab -> Dynamic updates. Three options: None, Nonsecure and secure, and Secure only (available only for AD-integrated zones).

For AD-integrated zones: set to Secure only – only authenticated principals can register records. For non-AD / standard primary zones: Nonsecure and secure may be the only dynamic-update option available for a file-backed zone, but it accepts unauthenticated updates – use it only where that risk is understood, and prefer an AD-integrated Secure-only zone where possible.

SOA discovery and the writable authoritative server

A cache-only resolver or secondary zone isn’t automatically a failure – see Windows Server DNS Forwarders for the broader forwarder/cache-only architecture question. The client queries its configured server for the zone’s SOA, identifies the writable authoritative server from that response, and sends the update there – Windows DNS secondaries can even forward it through the replication topology toward the primary. A cache-only resolver still works, provided the client gets the correct SOA response, resolves the primary, reaches it, and authenticates where required.

Timeouts (Event 8015) point toward reachability to whatever server SOA discovery resolved to; refusals (Event 8018) point toward zone mode or ACL once that server is confirmed reachable. In an AD-integrated zone, any DC hosting a writable copy can accept the update – don’t assume the client’s configured DNS server itself must host the writable zone.

Secure-only zones and non-domain devices

Devices that can’t authenticate to AD DNS get refused on Secure-only updates – most IoT devices, appliances, and unmanaged printers. Domain-integrated Linux can update via Kerberos/GSS-TSIG; others need DHCP registering on their behalf with a dedicated credential.

A records work, PTR records don’t

PTR records register separately from A records, with DHCP responsible by default. A working while PTR is absent almost always means: no reverse zone exists, or DHCP lacks the credential to register in it.

Reverse lookup zone missing or unreachable

Reverse zones aren’t created automatically. A missing or unreachable one can cause PTR failures and fill the DHCP retry queue, delaying forward A registration too. On current Windows Server this surfaces as specific DHCP events, not a silent failure:

A missing SOA response on the reverse zone is a major clue. Create reverse lookup zones for the address ranges that require PTR registration, aligned with administrative and subnet boundaries.

DHCP DNS registration settings

DHCP’s DNS tab (server- or scope-level) controls which records it creates: Enable DNS dynamic updates according to the settings below, only if requested by clients, Always dynamically update, Discard A and PTR records when lease is deleted, and update for clients that do not request updates (no Option 81). Server and scope settings can differ – capture the effective scope settings first:

DHCP Events 20319/20320 on PTR records with error 9005 indicate the reverse zone requires authentication and DHCP isn’t using a credential with write access to it.

DHCP DNS credentials and DnsUpdateProxy

When DHCP registers records in an AD-integrated Secure-only zone, it needs an identity that can authenticate. Without a dedicated DNS update credential, DHCP registers under its own computer account – on a domain controller, that’s the DC computer account, which Microsoft documents as Event 1056 because of its broad permissions.

Configure a dedicated low-privilege domain user account as the credential, using current PowerShell rather than netsh with a password on the command line – the older syntax exposes the password through console history, process inspection, and incident transcripts:

The account needs no administrative privileges – a plain domain user used consistently across every DHCP server updating the same records. The credential must stay valid, with rotation coordinated across every server using it; a forgotten permanent password isn’t a substitute for a documented lifecycle. Don’t restart the DHCP service automatically after setting the credential – it interrupts lease servicing, so only restart when actually required, in a maintenance window.

DnsUpdateProxy: members create records with a permissive security descriptor letting another qualified updater take ownership later – supported for multiple DHCP servers on overlapping scopes. The tradeoff: any authenticated principal, not just authorized DHCP servers, can update those records. It remains supported, but membership alone isn’t the complete design – prefer a dedicated shared DHCP credential instead, never run DHCP on a DC without one, and never add a DC to this group.

Secure dynamic updates and Kerberos

A domain-joined client doing a Secure-only update first negotiates a security context via TKEY, producing a GSS-TSIG signature the server validates before accepting it. Kerberos clock skew between client and DC breaks ticket acquisition and produces Event 8018. The default tolerance is five minutes, but it’s configurable policy – check the actual domain setting rather than treating five as fixed.

Records register, then disappear

If records appear after boot/lease renewal and disappear on a regular cycle, that’s DNS aging and scavenging, not a registration failure – a common misdiagnosis. Each registered record carries a timestamp; scavenging removes ones whose timestamp hasn’t refreshed within the aging window. Account for lease duration, T1/T2 renewal, the scavenging period, replication latency, and offline time:

Use manually managed, timestamp-zero records only for infrastructure names intentionally maintained as static – not a blanket practice for every server or printer. Don’t convert DC locator or other automatically managed service records into manual ones, and document ownership for every static record you create. For the full scavenging configuration and safe rollout workflow, see DNS Scavenging Windows Server; for recovery after scavenging has already deleted valid records, see DNS Scavenging Deleted Records: Recovery and Prevention.

DHCP not authorized in Active Directory

An unauthorized DHCP server stops issuing leases – clients fall back to APIPA and never get an IP to register, which looks like DNS dynamic update failed but is a DHCP failure. Event 1046: “The DHCP/BINL service … has determined that it is not authorized to start. It has stopped servicing clients.”

Event ID reference

For DNS dynamic update failed diagnosis, read the full provider, message, and embedded error code before diagnosing from an Event ID alone – registration and deregistration events can vary by operation and Windows version. Scavenging Events 2501/2502 belong primarily to the DNS Scavenging article linked above. Detailed DNS Server role Event IDs (4000, 4013, 4015, 407, 408, 6702) are covered in the Windows Server DNS Event IDs guide linked in the scope note.

Reproducible diagnostic workflow

Group Policy commonly controls client-side registration behavior – see Group Policy in Active Directory if a GPO setting is the suspected cause. On the affected client:

On the DNS server:

Use DNS Manager’s Advanced view for the record’s Owner and Security tab. On the DHCP server:

After applying the fix, for a DHCP Windows client, verify with ipconfig /renew rather than /registerdns, then confirm the A/AAAA record, PTR record, timestamp, owner/ACL, the client event, the DHCP event, and the DNS server’s audit event where enabled – not just the command prompt’s return.

Hardening checklist

FAQ

Why does ipconfig /registerdns show no error but DNS dynamic update failed on the server?

The command triggers a local registration attempt and returns to the prompt regardless of server acceptance – failures are silent there. Check the DNS-Client event channel (Applications and Services Logs -> Microsoft -> Windows -> DNS Client Events) for Events 8015 or 8018. If neither appears and the record is still wrong, confirm which server SOA discovery actually resolved to.

The DHCP server logs error 9005 – what does that mean?

Error 9005 (DNS_ERROR_RCODE_REFUSED) means the server refused the operation – it doesn’t by itself prove the record belongs to the client. Inspect the record type, zone, updater identity, current ACL/owner, and DHCP DNS design before concluding the cause.

How do I check who owns a DNS record?

In DNS Manager: enable View > Advanced, find the record, right-click -> Properties -> Security tab. The Owner and ACL entries show which security principal created and can modify the record – computer accounts aren’t shown by default, so click Object Types and check the Computers box. For programmatic inspection, query the underlying dnsNode AD object using ADSI or Get-Acl on the AD path, since Get-DnsServerResourceRecord doesn’t expose the security descriptor.

A machine was rejoined to the domain and now DNS dynamic update failed – why?

Rejoining creates a new computer account with a new SID. If the record’s ACL still reflects the old SID, the new account gets refused. Verify the ACL and owner first, then delete the confirmed stale record and let the client re-register – the new account will own the new record.

PTR records for DHCP clients are missing but A records are fine – where do I start?

Check in order: does a reverse lookup zone exist for the subnet? Is it set to accept dynamic updates (some newly created reverse zones default to None)? Is DHCP configured to register PTR records (DHCP server Properties -> DNS tab)? Does DHCP have a credential to authenticate to a Secure-only reverse zone? DHCP Events 20319/20320 with error 9005 point at the PTR step specifically – configure a dedicated DNS update credential with Set-DhcpServerDnsCredential.

Can Linux or non-domain clients use DNS dynamic updates in a Windows AD environment?

Devices that can’t authenticate to AD DNS get Secure-only updates refused. Properly domain-integrated Linux systems can update via Kerberos/GSS-TSIG; for anything else, DHCP registration with a dedicated credential is the supported path.

Can a client use a cache-only DNS server and still register successfully?

Yes, if SOA discovery returns the writable authoritative server and the client can resolve, reach, and authenticate to it. The cache-only server doesn’t itself need to host the zone.

References

• Dynamic DNS Update in Windows and Windows Server
• Troubleshooting DNS dynamic update issues
• Registration behavior when DHCP manages dynamic updates
• DHCP logging events for DNS record registrations
• DHCP deployment and DNS settings/credentials
• Event 1056 after installing DHCP on a domain controller
• DHCP authorization failures and Event 1046
• DNS scavenging setup