DNS 传播检查工具
实时检查 8 个全球 Anycast 解析器的 DNS 记录传播，确保域名割接零停机。
验证全球 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 解析器
点击“Check propagation”（检查传播）以触发跨 Google、Cloudflare、NextDNS、AdGuard、Alibaba 和 DNS.SB 的并行 DNS-over-HTTPS 请求。
检查同步率和 TTL 收敛情况
查看全球同步百分比仪表，验证解析器延迟（ms），并导出 Markdown 诊断报告以用于变更验证工单。
关于 DNS 传播的常见问题
什么是 DNS 传播？为什么它需要时间？
DNS 传播是指在权威域名服务器上所做的更新同步并分发到全球递归 DNS 解析器所需的时间段。修改 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 解析器之间有什么区别？
权威域名服务器持有主区域文件和域名的权威数据源（例如 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 和预先配置围墙花园域名？
Purple 运营全球分布的 Anycast 云基础设施，可在全球范围内提供低于 20 毫秒的 DNS 解析速度和即时 HTTPS Splash 页面加载体验。在入网切换前预先配置围墙花园域名白名单并降低 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