AD Dynamic DNS Updates not triggering on clients

Question

The problem

Recently the computers at our organization moved to a new AD domain, due to a merger. We are having problems getting the clients to dynamically register their DNS records in our AD-integrated DNS.

When a registration is triggered manually on the client (ipconfig /registerdns), everything works fine. You can see the registration process happening in wireshark as described here: https://technet.microsoft.com/en-us/library/cc771255.aspx

Only about 50% of the clients seem to be doing this by themselves however. On the other half, this process does not seem to trigger. Even though the events mentioned in the above article (e.g. on startup) should cause the client to register their A-record with the DNS server.

I have tcpdump constantly capturing traffic from a group of desktops which are exhibiting this problem. In these dumps, I can't find any registration attempts for the affected computers.

Some things to note about our environment

• The clients are getting their DHCP addresses from two DHCP servers in the old domain.
• The DNS servers the clients are told to use (option 006), are also the old domain controllers. But DNS requests for the new domain, are forwarded to the new DC's using conditional forwarding.
• For the new domain, updates are allowed. (Secure Only)
• The connection suffix provided by the DHCP (option 015) is still the old domain. But we have a list of suffixes deployed through a GPO, with the new domain suffix first in the list.
• The new AD domain has three domain controllers, two of which are also DNS servers.

Something we tried

For one of the DHCP scopes we set the connection suffix to the new domain and the DNS servers to the new domain controllers. This does not seem to make a difference.

This seems to be an interesting post about the subject: http://blogs.msmvps.com/acefekay/2012/11/19/ad-dynamic-dns-updates-registration-rules-of-engagement/ But most of the things mentioned there are in order. Except for the fact that IPv6 is disabled on the new domain controllers.

More info in response to Craig620's answer

• The DNS servers are running Windows server 2012 R2, the clients are all Windows 7, the DHCP servers are running server 2008 R2.
• All clients are joined to the same domain (new domain since merger), the problems occur only in this domain.
• There are no clients with static IP-addresses.
• We are not in the process of moving clients from the old to the new domain. We did this with some clients, but the computers which are having problems have not moved. They have been deployed using SCCM in the new domain.
• I can't find significant differences between the 50% that are having the problems and other systems. For example: Some computers in the same classroom are having problems, others are not. They are generally running the same software, updates, etc. And are connected to the same part of the network. Same hardware also. The difference that I can think of is that they are trying to contact another domain controller, but I can't see any attempts to do this.
• The problem has been going on for weeks so computers should have had plenty of time to register themselves.
• The clients don't seem to query for the zone SOA. The zone names for the old and new domain are not similar. (e.g. green.local for the old domain and int.blue.com for the new)
• I have a GPO in place for the DNS suffix search list. This is a list containing the new AD-domain in first place, followed by the legacy domains of the different merger organizations. This is the only DNS related GPO. But I will check this more thoroughly.

Solution

I solved this by using the following GPO setting:

Computer Configuration -> Policies -> Administrative Templates -> Network -> DNS Client -> Dynamic update -> Enabled

Which is strange, since the behaviour when not configured is enabled. I double checked and we don't have any other Group Policies active concerning DNS, except for the suffix search list.

Comments

[Jeremy Gibbons]

Windows PCs can also delegate updating their DNS entry to the DHCP server by providing their hostname as DHCP option 81. This of course in turn requires the DHCP server to have the appropriate permissions on the DNS server. Any chance you're having an issue where the DHCP server in the old domain can't update records on DNS in the new domain ?

[Omnomnomnom]

@JeremyGibbons Both clients that are failing and clients that are not, do not seem to include option 81 in their DHCP messages. It is also not set on the server.

[Omnomnomnom]

I put the requested information in my answer. I will check the GPO's more thoroughly on monday.

[Omnomnomnom]

System -> Computer Name -> Change Settings -> Change -> More -> Primary DNS suffix of this computer -> contains the suffix of the new domain (Correct)

[Joris]

yes, it should be blank if you want to use the computer's primary DNS suffix.

[Joris]

Is the "Use this connection's DNS suffix in DNS registration" checkbox unchecked ? (it should)

[Joris]

and the "Register this connection's addresses in DNS" checkbox should be checked

[Omnomnomnom]

In reaction to Edit 1/16: We have some addresses reserved in each scope, for devices that need a static address. I deleted the lease and gave a non-working client a static ip. It registered itself immediately. I deleted the A-record and rebooted the client. It registered fine again. So static addresses seem to work.

[Omnomnomnom]

"Use this connection's DNS suffix in DNS registration" is unchecked. "Register this connection's addresses in DNS" is checked. So all seems well there.

[jojojoj]

That seems to indicate the problem lies within the DHCP setup, not GPO and not the DNS server. If you run "ipconfig /all" on a good and a bad client, are there differences between the "Primary DNS Suffix" and the "Connection-specific DNS Suffix"? Those values should match the name of the domain the machine belongs to.

[Omnomnomnom]

The Primary DNS Suffix matches the domain of the client. (New domain) But the connection specific suffix is the old domain. This is logical, since the old DHCP server, has the old domain set in option 15. Is this bad? I was under the impression that DNS registration uses the Primary Suffix, not the connection specific suffix.

[jojojoj]

The connection specific suffix overrides the primary suffix for dynamic DNS registration.

[Omnomnomnom]

On one DHCP scope, I set the connection specific suffix to the new domain. So now, both suffixes are the same. I also told the client to use the new domain controllers as DNS servers. This does not fix the problem.