How to Configure DHCP with DNS Dynamic Update on Windows Server 2019

March 22, 2026
Tutorials
Comment off

Introduction to DHCP with DNS Dynamic Update on Windows Server 2019

DNS Dynamic Update (DDNS) allows the DHCP server to automatically register and deregister DNS records on behalf of DHCP clients whenever they obtain, renew, or release IP addresses. Without DDNS, administrators must manually maintain DNS A records and PTR records every time a machine gets a new IP, which is impractical in any environment with more than a handful of machines. Windows Server 2019 supports two models: clients register their own DNS records, or the DHCP server registers records on behalf of clients. The second model is essential for non-Windows clients (Linux, printers, embedded devices) that cannot register their own records.

Understanding the DDNS Registration Models

Client-initiated registration: The client sends a DHCP request with the FQDN option (option 81). The client then directly contacts the DNS server to register its A record. The DHCP server registers only the PTR (reverse lookup) record. This is the default for domain-joined Windows clients.

DHCP server proxy registration: The DHCP server registers both the A record and PTR record in DNS on behalf of the client. This is required for non-Windows clients or when clients cannot directly update DNS. The DHCP service authenticates to the DNS server using a special AD account called the DnsUpdateProxy group.

Prerequisites

# Verify DNS and DHCP roles are installed and operational
Get-WindowsFeature -Name DHCP, DNS
Get-Service -Name DHCPServer, DNS

# Ensure forward and reverse lookup zones exist in DNS
Get-DnsServerZone | Select-Object ZoneName, ZoneType, DynamicUpdate | Format-Table

The DNS zone’s dynamic update setting must be set to Secure (for AD-integrated zones) or Nonsecure and Secure to accept DDNS registrations:

# Check dynamic update setting on forward zone
Get-DnsServerZone -Name "corp.example.com" | Select-Object ZoneName, DynamicUpdate

# Enable secure dynamic updates on the zone
Set-DnsServerPrimaryZone -Name "corp.example.com" -DynamicUpdate Secure

# For the reverse lookup zone
Set-DnsServerPrimaryZone -Name "100.168.192.in-addr.arpa" -DynamicUpdate Secure

Configure DDNS on the DHCP Scope

DHCP scope-level DNS settings override server-level settings for that specific scope. Configure the update behaviour per scope:

# View current DNS settings for the DHCP server
Get-DhcpServerv4DnsSetting

# View DNS settings for a specific scope
Get-DhcpServerv4DnsSetting -ScopeId "192.168.100.0"

# Configure scope to always register A and PTR records on behalf of clients
Set-DhcpServerv4DnsSetting `
    -ScopeId "192.168.100.0" `
    -DynamicUpdates Always `
    -DeleteDnsRROnLeaseExpiry $true `
    -UpdateDnsRRForOlderClients $true `
    -NameProtection $true

The key parameters explained:

DynamicUpdates Always: The DHCP server always registers DNS records, regardless of whether the client requests it. This is required for non-Windows clients.

DynamicUpdates OnClientRequest: (Default) DHCP server registers only when the client requests DDNS via option 81.

DynamicUpdates Never: No DHCP-initiated DNS registration.

DeleteDnsRROnLeaseExpiry: When a lease expires, the DHCP server deletes the corresponding DNS records. Essential for keeping DNS clean.

NameProtection: Prevents another machine from overwriting an existing DNS record for the same hostname with a different IP. Uses DHCID records to claim ownership.

Configure Server-Level DDNS Settings

Server-level settings apply as defaults to all scopes that do not have explicit per-scope settings:

# Set server-level DDNS defaults
Set-DhcpServerv4DnsSetting `
    -DynamicUpdates Always `
    -DeleteDnsRROnLeaseExpiry $true `
    -UpdateDnsRRForOlderClients $true `
    -NameProtection $false  # Enable on scope level for specific scopes

# Confirm server-level settings
Get-DhcpServerv4DnsSetting

Configure DnsUpdateProxy Group for Secure Updates

When the DHCP server registers DNS records on behalf of clients using “Always” mode against a secure-only DNS zone, it uses its own computer account. This can cause issues: if DNS records are owned by the DHCP server’s computer account, clients cannot update them directly. The solution is to add the DHCP server’s computer account to the DnsUpdateProxy security group, which causes registered records to have no owner, allowing any authenticated client to update them.

# Add the DHCP server's computer account to DnsUpdateProxy group
# (Run on a domain controller or machine with AD module)
Add-ADGroupMember -Identity "DnsUpdateProxy" -Members "DHCP1$"

# Verify membership
Get-ADGroupMember -Identity "DnsUpdateProxy" | Select-Object Name, objectClass

# WARNING: Adding a domain controller to DnsUpdateProxy is a security risk.
# Never run DHCP on a domain controller in environments requiring security isolation.

Alternatively, create a dedicated AD credential account for DHCP server DNS registrations:

# Create a dedicated service account for DHCP DNS registrations
New-ADUser -Name "svc-dhcp-ddns" `
    -SamAccountName "svc-dhcp-ddns" `
    -UserPrincipalName "[email protected]" `
    -AccountPassword (ConvertTo-SecureString "S3cur3P@ss!" -AsPlainText -Force) `
    -Enabled $true `
    -PasswordNeverExpires $true

# Grant this account rights to update DNS records
# (Add to DnsUpdateProxy or configure specific DNS ACLs)
Add-ADGroupMember -Identity "DnsUpdateProxy" -Members "svc-dhcp-ddns"

Configure DHCP Server to Use a Specific Credential for DNS Updates

You can configure the DHCP server to use a specific AD credential when registering DNS records, rather than its own computer account. This provides cleaner audit trails and avoids DnsUpdateProxy group membership:

# Set the credential used for DNS dynamic updates
# This command sets the credential at the server level
$cred = Get-Credential -UserName "corpsvc-dhcp-ddns" -Message "DHCP DNS Update Credential"

Set-DhcpServerDnsCredential -Credential $cred

# Verify
Get-DhcpServerDnsCredential

Test DDNS Registration

After configuration, verify that DDNS registration is working by examining DNS records after a client obtains a lease:

# On a test client, release and renew IP to trigger DDNS registration
# ipconfig /release
# ipconfig /renew

# On the DNS server, check if the record was created
Resolve-DnsName -Name "testclient.corp.example.com" -Server 192.168.1.10

# Check PTR record was registered
Resolve-DnsName -Name "192.168.100.50" -Type PTR -Server 192.168.1.10

# Check DHCID record (Name Protection ownership claim)
Resolve-DnsName -Name "testclient.corp.example.com" -Type DHCID -Server 192.168.1.10

Troubleshooting DDNS Registration Failures

If records are not being registered, check the DHCP Server’s System event log:

# Search for DDNS-related DHCP events
Get-WinEvent -LogName System | 
    Where-Object { $_.ProviderName -match "DhcpServer" -and $_.Message -match "DNS" } |
    Select-Object TimeCreated, Id, Message | Format-List

# Common Event IDs for DDNS failures:
# 20010 - DNS update failed (permission denied — check DnsUpdateProxy or credentials)
# 20011 - DNS update failed (zone not found — check zone name in DHCP DNS settings)
# 20014 - DNS update failed (connection refused — check DNS service and firewall)

# Verify DHCP can reach the DNS server
Test-NetConnection -ComputerName "192.168.1.10" -Port 53

# Check DNS zone ACLs — DHCP server account must have Write access
$zonePath = "AD:DC=corp,DC=example,DC=com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=corp,DC=example,DC=com"
Get-Acl "$zonePathcorp.example.com" | Format-List

Summary

Integrating DHCP with DNS Dynamic Update on Windows Server 2019 eliminates the burden of manual DNS record management. Configuring the DHCP server to register both A and PTR records on behalf of all clients — especially non-Windows devices — keeps DNS accurate automatically. Name Protection prevents hostname conflicts, and DeleteDnsRROnLeaseExpiry keeps the DNS database clean as leases expire. Using a dedicated credential for DNS updates rather than the DnsUpdateProxy group provides better security and audit traceability in production environments.