谁的锅？一个ping案例（续）

在《谁的锅？一个ping案例》这篇文章中，虽然我大概排查问题了，但最后并没有说出具体的原因，那到底是哪个环节（local dns、公司 dns、ping 机制）的问题呢？ 当时我没有解释的原因很简单，因为我自己也不清楚，总觉得很遗憾。

因为两个事情，我今天又重新分析了下：

• 《谁的锅？一个ping案例》文章被开发者头条 APP 推荐后，有个同学评论到“然后呢？”，意思就是具体的原因呢。

• 同事也遇到了类似问题，主要是查询公司不同机房数据库（通过域名连接）也有缓慢的问题。

结论

先说结果把，确认是公司 DNS 的问题。有些同学说，在《谁的锅？一个ping案例》文章中，你不是说将 /etc/resolv.conf 中的 local dns 配置为 8.8.8.8 后，ping pop3.sina.net 不是没问题吗？说明不是你公司 DNS 的问题啊。我当时忽略了一点，切换 local dns 为 8.8.8.8 后，公司的 DNS 解析是不一样的，导致我误认为公司 DNS 没有问题。

那怎么证明呢？看下面这张图：

在这张图中，输入 nslookup 命令后很久才输出响应，其中 49.7.36.125 是 pop3.sina.net 电信机房的 A 记录，也就是《谁的锅？一个ping案例》 文章中有问题的解析。

注意其中的红圈**“SERVFAIL”**代表响应有问题，超时了。

接下去看第二张图：

在这张图中，输入 nslookup 命令后很快输出响应，其中 202.108.6.175 是 pop3.sina.net 联通机房的 A 记录。

有的同学可能会有疑问，nslookup 49.7.36.125 啥意思？它是 IP 地址的 PTR 反向解析命令，聪明的同学马上猜出来了，ping pop3.sina.net 在运行的时候是不是也进行了 PTR 反向查询？是的，而 dig pop3.sina.net 不会进行反向查询，这就是 dig pop3.sina.net 一直很快速的原因。

**结论：**ping pop3.sina.net 的时候，如果你从电信网络发出请求，ping 在执行 49.7.36.125 反向解析请求的时候遇到了问题。而如果从联通网络发出请求，ping 在执行 202.108.6.175 反向解析请求的时候是正常的。

接下去我说说是如何排查出的，这方面可能大家比较感兴趣。

问题排查

（1）第一个发现的问题

在《谁的锅？一个ping案例》文章中，我定位的问题是解析 A 记录缓慢，但这张图中，我发现了一个很奇怪的问题，虽然第一步（红字部分）跳到第二步花了很长时间，但实际上在第一步中，其实 49.7.36.125 已经被解析出来了。

这就颠覆了“A 记录查询缓慢的观点”，我当时怎么没发现呢？

（2）第二个发现的问题

我又打开 wireshark 仔细分析了有问题的包，如果你也想测试，输入以下命令：

仔细观察下面的截图：

• ping 命令分别向两个 local dns 进行了多次 DNS 查询，每次都失败了。。。

• DNS 查询命令是 PTR 125.36.7.49.in-addr.arpa，彻底颠覆了我的认知，为啥 ping 命令还要根据 IP 反向查询域名呢。。。

（3）第三个发现的问题

再一次查看 strace 输出，也发现了新问题，如下图：

也有 PTR 反向查询的超时输出（2秒），进一步确认是 ping 在执行 PTR DNS 查询遇到了问题（如果你是电信用户）。

遗留

目前基本能确认是公司 DNS 的问题了，如果用 dig 命令或者浏览器内部的 dns 解析，你不会遇到问题，因为不会进行 DNS 反向查询。 但如果你 ping 的时候触发了这个问题，可以通过下列命令避免反向查询：

至于公司 DNS 配置是否有什么问题，这方面不太懂，等将来有机会我再补充。

我的新书《深入浅出HTTPS：从原理到实战》，本书github地址是 https://github.com/ywdblog/httpsbook，大家可以一起讨论本书。本书豆瓣地址 https://book.douban.com/subject/30250772/（或点击文末“阅读原文”），如果你读了本书，还请在豆瓣写个评论。或者关注我的公众号（ID：yudadanwx，虞大胆的叽叽喳喳）。

本文转载自异步社区。

原文链接：https://www.epubit.com/articleDetails?id=N8c628008-2547-4efe-b406-aaa8ed7af030