1

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?

nepdev
  • 381
  • 1
  • 6
  • 19
  • 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 -ScriptBlock { gpupdate /force /wait:0 }` and then `restart-computer -computername -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 Apr 24 '22 at 20:07
  • 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. – Pimp Juice IT Apr 24 '22 at 20:09
  • What is the policy setting value for: Computer\Administrative Templates\Network\DNS Client!Register PTR Records (`HKLM\Software\Policies\Microsoft\Windows NT\DNSClient!RegisterReverseLookup`) – Greg Askew Apr 24 '22 at 20:43
  • @GregAskew - policy not configured, which should mean clients will register if A record succeeds. But A record succeeds, PTR not. – nepdev Apr 24 '22 at 21:04
  • And if you configure the policy on a client to register, does that have an effect? – Greg Askew Apr 24 '22 at 22:34
  • Set the policy to "Register" - no effect, set it to "Register only if A record registration succeeds" - no effect. It's awkward. – nepdev Apr 25 '22 at 09:16
  • 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. – nepdev Apr 25 '22 at 12:47

1 Answers1

1

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.)

nepdev
  • 381
  • 1
  • 6
  • 19