驗證全球 DNS 記錄同步
DNS 傳播收斂估算工具
根據您之前的區域 TTL,估算下游遞迴解析器與訪客裝置快取過期記錄的時間。
透過安全的 DNS-over-HTTPS (DoH) 查詢 Google、Cloudflare、NextDNS、AdGuard、Alibaba 及 DNS.SB 公共 Anycast 解析器。
全球 DNS 傳播的工作原理
當您在網域註冊商或權威名稱伺服器上新增或更新 DNS 記錄時,該更新會立即寫入您的主要區域檔案。然而,網際網路服務供應商 (ISP)、行動電信網路和公共 Anycast 網路中的遞迴 DNS 解析器並不會持續輪詢名稱伺服器。相反地,它們會在記錄的 TTL (生存時間) 值規定的時間內快取現有記錄。
此檢查器會直接針對部位於北美、歐洲和亞太地區的 8 個主要全球 Anycast 遞迴網路執行並行 DNS-over-HTTPS (DoH) 查詢。解析器之間的結果不一致表明區域更新正在積極傳播,這能讓網路工程師在宣布重大網路切換前驗證收斂情況。
全球 Anycast DNS 解析器基準測試矩陣
| 解析器網路 | 主要 Anycast IP | 路由架構 | EDNS 客戶端子網 (ECS) | 典型全球延遲 |
|---|---|---|---|---|
| Google Public DNS | 8.8.8.8 | 全球 BGP Anycast (100+ 個 POP) | 支援 (已啟用 ECS) | 10 - 45 ms |
| Cloudflare Standard | 1.1.1.1 | 全球 BGP Anycast (300+ 個城市) | 已停用 (隱私優先) | 5 - 25 ms |
| Cloudflare Security | 1.1.1.2 | 全球安全性 Anycast (攔截惡意軟體) | 已停用 | 10 - 30 ms |
| NextDNS Anycast | 45.90.28.0 | 全球超低延遲 Anycast | 支援 | 12 - 40 ms |
| AdGuard DNS | 94.140.14.14 | 全球分散式 Anycast | 已停用 | 15 - 50 ms |
| Alibaba Cloud DNS | 223.5.5.5 | 亞太與全球 Anycast | 支援 | 20 - 80 ms |
強制入口 DNS 傳播與圍牆花園機制
對於場館、飯店、零售中心和企業園區的訪客 WiFi 部署而言,DNS 的可靠性至關重要。當訪客連接到 WiFi 無線基地台時,無線區域網路控制器 (WLC) 會攔截早期 DNS 和 HTTP 流量,以觸發強制入口登入流程:
- 強制網路助理 (CNA) 探測:行動作業系統會自動針對探測網域發出 DNS 請求 (例如 iOS 上的
captive.apple.com與 Android 上的connectivitycheck.gstatic.com)。 - 驗證前圍牆花園:網路控制器必須在訪客進行驗證之前,允許對您的強制入口主機名稱、金流網關和社群登入 OAuth 驗證提供者進行無限制的 DNS 解析。
- DNS TTL 預先設定:遷移強制入口 URL 或 SSL 憑證時,網路工程師必須至少提前 24 至 48 小時將區域 TTL 降低至 300 秒 (5 分鐘),以防止切換期間用戶端連線逾時。
如何檢查強制入口網域的全球 DNS 傳播
供網路工程師在網域切換前後,驗證跨全球 Anycast 解析器的 DNS 記錄同步狀況之分步指南。
輸入主機名稱或強制入口 FQDN
在主機名稱欄位中輸入完全合格功能變數名稱 (FQDN),例如 portal.venue.com 或 purple.ai。
選擇目標 DNS 記錄類型
選擇要稽核的記錄類型:A (IPv4)、AAAA (IPv6)、CNAME (規範別名)、TXT (驗證或 SPF) 或 MX (郵件轉發)。
查詢全域 Anycast 解析器
按一下「檢查傳播」,跨 Google、Cloudflare、NextDNS、AdGuard、Alibaba 及 DNS.SB 觸發並行 DNS-over-HTTPS 請求。
檢查同步率與 TTL 收斂情況
檢視全域同步百分比計量器,驗證解析器延遲 (ms),並匯出 Markdown 診斷報告以用於變更驗證工單。
關於 DNS 傳播的常見問題
什麼是 DNS 傳播,為什麼需要時間?
DNS 傳播是指權威名稱伺服器(authoritative nameservers)上的更新散佈至全球遞迴 DNS 解析器(recursive DNS resolvers)並完成更新所需的時間。當 DNS 記錄被修改時,中間快取解析器(例如 ISP 解析器、Google 和 Cloudflare 等公共解析器以及企業轉發器)會保留舊記錄,直到其存活時間(TTL)過期。根據預先設定的 TTL,傳播通常需要幾分鐘到 24 小時不等。
為什麼訪客 WiFi 強制入口會在 DNS 傳播期間失效?
當訪客裝置連接到開放或安全的訪客 SSID 時,iOS、macOS、Android 和 Windows 等作業系統會啟動自動強制入口偵測探測(例如查詢 captive.apple.com 或 connectivitycheck.gstatic.com)。無線基地台或控制器會攔截 HTTP 流量,並將用戶端瀏覽器重新導向至強制入口網域(例如 portal.purple.ai)。如果用戶端裝置使用的 DNS 解析器尚未快取新的入口記錄,DNS 解析就會失敗,從而導致強制網路助理(CNA)瀏覽器逾時和註冊流程失敗。
DNS TTL 如何影響 ISP 解析器的傳播速度?
TTL(存活時間)是定義在每個 DNS 資源記錄上的 32 位元整數(單位為秒),用於指定允許遞迴解析器快取答覆的時間長度。較低的 TTL(例如 300 秒)可確保解析器每 5 分鐘查詢一次權威名稱伺服器,從而實現快速切換。較高的 TTL(例如 86,400 秒 / 24 小時)則會導致解析器提供舊的快取記錄長達一整天。
權威 DNS 與遞迴 DNS 解析器有何不同?
權威名稱伺服器持有主區域檔案(master zone file)以及網域的最終權威資料來源(例如 AWS Route 53、Cloudflare DNS、NS1)。遞迴 DNS 解析器(例如 Google 8.8.8.8、Cloudflare 1.1.1.1 和 ISP 名稱伺服器)則充當中間人,代表用戶端裝置查詢權威伺服器,並根據記錄的 TTL 快取結果。
網路工程師如何清除本機 DNS 快取以驗證傳播狀態?
在 macOS 上,於終端機中執行 `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder`。在 Windows 上,於命令提示字元中執行 `ipconfig /flushdns`。在 Linux 上,透過 `sudo systemd-resolve --flush-caches` 或 `sudo resolvectl flush-caches` 重啟 systemd-resolved。或者,使用此線上 DNS 傳播檢查工具直接查詢外部 Anycast 解析器,繞過所有本機作業系統快取。
為什麼 Purple 推薦使用 Anycast DNS 和預先設定的圍牆花園(walled garden)網域?
Purple 營運全球分散式的 Anycast 雲端基礎架構,能在全球提供少於 20 毫秒的 DNS 解析速度與即時的 HTTPS 宣傳頁面載入。在進行註冊切換前,預先設定圍牆花園網域白名單並降低 DNS TTL,可確保在 Cisco Meraki、Aruba、Ubiquiti UniFi、Ruckus 和 Cisco Catalyst 硬體上實現順暢無縫的訪客驗證。
相關網路診斷與 WiFi 工具
Related WiFi tools
正在遷移強制入口網域?
如果管理不當,網域切換和 DNS 傳播可能會導致訪客 WiFi 停機。Purple 提供高可用性的 Anycast 入口代管服務、自動化 SSL 憑證管理,以及預建的硬體整合,實現零停機時間的訪客入網流程。
Book a 20-min demoNetforge Network Multi-Tool
Run offline network health checks, path analysis, and latency diagnostic scans directly from your desktop.
Download Multi-Tool