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.
Too many unknowns for a comment...
What version OS are the DNS severs? the clients?
Do the failing clients all belong to one domain, or is the problem cross domains?
Does the problem also occur machines with static addresses?
Are you in the process of moving clients from oldDom to newDom?
What else is unique about 50% of the clients that do not have DNS records?
Clients only register the DDNS once per 24 hours. If you're just waiting for it to happen, be patient...
DDNS actions first query the zone SOA (start of authority). Are the zone names dissimilar (green.com, blue.com) or similar (green.com, grass.green.com, frog.green.com)? If similar, do you have a zone delegation setup? The registration will fail if it is not sent to the right DNS server and you have similar namespaces without a zone delegation.
Do you have any DNS related GPO's in place? There is a GPO option to disable Dynamic DNS registration. This is typically used when the DHCP server is configured to register DNS names on behalf of clients it issues addresses for.
Edit 1/16
Why are clients in newDom still being serviced by DHCP servers in oldDom, getting DHCP options with oldDom's suffix, and being told to use oldDom DC's for DNS resolution? That could all work, but it also adds complexity that could lead to problems. Even if you have a reason, try doing a test on a small client base with a new DHCP server in newDom that does not reference oldDom in any way (suffixes, dns resolvers, etc).
Can you answer Jeremy Gibbons question about DHCP Option 81?
A couple things you can try to help narrow down the source of the problem. Do each on a small sample (say 6-10) different machines:
Shrink one of your DHCP scope by 6-10 addresses, delete DNS records for those 6-10 machines, and then assign static to those machines.
Delete DNS records for a different 6-10 machines, move them to an OU where there are no group policies being applied.
If problem does not repro for first group of clients, problem is probably DHCP related.
If problem does not repro for second group of clients, problem is probably GPO related.
Edit 1/27
Try enabling both of these event logs:
Believe it or not, Dynamic DNS registration is actually performed by the DHCP client service. Invoke "ipconfig /registerdns". Review each of these logs for something that looks out of place. This is what a successful registration looks like:
i suspect it could come from a misconfigured DNS primary suffix on the workstations (or a DNS suffix set up on a network connection). Just to clarify, i am not talking about search suffix.
Could you confirm that those two properties are correct on a client?
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.