在《谁的锅？一个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 仔细分析了有问题的包，如果你也想测试，输入以下命令：
$ tcpdump -s 0 -i eth0 port 53 -w ping.pcap
仔细观察下面的截图：
- 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 的时候触发了这个问题，可以通过下列命令避免反向查询：
$ ping pop3.sina.net -n
至于公司 DNS 配置是否有什么问题，这方面不太懂，等将来有机会我再补充。
我的新书《深入浅出HTTPS：从原理到实战》，本书github地址是 https://github.com/ywdblog/httpsbook，大家可以一起讨论本书。本书豆瓣地址 https://book.douban.com/subject/30250772/（或点击文末“阅读原文”），如果你读了本书，还请在豆瓣写个评论。或者关注我的公众号（ID：yudadanwx，虞大胆的叽叽喳喳）。
