none
用 Windows Server 2008 R2 配置的 DNS 服务器角色只能用于本机解析 RRS feed

  • 问题

  • 用 Windows Server 2008 R2 搭建的 DNS 服务器,只能用于本机解析,其他客户端配置这台DNS,都不能打开网页(换其他DNS正常)。

    我们对这台DNS做了检查:

    1、这台服务器防火墙关闭,TCP UDP 53端口打开,也未安装杀毒软件。

    2、在客户端运行Nslookup,解析结果如下图:

    3,在DNS服务器上运行Nslookup,完全正常解析:

    请微软专家帮助我们诊断一下这个问题,非常感谢!

    2020年3月16日 8:32

全部回复

  • 您好:

    DNS请求超时意味着NSLookup向DNS服务器提交了查询,但未获得响应。
    请在客户端运行ipconfig/all, 并上传截图。
    您可以反向ping IP地址并查看它是否已解析为正确的主机名 。

    Best Regards,
    Cherry


    如果认为回帖者的回答有所帮助,请将之标记为答复,这样可以帮助更多的用户获取有效信息。

    针对Windows 2008/2008R2的扩展支持将于2020年结束,之后微软将不再为其提供安全更新。点击此处或扫描二维码获取《在 Azure 上运行 Windows Server 的终极指南》,把握良机完成云迁移并实现业务现代化。


    2020年3月17日 6:11
  • 1、我们尝试将运行在这台Server 2008 R2 上的DNS角色删除,重新添加,仍不能给其他客户端提供域名解析

    2、我们也曾尝试将运行在这台Server 2008 R2 上的DNS区域删除,重新添加,仍不能给其他客户端提供域名解析

    3、目前这个DNS仅当本服务器自身使用时(即将本服务器DNS指定为本机IP),解析完全正常

    请指教。

    2020年3月17日 11:44
  • 测试客户端IP: 192.168.0.254

    DNS服务器IP:192.168.0.252

    令人困惑不解的是:为什么这台DNS服务器配置在本机上使用,解析竟完全正常,但除此而外,在其他客户端上都不能解析呢?

    2020年3月17日 12:22
  • 您好,

    请使用命令 ping -a 192.168.0.252,是否能解析DNS主机名。

    并请查看高级TCP/IP属性中,是否附加DNS后缀列表中地址过多导致time out

    如图:打开Ethernet属性>ipv4属性>高级:

    请参考论坛中情况相同的发帖:

    https://social.technet.microsoft.com/Forums/lync/en-US/f8da7378-db99-4e25-a8f9-c6103dd809d4/nslookup-dns-request-timed-out-timeout-was-2-seconds-cant-find-server-name-for-address?forum=winserverDS

    希望这可以对您有所帮助,如果您有任何不清楚的地方,请告诉我。


    Best Regards,
    Cherry


    如果认为回帖者的回答有所帮助,请将之标记为答复,这样可以帮助更多的用户获取有效信息。

    针对Windows 2008/2008R2的扩展支持将于2020年结束,之后微软将不再为其提供安全更新。点击此处或扫描二维码获取《在 Azure 上运行 Windows Server 的终极指南》,把握良机完成云迁移并实现业务现代化。



    2020年3月18日 6:08
  • 非常感谢您的帮助,我把您提到的截图发给您,请再指教。
    2020年3月18日 12:11
  • 我读了一下那篇发帖,许多回答认为是反向区域中的PTR记录缺失所致,检查了那台DNS, 发现PTR记录存在。
    2020年3月18日 15:44
  • 由于这个DNS解析问题,局域网中任何一台客户端指向这个DNS,皆不能打开网页。

    只有这台server 2008自身指向这个DNS,正常打开网页(说明此时域名解析生效)

    2020年3月18日 15:48
  • 您好:

    请您尝试关闭IPv6再运行nslookup,看是否能解析。

    希望这可以对您有所帮助,如果您有任何不清楚的地方,请联系我。


    Best Regards,
    Cherry

    如果认为回帖者的回答有所帮助,请将之标记为答复,这样可以帮助更多的用户获取有效信息。

    针对Windows 2008/2008R2的扩展支持将于2020年结束,之后微软将不再为其提供安全更新。点击此处或扫描二维码获取《在 Azure 上运行 Windows Server 的终极指南》,把握良机完成云迁移并实现业务现代化。

    2020年3月19日 2:47
  • 在192.168.0.252上关闭IPV6,在192.168.0.254上指向DNS,运行Nslookup,结果仍然不能解析www.jd.com
    2020年3月19日 11:35
  • 192.168.0.252是域控制器,安装有AD和DNS
    2020年3月19日 11:36
  • 您好:

    请运行nslookup d2命令,并上传一下截图,具体过程如下:

    > NSlookup

    >set d2

    > [您要解析的名称]

    请注意:由于论坛是公共开放的,任何人都可以看到您发布的消息,请在发布信息之前,提前抹去/删除私人信息以防止隐私泄露。

    希望这可以对您有所帮助,如果您有任何不清楚的地方,请联系我。

    Best Regards,
    Cherry

    如果认为回帖者的回答有所帮助,请将之标记为答复,这样可以帮助更多的用户获取有效信息。

    针对Windows 2008/2008R2的扩展支持将于2020年结束,之后微软将不再为其提供安全更新。点击此处或扫描二维码获取《在 Azure 上运行 Windows Server 的终极指南》,把握良机完成云迁移并实现业务现代化。


    2020年3月20日 1:38
  • 在客户端192.168.0.254上执行Nslookup D2的截图
    2020年3月21日 3:17
  • 另外,我们又随便建立一个测试DNS服务器,区域类型为“标准区域”,完全可以正常解析。

    属性截图如下:

    而这台故障DNS服务器由于本身是域控制器,DNS区域采用“与AD集成的区域”,其属性截图如下:

    我看到,“与AD集成区域”和“标准区域”的属性比较,多了一个“安全”选项卡!

    为什么故障DNS配置在本机就可正常解析,而配置在其他客户端就不行,能否是某种权限导致的呢?

    2020年3月21日 3:28
  • 还有一个情况,前次您让我执行的ping -a命令似乎又有变化!

    在客户端192.168.0.254(DNS为192.168.0.252 即故障DNS)上执行ping -a 截图:

    2020年3月21日 3:39
  • 我检查了一下,上次给您的ping -a截图是从故障DNS服务器运行上获取的,这次是从客户端上执行的截图,所以不同。
    2020年3月21日 6:17
  • 这是在同一个客户端上,分别配置192.168.0.254和192.168.0.252两个不同的DNS服务器,对同一个网址www.jd.com进行解析的截图,请参考。
    2020年3月22日 15:06
  • 您好,

    请使用Network Monitor工具抓取DNS解析过程的包分析,可能是由于UDP传输过程中发生了错误。

    您可以在此链接下载Network Monitor工具:
    https://www.microsoft.com/en-US/download/details.aspx?id=4865

    如果问题依旧无法解决,建议您和Microsoft客户服务与支持联系,以便可以进行深入调查。

    您可以通过以下链接找到您所在地区的电话号码:
    https://support.microsoft.com/en-us/help/4051701/global-customer-service-phone-numbers

    祝好,
    Cherry

    如果认为回帖者的回答有所帮助,请将之标记为答复,这样可以帮助更多的用户获取有效信息。

    针对Windows 2008/2008R2的扩展支持将于2020年结束,之后微软将不再为其提供安全更新。点击此处或扫描二维码获取《在 Azure 上运行 Windows Server 的终极指南》,把握良机完成云迁移并实现业务现代化。


    2020年3月23日 7:01
  • 我下载了Network Monitor ,但确实不会分析UDP数据包!

    我想,这个DNS只有配置在本机即能解析,而配置在其他客户端都失败,是否因为这台服务器的DNS解析服务端口有问题呢?

    DNS解析服务端口是UDP 53吗?我用Netstat -a 命令看到UDP 53 状态如下:

    这个状态说明UDP 53 端口正常开放吗?请指教。

    2020年3月24日 15:51
  • 您好,

    请理解,根据论坛的安全政策,我们无法提供数据包的分析。对于此类文件的分析诊断,您可能需要新开一个case,链接如下所示:

    https://support.microsoft.com/zh-cn/supportforbusiness/productselection

    希望能帮助到您!

    祝好,
    Cherry


    如果认为回帖者的回答有所帮助,请将之标记为答复,这样可以帮助更多的用户获取有效信息。

    针对Windows 2008/2008R2的扩展支持将于2020年结束,之后微软将不再为其提供安全更新。点击此处或扫描二维码获取《在 Azure 上运行 Windows Server 的终极指南》,把握良机完成云迁移并实现业务现代化。



    2020年3月25日 5:46
  • 您好:

    由于该帖长时间未有响应。我们将其建议为“已回答”。如果您需要我们的继续协助,您可以随时在该帖下回复,同时您可以根据实际情况取消作为答复。
    感谢您的理解与支持。

    Best Regards,
    Cherry


    如果认为回帖者的回答有所帮助,请将之标记为答复,这样可以帮助更多的用户获取有效信息。

    针对Windows 2008/2008R2的扩展支持将于2020年结束,之后微软将不再为其提供安全更新。点击此处或扫描二维码获取《在 Azure 上运行 Windows Server 的终极指南》,把握良机完成云迁移并实现业务现代化。


    2020年3月27日 7:37
  • 这个问题虽经多次交流,但至今尚未解决,我们仍希望通过Technet专家讨论的方式得到解决。
    2020年3月29日 2:49
  • 另外,上次提到的DNS端口是否正常开放的问题,未有回答,请看一下Netstat -a截图,DNS端口是否正常开放?
    2020年3月29日 2:53
  • 您好:

    如您截图所示,53端口应该没问题。

    请检查一下DC上的网卡配置,在DC上首选DNS配置成自己的地址,第二选配置127.0.0.1,然后客户端上网卡设置仅配置DC的地址。 另外,请检查一下client能不能通过DNS解析到本地域的记录,是不是只有在解析internet时才有问题。

    祝好,

    Cherry


    如果认为回帖者的回答有所帮助,请将之标记为答复,这样可以帮助更多的用户获取有效信息。

    针对Windows 2008/2008R2的扩展支持将于2020年结束,之后微软将不再为其提供安全更新。点击此处或扫描二维码获取《在 Azure 上运行 Windows Server 的终极指南》,把握良机完成云迁移并实现业务现代化。



    2020年3月30日 7:10
  • 您好,按照您的要求,我们又做了相关测试,为便于理解,先将测试环境说明一下:

    1、故障DNS位于一台DC上,IP地址为 192.168.0.252

    2、客户端IP地址为192.168.0.254

    测试步骤:

    1、在故障DNS上创建关于客户端和DC的两条A记录。2、在DC上配置TCP/IP

    3、在客户端上配置TCP/IP

    4、在客户端(192.168.0.254)上运行Nslookup,尝试解析内网上的主机名Server

    结论:在客户端上用故障DNS解析内网主机失败。

    我们又在DC上尝试解析同一台内网主机(server):

    测试结论:完全成功。

    看来,这个故障DNS只能用于其DC自身,用于其他任何客户端都失败(无论内外网解析),不知何故?请指教。

    2020年4月12日 15:36
  • 您好,

    非常感谢您到目前为止在这个case上所做的努力和一直以来的耐心。
    首先,当客户端需要查找对应FQDN的IP地址时,它会发送DNS query给DNS服务器。DNS服务器从客户端收到DNS query之后,将会进行名称解析。最后将DNS reply返回给客户端。
    从您的情况来看,我们需要通过抓包分析客户端是否有发出DNS query,DNS query是否有发送到DNS服务器上,DNS reply是否有返回给DNS客户端。然而,希望您可以谅解,抓包分析已经超出了论坛的范畴。
    另外,由于微软针对Windows 2008/2008R2的技术支持已于2020年1月14日结束,据我所知,您还需要购买ESU,这样才能和微软开启case。
    同时,我们依旧强烈建议您升级到最新的系统版本以获取所需的服务或支持。
    希望这可以帮助到您。


    Phoebe Wu

    2020年4月13日 7:28
  • 那为什么这个DNS配置在本机上就能正常解析呢?
    2020年4月14日 10:48
  • 您好,

    您所说的DNS配置在本机上能正常解析是一个正常的现象。而现在不正常的现象是客户端配置的DNS无法正常解析,通过以上您给出的截图,我们判断您的配置没有问题,如果要找到根本原因,这个只能通过在客户端和服务器上进行抓包来判断并且根据抓包的结果进行后续的一系列分析。

    所以说,现在我们的问题主要是DNS客户端发送的query包是否有到达DNS服务器上。


    Phoebe Wu

    2020年4月15日 1:57
  • 是否与DNS所在的服务器(Win Server 2008 R2) 上的FireWall有关呢? 还是与ARP解析环节有关呢?
    2020年4月19日 9:18
  • 您好,

    我们建议您可以尝试先将客户端与服务器上的Firewall都禁用,因为firewall可能会阻塞某些网络流量。

    如果禁用了双方的firewall之后,仍然无法解析的话,可能还是需要在客户端和服务器上抓包才能进行后续的分析并判断引起这个问题的根本原因与哪个环节有关。


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com   

    2020年4月20日 1:56