ISC 以真实运营商流量为基础，在 BIND 9.18.4 上对比开启与关闭 DNSSEC 验证的资源消耗，覆盖 9 千与 13.5 万 QPS 两个负载极端，量化了延迟、带宽、CPU、套接字与内存的实际差距。
测试数据与方法：真实流量保留缓存命中率
ISC 拿到某欧洲电信商 2022 年 2 月匿名化流量，按源 IP 整组采样，保证缓存命中/未命中比例与线上一致。测试机跑 BIND 9.18.4，冷缓存起步，仅切换 validation 选项。用 DNS Shotgun 回放 PCAP，权威端直连公网，每组跑 10 轮再做统计后处理，资源采样来自 /proc 与 /sys。原文未给出具体服务器硬件配置。
轻载 9,000 QPS：验证开销在噪音线以内
在 9 千 QPS 场景下，开启验证后的平均延迟、CPU 占用、套接字数、内存增长均落在 10 轮测量的最小/最大值区间内，曲线几乎重合。带宽略增，但幅度小于公网抖动带来的波动。ISC 判定：轻载时验证带来的额外资源消耗可忽略。
重载 135,000 QPS：CPU 与套接字成比例上升
13.5 万 QPS 下，验证导致 CPU 占用显著抬升，套接字峰值同步增加，内存增长仍在可控范围。延迟中位数上移，但 95 分位数受公网权威响应波动影响更大。带宽增量与额外 DNSKEY/DS 查询数量对应。原文未给出具体百分比增幅。
对运维的启示：按负载规划验证策略
轻载递归节点可直接全开验证，无需顾虑性能；重载节点需预留 CPU 余量并监控套接字上限，必要时可通过缓存预热、限流或硬件加速抵消验证开销。实测数据确认：DNSSEC 验证不是性能杀手，但高负载下的资源放大效应需纳入容量规划。
原文: APNIC Blog（2022-08-22）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog