01 · 解析基础设施的可用性风险
DNS 的"集中化"使其既是便利也是风险：少数权威/递归服务商承载海量流量，一旦被 DDoS 或自身故障，影响被同步放大。安全三属性中，DNS 的可用性（Availability）常被完整性/机密性研究遮蔽，却是关基（关键信息基础设施）最关心项之一。可用性工程的基本度量是 SLA/SLO、MTTR（平均修复时间）与 RTO（恢复时间目标）；而 DNS 的"可用"至少要区分四档——可达（53端口可握手）、可答（返回有效应答）、答得对（与权威一致）、答得快（P95/P99时延达标）。许多"DNS事故"只破坏了后两档。
- 外部威胁：以 DNS 服务为目标或借 DNS 放大的 DDoS（见子课题04放大攻击）、针对权威服务器的查询洪泛（Dyn 2016 即此型）、NXNSAttack 类委托放大（USENIX Security 2020）。
- 内部脆弱：单点部署、NS 缺乏多样性（同机房/同ASN/同云账户）、TTL 过长导致故障切换迟缓、配置/人为错误（Facebook 2021、AWS 2025 均属此类根因）。
- 级联特性：解析中断会让依赖域名的网站、API、邮件、证书签发同时失效，并触发客户端/递归器重试风暴放大权威负载（详见分页第6页"三段级联失效模型"）。
02 · 重大中断事件复盘（公开报告口径）
| 事件 | 根因 | 启示 |
|---|---|---|
| Dyn 2016-10-21 | Mirai 僵尸网络对权威DNS商 Dyn 发起多波次 UDP/53 查询泛洪，涉及数千万级伪造源IP，峰值带宽约1.2 Tbps（第三方估算口径），Twitter/Netflix/GitHub 等上百家站点同时不可达，三波次持续约11小时 | 权威服务高度集中化会放大单点失效；Anycast稀释有容量阈值；多Provider必须预置 |
| Facebook 2021-10-04 | 例行维护命令在审计工具失效下断开骨干 BGP，权威 DNS 路由消失；运维系统与生产共用域名与网络平面形成"自举死锁"，约7小时后物理介入恢复 | DNS 与路由/配置强耦合；管理面必须与生产面分域，配置护栏与带外管理是底线 |
| AWS US-EAST-1 2025-10-19/20 | 维护操作竞态条件意外删除 DynamoDB 服务内部 DNS 记录，自动化修复失效、需人工逐节点恢复，区域级联持续约15.5小时，波及全球依赖服务 | 内部服务发现DNS是最高等级关键基础设施；MTTR由组织因素（告警分级、修复通道）主导 |
| Azure DNS 2019-05-02 | DNS 基础设施退化导致全球 Azure 服务名称解析失败约2.5小时 | 解析面是所有云服务的公共依赖，云内冗余不覆盖解析面 |
| Cloudflare 2019-07-02 | WAF 一条正则规则灾难性回溯耗尽全球边缘节点 CPU，约30分钟 | 非DNS根因也会经全球任播DNS被放大为全网事件；规则上线须压测与灰度 |
口径声明：上述事件的具体根因与时间线以厂商事后报告与权威媒体复盘为准（Meta官方工程博客、Cloudflare技术分析、AWS官方事后总结、各状态页历史），本页仅作韧性研究的实证参照；估算类数字（如收入损失、攻击峰值带宽）均标注"估算/约数"并说明口径，不臆测细节。
03 · 权威侧韧性
- Anycast：同一 IP 前缀在多处公告，流量就近进入、天然分摊 DDoS；根服务器系统（13 个逻辑标识，实际 2,000+ 任播实例，root-servers.org）即典型实践。吸收能力受单点/上游容量约束，超限后表现为局部拥塞而非优雅分摊（RFC 4786、RFC 7094，分页第3页）。
- NS 多样性：RFC 2182 要求辅/根名服务器在网络、机房、运营商、组织层面充分独立；现代扩展为八维失效域模型（机房/AS/前缀/软件/提供商/云账户/控制面/注册商，分页第4页）。"3条NS记录"若同属一个失效域，其冗余即退化为单点。
- 多Provider预置：两家DNS提供商的权威常态化共存于同一NS集合（配RFC 8901多签名者DNSSEC），是Dyn型单提供商全局故障的唯一架构级对冲；"事后接入"在NS父区缓存（24—48h TTL）面前物理不可行（分页第4、7页）。
- TTL分级设计：基础设施记录（NS/MX）长TTL换取缓存缓冲与切换确定性，调度记录短TTL换取GSLB敏捷；应急时临时改TTL不救近火（分页第4页）。
04 · 客户端/递归韧性
- 缓存缓冲带：正缓存+负缓存（RFC 2308）+serve-stale（RFC 8767）+预取，把权威中断转化为可容忍的降级；须治理stale的数据陈旧与恢复期重试雪邦（分页第5页）。
- 多解析器回退：终端配置多组递归并按健康探测切换；Happy Eyeballs（RFC 8305）竞速思想可延伸到"先到达的有效解析"，把故障发现从秒级压到亚秒级。
- SVCB/HTTPS 与加密DNS发现：SVCB/HTTPS 记录（RFC 9460，2023年11月发布）允许域名声明备用端点/参数；DDR（RFC 9462）与DNR（RFC 9463）使加密解析升级自动协商、失败可回退——但故障域也随之收敛至少数超级端点，需要治理（分页第5、7页）。
05 · 运维韧性实践
- 可观测：解析成功率、SERVFAIL/NXDOMAIN率、各权威命中分布、解析时延P95/P99纳入监控告警，按"可达/可答/答得对/答得快"四层定义SLI（呼应子课题04、05，分页第8页）。
- 演练：授权环境下的故障演练清单（D1—D10：单NS故障、单Provider故障、权威全失效、递归故障、TCP/53中断、重试风暴、路由面事故、公共DoH不可达、控制面失效、Zone漂移），全部演练预设熔断条件（分页第8页）。
- 合规基线：参照 NIST SP 800-81、等保2.0（GB/T 22239-2019）与《关键信息基础设施安全保护条例》落实容灾、演练与报告义务；故障演练仅限获得明确授权的内部环境，严禁对未授权目标开展压力测试。
边界声明：本页为子课题06概览，深度韧性度量（失效域模型、SLI/SLO、混沌演练）见八个分页；关基单位的可用性目标与报告口径以国内监管要求为准。国际最佳实践不构成国内合规结论。
06 · 全文八页分页导航
子课题06全文按"体系认知 → 逐层深挖 → 事件校验 → 度量收口"组织为八个分页，建议按页序阅读：
参考来源
以下均为真实可查的权威来源（IETF RFC、IANA/ICANN、运营方官方报告、权威机构分析），链接经逐一核验（2026年9月）。
RFC 1034 / RFC 1035（1987）：域名系统概念与实现规范，DNS标准化基石。rfc-editor.org/rfc/rfc1035
RFC 8499（2019）：DNS Terminology，DNS术语权威定义。rfc-editor.org/rfc/rfc8499
RFC 2182（1997）：Selection and Operation of Secondary DNS Servers，权威冗余设计经典原则。rfc-editor.org/rfc/rfc2182
RFC 4786（2006）：Operation of Anycast Services；RFC 7094（2014）：IP Anycast架构与测量方法学。rfc-editor.org/rfc/rfc4786
RFC 8767（2020）：Serving Stale DNS Data，过期缓存应答机制。rfc-editor.org/rfc/rfc8767
KrebsOnSecurity（2016-10-22）：DDoS on Dyn Impacts Twitter, Spotify, Reddit——Dyn事件权威媒体报道（经核验链接有效）。krebsonsecurity.com；Dyn官方分析声明（原文已随Oracle收购下线，可检索"Dyn Analysis Summary Of Friday October 21 Attack"经Web Archive查证）
Cloudflare博客（2021-10）：Understanding how Facebook disappeared from the Internet，BGP/DNS耦合分析。blog.cloudflare.com/october-2021-facebook-outage
Meta官方（2021-10-04/05）：More details about the October 4 outage，Facebook中断根因与自举死锁的官方复盘。about.fb.com/news
GitHub官方事件报告（2018-03-01）：February 28th DDoS Incident Report，1.35 Tbps峰值与51,000倍放大系数官方口径。github.blog（经核验链接有效）
AWS官方博客（2020-10）：AWS Shield事件复盘——缓解2.3 Tbps DDoS攻击。aws.amazon.com（AWS Shield官方渠道）
ICANN：Root Zone KSK Rollover官方项目页（2018年首次轮换，2017年推迟决定与RFC 8145测量依据均收录；2026年第二次轮换安排见第2页前瞻）。icann.org（经核验链接有效）
root-servers.org（13个逻辑根的运营方与全球任播实例实时聚合信息）：root-servers.org；IANA Root Zone Database：iana.org/domains/root/db