DNSSEC 验证检测工具
向 Google、Cloudflare 等多个公共 DNS 解析器查询域名的 DNSKEY 记录，检测其 DNSSEC 签名链是否验证通过。
使用提示
- AD（Authenticated Data，已验证数据）标志只有在您查询的 DNS 解析器自身执行了 DNSSEC 验证时才会被设置。不支持 DNSSEC 的解析器无法给出有意义的判定结果。
- "DNSSEC 未启用"并非错误——目前大多数域名仍未使用 DNSSEC，这不会直接影响搜索排名或邮件送达率。
- 若判定为"验证失败"，请先确认在注册商后台登记的父区域 DS 记录的密钥标签（Key Tag）与摘要是否与当前 DNSKEY 一致。
- DNSSEC 签名（RRSIG）具有有效期。请同时确认区域管理软件的自动重新签名是否已停止运行。
- 刚启用 DNSSEC 后，在 DS 记录传播到父区域完成之前，可能会暂时显示为"验证失败"。
常见问题
"DNSSEC 未启用"本身并不危险，目前绝大多数域名仍在没有 DNSSEC 的情况下运行。不过作为防范 DNS 缓存投毒的手段，如果条件允许，值得考虑启用它。
使用强制执行 DNSSEC 验证的解析器（许多企业网络及部分 ISP）的用户，可能完全无法解析该域名（会被当作 SERVFAIL 处理）。除非是刚启用 DNSSEC、DS 记录尚在传播中的临时状态，否则需要尽快修复。
在 DNSKEY 更新（密钥轮换）后不久，新旧密钥可能会在不同解析器的缓存中短暂共存，导致验证结果暂时出现差异。请稍等片刻后再次检测。
两者不同。DNSSEC 保证的是"域名解析响应未被篡改"，而 SSL/TLS 保证的是"通信内容已加密，且连接对象确实持有该证书"。二者相互独立，只启用其中一项的情况也是存在的。
本工具仅检测表层状态：DNSKEY 是否已发布，以及解析器是否报告 AD 标志。如需对完整签名链（RRSIG、NSEC/NSEC3 一致性等）进行严格分析，请配合使用 dnsviz.net 等专业工具。
闲话 ― DNS 为何需要一套防止"冒充"的机制
DNS 在 1983 年设计之初，并没有一种加密手段来确认响应的真实发送者。解析器只是信任任何看起来带有合理事务 ID 的 UDP 数据包——这是一种建立在"性善说"之上的协议，容易受到源 IP 伪造和 ID 猜测攻击。2008 年，安全研究员 Dan Kaminsky 发现这一弱点可被用于以实际可行的速度进行缓存投毒攻击（将伪造记录注入解析器缓存），这一发现震惊了整个行业。
DNSSEC（DNS 安全扩展）正是对这一问题的标准化回应。它利用公钥加密技术证明"该响应确实由区域的合法管理者签名"。域名使用自己的 DNSKEY 对记录进行签名，而在父区域注册的 DS 记录则担保该密钥的摘要，从而从 DNS 根区域一直到具体域名，构建起一条不间断的"信任链"。
DoH（基于 HTTPS 的 DNS）响应中的 AD（Authenticated Data）标志，正是解析器代为完成这一 DNSSEC 验证的结果。应用程序无需自行实现签名验证——只要向可信解析器查询并看到 AD=true，即可间接确认响应未被篡改，前提是解析器与应用之间的通信（HTTPS）本身已受到保护。