JPRS联合九家日本ISP在2019–2020年实测了同时开启fetch-limit与serve-stale的全服务解析器，验证其吸收海量查询洪峰、避免向权威服务器放大攻击流量的效果，并梳理出配置参数与运维指标的实际表现。
实验背景与特性选型：
实验针对僵尸网络发起随机子域查询导致解析器向权威服务器转发海量迭代请求的场景。fetch-limit通过限制并发迭代查询数量直接抑制上游压力；serve-stale则在权威无响应时返回过期缓存维持服务可用。JPRS当时排除NSEC激进使用与DNS Cookie：.jprs采用NSEC3 opt-out签名，无法在opt-out区证明不存在性，激进NSEC失效；DNS Cookie因RFC 7873在DNSOP修订中，存在任播多实现混部与密钥轮换问题，暂不启用。
攻击模拟与评估场景：
使用dnsperf发送大量查询模拟DDoS攻击，不涉及源IP地址分析，亦未测试DNS响应速率限制（RRL）。评估场域设定真实可解析域名rd2020-theme2.jprs，在互联网部署受害权威服务器[A]与[B]。步骤1建立攻击基线；步骤2令服务器[A]不响应，观察fetch-limit节流与serve-stale回退行为；步骤3恢复[A]并使[B]失效，验证双特性协同下的缓存命中与迭代抑制效果。原文未给出具体吞吐量、延迟或丢包率数据。
运维层面的配置与观测发现：
实测过程中发现各实现存在差异化配置旋钮，需逐一调优fetch-limit阈值与serve-stale的TTL容忍窗口。统计计数器新增了迭代查询被限流次数、过期回答服务次数等指标，日志输出亦增加对应事件标记，便于告警关联。原文未给出具体计数器名称或日志格式细节。
对网络工程师而言，实测确认双特性协同可在不依赖源IP限速的前提下缓解随机子域攻击，但需注意NSEC3 opt-out区无法激进使用NSEC、DNS Cookie在任播部署中的密钥轮换风险，建议结合统计计数器与日志完善告警阈值，并在上线前按实现差异逐项验证配置参数。
原文: APNIC Blog（2021-10-25）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog