nslookup 显示服务器未知：那只是一个标签

连接 VPN，运行 nslookup，头部会显示解析器的地址，名称字段被填成 Unknown。这个词位于答案上方，多数人还没读到关键部分就停下了。该标签只说明解析器自身是否有反向名称；它完全没有说明你查询的主机名是否已解析。尽早关掉那扇窗，才是这里的关键。

两种不同的查询都可能产生这一显示，而其中只有一种与你的问题有关。区分它们只需多一条命令，却能省下一下午去修改从来没有错的 DNS 设置。

工具在回答你之前做了什么

nslookup 可能会尝试为它即将使用的服务器地址查找一个名称，也就是在 in-addr.arpa 或 ip6.arpa 域中做反向查询。如果那条 PTR 记录缺失、被策略过滤，或根本没有发布，工具就会打印 Unknown 然后继续。前向解析不受这次失败影响，因为它是发往同一台服务器的另一个问题。

这就是为什么私有解析器能够正确回答每一个公司名称，却在工具的头部显得匿名。地址是已知的；它背后的名称不是，工具对此很诚实，尽管在选词上仍有点戏剧化。

刻意执行这两次查询

先查询你关心的主机，再查询解析器自己的地址。第一条请求携带你需要的名称；第二条询问服务器能否为自己命名。写出来是这样的：主机用 nslookup app.corp.example 10.77.0.53，解析器的反向名称用 nslookup 10.77.0.53 10.77.0.53。

两个示例都只是示意，请替换成你自己的名称和地址。重点不是精确语法，而是区分：两条命令问的是不同问题，完全可以在都不算故障的情况下给出不同结果。

三种看似相同实则不同的结果

超时意味着完全没有收到答案，指向可达性、过滤或错误的服务器地址。否定答案意味着服务器回复说名称不存在，指向区域或后缀。缺少反向名称意味着服务器对第二个问题没有给出有用的东西，而前向答案可能仍然完美。三种结果、三个责任方，其中只有一种与你需要的主机名有关。

只有前两种描述了让你的应用失败的 DNS 路径。第三种描述的是一条从未发布的记录，把它当成故障会导致无法修复它的改动，比如反复重写搜索后缀直到头部看起来更友好。

读各个部分，而不是头部

在头部下方，工具会打印答案、权威以及任何附加记录。答案部分中的正确地址就是你要的结果，即使头部的名称是 Unknown。带权威否定的空答案则是另一种结局，值得单独调查。

在发给支持的每份材料中都明确写出两件事：查询了哪个名称，询问了哪台服务器。只提到“VPN 上 DNS 坏了”的报告，会迫使下一个人重建你已经做过的测试。

当反向名称真正重要时

有些服务确实在意 PTR 记录：解析客户端地址的日志、邮件信誉检查，或显示名称的管理工具。如果其中之一失败，就发布记录或修好本该保存它的区域。这项工作是正当的，与 VPN 是否正确转发查询是两回事。

狭义结论依然成立：一条缺失的解析器标签不能证明隧道上的前向解析坏了，一次成功的前向查询也不能证明区域中的每个名称都能解析。测试你真正需要的名称，然后再判断头部那个词值多少。