Score:1

DHCP Server Not Registering PTR Records - Multiple DHCP Servers

cw flag

I have a DHCP server configured to always dynamically update DNS records. The DNS server is configured to allow both secure and insecure updates (I know it's not secure, but this is an internal-only network, no internet connection). Both are Windows Server 2016.

Single domain, single forest.

There is a branch office, which has a different subnet (still the same domain), with a VPN between main office and branch office. Another DC in the branch office, which runs DHCP (for the branch office only) and DNS (for the entire domain). Replication between the DCs on main and branch offices works fine.

There is nothing special set up regarding subnetting. Forward and reverse lookup zones exist for both subnets in DNS.

Clients on the main office get IP addresses from the DC in the main office, and DNS updates their A records and PTR records properly.

However - in the branch office, while clients do get IP addresses, and proper A records are created, no PTR records are created ever for DHCP clients. (Only for static entries.)

Clients do send the option 81 in the DHCP request packet, with FQDN, all flags set to zero.

Note that I allow both secure and insecure updates, so it should not caused by missing credentials. I have not configured credentials for DNS updates but I don't see how this would help since insecure updates are allowed.

On clients, the Advanced TCP option "Register this connection's addresses with DNS" is checked (Windows default).

I have seen suggestions to configure each client with the option "Use this connection's DNS suffix in DNS registration". Haven't tried this yet but fail to see why this should help anything. (It does send the FQDN, and it should be the server doing the DNS registration.) And would like to avoid having to configure all the clients manually.

Anyone know if this is related to the fact that there is a 2nd subnet in the same domain?

And how would I go about configuring it correctly so DNS / DHCP understand what to do?

Pimp Juice IT avatar
ch flag
If these are AD joined, setup a GPO to set the DNS suffices for the FQDN of the domain(s). You can use GPO to do this, run from DC as domain admin `invoke-command -computername <clientmachine> -ScriptBlock { gpupdate /force /wait:0 }` and then `restart-computer -computername <clientname> -force -asjob`. Now test on the remote machine and see what's up. Here's the post about setting the DNS suffix [Start reading #6 for GPO pointer](https://docs.microsoft.com/en-us/exchange/configure-the-dns-suffix-search-list-for-a-disjoint-namespace-exchange-2013-help). I think this will resolve
Pimp Juice IT avatar
ch flag
Make sure your AD "sites and subnets" are all set correctly and assigned, but the different subnets should not matter if they can connect and communicate on all the needed ports for the traffic across the tunnel.
cn flag
What is the policy setting value for: Computer\Administrative Templates\Network\DNS Client!Register PTR Records (`HKLM\Software\Policies\Microsoft\Windows NT\DNSClient!RegisterReverseLookup`)
cw flag
@GregAskew - policy not configured, which should mean clients will register if A record succeeds. But A record succeeds, PTR not.
cn flag
And if you configure the policy on a client to register, does that have an effect?
cw flag
Set the policy to "Register" - no effect, set it to "Register only if A record registration succeeds" - no effect. It's awkward.
cw flag
An error is logged "PTR record registration for IPv4 address [[]] and FQDN xxx failed with error 9017 (DNS bad key.)." - only visible in the Applications and Services Log > DHCP Server though.
Score:1
cw flag

Solved it by updating the credentials in DHCP server for the branch office - it was not actually related to multiple subnets.

(Right-click on IPv4 under the domain name in DCHP Server, select Advanced and Credentials, enter new user/password info - this should be an unprivileged user account for this purpose only, with password never expiring and user not being able to change password. I say unprivileged - it must be member of the DnsAdmin group though.)

On this DHCP server in the branch office (and only on this one), the credentials were set to an actual user account which had his password changed months ago.

Since insecure updates were allowed, the failed auth did not matter normally.

Why it did matter, though, I believe was that my domain name is multi-level (internal.example.com), and AD created a forward lookup zone for both "internal.example.com" and "example.com". And on the "example.com" zone Dynamic Updates was set to "Secure Only", while the "inernal.example.com" had "Insecure and secure".

So somehow the fact that a parent domain could not be updated seemed to make the PTR update fail.

(Note that adding the DHCP servers to the DnsUpdateProxy group did NOT resolve the problem in this case.)

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.