騰訊雲帳號認證充值 騰訊雲國際站雲伺服器內網 DNS 解析失敗排查

第一章：問題現象與影響範圍

內網 DNS 解析失敗，對於雲上業務的影響往往是「看似小問題、實則全鏈路故障」。常見現象包括：服務端無法通過域名連到內網對端、容器內解析域名失敗、某些節點可以解析、另一些節點卻不行，或出現解析超時而非立即報錯。由此導致的直接後果是：連線建立失敗、服務啟動卡在依賴解析、緩存失效後整體請求波動，甚至觸發重試風暴與熔斷。

在騰訊雲國際站的場景中，你通常會先確認：失敗的是「所有內網域名」還是「特定域名」；失敗的是「某一批機器」還是「全部機器」。這一步看似簡單，卻能決定你後續排查的方向。若只有少量機器失敗，往往指向機器端 DNS 設定、DHCP 下發異常或該機器所在子網路策略差異；若全部機器都失敗，則更可能是 VPC 內網解析服務、路由與安全策略、或網段/子網路配置。

先把現象「量化」

排查不是憑感覺，而是先把現象記錄清楚。請在出問題的節點上整理以下信息：

• 解析的是哪個域名？是全域名（如 service.internal）還是短域名（如 service）？
• 錯誤訊息是什麼？例如 NXDOMAIN（不存在）、SERVFAIL（伺服器失敗）、還是 i/o timeout（逾時）？
• 騰訊雲帳號認證充值 解析工具與版本：dig、nslookup、或系統解析（例如 curl 的行為）。
• 是否只影響 DNS，而網路連通性正常：例如可以 ping 目標 IP、但解析域名不行。

這些細節能幫你判斷是「DNS 服務不可達」還是「DNS 服務可達但資料不存在或策略不允許」。

第二章：快速定位——到底是「不可達」還是「解析錯」

DNS 解析失敗常見分兩類：一類是 DNS 查詢到不了解析器（逾時、連線失敗），另一類是查詢到了解析器，但返回結果不符合預期（NXDOMAIN、No such host）。把它們區分清楚，是排查最省時間的策略。

檢查解析器是否可連通

在故障機器上查看解析器 IP。不同系統略有差異，但核心是看 /etc/resolv.conf（Linux）或網路配置頁面（Windows）。然後用連通性測試確認解析器是否可達。

Linux 常用：

• 查看配置：cat /etc/resolv.conf
• 查詢指定 DNS：dig @<dns_ip> service.internal
• 快速看逾時：dig +time=2 +tries=1 @<dns_ip> service.internal

如果對 @dns_ip 直接查詢都超時，幾乎可以判斷「DNS 服務不可達」：要麼路由不通、要麼安全策略阻斷、要麼解析器 IP 不是你以為的那個。

騰訊雲帳號認證充值 判斷錯誤回覆型別

若 dig 能快速返回，但狀態顯示 NXDOMAIN 或 SERVFAIL，就要往「解析邏輯」與「DNS 資料是否存在/是否符合作用域」方向看。尤其注意：很多場景因為錯用短域名或 search domain 不一致，導致其實查的是另一個 FQDN。

建議你同時測試：

• 用 FQDN 直接查：dig service.internal.<你的zone> @<dns_ip>
• 騰訊雲帳號認證充值 用短名查（看是否依賴 search）：dig service @<dns_ip>
• 比較兩次回覆差異

第三章：VPC 與子網路——路由與網段是第一道門檻

很多 DNS 失敗，其實不是 DNS 本身壞了，而是「查詢封包走不到」。在騰訊雲國際站的 VPC 架構裡，子網路、路由表、以及是否跨網段，都會影響解析器是否能被連到。

確認問題節點與解析器在同一個可路由域

你需要確認故障節點的 IP 所在子網路，解析器（內網 DNS 服務）的 IP 所在位置，以及兩者是否存在可通行的路由。排查可以用兩個角度：網路拓撲與實際連通性。

• 從機器端測試到解析器 IP 的連通性（如 TCP/UDP 53）。
• 在雲端控制台核對 VPC 的路由表規則（尤其是到目標網段的下一跳）。

若你看到「解析器 IP 在某個網段，但故障機器所在子網路路由表沒有指向可達下一跳」，那 DNS 查詢就會逾時。這種情況在新增子網或調整路由後最常見。

跨子網/跨區時的注意點

如果你把解析器部署在另一個子網，或網段之間需要透過特定路由或網關才能通達，那麼你要確保：路由存在、同時防火牆/安全策略允許 UDP 53 或 TCP 53。更常見的失誤是「路由看似能達，但安全策略沒有放行 DNS 端口」，導致表面上仍表現為超時。

第四章：機器端 DNS 配置——最容易被忽略的變更點

內網 DNS 解析失敗，經常出在機器端：解析器 IP 設錯、search domain 不匹配、或 resolv.conf 被系統服務覆蓋。這些問題不一定在你部署當下發生，有時是在重啟、擴容、或鏡像更新後才露出。

騰訊雲帳號認證充值 核對 resolv.conf 與優先級

在 Linux 節點檢查：

• cat /etc/resolv.conf：看 nameserver 是否為你期望的內網 DNS。
• 騰訊雲帳號認證充值 看是否配置了多個 nameserver，其中第一個是不可達的，造成查詢延遲或間歇性成功。
• 看 search domain 是否正確。短域名查詢會依賴它。

若你發現 nameserver 指向外網 DNS 或錯誤的內網 DNS IP，那就會導致內網域名解析失敗，尤其在沒有外網互通的情況下。

DHCP 下發與自動覆寫

有些系統使用 DHCP 取得 DNS，當 DHCP 移除了或改寫了 DNS 參數後，機器就會解析錯誤。排查上你可以記錄「故障機器重啟後的 resolv.conf 是否有變化」。若你有配置管理工具（Ansible、Terraform + init script、或啟動腳本），也要檢查它們是否在啟動時覆蓋 resolv.conf。

簡化處理方式是：明確固定 nameserver，或使用雲端推薦的 DNS 配置方式，確保不被覆寫。

DNS 緩存與時間差

當你修改 DNS 相關配置後，很多人忽略 DNS 緩存。若節點上有 systemd-resolved、dnsmasq、或應用程式內建快取，就可能出現「改了但仍失敗」的錯覺。建議在排查過程中：

• 騰訊雲帳號認證充值 在改動 DNS 端後重啟解析服務或清理緩存。
• 用直接的 dig @dns_ip 查詢驗證，不依賴系統快取。

第五章：內網解析服務健康狀態——服務端因素要納入

即使機器端配置正確，DNS 服務本身也可能因配置錯誤、資源不足或服務未就緒而異常。你需要從「解析結果」與「查詢成功率」兩方面判斷。

觀察返回碼與延遲

你可以用 dig 針對不同域名多次查詢，觀察：

• 返回碼是否穩定（持續 NXDOMAIN 或偶發 SERVFAIL）。
• 延遲是否呈現明顯波動。
• 是否只影響某些 zone 或特定域名（例如只解析 service.internal，其他 domain 正常）。

若你看到「所有域名都逾時」，更偏向連通性或策略；若部分域名成功、部分失敗，要檢查 zone 與記錄是否正確，或解析服務是否沒有載入對應的資料。

解析器是否被限流或限制來源

部分安全設計會限制 DNS 解析服務只接受特定來源網段。若你近期調整了 VPC 網段、子網擴容或新增機器，新的 IP 可能不在允許列表內，導致解析服務直接丟棄查詢。這類問題通常在安全組/防火牆配置上能對得起來，但也可能存在服務端白名單或策略。

因此，排查時要把「解析服務允許的來源網段」納入核對。

第六章：安全組與防火牆——UDP 53 不放行就等於沒網

DNS 依賴 UDP 53（必要時也會使用 TCP 53）。很多團隊在設定安全策略時只考慮業務端口，卻忘了放行 DNS，或只放行 TCP/不放 UDP，導致特定解析行為失敗。

安全組/ACL 的方向性要看清

你需要檢查兩個方向：

• 故障節點到解析器：出方向是否允許 UDP 53（以及 TCP 53）。
• 解析器回應到故障節點：入方向是否允許對應流量。

如果安全策略只從一側放行，連通性仍可能失敗。尤其在雲上安全組模型下，入出方向都有影響。

本地防火牆與容器網路

除了雲端安全組，機器上還可能有防火牆（如 ufw、iptables、firewalld）。當你使用容器或 Kubernetes 時，容器網路模型還會引入額外的 NAT 與轉發規則：容器內部的 DNS 查詢可能被 host 的規則阻斷。

排查建議：

• 在 host 上測試到解析器 IP 的 UDP 53 連通性。
• 在容器內測試解析行為是否一致。若容器失敗而 host 成功，優先檢查容器 DNS 設置與網路規則。

第七章：域名與記錄——不是所有失敗都是網路問題

當你確認「DNS 服務可達」後，才算真正進入記錄層的排查。內網域名對應的 A 記錄、CNAME、或自訂 zone 可能存在多種來源：雲上的內網 DNS 服務、你自建的 authoritative DNS、或某種服務註冊機制。

先確認查詢的 FQDN 是否正確

很多失敗來自「短名推導錯了」。例如系統 search domain 為 svc.cluster.local，你以為解析的是 db.internal，實際卻查了 db.internal.svc.cluster.local。若你的 zone 不是這樣，就會得到 NXDOMAIN。

因此排查流程要養成習慣：對關鍵域名用 dig 明確寫出 FQDN，避免短名推導誤導。

記錄是否存在、TTL 是否異常

當你更新內網服務 IP 或重建實例時，如果記錄同步延遲或 TTL 設置過長，你可能遇到一段時間內解析結果不對。這種情況通常不是永久失敗，而是「某些時間點」解析會恢復。

你可以：

• 對同一域名用 dig 多次查詢，觀察結果是否一致。
• 檢查記錄更新流程是否覆蓋到正確的 zone。

第八章：一套可照做的排查流程（建議照順序走）

以下是一套從外到內、從快到慢的流程。你可以把它當成 SOP，確保每次都能在合理時間內定位原因。

步驟 1：確認失敗類型

在故障機器上分別用：

• dig @<dns_ip> <FQDN>
• dig +time=2 +tries=1 @<dns_ip> <FQDN>

判斷是逾時還是返回碼異常。

步驟 2：核對機器端 resolv.conf

• 確認 nameserver 是正確的內網 DNS IP。
• 騰訊雲帳號認證充值 確認 search domain 不會導致錯查詢。
• 必要時重啟解析服務或重登。

步驟 3：測通到 DNS 端口

用連通性測試確認 UDP 53 / TCP 53 是否可達。若不可達，回到雲端路由與安全策略。

步驟 4：核對 VPC/子網路由

• 確保故障節點所在子網到 DNS 服務所在網段有路由。
• 若跨子網或跨網段，核對下一跳與網關設定。

步驟 5：核對安全組與防火牆（雲端 + 機器）

• 放行 UDP 53（必要時 TCP 53）。
• 核對出入方向與來源範圍。
• 檢查 host 防火牆、容器網路設定。

步驟 6：核對 zone/記錄

• 用 FQDN 查詢，排除短名推導問題。
• 檢查 A/CNAME 記錄是否存在、指向是否正確。
• 若最近有部署變更，核對同步延遲與 TTL。

步驟 7：驗證與觀察恢復穩定性

修復後不要只測一次。建議：

• 對多台節點重複查詢。
• 監測一段時間的解析成功率與延遲。

第九章：常見原因清單（對照排查最省力）

• 解析器 IP 錯誤：resolv.conf 指向外網 DNS 或錯誤的內網 DNS。
• DHCP 覆寫：重啟後 DNS 回到錯誤值，導致問題反覆。
• 安全組未放行 UDP 53：只放 TCP 或只放業務端口，導致 DNS 查詢逾時。
• 路由表缺少到 DNS 網段的路由：新增子網/調整網段後遺留配置。
• 騰訊雲帳號認證充值 來源網段限制不一致：解析服務僅允許部分來源 IP/網段，新增節點被拒。
• 短域名推導錯誤：search domain 導致查到不存在的 FQDN（NXDOMAIN）。
• 記錄未更新或 TTL 太長：服務 IP 變了但記錄同步或過期時間未到。
• 容器 DNS 配置與 host 不一致：容器使用不同的 resolver 或被網路策略限制。

第十章：修復建議與預防機制

排查能解決當下，但更重要的是建立預防，避免下一次擴容或變更再次觸發 DNS 事故。

修復建議

• 把 DNS 配置變更納入版本化管理：明確 nameserver、search domain 與解析器行為。
• 在雲端安全策略中把 UDP 53 作為「必選項」：尤其針對需要內網解析的子網或安全組。
• 路由變更後立刻做回歸測試：對關鍵內網域名做 dig，並用應用層連線驗證。

預防機制

• 建立探測告警：定時對內網域名做解析測試，收集成功率與延遲。
• 標準化基礎鏡像：避免每次部署都靠人工修 resolv.conf 或臨時腳本。
• 變更前後對比：任何調整路由、子網、安全組時，都用同一套指令記錄基準值。
• 容器場景單獨驗證：主機通不代表容器通，兩者都要測。

結語：把 DNS 當作「網路健康指標」而不是孤立問題

騰訊雲國際站的內網 DNS 解析失敗，表面是域名解析問題，實質往往指向網路可達性、安全策略、配置一致性與記錄正確性。最有效的做法不是盲目調整 DNS 參數，而是先用 dig 與連通性測試把問題分型，再按 VPC/路由—安全策略—機器端配置—zone 記錄的順序逐步排除。當你把這套流程固定下來，未來遇到同類問題就能更快定位，更少依賴運氣。

如果你願意把實際的域名、解析器 IP、以及 dig 的返回碼貼出來（不需包含敏感資訊），就可以進一步把排查範圍縮到最小，直接對應到下一步該看哪個配置點。