调试DNS解析错误

我正在auth.otc.t-systems.com使用Cloudflare的服务器调试域的DNS解析错误，但卡住了。奇怪的是，查找成功/失败取决于运行查询的计算机，但是我无法弄清楚配置的不同之处。

失败总是带有以下消息： server can't find auth.otc.t-systems.com: SERVFAIL

1.1.1.1 是Cloudflare的DNS。

到目前为止，我已经尝试过：

nslookup auth.otc.t-systems.com 1.1.1.1在各种机器上运行：
- 它在我的具有工作和家庭互联网的计算机上失败（但是在两种情况下都可以通过Google的DNS成功运行）。
- 在具有工作互联网的同事计算机上失败。
- 它成功完成了到远程服务器的ssh会话。
现在，我假设我们的工作互联网上存在一些奇怪的配置，这会导致查找失败。但是我不知道该寻找什么，而且我还发现一些在线nslookup服务也失败了：
- 失败：https : //network-tools.com/nslook/Default.asp? domain = auth.otc.t-systems.com & type =1& server = 1.1.1.1 & class =1& port = 53 & timeout = 5000 & go.x =21& go.y =13
- 作品：http：//www.kloth.net/services/nslookup.php

有什么提示可以进一步调试吗？

networking domain-name-system

您是否也尝试过使用1.0.0.1IPv6 2606:4700:4700::1111和2606:4700:4700::1001，或者它们也都是CloudFlare。还要全局查看blog.cloudflare.com/fixing-reachability-to-1-1-1-1-global及其最后一段，其中提供了报告问题的方法。

— Patrick Mevzek '19

Answers:

尝试使用挖掘。二十年前，他们曾尝试弃用nslookup，但现在它已牢牢扎根到肌肉记忆中，无法摆脱，但挖深得多。例如。

dig +trace auth.otc.t-systems.com @1.1.1.1

将完全为您跟踪分辨率，您可以看到它们的不同之处。

— 西尔奇
source

谢谢，我对nslookup一无所知。我现在尝试了dig命令，奇怪的是它在我的机器上返回了正确的ip。我已经将命令的输出发布到了我的计算机和本地计算机上的gist.github.com/thomas88/600d367387505a13223a5270c89eedda上。不管挖掘工作有何不同，我的浏览器（Mac上为Chrome）似乎都与nslookup保持一致-它无法解析地址。

— ThomasObermüller'18

没有理由期望此查询之间dig以及nslookup针对此查询会有不同的结果。但是，由于这1.1.1.1是一个任播地址，因此结果可能会有所不同，具体取决于查询最终由哪个服务器提供服务。

— 卡巴斯德（Kasperd）'18年

作为网络客户端的Chrome可能会将您重定向。http标头是否可以卷曲-I <您要访问的网页>揭示了有关转发的任何信息？

— 希尔奇'18

同时使用+trace和有@1.1.1.1什么意义？您确定您了解这些选项如何协同工作吗？

— Barmar

是的，我确定我了解它们是如何协同工作的。使用@ <地址>的目的是要指定其客户端在两个位置使用的dns服务器。在给定的示例中，其云盘是光晕，但如果另一个客户端使用其他dns服务器，则会在此处指定。例如，在我所在的位置，resolv.conf中的服务器地址是公司地址，但我仍然可以从1.1.1.1

— Sirch

网络人员已经使用1.1.1.1年龄来替换交换机/路由器AP随机接口中的另一个专用地址。（我本人目前位于数百个无线AP面向公众的IP地址为1.1.1.1的位置）

我敢打赌，在无法与Cloufare的1.1.1.1交谈的机器上，我认为那里有一条（直接）路由用于此类接口。

例如，就我而言，1.1.1.1给我我的IP地址：

$ sudo tcpdump -i any -n host 1.1.1.1 and port 67
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
13:11:51.037186 IP 1.1.1.1.67 > 10.x.x.x.68: BOOTP/DHCP, Reply, length 296
13:11:51.037250 IP 1.1.1.1.67 > 10.x.x.x.68: BOOTP/DHCP, Reply, length 296

— Rui F Ribeiro
source

这就是为什么必须严格执行RFC 3849和RFC 5737的原因。

— 卡巴斯德（Kasperd）'18年

但是，“太低”是确定任何内容的棘手基础。Cloudflare有很多PoP。64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=1.30 ms是我对真实事物的RTT。

— 哈坎·林德奎斯特

@HåkanLindqvist你的价值就显得外部连接过低的延迟....但是，是不是一个可靠的指标。

— Rui F Ribeiro

@RuiFRibeiro延迟似乎适用于不涉及高延迟链接的同城连接。（Traceroute在我的ISP中显示了4个地址，在我所在城市的互联网交易所中显示了Cloudflare地址，然后是1.1.1.1。）

— HåkanLindqvist 18-10-9

看来我可以访问Cloudflare DNS，但对我而言，该域名失败了。我已经为auth.otc.t-systems.com和运行nslookup serverfault.com。这是tcpdump的结果：gist.github.com/thomas88/03acc781f45c9427863b1876c75acb4d

— ThomasObermüller18年