01 · 放大机理与责任分层
1.1 为什么递归器是天然放大器
反射放大攻击需要三个要素，递归解析器恰好全部具备：①UDP无连接——查询报文无需握手，源地址字段可被任意伪造；②应答远大于查询——对ANY、TXT、大RRset等QTYPE的应答可达查询体积的数十倍（CISA TA13-088A将其列为最常被滥用的协议之一）；③开放可达——对任意源提供递归服务的53端口。攻击者伪造受害者的IP作为源地址向海量开放递归器发小查询，递归器的大应答便汇聚成针对受害者的DDoS洪流。
1.2 治理责任必须在网络层与解析层之间切分
| 责任层 | 机制 | 责任主体 |
|---|---|---|
| 网络层（源头） | BCP38入口过滤（RFC 2827，更新见RFC 3704/RFC 6959）：丢弃源地址不属于入网前缀的出口包；uRPF反向路径校验 | 各接入ISP与云厂商——递归器运营者无根治能力，但应在采购SLA中要求 |
| 解析层（放大器侧） | 递归收敛、RRL、ANY最小化、容量冗余 | 递归器运营者——本课题直接审计对象 |
| 受害者侧 | Anycast分布式吸收、DDoS清洗、上游黑洞路由协作 | 受害者及其网络服务商（第8页Spamhaus复盘即为此类实践） |
审计要点：评估一家组织的递归安全姿态时，"你的上游是否部署BCP38"不在其控制范围内，但"你的递归是否仅对内开放、是否启用RRL、ANY应答体积多大"完全可控。审计报告应明确区分可控项与协同项，避免把网络层缺陷算在DNS团队头上，也反过来防止DNS团队把自身暴露面推卸给"上游过滤总会有的"。
02 · 开放递归现状与测量
2.1 历史基线与下降通道
Open Resolver Project等长期测量项目的公开结果显示，全球可被任意源使用的开放递归解析器数量曾长期处于数千万量级，随后在各运营商、云厂商与开源社区的持续治理下呈下降通道，但从未归零。
测量口径与数据来源说明：Open Resolver Project 的公开统计覆盖 2013 年 3 月至 2017 年 1 月，此后项目停止更新，引用其数据时须注明历史区间；当前持续性全网测量以 Shadowserver 的 DNS Open Resolvers Report 为代表（每日对全网 IPv4 地址的 53/UDP 进行探测并向网络所有者通报），学术论文《Swamp of Reflectors: Investigating the Ecosystem of Open DNS Resolvers》（PAM 2024）亦证实残余开放解析器生态仍被反射攻击持续滥用。
测量的难点在于"开放"的定义口径：对RD=1查询返回RA=1且给出非拒绝应答即判定为开放递归——不同扫描器对超时、TC回退与分片的处理差异会导致统计偏差，因此跨来源数据横向对比时必须先对齐口径。
2.2 三个容易混淆的"开放"形态
| 形态 | 特征 | 审计定性 |
|---|---|---|
| 裸奔开放递归 | 任意源RD=1均可递归，无速率限制、无容量冗余 | 必须收敛（高危） |
| 受控公共递归 | 开放但配严格per-client限流、Anycast冗余、滥用响应工单通道（如主流公共DNS） | 业务设计使然，审计其限流实效 |
| 仅权威应答 | 对RD=1返回REFUSED/无AA应答，但权威记录对全球可见 | 非开放递归，属权威面问题（不属本子课题） |
2.3 组织自测方法（授权前提下）
- 外部视角探测：从互联网不同位置（云主机、家宽、4G/5G出口）对递归器IP发RD=1查询，比对应答中的RA标志与结果一致性；nmap的
dns-recursionNSE脚本即为该检测的自动化实现之一。 - 配置与行为交叉验证：外部探测为"黑"，配置核查（allow-recursion/allow-query-cache等ACL）为"白"，二者不一致时以"行为证据"为准——配置漂移是常见根因。
- 影子资产排查：历史遗留测试实例、容器默认配置、云安全组0.0.0.0/0误放行的53端口，是开放递归最常见的"意外来源"。审计须纳入资产盘点，而非只查在册系统。
03 · 纵深防御四件套
3.1 递归收敛：最小权限原则
企业递归器的默认姿态应是"仅服务本网段"：BIND以allow-recursion与allow-query-cache分别约束递归功能与缓存读取（两者作用于不同语义面，审计须分别核查）；Unbound以access-control声明各网段的allow/deny/refuse动作；PowerDNS Recursor以allow-from控制。任何0.0.0.0/0的放行都必须有业务文书支撑，并配套3.2的速率限制。
3.2 ANY响应最小化（RFC 8482）
对QTYPE=ANY的查询，权威可返回最小化应答（如HINFO占位记录或截断提示），将放大体积压至接近普通查询量级。注意两点边界：①RFC 8482约束的是"应答方行为"，递归器侧的正确动作是把ANY作为普通QTYPE迭代转发并接受权威的最小化应答，而非自行伪造内容；②审计时以"实测ANY应答体积/迭代查询体积"的比值作为放大系数基线，长期监测其突变。
3.3 容量冗余与Anycast
单点递归器无论配置多优都扛不住定向大流量。工程惯例是Anycast多节点发布（同IP全球多点部署，路由就近牵引）叠加弹性容量。对不具备自建Anycast条件的组织，最低基线是：多上游转发冗余（见第6页）、与ISP/云厂商签订DDoS清洗SLA、关键时段的TTL预降策略（在攻击窗口前主动降低权威记录TTL以加速切换——该策略本身是双刃剑，须在演练中验证）。
3.4 流量基线与异常告警
纵深防御的最后一层是"看得见"：按QTYPE分布、源/目的熵、NXDOMAIN占比、单客户端速率、UDP/TCP比例建立基线；偏离基线即告警。第7页给出完整度量清单。
04 · RRL机制与参数工程
4.1 令牌桶原理与"截断替代丢弃"
RRL（Response Rate Limiting）针对"同一响应（按源/目标聚合）的重复速率"设限：窗口期内超出配额的重复响应被丢弃，并按slip参数决定每N次丢弃中有一次改为返回截断应答（TC置位）。这一设计的关键洞见是：真实客户端收到TC会回退TCP重试并拿到完整答案，而放大攻击洪流中的伪造源不会重试——TC滑窗因此成为区分"合法重试"与"滥用水流"的低成本探针。
4.2 参数建议（须按基线校准，标注为工程惯例值）
| 参数 | 常见设置区间 | 含义与调参逻辑 |
|---|---|---|
| window | 5–15秒 | 统计滑动窗口；窗口过长会误伤合法突发，过短则过滤效果差 |
| responses-per-second | 5–20次/秒 | 单类响应的速率阈值；公共递归场景应显著低于该区间并叠加per-client限流 |
| slip | 2–10 | 每N次超额丢弃中发1次TC截断；slip=2时约一半超额流量仍被直接丢弃 |
| errors-per-second | 对照NXDOMAIN/SERVFAIL子集单独设限 | 水刑攻击的主力过滤面：对NXDOMAIN类错误响应单独限速，压制随机子域泛洪 |
参数区间综合ISC BIND ARM与运营实践惯例整理，不构成唯一正确值；生产调参应以本组织流量基线为准，并在变更窗口内灰度验证。
4.3 实现差异与审计动作
- BIND：rate-limit配置块，支持per-domain与per-server细化，drop/log动作可观测；
- Unbound：ratelimit（对客户端）与domainratelimit（对域）等独立旋钮，语义与BIND不同，迁移配置时不可照抄数值；
- 审计动作：核查RRL启用状态→抽样调压验证→确认被丢弃/截断事件写入日志且可被监控消费→将"RRL触发次数"纳入第7页KRI面板。
05 · 两大事件复盘
5.1 Spamhaus事件（2013年3月）
公开事实：反垃圾邮件组织Spamhaus因将某网络服务商相关网段列入阻断名单引发纠纷，随后遭受大规模DDoS，公开报道峰值约300Gbps；攻击以DNS反射放大为主力手段之一；Cloudflare以Anycast分布式吸收承接流量，成为行业经典战例。CISA随后发布TA13-088A专项告警，系统总结DNS放大攻击机理与缓解建议。
对递归审计的启示：①受害者可能"什么都没做错"——你的递归器若开放，就是别人手里的武器，声誉与法律风险随之而来；②Anycast与上游协同是被验证有效的受害者侧手段；③事件级的跨组织协作通道（IR联系方式、滥用邮箱）应提前建立，战时再找必然延误。
5.2 Dyn事件（2016年10月21日）
公开事实：美国东部时间2016年10月21日，DNS服务商Dyn遭受Mirai僵尸网络驱动的超大规模DDoS，Twitter、GitHub、Netflix、Reddit等大量依赖其解析的站点数小时内间歇性不可达；公开分析指出数十万量级IoT终端参与；Dyn未公布官方流量峰值，媒体报道口径不一，本课题不采信任何单一流量数字。
对递归审计的启示：①解析集中化本身就是风险——单家权威/公共解析的可用性缺陷会沿依赖链放大成行业事件；②权威NS多样性（RFC 2182：至少两台、不同网络、不同管理域）与多解析服务商策略是低成本的韧性投资；③递归侧应预置"上游集体失效"的降级剧本：缓存过期策略（RFC 8767 serve-expired）、本地根提示文件的应急维护流程。
数据纪律：以上两案的流量数字均来自当时的公开报道，不同来源口径存在差异；本课题在报告中一律标注"公开报道口径"，不以估算数字充当事实。
06 · D1域审计检查清单
| 项 | 检查项 | 方法 | 合格判据 |
|---|---|---|---|
| 1 | 外部多源探测递归开放性（RD=1→RA=1非拒绝应答） | nmap dns-recursion NSE / 手工dig | 非授权源100%拒绝 |
| 2 | allow-recursion与allow-query-cache分离核查（BIND）或等效配置（Unbound access-control） | 配置审计 | 仅本网段放行 |
| 3 | RRL启用且参数经灰度验证，触发事件可观测 | 配置+日志 | 启用+有日志 |
| 4 | NXDOMAIN类响应单独限速（水刑防御） | 配置审计 | 已配置并验证 |
| 5 | ANY实测放大系数基线化并纳入监测 | 周期性测量 | 有基线+突变告警 |
| 6 | UDP/TCP 53均可用（TCP不可屏蔽，依据RFC 7766） | 连通性测试 | 双通 |
| 7 | Anycast或等效多节点冗余；无条件的组织有上游清洗SLA | 架构审查 | 冗余存在 |
| 8 | 流量基线（QTYPE分布/NXDOMAIN占比/单源速率）已建立 | 遥测核查 | 基线在跑 |
| 9 | 上游ISP BCP38部署情况的书面确认（协同项） | SLA/函件 | 有记录 |
| 10 | 滥用事件响应联系人（abuse邮箱/IR流程）公示并可达 | 演练拨测 | 可达 |
小结：D1域的目标状态可以一句话概括——不被滥用、被打不垮、异常看得见。下一页转向同样古老却从未过时的战场：缓存完整性。
本节参考来源（第3页）
事件细节以公开报道与官方通报为准，参数建议为工程惯例值并已注明。
CISA Alert TA13-088A《DNS Amplification Attacks》（2013-03-29）：cisa.gov
RFC 2827（BCP38网络入口过滤，更新：RFC 3704、RFC 6959）、RFC 2182（NS多样性）、RFC 7766（TCP）、RFC 8482（ANY最小化）、RFC 8767（serve-expired）、RFC 8906（运营常见问题）：rfc-editor.org
ISC BIND ARM rate-limit章节：bind9.readthedocs.io；Unbound ratelimit文档：unbound.docs.nlnetlabs.nl；RRL Internet-Draft（draft-jabley-dnsext-rate-limiting，未成为RFC）：datatracker.ietf.org
Open Resolver Project（开放递归历史测量，数据覆盖2013.03—2017.01，已停止更新）：openresolverproject.org；Shadowserver DNS Open Resolvers Report（当前持续测量）：shadowserver.org；PAM 2024《Swamp of Reflectors》
Spamhaus 2013事件与Dyn 2016事件的媒体报道（峰值数字为公开报道口径，存在来源差异）