Duplicate DNS A Record Issues with DHCP

Posted on 2014-11-06
Medium Priority
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 99.172.in-addr.arpa 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
  • 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 1500 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

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

Question has a verified solution.

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

The following article is comprised of the pearls we have garnered deploying virtualization solutions since Virtual Server 2005 and subsequent 2008 RTM+ Hyper-V in standalone and clustered environments.
Sometimes drives fill up and we don't know why.  If you don't understand the best way to use the tools available, you may end up being stumped as to why your drive says it's not full when you have no space left!  Here's how you can find out...
In this Micro Tutorial viewers will learn how they can get their files copied out from their unbootable system without need to use recovery services. As an example non-bootable Windows 2012R2 installation is used which has boot problems.
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles from a Windows Server 2008 domain controller to a Windows Server 2012 domain controlleā€¦
Suggested Courses

621 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