網域疑難排解

如果 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 6781StackExchange)
  • 從 RSA 簽名切換為較小的 ECDSA 簽名 (RFC 8624)

另請參閱步驟 2 中工具回報的任何其他 DNSSEC 問題。 例如,錯誤的 NSEC 或 NSEC3 存在不存在記錄,可驗證沒有子網域 (PowerDNS 中儲存在區域資料庫中的可用區可能存在這些記錄) 或過期的 RRSIG 簽名 (具有手動設定的簽署程序)。

步驟 2:檢查權威名稱伺服器

已封存的 DNSViz 頁面

如果 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 的名稱伺服器 AAAAA 記錄,查看名稱伺服器是否發生問題。

步驟 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 傳輸功能。
在每個名稱伺服器重複。
以上範例有兩個權威名稱伺服器 (ns1ns2),有些問題是由不同伺服器傳回不同的答案造成。在所有權威的伺服器重複執行相同的查詢,藉此檢查這些查詢是否一致提供答案。

如果所有查詢都'回應很小 (1400 個位元組以下)、快速 (建議 500 毫秒或更快) 和可靠 (透過 TCP 和 UDP 一致執行),則回應大小無關緊要。請詳閱其他疑難排解部分。即使您的回應速度較快,但地理位置距離較短的查詢速度可能較慢。

如果有任何檢查失敗 (大型?速度慢、不可靠?) 主要操作方法是 A) 確保伺服器在回應回應超過要求的 UDP 緩衝區空間時回應 UDP 截斷,以及 B) 可以處理後續的 TCP 查詢重試。以下幾項工具可協助您診斷 DNS 穩定性問題:

如果這些工具發現任何錯誤或警告,請妥善解決。 並詳閱這個網站的所有其他疑難排解操作說明。

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