May 05 2022 12:15 PM
May 05 2022 12:15 PM
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
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.
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?
May 05 2022 12:44 PM
May 05 2022 02:13 PM
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
May 05 2022 02:52 PM
May 05 2022 06:35 PM - edited May 05 2022 10:01 PM
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.
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.
Edited: Spelling corrections.
May 06 2022 08:00 AM
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.
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$
Also - all of these clients are domain-joined and we do not have any RODC in our environment.
May 08 2022 03:19 AM - edited May 08 2022 04:36 PM
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.
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.
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:
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)
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)
DHCP scope configuration
DHCP IPv4 properties (server configuration)
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:
Here's some references: