01 · 研究背景与意义
1.1 为何DNS需要"来源认证"
经典DNS（RFC 1034/1035）设计于1983—1987年，是一个无源认证的明文协议：递归解析器无法证明一条应答确实来自权威服务器、且在传输中未被篡改。攻击者可以在"终端—递归—权威"链路的任意环节注入伪造应答，实现DNS劫持、缓存投毒（如Kaminsky攻击，CVE-2008-1447）与中间人重定向。RFC 4033（DNSSEC威胁模型）将这类风险归纳为"数据来源可被伪造"与"数据完整性可被破坏"两类核心缺陷。
DNSSEC以公钥密码学回应这两类缺陷：每个区的授权数据（RRset）都附加由区签名密钥生成的数字签名（RRSIG），验证方持有从根逐级下发的信任锚与DS委托记录，即可在递归侧确认"这条应答确实由该区持有者签名、且未被改动"。它赋予DNS的是来源认证（authenticity）与完整性（integrity），而非机密性。
关键的边界：DNSSEC解决"应答是不是真的"，不解决"应答是不是加密的"。它不提供传输机密性（需配合DoT RFC 7858 / DoH RFC 8484 / DoQ RFC 9250），也不提供可用性保障（抗DDoS依赖RRL RFC 8906、Anycast与冗余）。将DNSSEC与TLS类比时须注意：TLS验证"服务端的身份与加密会话"，DNSSEC验证"域名到地址映射这一层解析结果的真实性"，二者互补而非替代。
1.2 DNSSEC在DNS解析安全体系中的定位
本专题（DNS解析安全）将DNSSEC置于"检测与验证并重"的核心支柱：在本专题子课题01（劫持与篡改检测）中，DNSSEC验证（delv）是判定应答真伪、区分"真实篡改"与"配置异常"的权威依据；在子课题03（加密DNS评估）中，DoH/DoT保障"终端↔递归"段的机密性，而DNSSEC保障"递归↔权威"段及整条链路的真实性；在子课题04~06中，递归解析器的DNSSEC验证开关、验证失败（Bogus）归因与解析基础设施韧性直接决定DNSSEC是否真正生效。
1.3 部署现实：能力已就绪， adoption 仍偏低
根区自2010年起由ICANN/Verisign签名，主流TLD与大量ccTLD已完成委派签名（DS记录置于根区）。但终端侧"真正被执行验证"的比例长期偏低：APNIC的测量显示，截至近年全球约三分之一（约34%）的互联网用户处于开启DNSSEC验证的递归解析器之后；而即便在验证开启的网络中，因绝大多数顶级站点（如google.com、wikipedia.org等）自身未签名，实际被验证的查询流量仅约1%（APNIC/Cloudflare数据推算）。这一"基础设施就绪、业务侧冷淡"的落差，正是本子课题研究部署障碍与运维最佳实践的现实意义。
研究取向声明：本子课题不臆造部署数据，所有统计均溯源至APNIC Labs、ICANN、ISOC Pulse、Verisign等公开测量，并在各页注明统计时点与口径；凡属演进方向（如算法推荐的更新）均明确标注所依据的RFC版本号，避免跨版本误读。
1.4 DNSSEC 发展大事记
为建立准确的时间坐标，下表梳理DNSSEC标准化与部署史上的关键节点（均可溯源至RFC Editor、ICANN及公开事件档案）：
02 · 研究目标与关键问题
本子课题以"可部署、可验证、可运维"为工程目标，围绕DNSSEC从签名、发布、委派、验证到轮换的全生命周期，回答以下三个关键研究问题：
| 编号 | 关键问题 | 内涵说明 | 对应章节 |
|---|---|---|---|
| KQ-1 | 部署正确性与签名—验证一致 | 区域签名、NSEC/NSEC3选择、DS/CSR同步、算法选择是否符合RFC 6781/8624；如何以最小错误面完成"上级DS ↔ 本区DNSKEY"的对齐，避免链断裂（Bogus）。 | 第2—3页 |
| KQ-2 | 覆盖率与验证率可量化 | "区已签名"与"递归真正验证"之间存在巨大鸿沟；如何建立验证开启率、验证失败归因、签名新鲜度的测量与监测模型。 | 第5、7页 |
| KQ-3 | 自动化运维与故障收敛 | ZSK/KSK/CSK轮换、CDS/CDNSKEY自动滚密钥（RFC 7344/8078）、签名过期与轮转时序（RFC 7583/5011）如何自动化；如何把"一次错误导致全网解析失败"的风险降到可接受水平。 | 第4、6页 |
2.1 研究范围界定
- 协议域：以RFC 4033–4035定义的DNSSEC核心协议为主线，覆盖NSEC（RFC 4034）、NSEC3（RFC 5155）、CDS/CDNSKEY（RFC 7344/8078）、算法与密钥运维（RFC 6781/7583/8624/9364）。
- 部署域：兼顾权威侧（BIND、Knot DNS、PowerDNS、OpenDNSSEC等主流签名方案）与递归侧（Unbound、BIND、Knot Resolver等验证解析器）。
- 边界：不涉及DANE（RFC 6698）的证书绑定应用、RPKI等相邻体系的具体实现，仅在"DNSSEC使能的应用"层面做必要关联说明；不提供可直接复用的攻击脚本，仅从防御与运维角度阐述。
03 · DNSSEC知识体系全景
3.1 RFC谱系（协议—运维—算法三层）
DNSSEC并非单一RFC，而是一组协同演进的标准。为本课题研究锚定版本，下表按"协议定义 / 运维实践 / 算法与密钥"三个维度梳理核心RFC：
| RFC | 名称（简） | 在本课题中的角色 |
|---|---|---|
| 4033 | DNSSEC 架构与威胁模型 | 定义DNSSEC的设计目标、威胁模型（数据来源伪造/完整性破坏）与安全假设，是本课题"研究背景"的理论基石。 |
| 4034 | DNSSEC 资源记录 | 定义DNSKEY、RRSIG、DS、NSEC四种核心记录的格式与语义（详见第2页）。 |
| 4035 | 协议修改 | 定义EDNS0 DO位、验证结果状态（Secure/Insecure/Bogus/Indeterminate）与解析器处理规则。 |
| 5155 | NSEC3 | 以哈希链替代NSEC明文枚举，支持Opt-Out，缓解区域枚举与区放大（详见第2、3页）。 |
| 6781 | DNSSEC 运维实践 | 密钥生成、签名、ZSK/KSK轮转、应急（Emergency）轮转的操作指南。 |
| 7344 | CDS / CDNSKEY | 以子区自声明方式自动维护父区DS，是"无人工介入"滚密钥的核心（第4页）。 |
| 8078 | CDS/CDNSKEY 注册语义 | 定义"this registry"删除DS、双算法切换等语义（第4页）。 |
| 7583 | 密钥轮转时序 | 给出ZSK/KSK轮转各阶段的安全时间窗（RFC 5011/6781参数），第4页时序模型依据。 |
| 5011 | 信任锚自动更新 | 根KSK滚动与验证方信任锚自动接纳的机制；2018根KSK轮转即依此（第5页）。 |
| 3225/6891 | EDNS0 / DO位 | 客户端通过DO=1请求携带DNSSEC记录的应答；6891为EDNS0现行规范（STD 75）。 |
| 7129 | 经认证的否定存在（背景评注） | 为NSEC/NSEC3否定存在机制提供深入的背景评注与攻击语境，是理解否定应答验证的关键参考（第2页）。 |
| 8080 | Ed25519/Ed448 for DNSSEC | 引入算法15/16，短签名、抗侧信道，是新建署的推荐方向之一（第2页）。 |
| 8198 | Aggressive NSEC 缓存 | 利用NSEC/NSEC3覆盖区间加速否定应答验证，缓解签名查询放大（第5页）。 |
| 8624 | 算法实现与选用指南 | 明确各算法/摘要的"必须/推荐/不建议"状态（第2、3页核心依据）。 |
| 9364 | DNSSEC 总体导览（BCP 237） | 由ICANN的P. Hoffman编写的DNSSEC RFC"导览图"，汇集核心/扩展/算法文档并声明：使用DNSSEC保障DNS数据来源认证是当前最佳实践（BCP），本课题框架与其对齐。 |
| 9904 | 算法推荐更新流程（废弃8624） | 2025年11月发布（Standards Track），废弃RFC 8624，将算法实现/使用状态迁入IANA注册表统一治理并规定更新流程；不改变8624原有推荐状态（第2页）。 |
说明：RFC编号与定位均以RFC Editor官方文档为准；算法状态表随RFC 8624（2019）与RFC 9904（2025）注册表更新而演进，引用时须注明版本。
3.2 四种核心资源记录与链式信任模型
DNSSEC在经典DNS之上新增四类核心记录（第2页逐一拆解）：DNSKEY（区公钥，含ZSK/KSK）、RRSIG（RRset的数字签名）、DS（父区对子区KSK的委托摘要）、NSEC/NSEC3（证明"某名下不存在"的否定证明）。它们共同构成从根到叶的"链式信任（chain of trust）"：
3.3 算法与摘要状态（RFC 8624 / 9904）
算法选择直接决定签名强度与兼容性。下表为RFC 8624给出的DNSKEY算法"实现/使用"推荐，并标注RFC 9904（2025）注册表更新后的实现级状态。运营商应优先选用被标注为MUST/RECOMMENDED的算法，并停止生成SHA-1相关记录。
| 编号 | 算法 | 签名/使用 | 验证实现 | 说明 |
|---|---|---|---|---|
| 8 | RSASHA256 | RECOMMENDED | MUST | RSA+SHA-256，兼容性好、被广泛部署，实现级MUST（RFC 8624，状态经RFC 9904迁入IANA注册表）。 |
| 13 | ECDSAP256SHA256 | RECOMMENDED | MUST | 椭圆曲线P-256，短签名、低计算/带宽开销，新建署首选，实现级MUST（RFC 8624）。 |
| 15 | ED25519 | RECOMMENDED | RECOMMENDED | EdDSA，确定性签名、抗侧信道、签名最短，被视为未来默认方向。 |
| 14 | ECDSAP384SHA384 | MAY | RECOMMENDED | 更高安全强度（约192位），签名略长。 |
| 16 | ED448 | MAY | RECOMMENDED | EdDSA高强变体，支持度低于Ed25519。 |
| 10 | RSASHA512 | NOT REC. | MUST | 验证须实现，但新签名不建议使用（签名长、益处有限）。 |
| 5 / 7 | RSASHA1 / RSASHA1-NSEC3 | NOT REC. | MUST | SHA-1已不安全；验证仍须支持旧数据，但切勿用于新签名。 |
| 1 / 3 / 6 | RSAMD5 / DSA / DSA-NSEC3 | MUST NOT | MUST NOT | 已被废弃，禁止实现与使用。 |
| 17 | SM2SM3 | MAY | MAY | 国密SM2/SM3算法，已分配IANA编号，支持国密体系的场景可启用。 |
DS摘要算法：SHA-1（值1）已MUST NOT用于新生成（验证仍须支持旧数据）；SHA-256（值2）RECOMMENDED/MUST；SHA-384（值4）MAY/RECOMMENDED。来源：RFC 8624 §3.3、IANA DNSSEC Algorithm Numbers / DS Digest Algorithms 注册表（RFC 9904于2025年11月将上述状态迁入注册表并废弃8624，原有状态未变）。
04 · 八页研究框架
本子课题按"认知框架 → 密码学基础 → 部署实战 → 运维轮换 → 验证监测 → 故障排查 → 测量生态 → 收口落地"的逻辑组织为八页，各页以统一的RFC与算法编号体系衔接：
与DNS解析安全专题的衔接：第3、6页对应子课题01（劫持检测）的"验证判定"环节；第5页衔接子课题03（加密DNS）的递归侧真实性保障；第4、7页的自动化与测量直接支撑子课题04（递归审计）与子课题06（基础设施韧性）。
05 · 核心研究内容总览
| 编号 | 研究内容 | 要点 | 展开位置 |
|---|---|---|---|
| A1 | DNSSEC密码学与记录模型 | 公钥密码学基础、DNSKEY/RRSIG/DS/NSEC/NSEC3/CDS语义、算法与摘要状态（RFC 8624/9904） | 第2页 |
| A2 | 区域签名部署 | 签名工作流、ZSK/KSK/CSK分离、主流签名工具、NSEC vs NSEC3、常见部署陷阱 | 第3页 |
| A3 | 密钥管理与轮换 | ZSK/KSK轮转剧本、双算法/双签名滚动、CDS/CDNSKEY自动滚密钥、时序（RFC 7583/5011） | 第4页 |
| A4 | 验证体系与递归侧部署 | 验证解析器、DO位、验证状态机、根信任锚与滚动、验证率测量 | 第5页 |
| A5 | 故障排查与运维监控 | Bogus归因分类、delv/dig诊断、签名新鲜度与轮转监测、典型案例 | 第6页 |
| A6 | 部署测量与生态评估 | 全球/区域部署与验证率统计、障碍分析、加密DNS协同、国内（.cn/CNNIC）视角 | 第7页 |
| A7 | 案例、风险与实施路线图 | 真实故障/中断复盘、部署风险评估、分阶段实施清单 | 第8页 |
5.1 关键技术方法（总览）
- 签名与校验：基于BIND dnssec-signzone、Knot DNS、PowerDNS、OpenDNSSEC等工具实现离线/在线签名，并以dig +dnssec / delv 进行端到端验证。
- 密钥运维：采用ZSK/KSK（或单一CSK）分离，配合CDS/CDNSKEY实现父区DS自动同步，降低人工错误。
- 验证监测：在递归侧开启dnssec-validation，结合APNIC等公开测量量化"验证开启率"与"验证失败归因"。
- 故障收敛：建立签名TTL/有效期告警、轮转状态机与回滚预案，避免单点误配导致Bogus全网阻断。
06 · 常见认知误区与术语辨析
DNSSEC在传播与运维中常被误读，以下辨析直接决定部署与验证结论的严谨性：
| 误区/混淆 | 辨析 |
|---|---|
| "DNSSEC = 加密DNS" | 错误。DNSSEC不加密应答内容，只保证真实性与完整性；加密由DoT/DoH/DoQ负责。二者目标不同、可叠加使用。 |
| "开了DNSSEC就绝对安全" | 错误。仅当递归侧真正执行验证且结果Secure时才生效；父链任一层缺失/错误即退化为Insecure甚至Bogus。 |
| "签名一次永久有效" | 错误。RRSIG有签名有效期（signature validity），过期未重签会被判Bogus；须持续重签与轮转。 |
| "NSEC会泄露全部域名" | 部分成立。NSEC明文枚举区内容；NSEC3以哈希缓解，但弱哈希仍可离线爆破，故需合理选参（见第2、3页）。 |
| "KSK与ZSK是一回事" | 错误。KSK（flag 257）只签DNSKEY RRset并被父区DS背书；ZSK（flag 256）签其余数据。分离便于高频轮转ZSK而不动父区DS。 |
| "验证率=部署率" | 错误。区已签名（部署）不等于查询被验证（验证率）。APNIC约34%用户处于验证解析器之后，但实际被验证查询仅约1%。 |
6.1 核心术语速查
| 术语 | 释义 |
|---|---|
| 信任锚 TA | 验证方预置/自动接纳的根级DNSKEY，是链式信任的起点（根区KSK-2017为现行锚）。 |
| 链式信任 | 从根TA逐级经DS背书、DNSKEY签名，验证到叶RRset的完整路径。 |
| ZSK / KSK / CSK | 区签名密钥 / 密钥签名密钥 / 合并签名的单一密钥（Combined Signing Key）。 |
| RRSIG / DS / NSEC | RRset签名 / 父区对子区KSK的摘要委托 / 否定存在证明（含NSEC3哈希变体）。 |
| Secure/Bogus | 验证通过 / 验证失败（链断裂或被篡改），Bogus将被验证解析器拒绝应答。 |
| CDS/CDNSKEY | 子区自声明的新DS/DNSKEY，供父区自动同步，是自动化滚密钥的关键（RFC 7344）。 |
07 · 研究边界与合规声明
合规与伦理声明：①本课题全部技术路线以防御与正确运维为目的，严格遵守《网络安全法》《数据安全法》《个人信息保护法》及等保2.0要求；②课题涉及的DNSSEC部署、验证与测量均在授权环境与公开数据范围内开展，严禁针对任何未授权目标；③对算法状态、部署统计的引用均标注RFC版本与统计时点/来源，所有引用均标注出处；④引用RFC与IANA注册表内容遵循其公开文档的使用条款；⑤文中涉及的密钥操作与轮转仅用于理解防御与构建稳健运维，不对外提供可直接复用的攻击实现；⑥面向国内关键信息基础设施的DNSSEC部署，须结合《关键信息基础设施安全保护条例》与等保2.0等国内合规锚点——DNSSEC部署不构成合规替代，合规结论以国内正式测评体系为准。
知识产权边界：DNSSEC相关RFC由IETF维护并以Trust Legal Provisions（TLP）发布；IANA注册表数据可公开使用。本课题在研究与教学材料中引用相关条目时保留其出处标注，不对标准与注册表内容本身主张任何权利。
08 · 预期成果与交付物
- 《DNSSEC部署与验证最佳实践》研究报告一份（含区域签名、密钥轮换、验证监测与故障排查规范）
- 算法与摘要选用对照表（RFC 8624/9904口径）及NSEC/NSEC3选型决策树
- ZSK/KSK/CSK 轮转剧本与 CDS/CDNSKEY 自动化流程模板
- 递归侧验证部署与 Bogus 归因排查手册（delv/dig 实战）
- DNSSEC 部署测量与验证率评估模板（APNIC等口径对齐）
- 常见认知误区与术语辨析速查表（培训配套）
本节参考来源（第1页）
以下均为真实可查的权威来源（IETF RFC Editor、ICANN、APNIC、IANA、ISOC），用于支撑本页事实性表述。
RFC 8624 — Algorithm Implementation Requirements and Usage Guidance for DNSSEC（2019）：rfc-editor.org/rfc/rfc8624
RFC 9904 — DNSSEC Cryptographic Algorithm Recommendation Update Process（2025，IANA注册表治理）：rfc-editor.org/rfc/rfc9904
ICANN — Review of the 2018 DNSSEC KSK Rollover（2019-03-04）：icann.org/review-2018-dnssec-ksk-rollover.pdf
RFC 5011 — Automated Updates of DNSSEC Trust Anchors（2009）：rfc-editor.org/rfc/rfc5011
APNIC Blog — "Calling time on DNSSEC?"（2024-05-28，全球验证率/签名域名统计）：blog.apnic.net/2024/05/28/calling-time-on-dnssec
APNIC Labs — DNSSEC Validation Measurement：stats.labs.apnic.net/dnssec
Internet Society Pulse — DNSSEC Adoption/Validation API：pulse.internetsociety.org
IANA — DNSSEC Algorithm Numbers / DS Digest Algorithms 注册表：iana.org/assignments/dnssec-algorithms
RFC 9364 — DNS Security Extensions (DNSSEC)（BCP 237，2023，DNSSEC RFC导览与最佳实践声明）：rfc-editor.org/rfc/rfc9364
ICANN — Root Zone DNSSEC Signing Ceremony / 根区签名公告（2010年起）：icann.org/resources/pages/dnssec