怎样核对 DNS 记录并定位解析问题
这个工具用于查询域名的公开 DNS 记录，帮助你核对网站、邮件和域名验证配置。它与“DNS 泄漏测试”解决的问题不同：这里把你输入的域名交给指定公共解析服务查询；泄漏测试则观察浏览器测试请求由哪些解析出口完成。查到一条 A 记录，不能据此判断设备是否采用了预期的 DNS 路径。
先确认输入和查询范围
输入完整域名，例如 example.com，或粘贴一个 HTTP/HTTPS 链接。本工具从链接中提取主机名，路径和查询参数不属于 DNS 记录名称。根域名、www 子域名和邮件主机可以有不同记录，排查时先确认发生故障的是哪一个名称。含用户名或密码的链接不适合作为输入。
选择需要的记录类型后再点击查询，避免一次查看过多无关信息。A 对应 IPv4，AAAA 对应 IPv6；CNAME 表示别名；MX 用于邮件路由；NS 指出相关域的权威服务；TXT 常承载验证或其他文本；SOA 提供区域管理信息。某种类型返回零条，不一定表示域名整体不可用。
结果从哪里来，信息会发给谁
当前页面通过浏览器向 Cloudflare 的 DNS over HTTPS 接口发送域名和记录类型。因此该查询服务会接收到你的查询和完成连接所需的信息。不要输入未经允许公开的企业内部名称、包含个人标识的子域名，或把内部系统命名清单批量提交到公共服务。
DoH 加密客户端与解析服务之间的传输，但解析服务仍需要处理查询内容。本工具不是离线工具；网络限制、服务不可用或浏览器拦截都可能导致失败。它提供一个公共递归解析器的观察位置，不能代表全球所有解析器。[Cloudflare DoH 接口说明]
区分无记录、错误和连接失败
先看页面是否明确显示查询失败、超时或域名错误。连接失败意味着尚未取得可以判断的记录，不应据此删除域名配置。请求成功但某类型没有结果时，要核对名称是否正确、是否查询了需要的类型，以及该业务本来是否需要这条记录。
例如，只配置了 A 记录的主机可能没有 AAAA。邮件配置也不能只看有没有 MX：邮件提供商通常还有发信验证等要求。本站界面便于查看结果；遇到复杂返回或需要查看完整权威、附加区段时，应结合管理员使用的 DNS 调试工具与原始响应。
TTL 与“已经生效”怎么理解
TTL 用于控制记录缓存寿命。递归解析器返回的剩余时间可能与管理面板配置的初始 TTL 不同。修改记录后，一个解析器看到新值，另一个仍保留旧缓存，并不一定表示后台没有保存成功。先记录修改时间、原值、新值与 TTL，再在合理时间后复测。
不要承诺等待一个固定时长就会在所有网络同时更新。缓存、委派、记录类型及服务配置都可能影响观察。降低 TTL 也不会追溯缩短所有已经发出去的旧缓存。验收时，应比较需要服务的实际用户网络与目标应用，而不只看本页一次查询。
网站打不开时怎样使用结果
- 确认浏览器实际访问的域名，分别核对根域名和需要的子域名，记录有无预期 A、AAAA 或别名。
- 比较结果与托管服务给出的目标，注意 CDN 地址可能只是入口，不是源服务器地址。
- 若地址正确，继续检查连接、TLS 证书和 HTTP 响应；DNS 成功并不证明网页服务正常。
- 双栈环境分别核对 IPv4 与 IPv6 的服务配置，不要只验证其中一种就宣称全部恢复。
- 保持相同设备和目标做复测，记录哪个阶段仍失败，再把证据交给对应负责人。
邮件与 TXT 验证应怎样核对
核对 MX 时，要同时阅读优先级和目标主机，而不是只看记录数量。核对 TXT 时，先确定服务商要求填写的主机名称和文本值，留意空格、引号和管理面板是否自动补全域名。不要把敏感密钥当成普通验证文本写入公开 DNS。
公开记录被正确解析，不等于目标服务已经完成验证。服务商可能需要你在后台再次触发检查，或等待它自己的缓存更新。遇到失败时保存具体提示，避免连续删除和重建记录，使其他依赖该域名的业务受到影响。
一个可复现的查询示例
假设你为测试站点新增了 www 子域名，但根域名正常、www 无法打开。先查询两个名称，发现 www 没有预期的记录，再与管理面板核对是否误填成了重复的完整域名。修正后记录保存时间，重新查询，并实际访问相同地址检查 TLS 和页面响应。这个例子是方法演示，不是真实用户故障记录。
分享结果前检查域名和截图中的个人信息。需要比较不同应用的网络行为，可阅读不同应用出现不同 IP 的原因；需要观察实际解析出口，请使用DNS 泄漏测试，并先明确预期路径。