01 · 典型故障案例（真实事件）
以下四个事件均出自可查的权威记录（Comcast/NASA联合分析报告、Internet Society、ICANN培训材料、IETF社区 outage 档案）。它们的共同点是：DNSSEC本身"正确地"拒绝了非法/错误的应答，问题几乎都出在"运维侧"——签名过期、密钥轮转失误、父链DS不一致、区域文件损坏被签名。
NASA.gov 签名错误
NASA在密钥轮转时未完成"双签名（double-signing）"过渡：区域用新KSK签名，但上级 .gov 的 DS 记录仍指向旧KSK，链式信任断裂。恰逢 Comcast 刚为约2000万用户开启DNSSEC验证，验证解析器返回失败，用户无法访问。
教训：轮转必须"先加新、等传播、再撤旧"；此事发生在SOPA/PIPA网络抗议"黑屏日"，一度被误传为Comcast故意屏蔽。Comcast与NASA事后联合发布详细分析报告。
HBO Now 上线即断
HBO Now 产品发布期间，hbonow.com 在 .com 存在 DS 记录指向某 DNSKEY（id 51249），但该密钥在区域中并不存在。Comcast、Google Public DNS 等验证解析器据此判定 Bogus、返回 SERVFAIL，用户无法下单。
教训（反面）：HBO 的"修复"是直接移除DNSSEC退回未签名——等于放弃真实性保障。正确做法应是补齐缺失的DNSKEY或同步DS（详见第3、6页）。事件被 IETF 社区 outage 档案与 ISOC 收录。
瑞典 .se TLD 全网中断
瑞典国家顶级域 .se 在例行操作中，一份已损坏的区域文件（NS记录错误）被照常签名。DNSSEC"正确地"证明了这份损坏数据的完整性，导致整个 .se 对所有验证解析器不可达，持续数小时。
教训：DNSSEC验证的是"未被篡改"，而非"语义正确"。签名前必须先做区域校验（zone validation），否则"垃圾进、加密签名的垃圾出"。
根 KSK 轮转
根区自2010年首次签名（KSK-2010）。因准备不足，原定2017年的轮转推迟，最终于2018-10-11完成（KSK-2017 发布到根区），旧锚于2019-01-11撤销。这是史上首次根信任锚更换。
教训：递归侧的信任锚更新是"全员必做"的操作；RFC 5011 的30天自动接受机制、以及根锚手动更新流程，须纳入运维日历，否则旧锚失效后将大面积 Bogus。
严谨声明：上述事件的时间、根因与处置均以 Comcast/NASA 联合报告、Internet Society(Deploy360)、ICANN《DNSSEC for Everybody》培训、IETF 社区 DNSSEC outage 档案等公开材料为依据。部分细节（如NASA究竟是"轮换失误"还是"密钥过期"）在不同复述中存在口径差异，本页采用 Comcast 工程分析的"双签名/DS不一致"口径，并保留必要存疑标注。
02 · 故障根因归类
把四个案例抽象为可管理的失效模式，便于在部署中"对症设防"：
| 失效模式 | 机理 | 典型触发 | 对应防线（详见各页） |
|---|---|---|---|
| 签名过期 | RRSIG 超过有效期，验证器判 Bogus | 自动重签失效、TTL/有效期配置过大或无人值守 | 第6页：签名新鲜度监测 + 告警阈值 |
| 密钥轮转失误 | 新旧密钥/DS未充分重叠，链路断裂 | 手动轮转、双签名窗口不足、DS未同步 | 第4页：RFC 6781 时序 + CDS 自动化 |
| 父链DS不一致 | 父区DS指向不存在/不匹配的DNSKEY | 签名后忘记在注册商处提交DS | 第3页：上线前 DNSViz 校验链 |
| 区域损坏被签名 | 错误数据被签名，完整性"正确"但语义错误 | 签名前置校验缺失 | 第3页：签名前 zone validation |
| 信任锚失配 | 递归侧信任锚未更新/错误 | 根KSK轮转、私有根锚漂移 | 第5页：RFC 5011 / 锚更新流程 |
| 算法/协议不兼容 | 选用验证器不支持的算法（如算法17） | 激进启用国密/新算法而未验证链路 | 第2页：RFC 8624 算法选型 |
统一结论：所有失效模式都可被"自动化 + 上线前验证 + 持续监测"三件套覆盖。这正是本子课题反复强调"优先自动化（CDS/CDNSKEY、inline-signing）"与"部署 delv/DNSViz 验证闭环"的原因。
03 · 风险评估矩阵
从"发生可能性"与"业务影响"两个维度评估DNSSEC相关风险，指导资源投放优先级（"高/中/低"为相对量级判断，非精确定量）：
| 风险项 | 可能性 | 影响 | 综合等级 | 缓释措施 |
|---|---|---|---|---|
| 签名过期导致 Bogus 断网 | 中 | 高 | 高 | 重签自动化 + 新鲜度监测告警 |
| 密钥轮转/DS同步失误 | 中 | 高 | 高 | CDS自动滚密钥 + 演练 |
| 父链DS不一致（忘记提交DS） | 高 | 高 | 高 | 上线前 DNSViz/ delv 校验 |
| 递归侧信任锚未更新 | 低 | 高 | 中 | RFC 5011 自动更新 + 锚日历 |
| 启用不被支持的算法（如17） | 低 | 中 | 低 | 仅选 RFC 8624 MUST/RECOMMENDED |
| 应答放大/运维开销上升 | 中 | 低 | 低 | EDNS0/TCP回退 + 容量规划 |
风险等级为相对排序，用于决策"先防什么"；具体量化应结合资产重要度与流量占比自行评估。
04 · 分阶段实施路线图
把"部署DNSSEC"拆成四个阶段，每阶段以"可验证的产出"为里程碑，避免一次性大爆炸式切换：
| 阶段 | 关键动作 | 退出标准（验收） |
|---|---|---|
| 1 准备 | 资产/链路盘点、算法选型、注册商DS能力确认、轮转策略文档化 | 具备可签名区域清单与策略文档 |
| 2 试点 | 测试区签名、delv 自验证、DNSViz 链路闭合、ZSK轮转演练 | delv 判定 Secure、轮转演练通过 |
| 3 签约 | 生产区签名、提交DS、观察窗口、监控解析成功率 | 生产域名 Secure 且无解析率下降 |
| 4 运营 | CDS自动轮转、新鲜度监测、Bogus告警、纳入变更/演练 | 轮转自动化上线、告警有效触发 |
05 · 场景优先级建议
结合第7页"部署—验证"落差分析，本课题主张"分场景、分优先级"推进，把有限的运维能力投到价值最高的域名上：
递归侧同样要"先动手"：应用侧不感知DNSSEC保护（第7页已述），因此组织机构应自建/选用开启验证的解析器（Unbound/BIND/Knot/公共DNS），让"被验证"在内部真实发生，而不只是依赖所访问域名是否签名。这是提升实际保护率性价比最高的动作。
06 · 合规与国内落地
- 等保2.0 与 关基条例：关键信息基础设施运营者的网络安全保护义务，可将DNSSEC纳入"网络架构安全/通信传输完整性"的强化手段；具体条款以最新法规与测评要求为准，本课题不代行合规认定。
- 国密算法选项（RFC 9563）：我国CNNIC主导的 RFC 9563 已将国密 SM2/SM3 引入DNSSEC（算法17、SM3摘要类型值6），为"自主可控"提供标准依据。但其为独立提交流程、且多数实现尚不支持，落地前须验证解析器与验证器链路的互操作性（呼应第2页算法选型）。
- 数据与管辖衔接：涉及根区/TLD/注册局的信任锚与DS提交，须遵循对应注册管理机构（如CNNIC、Verisign）的接口与流程；私有网络可部署私有根与信任锚，但须自行管理锚更新。
- 加密DNS协同：与子课题03（DoH/DoT/DoQ）一致，企业内网可部署"受控验证解析器 + 加密上行"，兼顾真实性、机密性与可审计（见第5、7页）。
边界声明：本页合规相关表述为通用性提示，不构成法律意见；具体合规要求以主管部门最新发布为准。关于".cn 等国内域当前签名/验证状态"以 CNNIC/ICANN 官方公告为准，本课题不臆测比例与日期。
07 · 本子课题交付回顾
本子课题（DNS解析安全 · 子课题02）以八页系统覆盖了DNSSEC"为什么→是什么→怎么签→怎么转→怎么验→怎么查→怎么测→怎么落"的完整链路：
| 页 | 主题 | 核心交付 |
|---|---|---|
| 01 | 研究总览与框架 | RFC谱系、链式信任模型、算法状态、八页框架、研究边界 |
| 02 | 密码学与资源记录 | 公钥模型、DNSKEY/RRSIG/DS/NSEC/NSEC3/CDS 解析、算法选型 |
| 03 | 区域签名部署实战 | ZSK/KSK/CSK、工具链对比、NSEC3、父链DS、部署清单 |
| 04 | 密钥管理与轮换 | 轮转类型、RFC 7583时序、CDS自动滚密钥、应急手册 |
| 05 | 验证体系与递归侧 | DO/AD位、验证状态机、根信任锚/RFC 5011、Aggressive NSEC |
| 06 | 故障排查与运维监控 | Bogus归因、delv/dig诊断、签名新鲜度监测、监控体系 |
| 07 | 部署测量与生态评估 | 部署/验证率落差、障碍分析、与加密DNS协同、国内视角 |
| 08 | 案例、风险与路线图 | 真实案例、根因归类、风险矩阵、分阶段路线图、合规落地 |
贯穿全课题的原则：以自动化降低运维失误、以上线前验证（delv/DNSViz）保证链路闭合、以持续监测守住新鲜度与可用性——把"误配即断网"的劣势，转化为"可控、可观测、可回退"的工程能力。
本节参考来源（第8页）
以下为真实可查的权威来源，支撑本页关于真实事件、根因归类、轮转时序与合规提示的事实表述。
Dan York (Internet Society/Deploy360) — "Comcast Releases Detailed Analysis of NASA.gov DNSSEC Validation Failure"（2012-01-25，Comcast/NASA联合技术报告的权威解读）：internetsociety.org/blog/2012/01/comcast-releases-detailed-analysis-of-nasa-gov-dnssec-validation-failure
Dark Reading — "DNSSEC Error Caused NASA Website To Be Blocked"(2012)：darkreading.com/risk/dnssec-error-caused-nasa-website-to-be-blocked
Dan York (Internet Society/Deploy360) — "HBO NOW DNSSEC Misconfiguration Makes Site Unavailable From Comcast Networks (Fixed Now)"（2015-03-10）：internetsociety.org/blog/2015/03/hbo-now-dnssec-misconfiguration-makes-site-unavailable-from-comcast-networks-fixed-now
IETF 社区 DNSSEC Outages 档案 — hbonow.com（2015-03-09/10）：ianix.com/pub/dnssec-outages/20150309-hbonow.com
ICANN — 《Review of the 2018 DNSSEC KSK Rollover》/ 根KSK轮转（2017–2019）：icann.org KSK Rollover Report
RFC 5011 — Automated Updates of DNSSEC Trust Anchors（30天接受机制）：rfc-editor.org/rfc/rfc5011
CNNIC — RFC 9563《域名服务系统安全扩展(DNSSEC)中的SM2算法》(2024-12-13)：cnnic.net.cn/n4/2024/1213/c208-11193.html