用几句话来说，问题是很less的域名在我们的networking中没有被工作站解决，而从服务器上的远程桌面会话成功完成。
现在的细节。
我们有一个路由器后面的Windows域networking。 内部地址是从192.168.1.x范围。 有一个隧道build立到一个客户网站，地址范围是10.xxx。 这工作很长一段时间。
有一些由客户定义的域名，指向内部networking中的服务器。 它们不是公开可见的，所以访问它们我在我们的域控制器（192.168.1.1，Windows Server 2008 R2）上添加了条件转发器，但是其中的一些有时候是由公共名称服务器解决的。 我不知道configuration，但客户端的networkingpipe理员声称我们应该直接查询他们的名称服务器，因此有条件的转发。 这工作很长一段时间没有问题。
我需要将域控制器升级到Windows Server 2016.为此，我添加了一个辅助域（192.168.1.7，Windows Server 2012 R2）。 包括有条件的转发器在内的AD被复制到这个新的服务器上。 在这一点上，我们没有问题。 有一些工作站的主DNS设置为主DC（192.168.1.1），其他主DNS设置为次DC（192.168.1.7）。 客户的域名已在所有工作站上成功解决。
然后，我在主服务器（192.168.1.1）上安装了Windows Server 2016，并将其作为主DC进行升级。 AD被复制并且有条件的转发器到位。 但是，当工作站尝试parsing客户端域时，如果它是辅助DC（192.168.1.7），则成功;如果它是主要DC（192.168.1.1），则成功。 有趣的是，DNS查询在服务器本身（在远程桌面会话中）被parsing。 否则DNS看起来正常工作，因为没有其他域名的问题（互联网接入几个星期工作正常）。 客户端的networkingconfiguration如下：
两个域控制器上的DNSconfiguration方式相同（至less我找不到任何重大区别）：
在这一点上，我能够解决在这两个服务器上的客户的域名。 如果我尝试在工作站上ping这个域，那么如果它的主DNS是192.168.1.7，则成功;如果是192.168.1.1，则成功。
我可以ping通工作站上的互联网域名，不pipe它是主DNS（192.168.1.1和192.168.1.7都可以正常工作）。
在服务器上使用nslookup时，如果服务器为192.168.1.1，则“DNS请求超时”会失败，但如果是192.168.1.7或客户端的名称服务器（10.xxx），则不pipeDNS设置（192.168.1.1）如何，都会失败。 1.1或192.168.1.7）。 ping客户端域时，我在工作站上使用了Nir Sofer的DNSQuerySniffer。 当它的DNS是192.168.1.1，我看到5个请求–4没有响应，第五个返回“服务器故障”，所有从工作站的IP和192.168.1.1作为目的地址。 当工作站的DNS设置为192.168.1.7时，我只看到一个成功的请求。 然而，当在服务器上运行它时，在192.168.1.1我看到DNS请求到我的路由器，而它应该是客户端的名称服务器， 即有条件的转发器不起作用，并且这个域由公共DNSparsing（可能，或可能无法解决它，但要按照客户的指示，我必须直接查询他们的名字服务器）。 在192.168.1.7我看到一个请求到他们的名字服务器的IP（10.xxx）， 即条件转发工程 。
我感到非常愚蠢！ 显然我错过了一些东西。 你觉得我应该检查什么？ 有什么可能是有条件转发不在这个DC上工作的原因？ 我将非常感激任何帮助！
先谢谢你！
事实certificate，一个Hyper-V虚拟networking适配器只剩下DHCP，并且它得到一个默认网关，这是我们的备份Internet提供商。 它没有build立到客户的网站的隧道，因此你不能使用这个互联网连接到他们的名字服务器，因此查询回退到公用名字服务器，这有时解决了查询，有时不（这是客户的问题）。 我使用静态IP地址正确configuration了此networking适配器，并删除了备份网关。 现在，所有DNS查询都通过主互联网进行路由，主互联网有一个到客户站点（和名称服务器）的隧道，所有域名都已成功parsing。