DNSSEC 当验证者可以建立信任链时，将原始身份验证和完整性添加到DNS数据中。它不会加密DNS答案、批准发送服务或验证消息内容。它对电子邮件的价值来自于保护DNS依赖性，当验证链中断时会产生可用性后果。
验证链而不是签名的存在
参考： RFC 4033 §3, RFC 4035 §5.
签名的答案包含加密材料，但仅存在 RRSIG 并不能成功验证。验证者需要一个可信的起点、适当的 DNSKEY 和委托信息、可用的签名和有效的计时。父 DS 数据和子密钥在更改期间必须保持协调。
使用具有已知信任配置的验证解析器或支持验证的诊断程序。如果应用程序依赖于解析器的经过身份验证的数据指示，则到该解析器的路径和信任关系就很重要。仅使用工具请求DNSSEC记录并不会使该工具对其进行验证，并且权威应答标志也不是DNSSEC验证结果。
将验证状态分开
参考： RFC 4035 §4.3, RFC 7672 §2.1.
安全结果具有针对返回数据的经过验证的信任链。不安全的结果可能是合法的未签名分支，并且与检测到的伪造不同义。虚假结果意味着预期的验证失败。还必须区分不确定结果：当解析器由于无法获取必要的DNSSEC记录而无法确定是否应该对数据进行签名时RFC 4035使用它。 RFC 7672使用RFC 4035的SMTP含义 DANE 并将这种情况视为失败，而不是默默地将其视为未签名。保留诊断上下文，因为RFC 4033对不确定性的描述不同。
验证解析器可以针对虚假数据返回SERVFAIL ，但SERVFAIL本身无法诊断DNSSEC ：其他DNS故障可能会产生该错误。检查验证诊断、父 DS、子 DNSKEY、签名和时间。不要禁用验证作为默认修复，因为这样做会更改正在测试的信任属性。
重现三个不同的邮件依赖关系
参考： RFC 4035 §5.2, RFC 4035 §5.4.
合成案例 A 具有签名区域、匹配的父 DS 和子 DNSKEY，以及所查询邮件记录的当前有效签名。配置的验证器的预期结果是安全的。案例 B 有一个故意未签名的孩子，其委托中没有 DS 的经过验证的证明。预期结果是不安全的，而不是虚假的。
情况 C 在更换子密钥后将旧 DS 留在父级，而没有兼容的翻转。预期结果是验证链损坏，并且对于定义的验证解析器固定装置， SERVFAIL会变为普通查询。非验证直接查找可能仍会显示TXT或 MX记录。这种差异并不能证明验证解析器是错误的。
仅在具有自己的信任锚的一次性签名测试层次结构中重现这些情况。保留父 DS、子 DNSKEY、查询记录、RRSIG、解析器配置、时钟和详细验证跟踪。查询每种情况下相同的所有者和类型并比较分类状态。这些递归解析器场景是测试规范，而不是声称的实时签名区域部署或递归验证器执行。后来捕获的离线验证案例部分记录了 2026 年 11 月 7 日捕获的单独的、有界的加密装置；它没有观察到SERVFAIL或测试集成SMTP DANE 。
了解DANE附加要求
参考： RFC 7672 §2.2, RFC 7672 §3.
SMTP DANE使用 DNSSEC 验证 TLSA 关联和发送方支持以验证传输。单独对域进行签名不会创建所需的 TLSA 记录或使每个发件人强制执行DANE 。 MX和 TLSA 发现路径以及证书关联需要根据RFC 7672进行自己的验证。
即使DNSSEC保持正常运行，证书或密钥翻转也可能会破坏 TLSA 匹配。相反，损坏的DNSSEC链可能会阻止支持的发件人安全地使用其他正确的 TLSA 数据。将两个层一起规划并保留受控的SMTP测试。 DANE和DNSSEC都不能替代 SPF, DKIM 或者 DMARC.
将签名作为维护的依赖项进行操作
参考： RFC 6781 §4.1.
记录签名、注册商 DS 更新、密钥轮转和监控的所有权。在更改DNS提供商之前，请确定是否保留或转换密钥和链。监视相关路径的签名有效性和验证，并在关闭故障之前要求恢复证据。报告观察到的确切DNS信任和邮件行为，而不是声称签名的DNS可以确保所有电子邮件的安全。
捕获的离线验证案例
参考： RFC 4035 §5.
保留的捕获（已检查但未为本次审查重新运行）记录了一个孤立的加密装置于 2026 年 11 月 7 日20:34:42 UTC 使用 Python 3.12.14 和 dnspython 2.9.2 执行。例如，它将生成的父 DNSKEY 作为其实验室信任锚，为signed.example生成子密钥，使用父密钥签署子 DS 并签署测试 TXT记录 与儿童钥匙。 DS 和TXT的实际签名检查成功，并且计算出的 SHA-256 DS 与孩子的 DNSKEY 相匹配。捕获的结果是经过验证的离线链。
对于断链情况，夹具会生成替换子密钥，同时保留旧 DS。计算出的 DS 不再匹配，并且夹具拒绝了该链。它没有运行递归验证器，也没有观察到SERVFAIL 。对于未签名的情况，它在unsigned.example上验证了父签名的 NSEC，其确切名称位图包含 NS 并省略了 DS，然后将该委托归类为不安全。这个狭隘的证明并没有实现一般的否认存在解析器。
要重现，请创建 ECDSA P-256 父密钥和子密钥，构建 DNSKEY 和 DS 记录，使用有限的启动/过期时间对 DS 和TXT进行签名，并根据固定的父密钥和匹配的子密钥调用 dnspython 的DNSSEC验证操作。更换不匹配情况下的子密钥。对于未签名的情况，验证精确委托 NSEC 签名并检查其位图。保留密钥的公开记录、签名、验证时间、依赖版本和结果；保持测试私钥是一次性的。证据显示实际的本地加密操作，而不是公共DNS验证、生产SMTP DANE或已部署的递归解析器。