DNS响应遭IP分片篡改可导致缓存投毒，DNSSEC虽是根治方案但部署缓慢。实验室规模化测试验证了三种TCP-only模式能有效阻断分片攻击，并量化了其对解析延迟与服务端负载的代价。
实验环境与攻击验证
搭建含多组根服务器、com/net/org及fr/ch/at/de等ccTLD、数百个二级域名的权威服务器集群（多数未签DNSSEC），对端模拟数百客户端冲击运营商级递归解析器。解析器跑BIND 9、Knot、Unbound、PowerDNS及Windows Server DNS。先确认无防护时分片攻击成功，再逐项开启缓解措施验证拦截效果，确保结论可映射至生产网。
TCP-only三种模式对比
TCP天然规避IP分片，但握手与状态维护增加开销。测试三种变体：Vanilla TCP——每查询建拆一次连接；TCP keep-open——修补版Unbound（未公开）对高频上游权威保持长连接；第三种模式原文未给出具体数据。实测显示长连接模式能摊销握手延迟，但需权威端配合维持会话状态，对连接表规模提出新要求。
部署取舍与工程建议
DNSSEC签名区+解析端验证仍是唯一不依赖传输层变更的完整解；若区暂不可签，TCP-only可作过渡屏障。工程上需权衡：Vanilla TCP延迟增幅最大，长连接需解析器与权威同步改造且占用更多文件描述符，Windows Server DNS等商业软件对补丁支持度原文未给出具体数据。建议优先在解析器侧启用TCP回退并监控连接池水位。
对运维而言，先在递归端开启TCP回退并观测延迟分位数；若权威端可控，推长连接补丁并扩连接表；同步推进DNSSEC签名才能从根源消除分片攻击面。
原文: APNIC Blog（2022-12-13）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog