The Case:

We where having an issue with some of our clients not getting updated properly in our DNS.
Our clients somehow had the wrong IP registered in our DNS server.
We knew that our clients was accessing a 802.1x network and spent some time getting authenticated.
Since this is a newly acquired network it had it’s own DHCP server and that DHCP server was enabled to
DDNS update for our clients, we where only experiencing the issue when the clients where successfully
authenticated on 802.1x.

The investigation:

So where to start? Is it the new DHCP that is overwriting the entries after the client successfully authenticated?
Is it the client that is not able to update it’s own records due to DNS No-Refresh intervall on the DNS server?
Is our primary DNS Server that is not able to update the records due to DNS No-Refresh?
Anyways, I started comparing our DHCP Servers DNS Settings.
Both of them where configured identically for the DNS Settings and was using the same DNS Update Credentials.

PS C:\> Get-DhcpServerv4DnsSetting -ComputerName
  DynamicUpdates             : Always
  DeleteDnsRROnLeaseExpiry   : True
  UpdateDnsRRForOlderClients : True
  DnsSuffix                  :
  DisableDnsPtrRRUpdate      : False
  NameProtection             : False

After checking all the scopes on the server, we could see that all the scopes had the same settings as our primary settings on the DHCP Server.
Here is a PowerShell Script to list all the scopes in a table with their DNS Settings (not perfect but gives you an overview,):

$srv = "."
$scopelist = Get-DHCPServerv4Scope -computername $srv
foreach ($item in $scopelist) {
Write-host $item.Name , $item.ScopeId.IPAddressToString
Get-DHCPServerv4DNSsetting -ComputerName $srv -ScopeId $item.Scoped.IPAddressToString | Format-Table

Well everything seamed to be as it should be.. but why didn’t our primary DNS Server update the latest DHCP Lease in DNS with the proper IP?
I decided to check out the DCHPLogs.. And check our client’s name. After opening the logfile I could see straigt away a bunch of error messages
related to DNS Updates.
The log file was filled up with ID 30 and ID 31 entries. They look something like this:
31,07/16/14,11:16:00,DNS Update Failed,,AP30f7.0d92.5ea1,,,0,6,,,
30,07/16/14,11:16:00,DNS Update Request,,AP30f7.0d92.5ea1,,,0,6,,,

After counting all the 31 Events in Notepad++ we had to many failed updates (aprox 60000 a day).
All kinds of clients failed to get updated. But also all kinds of clients succeed also. What could be doing this?

Discussing with Microsoft, we decided to increase the Que limit for DDNS updates on the DHCP server. [1]
Since we have Windows 2008 R2 DNS and DHCP Servers we increased the DynamicDNSQueueLength to 65536 as described in the article[2].

This didn’t actually help, as our que is still too big. So I stared to investigate what records are failing
and I was a bit surprised, but apparently we have a lot of units that have “invalid FQDN hostnames” reporting to the DHCP Server. 
As our DHCP Server is set to update “DynamicUpdates : Always and UpdateDnsRRForOlderClients : True” it will update any type of client
that is reporting it’s hostname to our DHCP server. The invalid FQDN’s was like this: AP30f7.0d92.5ea1.
It is two letters (AP) followed by an MAC address for our Cisco accesspoints. One of the issues with this is the use of “.” in the hostname.
If we where to allow the update to happen, we have to create the 0d92.5ea1 Zone in our DNS server and then the DHCP server will create
a record for AP30f7 inside that Zone. But we have to create a Zone for every Access Point because the last 9 characters is uniq to every Access Point.

So that is not an option. So how can we fix this or reduce the problem?
There is three ways of doing this:
1. Either we rename all our Access Points to a fitting standard
2. We adjust our settings for our DHCP Server globally
3. We adjust just the Scopes in question.

Our network admin wasn’t too glad about renaming several thousands of access points. So I decided to explore the other options.
If we are adjusting the DHCP DNS Update settings, what settings should we have?
Should we just adjust the scope settings or could we do it globally on the DHCP Server?

To figure our this I had to read up [3][4] on the DHCP protocol and how clients send information to the DHCP Server to do or not do DDNS.
In article “Using DNS with DHCP” [4] there is a nice schema of how it looks when the client is communicating with the DHCP Server:

DHCP and DNS Update interaction
DHCP and DNS Update interaction

This is when the client it self is updating the record via DDNS and not when the DHCP Server is doing it.
The setting in the DHCP Server is then “Dynamic Updates: OnClientRequest” which is default settings DDNS Updates from DHCP.
But ours has this set to “Always” and we also have the option “UpdateDNSRRForOlderClients: TRUE” also.

This means that all clients that are getting a lease from our DHCP Server will be updated in our DNS Server by our DHCP server.

So how does this work, DHCP has four steps that it goes through to give a lease and in an default DHCP setup decide if the client
or the DHCP server should do the DNS Update. Shown in the picture:

DHCP Message Exchange
DHCP Message Exchange

First the client does an DHCPDiscover and send the Hostname (ID 12) in the packet.
It then receives an packet from the DHCP Server with an IP Address, Subnet,DNSServer and other DHCPOptions in the DHCPOffer packet from the DHCP Server.
Then the Client sends a DHCPREQUEST packet, this packet contains RequestIP (ID 50), HostName (ID 12) and it may send FQDN (ID 81).
This last option is optional to send for the clients, but all the Windows XP/2003 and newer clients sends it.
The DHCPACK packet is the returned from the DHCP Server and it contains the DHCP DNS Settings in the FQDN Field (ID 81).
If the DNS Settings are default the client will update it self to the DNS Server.

So why is our Access Point not having a FQDN when we are looking in the DHCP Scope and in our logs?
As I was inspecting the packet dump from one of the Access Points i noted that the Access Points didn’t send
the option FQDN (ID 81) in the DHCPREQUEST packet to the DHCP server. So this client is actually not requesting to
be Updated in our DNS, but our DHCP Server still does it.

So this means we either adjust the Scope or set the settings globally on the DHCP Server.
If we change the settings to DynamicUpdates: OnClientRequest and set the option UpdateDNSRRForOlderClients: False.
We will avoid updates requests from clients that are trying to update to an non existing Zone on our DNS Server.


So we have experienced two things in this scenario.
1. Having a good naming standard for all your devices will help a lot and not get you into unexpected trouble like this.
2. Configuring the DHCP server to update everything to DNS might sound like a good idea, but only if you have done point 1 properly.

We have adjusted our DHCP Server globally to have the DynamicUpdates: OnClientRequest and UpdateDNSRRForFolderClients: False.
This is done at the root level of the IPv4 Settings, but you have to check all the scopes after as if it has been changed from the standard config.
The setting will not propegate to the Scopes. You can check with the earlier Powershell script,
and if the settings are inconsistent, it is easy to rewrite it so it sets the correct settings on the scopes that are not following the global config.
The DHCPServer module in Powershell is available in Windows 2012 and newer OSes. So for the Powershell script to work you have to have this OS.

Hope you feel this was worth your time reading and that you enjoyed it.


[3]Windows Server 2008 TCP/IP Protocols and Services

6 thoughts on “DHCP and Failing Dynamic DNS Update

  1. The diagram for “DHCP and DNS Update interaction” shows that the DHCP server updates the PTR record, I noticed in Windows Srv 2008 that the DHCP DNS options included both Host (A) and pointer (PTR) records. Is the diagram still accurate? I am actually looking for Windows Srv 2012 diagram that show DDNS update from DHCP.


    1. Hi Big Daddy,

      The diagram is a Picture from the article in my Sources.
      According to Microsoft, support case, there has been a lot of changes in 2003 -> 2008 R2, but not much after that.

      I would say that the diagram will be the same for 2012, but I can’t garantee it.
      I found that the diagram is accurat from 2003 -> 2008 R2 at least according to this discussion:


  2. The reason is DHCP does not contact the DNS even though the article refers to dns as one of the records being deleted and recreated. This allows our primary domain suffix to search it and append it. Hope that helps.


    1. Not sure I entirely understand what you mean.

      After I published this post,
      I’ve been investigating my issue more and found some other causes that was related to my main issue;
      “Clients were not getting updated properly in our DNS with the correct host A and PTR records in our domain”

      The primary suffix for all domain join computers is the domain name the computer is joined.
      So if a client is joined in domain mydomain.local and the is submitting DHCP Option 81 to the DHCP Server,
      Microsoft DHCP Server til connect to mydomain.local DNS Servers and update the A host records and PTR records straight away.
      The DHCP Server need read/write rights in the DNS Zone.

      If the option “UpdateDnsRRForOlderClients : True” is on it will update any hostname, even if the client is not responding with DHCP Option 81.
      The DHCP Server will then append the domain name configured in the respective subnet as primary domainname.

      Also, there if lets say the Reverse Lookup Zone for Subnet is not registered in DNS, the DHCP server, if it is an address with in,
      try to go online and update the reverserecord. This will fail because all records will be sendt to a IANA Blackhole / Prison address.
      This has to be removed from your DNS Cache and the respectively Reverse Zones have to be created.

      If the DHCP Server is handling the DNS Updates,
      and the client is changing IP within 2 min, common in 802.1X enviroments where user authentication autorizes the client to a more secure network.
      Then the DHCP Server should update the records A and PTR straight away and overwriting the first created records.

      These are common problems and easy problems to end up doing.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s