01 · Anycast原理与韧性价值
Anycast（任播）指同一IP前缀在多个地理位置同时由不同节点宣告，BGP路由系统据此将用户流量引导至拓扑"最近"的节点。对权威DNS而言，任播同时带来三种韧性收益：①加速——用户访问就近节点，解析时延下降；②稀释——DDoS流量在多个节点间被地理分摊，单点承压下降；③容错——单节点下线时，BGP撤销宣告即可将其流量自动转移（收敛时间取决于路由更新传播，通常在秒至分钟级）。RFC 4786（2006）是任播运营要求的核心参考，RFC 7094（2014）则系统综述了任播测量方法学。
"吸收"的边界：任播的稀释效应存在明确阈值——当攻击流量超过单节点容量或节点上游链路容量时，受影响的不是"全部节点平均变慢"而是"攻击入口附近的节点拥塞"。2016年Dyn事件中，攻击流量被刻意分散到多个目标POP，任何cast稀释都无法应对全网规模的查询泛洪。工程评估任播吸收能力，应测量"失效比例曲线"：注入递增的测试流量，观察各节点丢包率何时越过可用阈值（此类测量必须在授权测试网或探针网络如RIPE Atlas上进行，第8页详述）。
1.1 Catchment与流量工程
任播的"就近"由BGP决策决定，而非地理距离：运营商间的对等/转接关系、Local-Pref、AS Path长度都会改变用户的实际归属节点（catchment）。这意味着catchment会随全网路由变化而漂移——某节点检修或某链路中断后，其流量可能涌向另一个节点并造成容量越限。成熟的任播运维（RFC 4786 §运营实践）要求：每个节点按"失去邻居节点后的承接量"做容量规划；重大变更前进行路由预演；持续监控各节点流量占比的异常偏移（突变往往预示攻击或路由事故）。
1.2 路由安全：任播的前置条件
任播前缀的可达性完全托付给BGP，因此路由劫持与泄漏是任播韧性的最大外部风险。缓解依赖RPKI体系：ROA（Route Origin Authorization，RFC 6482）声明合法起源AS，路由源验证（ROV）在全网过滤器层丢弃非法宣告。Cloudflare、Google等大规模任播运营方均是其前缀ROA的积极签署者；国内运营商与企业的ROA覆盖度仍是解析韧性评估的薄弱环节之一（可在RPKI RTR数据与BGP观察平台如BGPStream公开数据中查证）。
02 · 针对DNS的DDoS：攻击面与量级
2.1 攻击类型学
| 攻击类型 | 机制 | 韧性对策 |
|---|---|---|
| 查询泛洪（UDP/53） | 海量伪造源IP查询耗尽权威/递归处理与带宽 | Anycast稀释、RRL限速（第2.2节）、上游清洗 |
| 反射放大 | 利用开放解析器/支持ANY或TXT大应答的服务器，以小博大冲击受害者 | 收敛开放解析器、禁用ANY（RFC 8482）、BCP38源地址过滤（RFC 2827） |
| memcached类跨协议放大 | UDP/11211等开放性UDP服务产生万级放大 | 服务侧关闭UDP、ACL、BCP38 |
| NXNSAttack（2020） | 利用递归器对多NS委托的并发重试放大NXDOMAIN/委托查询，论文报告在特定配置下放大倍数可达上千倍（约1,620倍） | 限制委托NS处理数、响应速率限制、厂商补丁 |
| TCP/53消耗 | 耗尽递归器TCP连接表（TCP成本约为UDP的数倍） | TCP连接数限制、Cookie、上游限流；同时必须保证RFC 7766合规的TCP可用性 |
| 碎片化攻击 | 伪造第二片IP碎片（首片含UDP头被丢弃）绕过五元组防御 | 避免IP碎片化（RFC 8900）、DNS Flag Day式EDNS合规、丢弃异常碎片 |
NXNSAttack出处：Shafir et al., "NXNSAttack: Recursive DNS Inefficiencies and Vulnerabilities", USENIX Security 2020。放大倍数依实现与配置而异，论文实验环境中报告最高约1,620倍。
2.2 公开事件量级（用于容量锚定）
从Tbps到DNS查询量的换算警示：1 Gbps线速小UDP包（100字节级）约合每秒百万级查询。防御规划若以"带宽冗余"为核心指标，将严重低估查询速率型攻击（query-rate attack）的处理压力——权威服务器瓶颈通常在CPU（签名/应答构造）而非带宽。容量评估应同时给出带宽（Gbps）与包速率（Mpps/qps）两个维度。
2.3 RRL：响应速率限制
RRL（Response Rate Limiting）由ISC的Paul Vixie与Vernon Schryver设计，是BIND/Unbound广泛实现的事实标准（无对应RFC，以ISC文档与实现为准）。其原理（Vixie与Schryver的ISC技术文档）是对相同目标的重复应答按"滑动窗口+令牌桶"限速，对查询泛洪与反射放大攻击可将对权威/递归的损伤降低一到两个数量级，同时对合法客户端的误伤可控（伪造源攻击下，被限速的是受害者的IP，合法用户共享该IP时才受影响——这正是"edns-client-subnet可见性 vs 限速精度"权衡的来源）。部署要点：按节点差异化阈值（任播节点共享阈值会互相"借道"绕过）、与anycast TTL策略联动、持续监控SLIP（丢弃比例）日志。
03 · 传输层韧性纵深：TCP、Cookie与扩展信号
3.1 TCP/53不可绕开
许多运维者为"安全"封禁TCP/53，这违反RFC 7766（DNS over TCP的运维要求，2016）：大应答截断（TC=1）后必须能回退TCP，否则大应答域名（如DNSKEY、含SVCB/HTTPS记录的域名）将持续解析失败。Facebook 2021事件的分析中，Cloudflare特别指出其对TCP路径异常中断的观察。正确的韧性姿态是：保证TCP/53可用 + 对其设连接与速率上限（SYN Cookie、per-IP并发限制、TCP Keepalive RFC 7828降低短连接成本）。
3.2 DNS Cookie与零RTT认证
DNS Cookie（RFC 9018，更新RFC 7873）在请求/应答中携带双方各自生成的Cookie，为递归器与权威间提供轻量级活跃性认证：权威可据此识别并丢弃伪造源的重放泛洪（对离线投毒也有削弱作用）。其优势是零额外往返与无状态，是UDP路径上性价比最高的抗滥用机制之一；BIND、Knot、PowerDNS及主流公共递归器均已支持。
3.3 EDE与可诊断性
故障时"答得快"不如"答得明白"。RFC 8914定义扩展DNS错误（Extended DNS Errors, EDE），允许递归器在SERVFAIL等应答中附带结构化原因码（如"DNSSEC Bogus""上游超时"）。对韧性工程而言，EDE把"全网超时黑盒"变成"可分类的故障信号"，是MTTR压缩与自动故障转移决策（第5页多解析器竞速、第8页SLO告警）的前置条件。
04 · 纵深防御体系与缓解编排
单一机制无法覆盖全部攻击类型，成熟的权威DNS防护为四层纵深：
| 层级 | 机制 | 覆盖攻击类型 |
|---|---|---|
| L1 网络层 | Anycast多节点 + 上游容量 + RPKI/ROV保护路由 | 全网泛洪、节点级拥塞、路由劫持 |
| L2 速率层 | RRL、per-IP/前缀限流、TCP并发上限 | 查询泛洪、TCP消耗、反射放大落地 |
| L3 协议层 | DNS Cookie、EDNS合规、TCP可用性保障、碎片规避（RFC 8900） | 伪造源泛洪、碎片攻击、协议降级 |
| L4 清洗层 | 运营商/云清洗服务、Anycast+Unicast混合、应急切流 | 超容量事件、定向穿透攻击 |
演练要求：纵深是否有效只能用实测回答。第8页给出故障演练清单，其中针对本页内容的最低演练集为：①单节点BGP撤流（验证catchment转移与剩余节点容量）；②授权范围内的qps阶梯注入（验证RRL阈值与误伤率）；③TCP/53中断模拟（验证TC回退链路）。
本节参考来源（第3页）
RFC 4786（2006）：Operation of Anycast Services。rfc-editor.org/rfc/rfc4786
RFC 7094（2014）：Architectural Considerations of IP Anycast（含测量方法学综述）。rfc-editor.org/rfc/rfc7094
RFC 7766（2016）：DNS Transport over TCP - Operational Requirements。rfc-editor.org/rfc/rfc7766
RFC 7828（2016）：The edns-tcp-keepalive EDNS0 Option。rfc-editor.org/rfc/rfc7828
RFC 9018（2021）：DNS Cookies（更新RFC 7873）。rfc-editor.org/rfc/rfc9018
RFC 8914（2020）：Extended DNS Errors（EDE）。rfc-editor.org/rfc/rfc8914
RFC 8482（2019）：QTYPE=ANY的最小化应答。rfc-editor.org/rfc/rfc8482
RFC 8900（2020）：IP Fragmentation Considered Fragile。rfc-editor.org/rfc/rfc8900
Shafir et al., "NXNSAttack: Recursive DNS Inefficiencies and Vulnerabilities", USENIX Security 2020。usenix.org
AWS官方博客（2020-10）：缓解2.3 Tbps DDoS攻击披露。aws.amazon.com；GitHub官方事件报告（2018）。github.blog
RFC 2827 / BCP 38（2000）：Network Ingress Filtering，抑制源地址欺骗的入口过滤最佳实践。rfc-editor.org/rfc/rfc2827；CAIDA BCP38项目（入口过滤部署与测量）：caida.org/projects/bcp38；Vixie & Schryver《Response Rate Limiting in the Domain Name System (DNS)》（ISC技术文档，RRL原始规范，无正式RFC，经ISC及实现文档可查）。