什么是 DNSSEC？
DNSSEC（域名系统安全扩展）为 DNS 资源记录集添加数字签名。验证解析器可以利用有效签名和信任链验证已签名数据的来源与完整性，并检测未经授权的更改。DNSSEC 不会加密 DNS 查询或响应。DNSSEC 如何工作
信任链（双密钥示例）：
根区 (.)
├── 根区 KSK（信任锚）签署根区 DNSKEY RRset
└── 根区 ZSK 签署根区权威 RRset，包括父区域中用于 .com 委派的 DS RRset
└── DS 摘要与 .com KSK 匹配
├── .com KSK 签署 .com DNSKEY RRset
└── .com ZSK 签署 .com 区域的权威 RRset，包括父区域中用于 example.com 委派的 DS RRset
└── DS 摘要与 example.com KSK 匹配
├── example.com KSK 签署 example.com DNSKEY RRset
└── example.com ZSK 签署 example.com 区域的权威 RRset
解析器以根信任锚为起点，验证各级签名和 DS 摘要
DNSSEC 记录类型
| 记录 | 用途 | 说明 |
|---|---|---|
| RRSIG | 签名 | 每组记录的加密签名 |
| DNSKEY | 公钥 | 区域的公共签名密钥（KSK 和 ZSK） |
| DS | 委派签名者 | 父区域中子区域 KSK 的哈希值 |
| NSEC/NSEC3 | 经验证的否定证明 | 证明某条记录不存在 |
密钥类型
| 密钥 | 用途 | 轮换频率 |
|---|---|---|
| KSK（密钥签名密钥） | 签署 DNSKEY 记录 | 取决于 KSK 的用途和运营策略 |
| ZSK（区域签名密钥） | 签署其他权威 RRset；父区域一侧的委派 NS 和胶水 RRset 不签名（[RFC 4035 第 2.2 节](https://www.rfc-editor.org/rfc/rfc4035.html#section-2.2)） | 取决于运营策略；见下文 |
KSK 的轮换间隔取决于它的用途和运营策略。[RFC 6781 第 3.3 节](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.3) 指出，如果选择定期轮换，与父区域 DS 记录关联的 KSK 采用一年作为有效期是合理的。配置为信任锚的 KSK 需要与验证解析器协调，其有效期可能长得多（参见 [RFC 6781 第 3.2.2 节](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.2.2)）。
ZSK 的轮换时机取决于 DNSKEY 和签名的 TTL、区域传播情况，以及使用即将退役的密钥生成的签名可能在解析器缓存中保留多久（[RFC 7583 第 3.2.1 节](https://www.rfc-editor.org/rfc/rfc7583.html#section-3.2.1)）。对于在线运行且密钥遭到泄露的风险相当高的 ZSK，[RFC 6781 第 3.3 节](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.3) 认为，一个月的预期有效期可能是合理的；这是有条件的建议，并非通用轮换周期。
2026 年 10 月 11 日根区 KSK 轮换
ICANN 计划于 2026 年 10 月 11 日进行根区 KSK 轮换。运行 DNSSEC 验证解析器的运营者应确认信任锚配置中包含 KSK-2024（密钥标签 38696）。请勿假设自动信任锚更新已成功。如果缺少该密钥，请确认自动更新已启用，并按照解析器供应商的指导更新信任锚。请参阅 [ICANN 的根区 KSK 轮换说明](https://www.icann.org/resources/pages/ksk-rollover-en)。
DNSSEC 验证流程
1. 客户端向 DNS 解析器查询 example.com 的 A 记录
2. 解析器获取 A 记录和 RRSIG 签名
3. 解析器获取 DNSKEY 以验证 RRSIG
4. 解析器根据 DNSKEY 验证 DS 记录
5. 链条继续向上到根区域，逐级完成验证
6. 如果所有签名都有效，响应即通过身份验证
DNSSEC 验证可帮助发现的问题
这些检查要求 RRset 已签名、解析器执行 DNSSEC 验证且信任链完整。未签名或不安全的数据无法通过 DNSSEC 完成认证。
| 威胁 | 示例 | DNSSEC 的防护作用 |
|---|---|---|
| 缓存投毒 | 向解析器缓存中插入伪造的 DNS 数据 | 验证解析器可拒绝未通过签名或信任链验证的数据。 |
| 响应篡改 | 传输中的已签名 DNS 记录集被更改 | 更改后的数据无法通过签名验证。 |
| DNS 欺骗 | 为已签名区域提供伪造应答 | 验证解析器可拒绝未通过验证的应答。 |
实施注意事项
- 性能：签名会使响应变大（约 1000 至 4000 字节，而普通响应约 100 字节）
- 密钥管理：需要安全地生成、存储和轮换密钥
- 区域签名：记录变更后必须重新签署区域
- 解析器支持：客户端需要使用支持 DNSSEC 验证的解析器
最佳实践
1. 选择 DNSSEC 签名算法：[IANA DNSSEC 算法注册表](https://www.iana.org/assignments/dns-sec-alg-numbers) 将 ECDSAP256SHA256（算法 13）列为签名和验证的推荐算法。对于需要 192 位安全强度的场景，ECDSAP384SHA384（算法 14）可能更合适；更换算法前请确认解析器支持（[RFC 9904](https://www.rfc-editor.org/rfc/rfc9904.html)，[RFC 8624 第 3.1 节](https://www.rfc-editor.org/rfc/rfc8624.html#section-3.1)）。
2. 自动轮换密钥：使用 OpenDNSSEC 等工具管理密钥生命周期
3. 监控过期时间：RRSIG 签名具有有效期
4. 部署前测试：使用 dnsviz.net 等工具验证区域
5. 准备应急方案：记录密钥轮换流程
验证解析器确认整条信任链后，DNSSEC 可验证已签名 DNS 数据的来源和完整性。但这并不能证明返回地址上的网站或服务器值得信任。