誰的鍋？一個ping案例（續）
在 ofollow,noindex">《誰的鍋？一個ping案例》 )這篇文章中，雖然我大概排查問題了，但最後並沒有說出具體的原因，那到底是哪個環節（local dns、公司 dns、ping 機制）的問題呢？ 當時我沒有解釋的原因很簡單，因為我自己也不清楚，總覺得很遺憾。
因為兩個事情，我今天又重新分析了下：
結論
先說結果把， 確認是公司 DNS 的問題 。有些同學說，在《誰的鍋？一個ping案例》文章中，你不是說將 /etc/resolv.conf 中的 local dns 配置為 8.8.8.8 後，ping pop3.sina.net 不是沒問題嗎？說明不是你公司 DNS 的問題啊。我當時忽略了一點，切換 local dns 為 8.8.8.8 後，公司的 DNS 解析是不一樣的，導致我誤認為公司 DNS 沒有問題。
那怎麼證明呢？看下面這張圖：
圖1
在這張圖中，輸入 nslookup 命令後 很久 才輸出響應，其中 49.7.36.125 是 pop3.sina.net 電信機房的 A 記錄，也就是《誰的鍋？一個ping案例》 文章中有問題的解析。
注意其中的紅圈 “SERVFAIL” 代表響應有問題，超時了。
接下去看第二張圖：
圖2
在這張圖中，輸入 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）第一個發現的問題
圖3
在《誰的鍋？一個ping案例》文章中，我定位的問題是解析 A 記錄緩慢，但這張圖中，我發現了一個很奇怪的問題，雖然第一步（紅字部分）跳到第二步花了很長時間，但實際上在第一步中，其實 49.7.36.125 已經被解析出來了。
這就顛覆了“A 記錄查詢緩慢的觀點”，我當時怎麼沒發現呢？
（2）第二個發現的問題
我又開啟 wireshark 仔細分析了有問題的包，如果你也想測試，輸入以下命令：
$ tcpdump -s 0-i eth0port 53 -w ping.pcap
仔細觀察下面的截圖：
圖4
- ping 命令分別向兩個 local dns 進行了多次 DNS 查詢，每次都失敗了。。。
- DNS 查詢命令是 PTR 125.36.7.49.in-addr.arpa，徹底顛覆了我的認知，為啥 ping 命令還要根據 IP 反向查詢域名呢。。。
（3）第三個發現的問題
再一次檢視 strace 輸出，也發現了新問題，如下圖：
圖5
也有 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，虞大膽的嘰嘰喳喳）。