DNSSEC 的 DNSKEY、DS、RRSIG、NSEC、NSEC3、KSK、ZSK 和 Trust Anchor 有什么区别？

八个概念快速对比

DNSSEC 在 DNS 中发布的是公钥、摘要和签名，签名私钥必须留在权威 DNS 运营方的安全环境中。

DNSSEC 提供什么

DNSSEC 为 DNS 数据提供来源认证、完整性保护和对不存在结果的认证。验证器可以判断收到的 RRset 是否由受信任链上的区域密钥签名且未被篡改。

它不加密查询内容，也不隐藏用户访问的域名。需要传输保密性要使用 DoT、DoH 或 DoQ 等加密 DNS 传输。

DNSSEC 不提供什么

DNSSEC 不保证区域运营方发布的业务数据本身正确，也不防止权威方签署错误记录。它证明的是“响应与签名区域发布的数据一致”。

它也不替代 HTTPS。A/AAAA 记录被验证，不代表连接到的 Web 服务证书、应用身份或内容自动可信。

RRset 是什么

同一 Owner Name、Class 和 Type 的一组资源记录构成 RRset。例如一个名称的多个 A 记录一起作为一个 RRset 被签名。

RRSIG 覆盖 RRset，而不是给每条 A 记录分别签一份。修改集合成员或相关签名输入都会使验证结果变化。

DNSKEY 是什么

DNSKEY Resource Record 发布区域用于 DNSSEC 验证的公钥，包括 Flags、Protocol、Algorithm 和 Public Key 等字段。区域用对应私钥签署 RRset。

DNSKEY 不用于保存任意 TLS 证书或应用公钥。RFC 4034 明确限定它与 DNS 基础设施认证有关。

DNSKEY Flags 256 与 257

常见 DNSKEY Flag 256 被运营工具称为 Zone Signing Key，257 增加 Secure Entry Point 位，常被称为 Key Signing Key。

这个 Flag 主要是运营与工具提示。验证器仍依据签名、算法、Key Tag 和信任链做验证，不能只看 257 就自动信任该 Key。

KSK 是什么

KSK 即 Key Signing Key，常用于签署区域顶点的 DNSKEY RRset。父区 DS 通常引用 KSK 对应 DNSKEY，从而把父区信任传到子区。

KSK 轮换涉及注册商或父区 DS 更新，协调不当会导致整个区域验证失败，因此周期通常比 ZSK 更谨慎。

ZSK 是什么

ZSK 即 Zone Signing Key，常用于签署 A、AAAA、MX、NS 等区域数据 RRset。DNSKEY RRset 再由 KSK 签名。

将角色分离可让频繁区域签名使用 ZSK，而 KSK 私钥采取更严格保护。但 DNSSEC 协议允许更灵活的签名方案，KSK/ZSK 是常见运营模型，不是两个独立 RR Type。

CSK 是什么

Combined Signing Key 使用一把密钥同时承担 KSK 与 ZSK 角色。规模较小或自动化成熟的运营环境可能采用 CSK，减少密钥数量和签名复杂度。

它简化管理，也让同一密钥轮换同时影响父区 DS 与区域数据签名。选型要结合自动化、算法、注册商能力和故障恢复流程。

Key Tag 是什么

Key Tag 是从 DNSKEY 计算出的短标识，RRSIG 和 DS 用它帮助高效选择候选公钥。它不是密码学上唯一的 Key ID，可能发生碰撞。

验证时还要结合 Owner Name、Algorithm、完整 DNSKEY 或 Digest，不能仅因 Key Tag 相同就认定是同一把密钥。

RRSIG 是什么

RRSIG 保存某个 RRset 的数字签名，并包含 Type Covered、Algorithm、Labels、Original TTL、Signature Inception、Expiration、Key Tag 和 Signer Name 等信息。

验证器找到对应 DNSKEY 公钥，对规范化 RRset 和签名输入执行算法验证，确认数据在有效期内且未被修改。

RRSIG 有效期为什么重要

签名在 Inception 之前或 Expiration 之后不能用于认证。权威区域数据仍可能存在，但验证器会把过期或尚未生效签名视为无效。

区域签名系统必须提前重签，并保证系统时钟可靠。缓存 TTL 没过期也不能绕过 RRSIG 的密码学有效期。

DS 是什么

DS Resource Record 位于父区的委派点，保存子区某个 DNSKEY 的 Key Tag、Algorithm、Digest Type 和摘要。它不保存完整公钥。

例如 example.com 的 DS 由 .com 区域发布，而对应 DNSKEY 由 example.com 权威服务器发布。验证器比较摘要并建立父子信任链接。

DS 为什么在父区

如果 DS 与 DNSKEY 都只由子区自行发布，攻击者可以同时替换公钥和数据。父区对 DS 的签名让子区密钥获得上级背书。

创建 DS 通常需要在注册商提交 DNS 服务商给出的值，再由 Registry 发布。只在子区添加文本形式的 DS 并不能建立标准委派链。

Trust Anchor 是什么

Trust Anchor 是验证器本地预先信任的 DNSKEY 或摘要。公共 DNS 验证通常以 Root Zone 的密钥作为 Anchor，再逐级验证 TLD 与子域。

私有 DNS 环境也可配置额外 Anchor。Anchor 是本地信任决策，不是查询时从不可信网络临时得到后就自动相信。

Chain of Trust 如何形成

验证器先信任 Root Anchor，验证根区签名；再验证父区中的 DS；用 DS 认证子区 DNSKEY；再用该 DNSKEY 验证子区 RRSIG，直到目标 RRset。

链中如果父区没有 DS，子区通常被视为 Insecure 委派，而不是自动 Bogus；如果存在 DS 但无法匹配有效 DNSKEY，才是危险断链。

Secure、Insecure、Bogus 和 Indeterminate

Secure 表示存在完整可验证的信任链；Insecure 表示经认证证明某个委派未启用 DNSSEC；Bogus 表示本应安全但验证失败；Indeterminate 表示无法确定状态。

终端常只看到 SERVFAIL，递归解析器日志或验证工具才能显示具体安全状态。

NSEC 是什么

NSEC 把区域中存在的名称按规范顺序链接，并列出某名称存在的 RR Type。它能证明某名称不存在，或名称存在但查询类型不存在。

NSEC RRset 自身也有 RRSIG，验证器因此可以认证 NXDOMAIN 和 NODATA，而不是相信未经签名的否定回答。

NSEC 的 Zone Walking 问题

因为 NSEC 指向下一个存在名称，查询者可能沿链枚举区域中的名称。这不会泄露记录内容以外的秘密数据，但可能暴露原本不希望轻易枚举的命名结构。

NSEC3 引入哈希名称以降低直接枚举，但也不是绝对保密机制。

NSEC3 是什么

NSEC3 对名称进行哈希后建立认证否定链，并包含 Hash Algorithm、Flags、Iterations、Salt 和 Next Hashed Owner Name 等字段。

验证器计算查询名称的哈希并检查覆盖范围，以证明不存在。它增加计算与响应复杂度，需要正确选择参数。

NSEC3 与 NSEC 的区别

NSEC 使用明文规范名称链接，结构直观；NSEC3 使用哈希后的 Owner Name，降低直接 Zone Walking 的便利性，并支持 Opt-Out 等机制。

两者都用于认证否定回答，不是 DNS 缓存的负 TTL，也不决定 NXDOMAIN 保存多久。

NSEC3 Opt-Out 是什么

Opt-Out 允许大型签名区域在特定条件下省略对未签名委派的逐一覆盖记录，减少 NSEC3 规模。它改变否定证明和委派验证细节。

它不是“关闭子域 DNSSEC 检查”的通用开关。使用前必须理解未签名委派和攻击面的权衡。

AD 与 CD 位

递归解析器成功验证后，可能在响应中设置 AD（Authentic Data）位。客户端只有在信任与递归解析器之间的通道和解析器本身时，才能把 AD 当有效信号。

CD（Checking Disabled）允许请求方表达禁用验证检查的意图，主要用于具备自身验证能力的客户端和诊断，不应作为永久绕过故障的修复。

DO 位是什么

客户端通过 EDNS 的 DO（DNSSEC OK）位表示希望接收 DNSSEC 相关记录。dig +dnssec 会请求相应材料，但看到 RRSIG 不等于本机已经完成验证。

验证需要信任链、算法支持、时间检查和签名计算。普通输出仅证明服务器返回了记录。

为什么 DNSSEC 常表现为 SERVFAIL

验证器不能把 Bogus 数据当正常答案返回，通常向客户端返回 SERVFAIL。常见原因包括 DS 指向旧 KSK、RRSIG 过期、签名缺失、算法不支持、时间错误或响应截断。

需要比较带验证与不带验证的递归结果，并逐级查询 DS、DNSKEY 和 RRSIG，不能把所有 SERVFAIL 都归因于权威宕机。

DS 与 DNSKEY 不匹配

迁移 DNS 服务商后，如果父区仍保留旧 DS，而新权威只发布新 DNSKEY，验证器无法连接信任链。未验证解析器可能正常，验证解析器则 SERVFAIL。

迁移必须先禁用旧 DS 或执行 Multi-Signer/预发布密钥等无中断流程，不能只修改 NS。

RRSIG 过期

区域签名器停摆、时钟异常或发布流水线失败，会让 RRSIG 到期。权威服务器仍能返回 A 记录，但验证器拒绝过期签名。

应监控距离最早 Expiration 的剩余时间，而不是等用户报告解析失败后才检查。

UDP 大响应与 Fragmentation

DNSKEY、RRSIG 和 NSEC3 会增大 DNS 响应，可能超过路径可承载的 UDP 大小，触发 Fragmentation 或 TCP Fallback。

防火墙若阻断 TCP 53 或错误丢弃 Fragment，会造成间歇性验证失败。排障应同时测试 UDP/TCP、EDNS Buffer 和路径 MTU。

KSK 轮换基本顺序

轮换需要确保新 DNSKEY 已发布并传播、父区 DS 在正确时点更新、验证器缓存能够平滑过渡，最后再撤旧 Key。具体方案取决于 Pre-Publish、Double-DS、Double-Signature 或自动化协议。

不要在同一时刻删除旧 DNSKEY 并替换 DS。缓存中的父子记录可能来自不同时间点，形成临时断链。

ZSK 轮换基本顺序

ZSK 轮换通常不需要父区修改 DS，但要确保新 DNSKEY 与新签名提前可见，旧签名和旧密钥在缓存过渡期内仍可验证。

自动签名平台也应记录 Key ID、Activation、Publication、Retirement 和 Removal 时间。

CDS 与 CDNSKEY

CDS 和 CDNSKEY 允许子区发布希望父区采用的 DS 或 DNSKEY 信息，支持 RFC 8078 所述的自动化父区 DS 维护流程。

只有注册商/Registry 支持并按安全流程扫描时才会生效。发布记录不等于父区一定自动更新。

排障命令思路

用 dig +dnssec 查看目标 RRset 与 RRSIG，用 dig DNSKEY 查看区域公钥，用 dig DS 从父区检查摘要，再用支持追踪验证的工具逐级建立链。

同时查询多个递归解析器和权威服务器，记录是否只在验证器失败，避免缓存和 Anycast 节点差异误导结论。

监控清单

监控 DS/DNSKEY 匹配、算法与 Digest 支持、RRSIG Inception/Expiration、权威节点签名一致性、TCP 53 可达、响应大小和 KSK/ZSK 生命周期。

变更 NS、DNS 服务商、Registrar 或 Signing Algorithm 前，必须把 DNSSEC 链纳入迁移计划。

常见误区

常见误区包括认为 DNSSEC 加密查询、看到 RRSIG 就算验证成功、把 DS 放在子区、只看 Key Tag 判断密钥、删除旧 Key 不等缓存，以及用关闭验证长期掩盖 Bogus。

另一个误区是认为 NSEC3 能完全隐藏区域名称。可预测名称仍可能被离线猜测，敏感主机不应只依赖 DNS 名称不可枚举。

结论

DNSKEY 提供公钥，RRSIG 签署 RRset，父区 DS 认证子区 DNSKEY，NSEC/NSEC3 认证不存在，KSK/ZSK 组织签名运营，Trust Anchor 提供信任起点。

DNSSEC 稳定性的关键是父子区域、签名有效期、密钥轮换、缓存传播和网络传输全部协调，而不是“开启一个开关”后永久不管。

常见问题

DNSSEC 会隐藏我查询的域名吗？

不会。它提供认证和完整性，不提供传输加密。隐藏链路上的查询需使用加密 DNS 传输。

为什么没有 DS 的域名还能正常解析？

没有 DS 的委派通常被认证为 Insecure，解析器仍返回数据，只是数据没有 DNSSEC 信任链保护。

KSK 和 ZSK 是不同的 DNS 记录类型吗？

不是。它们都是 DNSKEY，区别主要来自 Flags 与运营签名角色。

RRSIG 的 TTL 没过期，为什么仍验证失败？

RRSIG 还有独立的 Inception 和 Expiration。缓存 TTL 有效不能让已过密码学有效期的签名继续可信。

NSEC3 是否比 NSEC 的签名更安全？

它主要改变不存在证明的名称表示和枚举特性，不代表对普通 RRset 使用更强的数字签名。

标准与权威资料

1. RFC 4033：DNS Security Introduction and Requirements — https://www.rfc-editor.org/rfc/rfc4033

2. RFC 4034：Resource Records for DNSSEC — https://www.rfc-editor.org/rfc/rfc4034

3. RFC 4035：Protocol Modifications for DNSSEC — https://www.rfc-editor.org/rfc/rfc4035

4. RFC 5155：DNSSEC Hashed Authenticated Denial of Existence — https://www.rfc-editor.org/rfc/rfc5155

5. RFC 8078：Managing DS Records from the Parent via CDS/CDNSKEY — https://www.rfc-editor.org/rfc/rfc8078

6. ICANN：DNSSEC — https://www.icann.org/resources/pages/dnssec-2012-02-25-en

7. Cloudflare：DNSSEC Validation and Key Management — https://developers.cloudflare.com/dns/dnssec/validation-and-key-management/