DNS duplicate record issue

Copper Contributor

Currently we are seeing duplicate DNS records for multiple DNS zones. This is specific to our VPN IP scopes, as other scopes do not appear to have this problem. In an effort to correct this issue, as it appears to be occurring from DHCP not being able to update/delete DNS records due to the client being the owner of the record, the below steps have been implemented. This is a smaller environment with approx 1200 endpoints, so the slightly more aggressive DNS intervals is not a concern.

 

DHCP lease time adjusted to 8 days from previously 1 day

DNS scavenging adjusted to "No Refresh + Refresh" = DHCP lease - 1 day

3 days (no-refresh) + 4 days (refresh) and 1 day scavenging

https://docs.microsoft.com/en-us/archive/blogs/askpfe/how-dns-scavenging-and-the-dhcp-lease-duration...

 

I also implemented Dynamic DNS Updates per the below MVP blog, but oddly the owner of all DNS records changed from SYSTEM as the owner to being self owned, rather than being owned by the DHCP server.

https://blogs.msmvps.com/acefekay/2009/08/20/dhcp-dynamic-dns-updates-scavenging-static-entries-amp-...

 

The DNS duplicate issue is still occurring, which I'm assuming is due to the DHCP server not owning the DNS records and deleting them when their lease expires or updating when the IP is reassigned.

 

Searched around quite a bit on this one and I'm stumped at this point. Anyone have an thoughts/suggestions to get DNS records to be properly owned by the DHCP server?

6 Replies

@Dave Patrick 

Credentials for secure DNS updates is configured
DHCP server is part of the DnsUpdateProxy AD group
DHCP server is 2008 R2 (to be upgraded soon) and DNS servers are 2016, so dynamic updates are supported
The DNS forward lookup zone where the duplicate DNS issue is occurring does not have WINS enabled

@Greg_Vickers4 

 

Hey, Greg.

 

It doesn't necessarily sound like a permissions issue to me, to be honest. Happy to be wrong but I'll explain why I say that.

 

Behind the DNS Server service, the records are stored in an Active Directory partition - which I'm sure you already know (typically, they'll be in the DC=DomainDnsZones,... partition.)

 

What you see as two (or more) records in the DNS management console (or PowerShell) is actually just a single object within that AD partition, so from a permissions perspective, if you're seeing any kind of change at all, be that adding a new record (what you're seeing), changing an existing one, or deleting a record, then permissions aren't the issue.

 

Here's a quick visual example of what I'm talking about as seen via ldp.exe when looking at my adfs.robertsonpayne.com DNS record, where you can see (in blue) that there's two entries held within the single AD object.

 

LainRobertson_0-1651800261386.png

 

What that leads me to believe in your situation is that something is explicitly requesting the addition of the VPN-based IP address rather than the updating of any existing value, and that is something I've seen VPN products do before.

 

Looking at a different scenario to further explain permissions, when you have one client that's been issued the the IP address that another client had previously but didn't de-register, that new client (this is assuming it's a Windows domain-joined client pointing at a writeable domain controller, in which case the default is to perform a dynamic update) cannot update the existing record, nor does it try to create a new one.

 

While I'm probably making myself look silly by stating the obvious, this is because the new client does not have permissions to the backing AD object - which DNS honours and DHCP behaviour varies depending on configuration.

 

Are the VPN clients pointing to writeable domain controllers for DNS? If so, then I am at a bit of a loss for the time being since they should be updating their own records directly - assuming the VPN adapter isn't precluded from doing so - but if not, then what you're describing does make sense.

 

You should be able to check your VPN client adapter's DNS registration configuration by running:

 

 

Get-DnsClient | ft -AutoSize InterfaceAlias, RegisterThisConnectionsAddress, UseSuffixWhenRegistering, ConnectionSpecificSuffix

 

 

Again, this is only relevant if the VPN client is pointing at writeable domain controllers. Otherwise, I feel like this is going to be an issue with the VPN server, possibly in conjunction with how DNS registration has been configured on the DHCP server.

 

Cheers,

Lain

 

Edited: Spelling corrections.

@LainRobertson 

I wont pretend to be familiar with the AD partition on the backend or the ldp.exe tool :)

 

However, when I do look at records in DNS Manager and each of these records are owned by themselves, I would think they would have to be separate records. See the below image which shows two DNS records for different clients, both have the same IP registered and their permissions show them to be the Owner of their DNS records.

Greg_Vickers4_0-1651847847495.png

 

This is part of my confusion as the information in the below article clearly states DHCP must own the DNS records, which I've seen screenshots from other posts showing where the DNS record owner is listed as DHCPSERVER$

 

Overview to make this work:

  • DHCP must own the record, not the client. This is done by configuring DHCP to register all DHCP clients, whether the client supports Dynamic Updates or not.
    • As long as DHCP owns the record, can keep the records in the FLZ and RLZ up to date when the client renews its lease, same IP or different IP.
    • Otherwise you’ll see duplicate A and PTR records in DNS, whether scavenging is enabled or not.

https://blogs.msmvps.com/acefekay/2009/08/20/dhcp-dynamic-dns-updates-scavenging-static-entries-amp-...

 

Also - all of these clients are domain-joined and we do not have any RODC in our environment.

@Greg_Vickers4 

 

Ah, righteo - that makes sense.

 

I tend to interpret "duplicate" as a duplication of the name portion of the record, not the IP address - which is an issue I've seen before when clients transition from one network to another, such as from something well-connected like a wired network to VPN.

 

This can result in a duplication where two (or more) records have the same name but a different IP address. So, I'd assumed the opposite case to what your pictures show above.

 

Since this isn't your scenario, let me throw out my previous post entirely (though the explainer about permissions is still relevant as I'll come back to.)

 

If the duplication of the record value (aka the IP address) is your biggest concern then scavenging is really your main point of concern. So long as the records themselves are updating then permissions (specifically, who the owner is) aren't relevant.

 

Speaking to DNS scavenging quickly - and I'm sure you've already read this but it does come up often as something people overlook: it needs to be enabled both on the DNS Server properties as well as any relevant zones - setting one location while forgetting the other results in nothing happening.

 

And be careful you don't set the scavenging interval too low as you can run into issues such as server static IP's going missing (as they only re-register every 24 hours.) Just remember that the scavenging interval (i.e. [no refresh] and [refresh]) is for the entire DNS zone, not a subnet, meaning it should accommodate your longest defined DHCP lease window.

 

Supplemental information

Looking at your second topic of permissions (ownership, et al), I'll use a contrived example as a case in point on why that doesn't appear to be your issue.

 

Context

My desktop has a wired and wireless connection. I generally run with wireless switched off meaning the A record is owned by my desktop.

 

However, my wireless VLAN is configured as shown below meaning it's the DHCP server (catering to BYOD) performing the update on that very same DNS record (keeping in mind what I said about there being only one record in AD, with multiple address entries as per the previous LDP screenshot.)

 

Here's the results as shown by DNS Manager:

 

LainRobertson_0-1652001003607.png

 

And here's the ownership, where you can see ownership remains with the client (RP03$), not the credentials used by the DNS Server service to perform the update

 

Dynamic update-capable client (domain-joined)

LainRobertson_1-1652002123572.png

 

This works under the following configuration, where clients capable of dynamic updates are configured to do so, while leveraging name protection for improved security.

 

This means my Windows domain-joined clients maintain their A records as they float between wired and wireless, and the dynamic DNS update credentials don't come into it.

 

Conversely, if I look at my Samsung phone, which can't handle dynamic updates, you can see the owner is indeed the regular user account supplied in DHCP Manager for performing dynamic registrations.

 

Dynamic update-incapable client (Samsung phone registered by DHCP credentials)

LainRobertson_4-1652002769111.png

 

 

DHCP scope configuration

LainRobertson_2-1652002554848.png

 

DHCP IPv4 properties (server configuration)

LainRobertson_3-1652002636210.png

 

Other considerations

This is my configuration for domain-joined Windows and BYOD but it certainly isn't the only way to configure things.

 

Something you mentioned that I'm unsure about were the comments about "SELF" being the owner. I can't quite reconcile how, if you've created a vanilla, unprivileged user account and used that for the DNS dynamic update credentials, you're seeing SELF as the owner - unless it's for a record that existed prior to the setting of the credentials. Maybe you could explain in what order you configured the various settings and when the client registered its address.

 

Assuming everything is set up correctly, new DNS registrations should appear with the dynamic update credential as the owner (subject to the scope registration options chosen) - as per the Samsung phone example above, not the DHCP host's identity.

 

Going over the process really quickly, you would have:

 

  1. Added the DHCP computer account (if it's a domain controller, you should really take note of the various warnings about the security risks in the Microsoft doco) to the DnsUpdateProxy group;
  2. Created a vanilla, unprivileged AD user account to act as the dynamic update account - making sure the account never expires (as per the Microsoft doco);
  3. Within DHCP Manager -> IPv4 -> Properties -> Advanced -> Credentials, use the above account;
  4. On the relevant VPN scope -> Properties -> DNS tab -> whatever relevant options you think you need depending on the nature of your clients.

 

Here's some references:

 

Cheers,

Lain