DNS Dynamic Update Failures on Windows Server

When dns dynamic update failed errors surface on Windows Server, records stop registering automatically – clients go missing from DNS, DHCP leases don’t update forward or reverse zones, and services that depend on name resolution start failing. This guide covers every common cause, organized by symptom so you can identify the actual failure point without chasing the wrong fix.

Quick diagnosis: dns dynamic update failed by symptom

How dns dynamic update failed errors happen

A dns dynamic update failed condition on Windows Server traces back to one of two mechanisms: either the DNS client or DHCP server never successfully sent the update, or the DNS server received it and refused it. Understanding which mechanism is in play determines the entire fix path. Microsoft documents the dynamic update protocol and its failure modes in the DNS dynamic update troubleshooting guide and the Windows Server DNS documentation. For DHCP-side registration failures specifically, the relevant reference is DHCP and DNS registration.

Client self-registration: a domain-joined Windows client registers its own A (and AAAA) records directly with the authoritative DNS server. The client authenticates using Kerberos/GSS-TSIG (RFC 3645) when the zone requires Secure-only updates. The computer account in AD becomes the record owner.

DHCP server registration: the DHCP server registers DNS records on behalf of the client. By default the DHCP server registers PTR records; A record registration depends on the DNS tab settings and client negotiation. The identity that registers the record – the DHCP server computer account, a dedicated DHCP DNS update credential, or a member of DnsUpdateProxy – becomes the record owner and determines who can update it later.

Ownership is the core of most dns dynamic update failed scenarios in AD-integrated Secure-only zones. The record owner has write access; other principals are refused.

Who owns the record – the key design decision

One client: dns dynamic update failed

Stale record owned by a different principal

The most frequently encountered cause of single-client dns dynamic update failed in established AD environments: the existing DNS record is owned by a security principal that is not the current computer account. The update attempt is refused at the DNS server, but the client receives no useful error at the prompt.

This happens when:

• A computer account was deleted and recreated – the new account has a new SID, but the old SID owns the DNS record
• 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 cannot 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 20319 (A record) and 20322 (PTR record) with error 9005 (DNS_ERROR_RCODE_REFUSED). A fountain pen icon next to a DHCP lease in the DHCP console indicates incomplete DNS registration.

Fix: delete the orphaned record and let the legitimate owner re-register. After deletion, run ipconfig /renew on a DHCP client. The client or DHCP server re-creates the record under the correct ownership.

For scripted ACL inspection: use DNS Manager for the Security tab view. Get-DnsServerResourceRecord returns record data and timestamps but does not 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 triggers the DNS Client service to attempt immediate A record registration for the adapter. It returns to the prompt regardless of whether the DNS server accepted the update. A silent dns dynamic update failed at the server only appears in the DNS-Client event channels.

In environments where DHCP is configured to own and update A records, using ipconfig /registerdns can create or reinforce a client-owned record that the DHCP update identity cannot later modify. Use it after confirming which principal is intended to own the record.

To check the result: enable the DNS-Client event log under Applications and Services Logs → Microsoft → Windows → DNS Client Events, then re-run the command and look for Events 8015 (timeout) or 8018 (refused).

What ipconfig /registerdns does not do:

• Register SRV or Netlogon records – that is nltest /dsregdns on a DC
• Register PTR records on DHCP-addressed adapters – that is the DHCP server job by default
• Confirm the server accepted the update – the prompt returns success regardless

Every client: dns dynamic update failed

Zone not configured for dynamic updates

The simplest zone-wide cause of dns dynamic update failed across all clients: the zone is set to None. All dynamic registrations are refused. Newly created reverse lookup zones default to None in some configurations and accept no PTR registrations.

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

Fix for AD-integrated zones: set to Secure only. This is the recommended setting for AD environments – only authenticated principals can register records.

Fix for non-AD / standard primary zones: set to Nonsecure and secure. This accepts unauthenticated updates and should be evaluated for security implications in the specific environment.

Wrong DNS server or unreachable authoritative server

A client pointing at a secondary zone or a caching-only server will see dns dynamic update failed on every attempt – only the primary authoritative server or an AD-integrated replica accepts dynamic updates. Timeouts (Event 8015) rather than refusals (Event 8018) indicate a reachability problem.

Verify the client is pointing at an AD DNS server that hosts a writable copy of the zone: Resolve-DnsName [zone] -Type SOA from the client shows the authoritative server. The client configured DNS server should match or forward to it.

Secure-only zones and non-domain devices

Devices that cannot authenticate to AD DNS cannot directly perform Secure-only updates – dns dynamic update failed is the expected result. This includes most IoT devices, network appliances, and unmanaged printers. Linux systems that are properly domain-integrated can update through Kerberos/GSS-TSIG; others require DHCP to register on their behalf using a dedicated update credential.

A records work, PTR records do not

PTR records register separately from A records. The DHCP server is responsible for PTR registration by default. A records working while PTR records are absent almost always points to one of two causes: no reverse lookup zone exists, or DHCP lacks the credentials to register in it.

Reverse lookup zone missing

Reverse zones are not created automatically. A missing reverse zone causes DHCP PTR registration attempts to fail silently – and when the DHCP DNS update queue fills with failed PTR requests, forward A record registration can also slow down or stall.

Create reverse lookup zones for the address ranges that require PTR registration. Align zones with administrative and subnet boundaries.

DHCP not configured to register PTR records

DHCP server registration settings control which records the DHCP server creates. The relevant setting is on the DHCP server Properties → DNS tab: “Dynamically update DNS records for DHCP clients that do not request updates” covers clients that do not send Option 81. Without this setting, non-Windows clients and legacy devices are not registered.

DHCP Events 20322 with error 9005 on PTR records indicate the reverse zone requires authentication and the DHCP server is not using a credential that has write access to it – dns dynamic update failed at the PTR registration step.

DHCP DNS update credentials

When the DHCP server registers records in an AD-integrated Secure-only zone, it needs an identity that can authenticate. Without a dedicated DNS update credential, the DHCP server registers under its own computer account identity. On a domain controller this is the DC computer account, which has broad permissions – documented by Microsoft as Event 1056.

Configure a dedicated low-privilege domain user account as the DHCP DNS update credential:

The credential account needs no special privileges – a plain domain user with password set to never expire is correct. This applies to every DHCP server that registers DNS records in AD-integrated zones, including DHCP servers that are not on domain controllers.

Records register and later disappear

If records are present after a client boots or renews a lease and then disappear on a regular cycle, the problem is DNS aging and scavenging – not dns dynamic update failed. This is a common misdiagnosis.

How aging and scavenging interact with dynamic registration

Each dynamically registered record carries a timestamp. Scavenging removes records whose timestamps have not been refreshed within the configured aging windows. If the aging intervals are shorter than the real refresh cycle, scavenging removes records that are still in active use.

The key intervals are the no-refresh interval (period after registration during which refreshes are ignored) and the refresh interval (period during which a refresh must arrive before the record becomes eligible for scavenging). In DHCP environments, account for lease duration, T1/T2 renewal behavior, the DNS scavenging period, AD replication latency, and how long clients may remain offline.

Convert records for servers, printers, and other infrastructure with static IPs to static DNS records (no timestamp). Static records are never scavenged regardless of aging settings.

For the full scavenging configuration and safe rollout workflow, see DNS Scavenging Windows Server. For recovery when 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 addresses and never get an IP to register in DNS. This looks like dns dynamic update failed but is actually a DHCP service failure.

Event 1046 in the System log: “The DHCP/BINL service on the local machine has determined that it is not authorized to start. It has stopped servicing clients.”

DnsUpdateProxy group

Members of DnsUpdateProxy create DNS records with a permissive security descriptor that allows another qualified updater to take ownership later. This was designed for environments with multiple DHCP servers handling overlapping scopes – the second server can overwrite records created by the first.

The same permissive ACL is the security concern. Records created by group members can be updated by other authenticated principals, not just authorized DHCP servers. Additionally, when a member of DnsUpdateProxy creates its own DNS record, that record also receives the same permissive ACL.

Do not add a domain controller to DnsUpdateProxy. Do not run DHCP on a DC without a dedicated DNS update credential.

For most AD environments, the recommended approach is to not use DnsUpdateProxy at all. Use a dedicated DHCP DNS update credential configured via netsh dhcp server set dnscredentials instead. The dedicated credential provides consistent ownership without the broad ACL exposure.

Kerberos and secure dynamic update failures

When a domain-joined client performs a Secure-only dynamic update, it first negotiates a security context with the DNS server using TKEY, exchanging tokens to produce a GSS-TSIG signature. The DNS server validates this before accepting the update. Kerberos clock skew between the client and the DC breaks ticket acquisition and causes dns dynamic update failed with Event 8018.

Event ID reference

For detailed DNS Server Event IDs (4000, 4013, 4015, 407, 408, 6702), see Windows Server DNS Event IDs Explained.

Hardening checklist

FAQ

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

The command triggers a registration attempt locally and returns to the prompt regardless of whether the DNS server accepted the update. Failures are silent at the prompt. Check the DNS-Client event channels (Applications and Services Logs → Microsoft → Windows → DNS Client Events) for Events 8015 or 8018 after running the command. If neither appears and the record is still incorrect, confirm which DNS server is authoritative for the zone and whether it even received the update request.

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

Error 9005 (DNS_ERROR_RCODE_REFUSED) means dns dynamic update failed because the DNS server refused the DHCP registration attempt. The record already exists and is owned by a different principal – typically the client computer account. The DHCP server cannot overwrite it under Secure-only mode. Decide which principal should own the record and align the DHCP DNS tab settings accordingly. If clients should own their records, disable DHCP A-record registration.

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 the ACL entries show which security principal created and can modify the record. Note that computer accounts are not shown by default – 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, as Get-DnsServerResourceRecord does not 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. The existing DNS record is still owned by the old SID, which no longer exists or no longer matches the current account. The new computer account is refused when it tries to update. Fix: delete the old DNS record and let the client re-register after rejoin. The new computer 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: (1) does a reverse lookup zone exist for the subnet? DNS Manager shows all reverse zones. (2) Is the zone set to accept dynamic updates? Newly created reverse zones sometimes default to None. (3) Is DHCP configured to register PTR records? Check the DHCP server Properties → DNS tab. (4) Does DHCP have a credential to authenticate to a Secure-only reverse zone? DHCP Events 20322 with error 9005 confirm dns dynamic update failed at the PTR step – configure a dedicated DNS update credential.

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

Devices that cannot authenticate to AD DNS will see dns dynamic update failed when attempting Secure-only updates directly. Linux systems that are properly domain-integrated can perform updates via Kerberos/GSS-TSIG. For devices that cannot authenticate, DHCP registration using a dedicated credential is the supported path – the DHCP server registers the record on the device behalf.

DHCP is authorized but Event 1046 keeps firing after a server rebuild – what now?

A server rebuild typically changes the machine SID or the server AD computer object. The old DHCP authorization entry in AD references the old IP or object. Run Get-DhcpServerInDC to see what is currently authorized. Remove stale entries with Remove-DhcpServerInDC, then re-authorize with the current FQDN and IP. If the error persists, check ADSI Edit → Sites and Services → Services → NetServices for orphaned DHCP server objects from the previous install.