如果 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) 回報任何類似問題，請向我們回報，包括報表中的指令輸出及診斷頁面文字或螢幕截圖。