很多網(wǎng)絡(luò)問題最煩人的地方，不是“徹底不可用”，而是那種**偶發(fā)、間歇、說不清**的卡頓。
用戶描述通常都很像：
- 網(wǎng)頁不是打不開，而是“有時候第一下很慢”
- 系統(tǒng)不是完全超時，而是“偶爾會轉(zhuǎn)兩三秒”
- 運維看監(jiān)控也很委屈：出口帶寬沒滿、服務(wù)器 CPU 正常、鏈路也沒掉
這類問題里，**DNS 慢查詢**是一個被長期低估的根因。
因為它很少把系統(tǒng)直接打死，卻非常擅長制造一種錯覺：**像應(yīng)用慢、像鏈路抖、像服務(wù)器抽風(fēng)，但偏偏不太像 DNS 故障。**
這篇文章不講教材式原理，直接按一線排障思路展開：當(dāng)你懷疑“不是完全斷網(wǎng)，而是訪問首包慢、首開慢、偶發(fā)轉(zhuǎn)圈”時，怎么一步步判斷問題是不是出在 DNS，怎么抓包、怎么看指標(biāo)、怎么縮小責(zé)任邊界，以及最后怎么治理。
---
## 一、為什么 DNS 慢查詢特別難被第一時間想到
傳統(tǒng)排障里，很多團隊對 DNS 的理解還停留在“能解析 / 不能解析”二元狀態(tài)。
但真實生產(chǎn)環(huán)境里，更常見的是下面這些灰度故障：
1. **遞歸解析鏈路變長**：本地 DNS 沒命中緩存，需要繼續(xù)向上游遞歸查詢
2. **上游 DNS 響應(yīng)抖動**：并非完全不可達，而是 RTT 明顯波動
3. **UDP 查詢丟包或重傳**：在高峰期、跨區(qū)域鏈路、策略設(shè)備上更常見
4. **EDNS / 大包響應(yīng)被截斷**：觸發(fā) TCP fallback，導(dǎo)致時延陡增
5. **個別域名異常**：外部依賴、CDN 調(diào)度、權(quán)威 DNS 波動，只影響部分業(yè)務(wù)
6. **客戶端本地緩存策略失效**：導(dǎo)致重復(fù)查詢明顯增多
于是你會看到一個很典型的現(xiàn)象：
- ping 正常
- TCP 三次握手也正常
- 應(yīng)用服務(wù)器資源也不高
- 但用戶打開頁面就是“第一下慢”
因為真正慢的，往往發(fā)生在**TCP 建連之前**。
---
## 二、這類故障最典型的現(xiàn)場癥狀
如果你在一線值班，下面這些現(xiàn)象同時出現(xiàn)時，優(yōu)先把 DNS 放進懷疑名單：
### 1）首開慢，刷新反而快
第一次訪問一個站點明顯慢，第二次刷新恢復(fù)正常。這通常意味著：
- 第一次命中了真實解析流程
- 第二次吃到了客戶端或本地遞歸 DNS 的緩存
### 2）同一業(yè)務(wù)，不同域名體驗差異很大
例如：
- 主頁面打開快
- 靜態(tài)資源域名慢
- SSO 域名慢
- 第三方 API 域名偶發(fā)超時
這時候就別再把鍋一股腦甩給“應(yīng)用整體性能”了。問題可能根本不在 Web 服務(wù)，而在**某一類域名解析質(zhì)量**。
### 3）監(jiān)控看著綠，但用戶持續(xù)反饋卡
傳統(tǒng)監(jiān)控往往關(guān)注：
- 主機 CPU / 內(nèi)存
- 鏈路帶寬
- ICMP 可達性
- 端口存活
這些指標(biāo)對 DNS 慢查詢并不敏感。因為 DNS 的問題常常不是“掛了”，而是：
- 查詢耗時從 20ms 變成 600ms
- 某個時間段丟掉 5% 的請求
- 某個上游節(jié)點偶發(fā)劣化
從 NOC 大盤看，一切都還活著；從用戶體驗看，已經(jīng)開始掉分了。
---
## 三、排障不要上來就抓全網(wǎng)，先做最值錢的切分
DNS 類故障最怕“抓了一堆包，最后只得到一堆包”。
正確姿勢不是先堆工具，而是先切分問題邊界。
### 第一步：先確認(rèn)慢的是“連接前”還是“連接后”
你可以讓現(xiàn)場同事做一個最簡單的對照測試：
- 直接訪問域名
- 直接訪問已知 IP（或 hosts 綁定）
如果綁定 IP 后明顯變快，說明問題高度集中在：
- DNS 查詢階段
- 調(diào)度到錯誤目標(biāo)
- 或解析結(jié)果對應(yīng)鏈路質(zhì)量不佳
這一步非常重要。它能幫你避免把 2 小時浪費在錯誤方向上。
### 第二步：區(qū)分“全部域名都慢”還是“特定域名慢”
建議把現(xiàn)場樣本先分成三類：
- 內(nèi)部域名（如 OA、ERP、內(nèi)部 API）
- 常見公網(wǎng)域名（如搜索、CDN、公共服務(wù)）
- 出問題業(yè)務(wù)對應(yīng)域名
如果只有某些外部域名慢，重點看：
- 上游遞歸 DNS 質(zhì)量
- 權(quán)威 DNS 穩(wěn)定性
- 跨運營商 / 跨區(qū)域解析路徑
如果連內(nèi)部域名也慢，那就要懷疑：
- 本地 DNS 服務(wù)器性能
- 轉(zhuǎn)發(fā)器策略
- 安全設(shè)備對 53 端口流量的影響
### 第三步：確認(rèn)是“慢”還是“重試后才成功”
很多時候業(yè)務(wù)方說“慢”，但抓包會發(fā)現(xiàn)更精確的事實是：
- 第一包沒回來
- 第二次查詢才成功
- 或 UDP 超時后轉(zhuǎn) TCP 才成功
這兩種問題的治理方式完全不同。
---
## 四、抓包時到底該看什么，不該看什么
做 DNS 排障，最常見的浪費動作是：
- 抓了太長時間
- 抓了太大范圍
- 最后只會按域名搜關(guān)鍵字
如果你真想把 DNS 慢查詢定位快一點，抓包時建議只盯四類信息。
### 1）查詢發(fā)出時間與響應(yīng)返回時間
這是最基礎(chǔ)、也最關(guān)鍵的數(shù)據(jù)。
你需要知道：
- 某次 query 發(fā)出的時間點
- 對應(yīng) response 回來的時間點
- 二者差值是多少
重點不是看有沒有響應(yīng)，而是看：
- 平時 20ms 的查詢是不是偶發(fā)到了 300ms、800ms、2s
- 這種抖動是否集中在某幾個域名
- 是否集中于某個 DNS 服務(wù)器
### 2）是否存在重復(fù)查詢
如果同一個客戶端、同一個事務(wù)周期里，對同一域名短時間內(nèi)連續(xù)發(fā)起多個請求，要重點懷疑：
- 前一個響應(yīng)丟失
- 應(yīng)用超時閾值過短
- 本地 stub resolver 行為異常
- 中間網(wǎng)絡(luò)對 DNS 請求存在丟包
重復(fù)查詢不是“用戶比較著急”，通常是系統(tǒng)已經(jīng)在用腳投票：**它不信任當(dāng)前解析鏈路。**
### 3）是否出現(xiàn)截斷與 TCP 回退
某些響應(yīng)包會帶有截斷標(biāo)記，隨后客戶端改用 TCP 53 再發(fā)一次。
這在下面幾類場景里特別常見：
- 返回記錄較多
- DNSSEC 相關(guān)響應(yīng)較大
- EDNS 配置不一致
- 中間設(shè)備對大 UDP 包處理不好
如果你看到明顯的 UDP 查詢后又跟著 TCP 建連，再結(jié)合整體訪問時延上升，基本就能解釋“為什么不是一直慢，而是偶發(fā)很慢”。
### 4）慢查詢是否集中在某個上游解析器
很多企業(yè)環(huán)境并不是只用一個上游 DNS，而是：
- 主備 DNS
- 多運營商 DNS
- 本地遞歸 + 上游轉(zhuǎn)發(fā)
這時非常值得比對：
- 發(fā)往 A 解析器的耗時分布
- 發(fā)往 B 解析器的耗時分布
- 是否某一個節(jié)點在高峰時段特別差
真正成熟的排障，不是證明“DNS 有問題”，而是繼續(xù)推進到：**到底是哪一段 DNS 路徑有問題。**
---
## 五、一個典型實戰(zhàn)：表面像應(yīng)用卡頓，實際是 DNS 上游抖動
下面給你一個非常典型、也非常常見的排障模型。
### 現(xiàn)場現(xiàn)象
某辦公系統(tǒng)在周一早高峰經(jīng)常被投訴“登錄頁轉(zhuǎn)圈”。
已知事實：
- 應(yīng)用服務(wù)器 CPU 35% 左右
- 數(shù)據(jù)庫無慢查詢峰值
- 出口帶寬占用 40% 左右
- 防火墻無明顯會話打滿
- 只有早上 9:00-10:00 問題最明顯
從傳統(tǒng)視角看，這不像服務(wù)器扛不住，也不像主鏈路斷了。
### 排查動作
先讓現(xiàn)場做兩組測試：
1. 瀏覽器正常訪問業(yè)務(wù)域名
2. 將關(guān)鍵域名寫入 hosts 后訪問
結(jié)果很有意思：
- 正常訪問：首屏經(jīng)常 2-4 秒
- 寫 hosts 后：多數(shù)請求 1 秒內(nèi)完成
到這一步，方向已經(jīng)很清楚：**瓶頸出在解析前鏈路，而不是應(yīng)用主處理鏈路。**
### 抓包觀察
對客戶端與本地 DNS 之間做鏡像抓包后，發(fā)現(xiàn)：
- 大部分 DNS 查詢在 20-40ms 內(nèi)返回
- 但登錄依賴的兩個外部域名，偶爾會飆到 700ms 以上
- 少量請求第一次 UDP 無響應(yīng)，第二次重試才回來
- 問題集中發(fā)生在某一個上游轉(zhuǎn)發(fā) DNS
### 進一步驗證
把本地 DNS 的上游從“運營商默認(rèn)轉(zhuǎn)發(fā)器”切換到另一組穩(wěn)定遞歸節(jié)點后：
- 慢查詢比例顯著下降
- 用戶投訴明顯減少
- 抓包中重復(fù)查詢次數(shù)同步下降
### 最終根因
不是應(yīng)用性能，不是服務(wù)器資源，也不是出口擁塞。
而是：
**某上游 DNS 節(jié)點在高峰期出現(xiàn)明顯抖動，導(dǎo)致關(guān)鍵業(yè)務(wù)域名解析耗時上升，并觸發(fā)應(yīng)用首開卡頓。**
這類問題如果沒有流量級證據(jù)，現(xiàn)場很容易陷入“你那邊看起來都正常”的多人甩鍋局。
---
## 六、DNS 慢查詢的高頻根因清單
如果你想少走彎路，可以優(yōu)先按下面這個清單排。
### 1）本地 DNS 服務(wù)器資源不足
關(guān)注：
- CPU、內(nèi)存、線程數(shù)
- 查詢隊列長度
- 緩存命中率
- 峰值時段響應(yīng)耗時
很多團隊只看業(yè)務(wù)服務(wù)器性能，完全忘了 DNS 本身也是服務(wù)器。
### 2）上游轉(zhuǎn)發(fā)器質(zhì)量差
這是企業(yè)里非常常見的問題。
尤其在以下場景中更明顯：
- 直接使用運營商默認(rèn) DNS
- 多地辦公但統(tǒng)一轉(zhuǎn)發(fā)到單一出口
- 跨境 / 跨區(qū)域依賴較多
### 3）鏈路上對 UDP 53 不友好
例如：
- 丟包
- 策略限速
- 安全設(shè)備誤判
- NAT 表波動
DNS 天生對“輕微丟包”非常敏感，因為它包小、頻繁、依賴及時響應(yīng)。
### 4）響應(yīng)包過大，觸發(fā)回退
尤其當(dāng)你遇到：
- 某類域名解析特別慢
- 不是全部慢
- 不是一直慢
要重點考慮是不是存在：
- 截斷
- TCP fallback
- 中間設(shè)備對大包 / 分片處理異常
### 5）業(yè)務(wù)依賴外部第三方域名過多
現(xiàn)代應(yīng)用經(jīng)常在首屏階段就依賴：
- SSO
- 埋點
- CDN
- 字體服務(wù)
- 第三方接口
這些域名中只要有一個解析慢，用戶感知就會直接變差。
所以很多“應(yīng)用慢”本質(zhì)上是“依賴鏈太碎，且 DNS 鏈路不穩(wěn)”。
---
## 七、怎么把 DNS 排障做成標(biāo)準(zhǔn)動作，而不是靠運氣
成熟團隊和疲于救火團隊的差別，往往不在技術(shù)深度，而在于有沒有把方法論沉淀下來。
這里給一個實戰(zhàn)里很好用的 DNS 慢查詢排障框架。
### 框架一：先判定層次
按順序問四個問題：
1. 慢發(fā)生在解析前、連接中，還是應(yīng)用處理階段？
2. 是全部域名慢，還是部分域名慢？
3. 是持續(xù)慢，還是偶發(fā)重試后恢復(fù)？
4. 是客戶端到本地 DNS 慢，還是本地 DNS 到上游慢？
只要這四個問題答清楚，問題范圍通常已經(jīng)縮小一半以上。
### 框架二：建立 DNS 關(guān)鍵指標(biāo)
不要只監(jiān)控“53 端口活著沒有”，至少要補齊：
- 查詢量趨勢
- 平均響應(yīng)時間 / P95 / P99
- NXDOMAIN 比例
- SERVFAIL 比例
- 超時比例
- 重復(fù)查詢比例
- TCP fallback 比例
- 熱點域名分布
- 上游解析器耗時對比
如果這些指標(biāo)長期缺位，那你每次 DNS 出事，都會像第一次見鬼。
### 框架三：把業(yè)務(wù)域名分層
建議把核心依賴域名分成三類：
- 一級核心：登錄、下單、支付、主 API
- 二級關(guān)鍵：靜態(tài)資源、搜索、報表
- 三級外圍：埋點、廣告、非關(guān)鍵第三方組件
這樣你在排障和治理時，才能分清：
- 哪些必須保證低時延
- 哪些適合本地緩存優(yōu)化
- 哪些就算慢一點也不至于影響主鏈路
---
## 八、治理建議：別只會換個 DNS 試試
“換一個 DNS 試試”當(dāng)然是有用的，但它只是應(yīng)急動作，不是治理閉環(huán)。
更穩(wěn)的做法通常包括：
### 1）建立多上游 DNS 質(zhì)量對比
不要把所有希望押在一個解析器上。
至少要能持續(xù)比較：
- 不同上游的成功率
- 不同上游的時延分布
- 不同時間段的穩(wěn)定性
### 2）對關(guān)鍵域名做專項觀測
核心業(yè)務(wù)依賴的域名應(yīng)該單獨看，而不是混在全體 DNS 指標(biāo)里平均掉。
因為平均值最擅長掩蓋問題。
### 3）優(yōu)化緩存策略
適當(dāng)提升本地緩存命中率，可以非常有效地減少：
- 高峰期重復(fù)查詢
- 對上游質(zhì)量波動的敏感性
- 外部依賴帶來的不確定性
當(dāng)然，緩存策略不能瞎拉長，要結(jié)合業(yè)務(wù)變更頻率與 TTL 設(shè)計。
### 4）把 DNS 證據(jù)鏈接入日常排障體系
真正高效的排障，不是等用戶截圖說“慢”，而是系統(tǒng)已經(jīng)能告訴你：
- 哪個域名慢
- 從什么時候開始慢
- 慢在哪個遞歸節(jié)點
- 是否伴隨重復(fù)查詢、超時或 TCP fallback 上升
做到這一步，網(wǎng)絡(luò)團隊和應(yīng)用團隊之間的溝通成本會下降很多。
---
## 九、最后說句實話：很多“應(yīng)用體驗差”，根子都不在應(yīng)用
一線排障最容易出現(xiàn)的誤區(qū)，就是誰離用戶最近，誰先背鍋。
用戶看到網(wǎng)頁慢，自然罵應(yīng)用；應(yīng)用看自己 CPU 不高，就懷疑網(wǎng)絡(luò)；網(wǎng)絡(luò)一看鏈路沒斷，又懷疑用戶電腦。
最后所有人圍著“慢”這個字轉(zhuǎn)，卻沒人把它拆成：
- 解析慢
- 建連慢
- 服務(wù)端處理慢
- 返回內(nèi)容慢
而 DNS 慢查詢恰恰就是那種：
**不夠致命，但非常影響體驗；不夠顯眼，但極其高頻；不夠“爆炸”，卻最消耗團隊信任。**
所以，如果你的系統(tǒng)最近總出現(xiàn)“偶發(fā)卡頓、首開慢、刷新就好”的詭異現(xiàn)象，不妨先把 DNS 拉出來認(rèn)真審一遍。
很多問題，真不是應(yīng)用寫得爛，而是請求還沒出發(fā)，時間就已經(jīng)花掉了。
---
## 結(jié)語
如果你的團隊正在做網(wǎng)絡(luò)故障排查、流量分析、DNS 性能治理或全流量可觀測建設(shè)，建議盡量別只依賴“監(jiān)控全綠”和人工臨時抓包這兩板斧。更有效的方式，是把**DNS 查詢質(zhì)量、TCP 會話質(zhì)量、全流量回溯與異常證據(jù)鏈**放進同一套診斷視角里。
像 AnaTraf 這類網(wǎng)絡(luò)流量分析與診斷平臺，適合用來持續(xù)觀察 DNS 慢查詢、TCP 重傳、連接質(zhì)量抖動和全流量回溯證據(jù)，幫助團隊把“偶發(fā)卡頓”從口水仗變成可驗證、可定位、可治理的問題。了解更多可參考：www.anatraf.com
