签名

DNSSEC 为 DNS 数据增加来源认证和完整性检查。RRSIG 对记录集签名，DNSKEY 发布验证密钥，父区 DS 则通过摘要标识一个子区 DNSKEY。父区签名的是自己的 DS 记录集，不是简单直接签署子区公钥。验证从配置的信任锚出发，沿这些关系抵达所请求数据。理解链中每类记录的责任，才能准确定位发布与验证之间的差异。 坏掉的样子 如果委派没有建立预期信任路径，仅发布签名并不足够。缺失 DS 可能让子区处于不安全状态，错误 DS 则可能让原本应安全的子区验证失败；这是不同状态。已经安全证明不存在 DS，并不要求把每个未签名或独立签名的子区回答都当成无效数据拒绝。不能把“没有形成认证链”和“已有安全链却证明失败”混成一种结果。 签名具有独立于普通缓存 TTL 的生效与到期时间。签名过期后，权威区域可能继续回答记录，验证器却会拒绝。错误时钟、不完整密钥轮换和父区旧 DS，都可能中断一个普通查询看似仍正常的区域。只监控 DNSKEY 或 RRSIG 是否存在，会漏掉真正验证边界；应关注当前数据能否在有效时间和正确委派下被实际验证接受。 AD 标志也需要通过受信任解析路径解读。任意未受保护响应里出现该位，不会使回答自动可信，攻击者可以修改没有认证保护的消息。同样，使用 DO 请求 DNSSEC 记录，并不等于执行验证。应先确认哪个组件验证，以及应用如何信任它的回答，再把显示的标志作为证据。不能只凭工具输出里出现两个字母，就扩大为端到端安全保证。 快速验证 将脚本保存为 check-dnssec.py，准备 Docker 后执行 python3 check-dnssec.py。固定 BIND 9.18.49 环境创建一次性密钥和离线签名父子区域。独立验证解析器信任本地 lab.test 锚，只把这个测试命名空间转发给临时权威。私钥留在容器内部，不更改宿主信任配置和系统时间；不同案例使用独立进程，避免此前缓存影响结果： ...