Duplicate DNS A Record Issues with DHCP

Posted on 2014-11-06
1 Endorsement
Last Modified: 2014-11-25
I was getting complaints of duplicate A records for a while so starting digging in.  The DHCP audit log will show DNS Update Failed with a 9005 error.  I had previously cleaned up the structure by rebuilding the _MSDCS zone at the top level and confirming all the SRV records exist (supported by DNS Lint and DCdiag verbose DNS tests). Also set the zones to replicate across the forest and use secure updates and consolidated a bunch of reverse zones into a two-octet one (new one would be as example). So reading up on it I decided to add all my DHCP servers into the DNSUpdateProxy Group, create an account to bind credentials on my DHCP servers (some happen to be DCs), set the DHCP scopes to "always dynamically update...", "Discard A and PTR records when lease deleted", and "Dynamically update DNS A and PTR for DHCP clients that do not request...". Scavenging is set to 7 days refresh/no-refresh on server and all zones.

The problem is really prevalent on our VPN scope- you know the deal folks are connecting and disconnecting all the time. We had the scope set to a 2 hour lease.  So yesterday I changed the lease to 25 hours, and set Scavenging to 1 day. Thought this would resolve it. But we are still getting duplicate A records some even with the same time stamp!  Happening in other scopes/networks as well that have longer leases.  I've noticed different security on records that were even time-stamped in the last day since the changes. Some have the client name, some have the DHCP server and some have the Dynamic Update account I created.  Not really sure what to make of it; wondering if I need to set the security on the actual zone to allow the DNSUpdateProxy group full control or maybe even schedule a script to run against my VPN scope to get rid of the duplicate record that has an older time-stamp or compare against the DHCP lease and delete the other.   Any help would be greatly appreciated!
Question by:mcburn13
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
  • 2
LVL 71

Expert Comment

by:Chris Dent
ID: 40427910
This is quite a common problem where there's more than one possible update source, especially if you use scope with very short lease times.

The DNSUpdateProxy group is  a bit nasty really, you should avoid using it if you can. Use credentials if you must drive updates from DHCP.

> Some have the client name, some have the DHCP server and some have the Dynamic Update account I created.

If DHCP doesn't universally update DNS; for example, if it updates for clients connecting to a LAN, but not for Wireless problems will abound. If that is the case I recommend you stop DHCP updating DNS entirely and allow the clients to do it themselves. This is done by simply removing the DNS update options from DHCP.

If DHCP is updating universally you should drive for consistency, get the servers out of that proxy update group. Set the same credentials for all DHCP servers (and all scopes).

You mention changing Scavenging to 1 day. What exactly did you change? The Aging settings dictate how quickly a record can be scavenged, but those should never be set to less than a day or you'll find records for your servers and domain controllers vanish.

It's rarely so easy, but if possible set a consistent lease time across all your scopes and align the Aging times with that lease time. For example, if I set an 8 day lease I would set 3 days No-Refresh and 5 days Refresh. I'd set Automatic scavenging to run once a day from a single DNS server (or two at the most).


Author Comment

ID: 40435936
Well not having these settings in place is what led me to this quest... At this point it appears to be taking hold on all records except that which associates to my VPN scope.  Yesterday I decided to delete the credentials binding on this DHCP server is this one is NOT a domain controller. So only using the DNSProxyUpdate settings from the server's group membership. Appears to be "better" but still some records are getting left behind.  The ones that are have their own client name in the ACLs and the ones that are being recycled properly have the DHCP server in the ACL of the record....

I'm wondering if there is some refresh happening on the client that is taking ownership of the record and that's why its happening...
LVL 71

Assisted Solution

by:Chris Dent
Chris Dent earned 500 total points
ID: 40435982
First things first.

The VPN scope, I assume that's just a pool of addresses your firewall hands out when someone connects?

If so, the fact you've started using DNSProxyUpdate will let clients overwrite records added by your DHCP server (as records are written without security). However, once the client does that the DHCP server cannot take back the record when the client connects to the LAN again.

If you cannot use a single security principal for all DNS updates you will be far better served by turning off DNS updates from DHCP and letting your clients take care of it themselves. It should be noted that DHCP updates DNS by default, so if you'd done nothing at all you'd still be faced with the problem.

So, if I had your network I would:

1. Attempt to set a common DHCP lease time across all scopes (where reasonable). Ideally longer than 1 day.
2. Set automatic scavenging to run once a day on a single DC.
3. Set No-Refresh plus Refresh to match the DHCP Lease time (e.g. a DHCP Lease time of 8 days would have me set 3 days No-Refresh and 5 days Refresh).
4. Disable dynamic updates from DHCP.
5. Review records after 8 days (the maximum life-span for any DNS record with these settings).

I've used this style of configuration successfully in many different organisations with great success.


Accepted Solution

mcburn13 earned 0 total points
ID: 40454988
Well we were able to make this work consistently by putting our "DHCP Update" service account in the BUILTIN\Administrators group.  Previously the only remaining problem-scope was our Cisco AnyConnect one... I guess the way the AnyConnect virtual adapter handles DHCP doesn't really jive so nicely with Microsoft DHCP/DNS. But the elevated perms for that account appears to give it the ACLs on all the A records and now they are being removed 100% of the time. Thanks for your help with this.

Author Closing Comment

ID: 40464126
My solution ended up being the dominant one but the expert's suggestion may come in handy for other users here searching for a similar solution.

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

I've written instructions for one router type, but this principle may be useful for others of the same brand and even other brands of router. Problem: I had an issue especially with mobile devices that refused to use DNS information supplied via…
BIND is the most widely used Name Server. A Name Server is the one that translates a site name to it's IP address. There is a new bug in BIND (, affecting all versions of BIND 9 from BIND 9.1.0 (inclusive) thro…
In this Micro Tutorial viewers will learn how to use Boot Corrector from Paragon Rescue Kit Free to identify and fix the boot problems of Windows 7/8/2012R2 etc. As an example is used Windows 2012R2 which lost its active partition flag (often happen…
This tutorial will walk an individual through the process of configuring their Windows Server 2012 domain controller to synchronize its time with a trusted, external resource. Use Google, Bing, or other preferred search engine to locate trusted NTP …

730 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question