Duplicate DNS A Record Issues with DHCP

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!
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Chris DentPowerShell DeveloperCommented:
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).

mcburn13Author Commented:
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...
Chris DentPowerShell DeveloperCommented:
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.

mcburn13Author Commented:
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.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
mcburn13Author Commented:
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.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.