DNS not working for remote site's workstations after domain transition

[AJ]

Background:

"Site1" and "Site2" have been communicating with each other for several years via Meraki MXes (same models) with no DNS problems. They have their own subnets, which the MXes are aware of and route properly. There was one DNS server in Site1, which Site2 has been using without issues. Both sites have been operating in the same AD domain. All servers are at Site1, so Site2 has DHCP handled by the MX. Basically, everything has been hunky dory with the site-to-site connection (aside from Internet service burps).

Now, I'm transitioning our network from one domain ("D1") to another ("D2"). D1 and D2 are setup with proper trusts, both have DNS servers that aware of each other. The workstations at Site1 have no problem with finding each other between D1 and D2 via DNS and have no problems with security (that I'm aware) between D1 and D2. 

Problem:

When I transition a workstation at Site2 from D1 to D2, it fails to handle DNS resolution. It won't find anything on either D1 or D2, despite it still being assigned the DNS server from D1 (which is not a problem for any workstations at Site1). I can run NSLOOKUP from the command prompt, and it will indicate the correct DNS server, but it fails to resolve any names. Pinging by IP address works fine. The MX at Site2 is able to ping DNS servers in both D1 and D2 by short name. There are no WINS servers in either domain. At Site1, only D1 has DHCP services. All of Site1 is on the same subnet, no matter which domain.

I attempted this transition on two workstations at Site2, both Windows 7, and they both have the same issue. They have no problems with DNS when I move them back to D1. Again, no workstations in Site1 have any observed DNS or security issues.

Any ideas on what's going on?

(edit)

Now that I think about it, there was a strange error message when attempting to join the new domain. Something along the lines of, "Changing the Primary Domain DNS name of this computer to "" failed. The name will remain "D2.COM".The specified server cannot perform the operation." MS says that this happens due to security package or RPC failure and it appears to be related to only Windows 7/Server 2008 (which we are phasing out). I'm guessing that there's a latency and/or subnet translation issue that's causing problems with the domain join attempt. I may have to find a way to join the Site2 workstations to D2 by putting them directly into the Site1 subnet (physically or by client VPN). Then once they are joined to D2, maybe they won't have DNS issues while using the site-to-site VPN.

[PhilipDAth]

I think you might be running into a domain search issue on the local workstation.

You can test this by trying to ping the FQDN of a machine and ending the domain with a "." to make it an absolute lookup.  For example:

ping www.google.com.

Typically we don't use the trailing dot and use relative lookups.

Try this on one of your workstations, go into the NIC settings and find the bit about the DNS suffix search, and put both the old and new domains into it.

[AJ]

That particular setting is handled via group policy. Members of D1 have the suffix order of "D1.COM, D2.COM", and members of D2 have search order of "D2.COM, D1.COM".

[AJ · Accepted solution]

Closing this question.

Verified that the problem I had is only found with Windows 7, which is now antiquated. Again, this was observed only the remote site (Site2), so I'm assuming this has something to do with the poor-quality Internet connection. Taking care of this on a Sunday proved to work better.