DNS 查詢出現 Server Failure／SERVFAIL：如何檢查轉寄站、防火牆 53 連接埠與快取？
SERVFAIL 表示 DNS 伺服器無法完成查詢。應從權威區域、轉寄站、TCP/UDP 53、DNSSEC、超時和快取順序疑難排解。
先控制風險，再實施變更建議先在測試環境或單一對象上驗證，保存設定、日誌和可復原備份。涉及生產切換、批次策略、資料庫修復或儲存重建時，應設定維護時段和明確復原條件。
1. 結論與適用範圍
SERVFAIL 不是“網網域名稱稱不存在”，而是解析流程中的伺服器失敗。用戶端、快取 DNS、上游轉寄站和權威 DNS 任一環節超時、拒絕或返回無效資料，都可能產生相同結果，因此必須比較不同伺服器和查詢類型。
該問題涉及 DNS、網絡、VPN、防火牆和受控存取。應從查詢路徑、連接埠、回程和日誌分層驗證。
2. 需要優先關注的風險信號
- 同一網網域名稱稱時通時不通，清快取後短暫復原。
- A 記錄可查但 CNAME、AAAA 或較大響應失敗，或不同 DNS 伺服器結果不一致。
3. 遷移或處理前的檢查清單
- 使用 Resolve-DnsName 或 nslookup 分別指定兩台內聯網 DNS 和上游 DNS。
- 檢查條件式轉寄站目標是否為空、地址錯誤、順序異常或已失效。
- 在防火牆確認 DNS 伺服器到上游的 UDP 53 和 TCP 53 以及回程。
- 查看 DNS Server 事件、調試日誌、遞歸超時、DNSSEC 和負快取。
唯讀檢查與驗證範例
Resolve-DnsName vendor.example -Type A -Server 192.0.2.53
Resolve-DnsName vendor.example -Type CNAME -Server 192.0.2.53
Test-NetConnection 203.0.113.53 -Port 53
Clear-DnsServerCache -Forcecorp.example、192.0.2.0/24 與 203.0.113.0/24 均為檔案範例。只有在確認實際環境參數後，才能取代為實際值。
4. 推薦實施步驟
- 先修正錯誤轉寄站和防火牆策略，再在兩台 DNS 清理快取。
- 不要在用戶端繞過內聯網 DNS 作為長期方案。
- 對單個供應商域建立條件式轉寄站並記錄上游，避免影響所有遞歸查詢。
- 若權威 DNS 本身異常，保留查詢證據並聯繫網網域名稱稱服務方。
遙距還是現場處理？日誌、設定和少量對象通常可先遙距評估；涉及物理伺服器、儲存、機房供電、批次切換或復原演練時，應安排受控現場維護時段。浙江、上海、江蘇可根據項目情況上門，其他地區可遙距協助。
5. 驗證、復原與常見誤區
- 連續多次查詢 A、AAAA、CNAME 和 SOA 結果一致。
- 兩台內聯網 DNS 在主備切換和快取冷熱狀態下均成功。
- 日誌中沒有持續超時、拒絕或 TCP 復原失敗。
常見錯誤做法
- 只測試 ping 或網頁。
- 只清用戶端快取，不處理伺服器快取和錯誤轉寄站。
- 認為放行 UDP 53 就覆蓋全部 DNS。
常見問題
SERVFAIL 是否等於網網域名稱稱不存在？
不是。不存在通常返回 NXDOMAIN，SERVFAIL 表示伺服器未能完成解析。
兩台 DNS 都要清快取嗎？
需要。用戶端可能使用任意一台，設定和快取都應分別處理。