1

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.
Greg Askew
  • 34,339
  • 3
  • 52
  • 81
Omnomnomnom
  • 649
  • 2
  • 10
  • 22
  • 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 ? – Jeremy Gibbons Jan 14 '16 at 19:50
  • @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 Jan 18 '16 at 14:19

3 Answers3

0

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:

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

  2. 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:

  • "Microsoft-Windows-DNS Client Events/Operational"
  • "Microsoft-Windows-DHCP Client Events/Operational"

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:

Log Name:      Microsoft-Windows-Dhcp-Client/Operational
Source:        Microsoft-Windows-Dhcp-Client
Date:          1/27/2016 8:42:01 AM
Event ID:      50042
Task Category: DNS State Event
Level:         Information
Keywords:      
User:          LOCAL SERVICE
Computer:      dns1.acme.local.com
Description:
Dns registration has happened for the adapter 12. Status Code is 0x0. DNS Flag settings is 10.

dnsCliEvt

Clayton
  • 4,483
  • 16
  • 24
  • I put the requested information in my answer. I will check the GPO's more thoroughly on monday. – Omnomnomnom Jan 15 '16 at 16:17
  • 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 Jan 18 '16 at 15:15
  • 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. – Clayton Jan 19 '16 at 14:16
  • 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. – Omnomnomnom Jan 22 '16 at 09:35
  • The connection specific suffix overrides the primary suffix for dynamic DNS registration. – Clayton Jan 22 '16 at 17:31
  • 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. – Omnomnomnom Jan 27 '16 at 14:07
0

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?

  • System -> Computer Name -> Change Settings -> Change... -> More... -> Primary DNS suffix of this computer
  • Start -> RUn -> ncpla.cpl -> Properties of the default net connection -> TCP/IPv4 -> Advanced -> DNS Tab -> DNS suffix for this connection :
Joris
  • 1
  • 2
  • System -> Computer Name -> Change Settings -> Change -> More -> Primary DNS suffix of this computer -> contains the suffix of the new domain (Correct) – Omnomnomnom Jan 18 '16 at 14:40
  • Start -> Run -> ncpa.cpl -> Properties of the default net connection -> TCP/IPv4 -> Advanced -> DNS Tab -> DNS suffix for this connection -> This field is blank (Is this ok?) – Omnomnomnom Jan 18 '16 at 14:50
  • yes, it should be blank if you want to use the computer's primary DNS suffix. – Joris Jan 18 '16 at 15:07
  • Is the "Use this connection's DNS suffix in DNS registration" checkbox unchecked ? (it should) – Joris Jan 18 '16 at 15:08
  • and the "Register this connection's addresses in DNS" checkbox should be checked – Joris Jan 18 '16 at 15:08
  • "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. – Omnomnomnom Jan 18 '16 at 15:47
0

I solved this by using the following GPO setting:

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

enter image description here 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.

Omnomnomnom
  • 649
  • 2
  • 10
  • 22