DNSSEC 验证检测工具
向 Google、Cloudflare 等多个公共 DNS 解析器查询域名的 DNSKEY 记录，检测其 DNSSEC 签名链是否验证通过。
诊断 DNSSEC 的信任链
本工具把某个域名的 DNSKEY 记录投向数个公开解析器，报出 DNSSEC 的签名是否一路验证得通。它揪得出这样一种状况：本以为已启用 DNSSEC，链条却在半途断了。
**DNSSEC 所护的是「答案未曾被篡改」，而非「内容是秘密」。** 往来的东西一如既往人人可见，所担保的唯有真伪。**而最常见的疏漏，是忘了把 DS 记录登记到父区域。** 您纵在自家区域放好密钥并签了名，**若不经注册商把 DS 登记到父区域（譬如 `.com`），信任链便在此处断开，什么也验证不了。** 反过来，密钥轮换若出了岔子而留下不一致，**在凡是作验证的解析器那里，整个域名便都解析不出来了。** 故而半途而废的状态，反倒可能比从未启用更危险。
使用方法
- 输入域名 只给域名即可，形如 `example.com`。
- 阅读验证的结果 **它判定签名之链是否一路接到了父区域。**
- 确认有无 DS 记录 **此处一旦缺失，您放下再多密钥也验证不了。**
- 比对数个解析器的答案 若有出入，便可疑心是缓存或是配置。
用好本工具的小技巧
- AD（Authenticated Data，已验证数据）标志只有在您查询的 DNS 解析器自身执行了 DNSSEC 验证时才会被设置。不支持 DNSSEC 的解析器无法给出有意义的判定结果。
- "DNSSEC 未启用"并非错误——目前大多数域名仍未使用 DNSSEC，这不会直接影响搜索排名或邮件送达率。
- 若判定为"验证失败"，请先确认在注册商后台登记的父区域 DS 记录的密钥标签（Key Tag）与摘要是否与当前 DNSKEY 一致。
- DNSSEC 签名（RRSIG）具有有效期。请同时确认区域管理软件的自动重新签名是否已停止运行。
- 刚启用 DNSSEC 后，在 DS 记录传播到父区域完成之前，可能会暂时显示为"验证失败"。
这些场景会用到
启用 DNSSEC 之后的确认
**在控制面板上勾一下，往往并未把事情办完。**
把密钥轮换看到底
可在换钥的前后确认验证不曾断掉。
查究名称为何解析不出
**DNSSEC 的不一致，会让域名在部分用户眼里像是凭空消失了。**
查一查往来对象的域名
由此可知对方把自家的措施做到了哪一步。
DNSSEC 的术语
- DNSKEY
- 存放某区域公钥的记录，用于验证签名。
- DS 记录
- **把子区域密钥的指纹登记到父区域的记录。** 少了它，信任链便断。
- RRSIG
- 附在每条记录上的签名本身。它带有有效期，须按期更新。
- 信任链
- 签名自根经父及子一路相扣的结构。**任何一处断开，验证便无从谈起。**
- 密钥轮换
- 以新钥替换旧钥的作业。**步骤一错，整个域名便解析不出来。**
- 作验证的解析器
- 当真去核验 DNSSEC 签名的解析器。**一旦有不一致，它便什么答案也不返回。**
常见问题
闲话 ― 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）本身已受到保护。