问如何为远程VPN访问Windows域配置DNS？

EN

假设您有一个小窗口域，配置如下：

• 域名为ad.example.com (按这些准则)
• DC1为10.10.10.3
• DC2在10.10.4
• DC1和DC2正在运行AD集成的DNS和DHCP服务器角色。
• AD配置的地址池为10.10.10.50-99
• AD正在签发客户端租约，其中006 DNS Servers选项设置为运行AD集成DNS的DC's的地址(即10.10.10.3和10.10.4)
• AD集成的DNS服务器将google的8.8.8.8配置为转发器
• 10.10.10.0/24子网通过Cisco ASA连接到因特网，内部地址为10.10.10.1
• ASA是10.10.10.0/24网络的网关
• vpn.example.com是一个公共DNS条目，解析为ASA的外部IP地址。
• 远程Windows计算机通过ASA连接10.10.10.0/24网络，使用思科IPSec VPN客户端指向vpn.example.com
• 远程Windows计算机的IP地址为10.10.10.200-10.10.10.254
• 分流隧道的启用使得隧道的流量仅为10.10.10.0/24 (该站点的最高可用上游带宽仅为2 2Mbps)。

有时通过虚拟专用网连接的

Windows膝上型计算机，其DNS应如何配置？

如果移动Windows膝上型计算机只接受随机的公共DNS服务器地址，则当隧道不活动时，它会将_ldap._tcp.site._sites.ad.example.com的DNS查询发送到随机公共DNS服务器。这是标准做法吗？不知怎么的，这似乎是个坏主意。

另一方面，如果Windows膝上型计算机只配置了内部DNS服务器10.10.10.3和10.10.10.4 (作为在此严正推荐)，那么VPN客户端就无法解决vpn.example.com的连接--这是一个鸡与蛋的问题。

在通过VPN连接的Windows笔记本电脑上，是否有什么东西应该与DNS一起进行呢？

一个虚拟专用网客户端对Windows查询有多少控制？应该启用DNS拆分隧道吗？

启用DNS拆分-隧道似乎意味着我们依赖VPN客户端来拦截像_ldap._tcp.site._sites.ad.example.com这样的DNS查询，以防止它们被发送到公共DNS服务器。VPN客户端的DNS拆分隧道严格可靠吗？因此，一些应用程序似乎完全忽略了VPN适配器，试图使用物理适配器上的公共DNS服务器解析Windows域地址。这是我应该关心的事情吗？

另一种选择--将所有DNS查找通过隧道发送到AD --集成DNS服务器--似乎是个坏主意，原因有两个: 1)当用户来自ASA的多个跃点时，隧道的延迟可能要比公共DNS服务器高得多。( 2)名称似乎将解析为与靠近ASA而不是远程计算机的服务器对应的IP地址。如果我正确地理解了这一点，那就意味着在CDN上访问媒体会有问题。(编辑：这里有一个例子，就是有人正经历着这个问题。)