DNSSEC 详解：DNS 应答如何被认证

DNS 安全扩展（DNSSEC）为 DNS 数据增加了密码学认证。它帮助验证型解析器确认某个响应来自预期的区域，并且在传输过程中没有被篡改。DNSSEC 不会加密 DNS 查询，不会隐藏所请求的域名，也不会让网站变得可以放心使用。它提供的是一条由签名和密钥构成的链，使解析器能够沿着这条链，一直验证已签名的数据直至受信任的根。链条配置正确时，解析器能获得更有力的证据，证明响应是真实的；链条一旦断裂，验证就会让原本正常的查询失败。

DNSSEC 信任链中的记录

已签名的区域会发布 DNSKEY 记录，其中包含用于验证签名的公钥。RRSIG 记录承载记录集的签名，父区域中的 DS 记录则把子区域的密钥接入父区域的信任链。当某个名称或记录不存在时，NSEC 或 NSEC3 数据可以支持经认证的“不存在”应答。运维人员通常依赖 DNS 服务商或注册商来创建和维护这些值，但职责可能是分开的：子区域由 DNS 托管方签名，而父区域的 DS 记录则通过注册商发布。两者不一致，是验证出问题的常见原因。

验证型解析器会从已配置的信任锚（通常是根）出发，沿着信任链依次经过父区域和子区域，检查签名是否有效，以及记录是否与密钥和委派数据相匹配。普通用户可能从未见过这些步骤，但效果会体现在结果上：有效的已签名响应会被接受，而签名链一旦断裂，就可能导致 SERVFAIL。不做验证的解析器可能返回一个验证型解析器会拒绝的值，这就是 DNSSEC 故障看起来像是只在某些网络上才出现的原因。比较不同的解析器并检查验证状态，比单纯认定该主机名没有记录更有参考价值。

DNSSEC 故障是如何发生的

常见的故障情形包括：更换 DNS 服务商之后，在注册商处遗留了过时的 DS 记录；发布了与已签名区域不对应的密钥；因为签名工作停止而让签名过期；或者在没有协调父区域和子区域的情况下更改了委派。DNSSEC 的部署或密钥轮换，应遵循服务商文档中的流程，并通过独立的验证型解析器进行验证。如果停用了 DNSSEC，过时的 DS 数据可能比根本没有 DS 记录危害更大，因为验证方可能仍然期待一条子区域已不再提供的信任链。请把注册商和 DNS 托管方视为同一个流程中相互关联的两个环节。

• 询问 DNS 服务商是否为区域签名，并负责密钥轮换。
• 确认注册商处的 DS 值与服务商当前提供的说明一致。
• 启用、停用或迁移 DNSSEC 之后，通过验证型解析器进行测试。
• 谨慎安排密钥变更的时间，并保留回滚路径。
• 不要把 DNSSEC 认证与加密的 DNS 传输混为一谈。

排查验证失败

如果某个域名在验证型解析器上返回 SERVFAIL，请先检查 DNSSEC 信任链，再考虑改动无关的 A 或 MX 记录。先确认权威区域的 DNSKEY 和签名，再对比父区域发布的 DS。查看签名的有效期，以及服务商最近的变更。通用的域名转 IP 查询可以告诉您解析失败了，却不一定能解释 DNSSEC 链条中是哪一环断了，要回答这个更深层的问题，请使用支持 DNSSEC 的诊断工具。请记录下解析器、验证结果和查询时间，方便服务商复现并排查问题。

DNSSEC 增强了数据的真实性，但运维上的准确性依然重要。它无法防止域名所有者的账户被入侵，也无法把错误的记录变成正确的记录，它只是按照所配置的密钥，认证已发布的数据。如需了解基础背景，请参阅 DNS 解析详解和 DNS 记录类型。只有当您能够维护这条信任链，并在续期和迁移过程中持续监控它时，才应启用 DNSSEC，不要把它当作一次性开关，更不要以为它永远不会出错。

把密钥轮换当作协调一致的变更

DNSSEC 密钥轮换会改变验证型解析器所依赖的密码学材料。确切的安全步骤取决于签名服务商，以及轮换是托管的还是手动的。请遵循文档中的流程，使新旧密钥按要求重叠，签名保持有效，并在恰当的阶段让父区域的 DS 数据与已发布的密钥相匹配。不要从过期的控制台截图中抄录 DS 值，也不要仅仅因为某次无关的查询超时就把它删除。轮换之后，请使用不止一个启用 DNSSEC 验证的解析器进行验证，并保留服务商的事件日志。如果验证失败，请记下域名、解析器、响应码和时间，再检查签名和 DS 的关联，然后才能去动应用层的记录。在监控下进行的受控轮换，要比等浏览器和邮件系统开始出错后再紧急修复信任链安全得多。