DNS傳播檢查工具(免費・全球DNS伺服器一鍵查詢)

免費同時向Google、Cloudflare等全球多個公共DNS解析器查詢域名的DNS記錄,一覽對比域名伺服器變更後是否已在全球傳播完成。

確認 DNS 的變更是否已散布到世界各地

本工具把某個網域的 DNS 記錄一併投向世界各地的公開解析器——Google、Cloudflare 等等——再把回來的答案並排擺出。剛挪過名稱伺服器,或剛改寫過 A 記錄時,變更走到了哪一步,一眼便知。

「傳播」這個詞,說實話有幾分誤導。 DNS 並非一套把變更推送到各地的機制。各解析器不過是把先前的答案存在快取裡,直到快取過期之前,一直回以舊值罷了。 因此等候的長短,取決於變更之前生效的那個 TTL。 事後再把 TTL 調短,對已經發出去的快取毫無作用。正因如此,若有遷移在即,通行的做法便是提前數日把 TTL 調低。 此處答案彼此不一,並非出了差錯,而是快取尚未到期。

使用方法

  1. 給出網域與記錄類型 選定您要查的類型:A、MX、TXT 等等。
  2. 比對各解析器的答案 新舊取值雜陳,便說明切換仍在途中。
  3. 弄清哪些地區尚不一致 可以看出哪些解析器仍持舊值。
  4. 把 TTL 等滿 在變更之前生效的那個 TTL 走完之前,除了等候別無他法。

用好本工具的小技巧

  • 剛修改域名伺服器或A記錄後,部分解析器可能會在TTL(快取有效期)到期前仍返回舊值,這是正常現象而非故障。
  • 如果各解析器返回的值不一致,請先檢查TTL設定。TTL越長(例如24小時),全網傳播完成所需的時間也越長。
  • 本工具不僅可用於A記錄,也可用於檢查MX、TXT(如SPF/DKIM)等記錄的變更,修改郵件相關設定後務必也檢查TXT記錄。
  • 返回"NXDOMAIN"表示該域名本身不存在,請檢查是否輸入有誤或域名已過期。
  • 本工具查詢的解析器並不限於本地,也涵蓋海外主要公共解析器,因此也可用於瞭解面向海外使用者的傳播情況。

這些情境會用到

剛挪過名稱伺服器時

可確認轉移是否已在世界範圍內生效。

切換伺服器時

可確認那個名稱如今是否指向了新位址。

查究為何只有自己打不開

若只有自己這邊的解析器持著舊值,與別處的答案一比便可判明。

籌劃一次切換

可由等候的時長倒推,定下何時把 TTL 調低。

DNS 傳播的術語

解析器
代使用者去查 DNS 的伺服器。Google 的 8.8.8.8 與 Cloudflare 的 1.1.1.1 最為人知。
TTL
一個答案可被快取的秒數。決定等候長短的,是變更之前而非之後的那個 TTL。
否定快取
「並無此記錄」這樣的答案同樣會被快取。新建的記錄起初看不見,有時便是因為它。
權威伺服器
持有某網域正確答案的伺服器。各解析器向它發問以取得答案。
名稱伺服器
某網域所委任的權威伺服器。轉移網域,便是換掉它。
傳播
指一項變更抵達各地解析器的慣用語。其實那並非分發,而是快取的過期。

常見問題

一般在數分鐘到48小時之間,具體取決於記錄的TTL設定及各ISP的快取行為。提前將TTL設定得更短,可以讓下次變更時的傳播速度更快。

如果是剛變更之後,這屬於正常現象。每個解析器快取舊值的時長取決於TTL,過一段時間再次檢查,各解析器的結果會逐漸趨於一致。

可能是域名輸入有誤、域名已過期,或域名伺服器的設定本身尚未生效。請通過WHOIS資訊或註冊商的管理後臺確認域名當前狀態。

您電腦或所在ISP的DNS快取中,可能保留著與本工具查詢的公共解析器不同時間點快取下來的值。建議同時嘗試清空作業系統層面的DNS快取。

因為TTL可以按記錄型別分別設定,如果MX記錄的TTL設定得比其他記錄更長,其傳播完成所需的時間自然也會更久。
工具君

閒話 ― DNS的"傳播"其實並非由誰主動推送

DNS自1983年設計之初,就建立在"分層快取"的前提之上。如果全球每一臺解析器每次查詢都要一路追溯到根伺服器,系統性能將難以為繼,因此每個解析器都會將獲得的答案在TTL(Time To Live,存活時間)規定的期限內儲存在本地快取中,相同問題再次到來時便可直接從快取中即時應答。這一機制讓DNS變得高速,但也帶來了一個副作用:變更傳遍全世界之前會存在延遲。

這種延遲俗稱"DNS傳播(DNS Propagation)",但實際上並非有人主動將資訊廣播到全世界。真實情況是:各解析器持有的舊快取會隨著TTL到期而依次失效,等到下一次有人查詢時才會重新獲取新值——這是一種被動的、逐步更替的過程。如果TTL設定為24小時,理論上變更後的24小時內,某些解析器仍可能持續返回舊值。

本工具所使用的DoH(DNS over HTTPS)技術,最初大約在2018年前後由Mozilla和Google出於隱私考量而推廣普及——目的是不讓ISP或網路路徑上的第三方窺探DNS查詢的內容。將DNS查詢放入HTTPS中傳輸的方式,已於2018年10月作為RFC 8484完成標準化。不過,RFC標準化的只是直接傳送DNS二進位封包(wire format,application/dns-message)的格式;本工具所讀取的易讀JSON格式回應(application/dns-json),是Google率先自行公開的API,後來被Cloudflare等服務商作為相容格式採用。由於它並非IETF標準,各解析器之間仍存在細微差異,例如TXT紀錄是否用引號括起來。