如果 Google 公用 DNS 無法解析網域,通常是因為該網域或權威名稱伺服器發生問題。這些步驟有助於判斷問題所在,方便網域管理員自行解決。
開始執行這些步驟前,請先按照一般疑難排解頁面的說明檢查 dns.google 網域,可能會參照以下特定的診斷步驟。否則,請嘗試所有的步驟,直到找出原因。
步驟 1:檢查 DNSSEC 驗證問題
如果網域的 dns.google 網路查詢顯示 "Status": 2
(SERVFAIL) 且沒有 DNSSEC 的查詢成功,則網域名稱的名稱伺服器或頂層網域 (TLD) 註冊管理機構可能會發生 DNSSSEC 問題 (發布網域的 DNSSEC 驗證會發布 DS
記錄)。
- 註冊商或 DNS 服務的變更
網域從支援 DNSSEC 的註冊商或 DNS 服務切換為不支援時,可能會發生 DNSSEC 問題。如果先前的服務在 TLD 註冊管理平台中淘汰了過時的
DS
記錄,且新的服務未在 TLD 註冊管理資料庫中比對相符的DS
記錄,驗證 Google 公用 DNS 等解析器就無法解析該網域。如果發生這種情況,請要求您的網域註冊商從 TLD 註冊資料庫中移除過時的 DS 記錄。
- DNSSEC 回應過大
DNSSEC 問題的另一個可能原因,在於 DNSSEC 回應過大,無法在單一 IP 封包中容納,因而造成可能遭到捨棄的片段回應。如果 DNSViz 顯示「在 UDP 酬載大小縮減前未收到回應」,即代表錯誤,錯誤通知可能會導致 DNSSEC 失敗。 您可以透過下列一或多項動作來縮減回應大小:
- 設定具公信力的名稱伺服器以「最小回應」
- 將使用中的
DNSKEY
記錄數量減少為二或三則 - 使用 1280 或 2048 位元
DNSKEY
記錄 (RFC 6781、StackExchange) - 從 RSA 簽名切換為較小的 ECDSA 簽名 (RFC 8624)
另請參閱步驟 2 中工具回報的任何其他 DNSSEC 問題。 例如,錯誤的 NSEC 或 NSEC3 存在不存在記錄,可驗證沒有子網域 (PowerDNS 中儲存在區域資料庫中的可用區可能存在這些記錄) 或過期的 RRSIG 簽名 (具有手動設定的簽署程序)。
步驟 2:檢查權威名稱伺服器
如果 Google 公用 DNS (或任何開放式解析器) 無法順利解析網域,DNSViz 會顯示導致網域的網域和名稱伺服器問題。前往 DNSViz 網頁,然後輸入有問題的網域名稱。 如果 DNSViz 沒有歷來資料,或是只有超過一天的資料 (例如網頁顯示的資訊),請按一下大型的「Analyze」(分析) 按鈕,在下方顯示較小的「分析」按鈕 (如果尚未顯示的話),然後按一下該按鈕。分析完成後,按一下「繼續」即可查看結果。 按一下左側欄中的紅色錯誤和黃色警告即可顯示詳細資料,或按住圖表中的指標,即可在結構定義中顯示彈出式視窗。
如果先前的診斷顯示該網域可能存在 DNSSEC 問題,請前往「DNSSEC 分析工具」頁面輸入網域名稱。如果分析器回報 DNSSEC 錯誤或警告,請將遊標懸停在紅色的「⊗」
intoDNS 網頁會針對在主網頁上輸入的網域回報非 DNSSEC 問題,並提供修正問題的建議。
網域管理員可修正這些工具的大部分錯誤,因為這不僅會導致 Google 公用 DNS 發生問題,也可能造成其他解析器發生問題。
步驟 3:檢查委派問題
Google 公用 DNS 是「以父項為中心」的解析器,其只會使用上層網域參照連結網址傳回的名稱伺服器。如果 TLD 中的名稱伺服器名稱和黏附地址過時或造成,可能會導致委派問題。
如果 DNSViz 或 inDNS 回報名稱伺服器在 TLD 中委派的名稱伺服器與子項網域本身的名稱伺服器不一致,您可能需要先解決這類問題,Google 公用 DNS 才能解析該網域。 如果這些工具回報已註冊的網域不存在 (NXDOMAIN),請確認該網域是否因任何原因而未過期或處於註冊保留狀態。
如果無法順利解析網域名稱的名稱伺服器名稱,就會造成委派問題。請前往 dns.google 的名稱伺服器 A
和 AAAA
記錄,查看名稱伺服器是否發生問題。
步驟 4:檢查是否有大型回應
DNS 會使用 UDP 傳輸大部分的流量。大型 UDP 資料圖表會受到不可靠的交付情形和片段化 UDP 緩衝區影響。這是 2020 年 DNS 旗標日的焦點,旨在改善全球 DNS 的穩定性。Google 公用 DNS 服務已參與這項計畫,並會限制透過 UDP 接受的 UDP 回應大小。嘗試使用自己的指令提示或 Google Cloud Shell 來查詢下列內容:
$ dig +short example.com NS ns1.example.com ns2.example.com $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com A ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com TXT ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com DNSKEY ... $ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com com DNSKEY ...
各種記錄類型的查詢如下:
+dnssec
- 啟用 DNSSEC,尤其是在 DNSSEC 驗證可用時傳回必要的記錄。可大幅擴充結果的大小。這個模式會模擬 Google 公用 DNS 的運作行為。
+bufsize=1400
- 限制允許的 UDP 緩衝區大小。在 2020 年 DNS 旗標日之後,這項功能會模擬 Google 公用 DNS 的行為。
+timeout=1
- 將逾時設定為一秒,這個模式會模擬 Google 公用 DNS 的運作行為。
@ns1.example.com
- 要查詢的權威伺服器,請保留
@
符號,但替換為自己網域的權威伺服器,如第一個指令所示。
觀察輸出結果;您是否看見類似以下的行:
;; Truncated, retrying in TCP mode.
- 這表示回應大於要求的 UDP 緩衝區空間大小,因此會遭到截斷,並回應用戶端切換至 TCP。權威伺服器應可處理 TCP 通訊埠 53 的 DNS 流量。(請參閱 RFC 7766,其中要求「實作」不得同時支援 UDP 和 TCP 傳輸)。
;; MSG SIZE rcvd: 2198
- 對於超過 1400 的數字?這也代表了大型回應。
;; Query time: 727 msec
- 任何超過 500 的數字嗎?Google 公用 DNS 可能會捨棄緩慢的回應 (尤其是近 1 秒以上的回應)。尤其是在 UDP 嘗試後,透過 TCP 嘗試進行一段時間後,會發生這種情況。伺服器與用戶端的地理位置可能會影響延遲時間。
;; connection timed out; no servers could be reached
- 尤其是在部分查詢中,伺服器會導致無法及時回答 DNS 查詢的問題。
請嘗試以下查詢變化版本:
- 新增
+tcp
參數。 - 這會強制
dig
立即使用 TCP,而您可以檢查權威伺服器是否直接透過這種方式處理 TCP 查詢。 - 移除
+bufsize=1400
參數。 - 這樣可以還原
dig
的預設行為 (bufsize 4096)。如果查詢作業在這項設定失敗時無法運作,這表示您的伺服器並未妥善處理 TCP 容錯移轉。有時必須使用 UDP 來傳送大型回應。最佳做法是支援 DNS 的 TCP 傳輸功能。 - 在每個名稱伺服器重複。
- 以上範例有兩個權威名稱伺服器 (
ns1
和ns2
),有些問題是由不同伺服器傳回不同的答案造成。在所有權威的伺服器重複執行相同的查詢,藉此檢查這些查詢是否一致提供答案。
如果所有查詢都'回應很小 (1400 個位元組以下)、快速 (建議 500 毫秒或更快) 和可靠 (透過 TCP 和 UDP 一致執行),則回應大小無關緊要。請詳閱其他疑難排解部分。即使您的回應速度較快,但地理位置距離較短的查詢速度可能較慢。
如果有任何檢查失敗 (大型?速度慢、不可靠?) 主要操作方法是 A) 確保伺服器在回應回應超過要求的 UDP 緩衝區空間時回應 UDP 截斷,以及 B) 可以處理後續的 TCP 查詢重試。以下幾項工具可協助您診斷 DNS 穩定性問題:
- DNSViz
- DNSSEC 偵錯工具
- EDNS 法規遵循測試工具
- DNS 檢查工具:請務必取消勾選「CDSEC」 (停用檢查 DNSSEC) 方塊
如果這些工具發現任何錯誤或警告,請妥善解決。 並詳閱這個網站的所有其他疑難排解操作說明。
步驟 5:檢查其他公開解析器是否能解析網域
如果完成上述步驟後,都無法解決問題,請在命令提示字元中執行下列指令,並將 example.test.
替換為有爭議的網域 (並保留結尾的點):
Windows
nslookup example.test. resolver1.opendns.com.
nslookup example.test. dns.quad9.net.
nslookup example.test. one.one.one.one.
macOS 或 Linux
dig example.test. '@resolver1.opendns.com.'
dig example.test. '@dns.quad9.net.'
dig example.test. '@one.one.one.one.'
這些指令使用 OpenDNS、Quad9 和 Cloudflare 1.1.1.1 的 DNS 解析器。如果您同時收到這兩個問題,以及 Google 公用 DNS 發生問題,則問題可能出在網域或其名稱伺服器。
如果您在多個公開解析器取得成功結果,則 Google 公用 DNS 可能發生問題。 如果 Issue Tracker 上並未針對網域 (或其 TLD) 回報任何類似問題,請向我們回報,包括報表中的指令輸出及診斷頁面文字或螢幕截圖。