背景:
> Active Directory域控制器位于172.16.1.3
> AD / DC机器也运行DHCP,DNS和HTTP(IIS)
>我们在company.com和subdomain.company.com上的组织网站由AD / DC计算机上的IIS托管
>我们有一个拆分DNS方案,其中AD / DC服务器用于内部DNS解析,但另一个异地服务器为公共查询提供DNS解析
> company.com和subdomain.company.com对应的IP地址是我们网络边缘防火墙使用的公共IP地址(AD / DC DNS服务器和场外DNS服务器)
>防火墙已正确配置NAT,以便将其在公共IP地址上接收的HTTP和HTTPS请求传递到AD / DC服务器的内部IP并反映
场景1:
>加入域的Windows 7 Enterprise计算机上的用户直接连接到本地网络,本地地址为172.16.6.100 / 16,由DHCP服务器发出.
> DNS服务器条目由DHCP提供(172.16.1.3)
>此用户可以访问在company.com和subdomain.company.com上托管的网站
>编辑:nslookup已在此方案中运行,并从内部DNS服务器正确返回正确的DNS记录(172.16.1.3)
场景2:
>同一个加入域的Windows 7 Enterprise计算机上的同一用户回家并使用其住宅ISP连接到Internet
>客户端计算机的IP和DNS服务器条目由DHCP提供
>此用户可以访问任何互联网资源,例如google.com
>此用户无法访问company.com或subdomain.company.com上的网站(返回“主机未解析”错误)
>当此用户在company.com上运行nslookup时,他们会收到DNS提供的正确公共IP地址
>对IP地址的HTTP / HTTPS请求成功,服务器正确返回网页
>此问题在所有Web浏览器中都很普遍
>使用tracert company.com返回“无法解析目标系统名称”
>使用ping company.com返回“找不到主机company.com”
>在失败请求之前/期间在客户端上运行Wireshark时,客户端计算机不会发送任何数据包(DNS解析或初始HTTP / ping / tracert请求)
>重新启动DNS客户端服务无法解决问题
>停止DNS客户端服务无法解决问题
>使用ipconfig / flushdns无法解决此问题
>使用route / f无法解决此问题
>使用netsh int ip reset重置网络连接无法解决此问题
>编辑:nslookup已在此方案中运行,并正确地从用户使用的网络的DHCP设置指定的DNS服务器返回正确的DNS记录
场景3:
>当连接到我们的本地网络时,个人(非域加入)Windows 7 Professional计算机上的同一用户可以访问company.com和subdomain.company.com上的网站
>编辑:nslookup已在此方案中运行,并从内部DNS服务器正确返回正确的DNS记录(172.16.1.3)
场景4:
>在连接其家庭网络时,并正确地从用户使用的网络的DHCP设置指定的DNS服务器返回正确的DNS记录
最后的笔记:
这个问题似乎被推广到影响所有公司拥有的计算机.我们正在为所有公司拥有的计算机使用通用系统映像,该计算机刚刚在8月份加载.我一直在寻找可能的解决方案,并且到目前为止空手而归 – 我真的很感激您的任何建议或建议.
@R_301_323@
当您使用ping或(几乎)任何Windows应用程序时,它使用完整的Windows IP堆栈,包括与AD通信的部分.而NSLookup实际上只是进行DNS查询.您已经使用Wireshark跟踪验证了这一点,在尝试访问company.com时,Windows没有执行任何查找,但nslookup显示正确的DNS查找.这就是您无法通过ping或Web浏览器解析域的原因,但nslookup很好.
第一部分的解决方案是使用www.company.com在内部和外部访问网站,以便客户完全忽略寻找DC.
第二部分的解决方案比较棘手,具体取决于subdomain.company.com在内部和外部的引用. DC是否具有子域的DNS记录,或者是那些仅发送到外部DNS服务器的请求?如果它有DNS记录,那记录点在哪里?