APNIC 因商业 DNSSEC 签名器在 ECDSAP256SHA256 算法下出现 CPU 瓶颈，被迫在 Knot 2.9 与 Bind 9.16 间开展实测选型。文章记录从 RSASHA1 迁移至 ECDSAP256SHA256 的完整过程、性能问题暴露、候选筛选依据与并行测试架构，为同类迁移提供可复用的工程参考。
算法迁移与性能瓶颈
2010 年 APNIC 采用商业签名器部署反向区域 DNSSEC，长期使用 RSASHA1。2019 年 RFC 8624 发布，推荐最低 RSASHA256、强推 ECDSAP256SHA256（签名更短、强度更高）。APNIC 按文档完成算法滚动，约一周内无缝切换，信任链未断。但切换后商业签名器每日重签名时 CPU 吃紧，DNS 服务端查询正常，签名端成瓶颈。厂商无补丁，仅能回滚或更换。
候选筛选与测试架构
参考 RIPE NCC 迁移 Knot 经验，列入 Knot 2.9 与 Bind 9.16 两候选。PowerDNS 因密钥滚动需手动创建、退役旧密钥，未纳入测试。测试在虚拟机并行部署，加载生产同款区域、复用监控工具，确保对比基线一致。原文未给出具体测试指标与最终选型结果。
对运维工程师的启示
实测表明算法升级虽符合 RFC 8624，却可能触发签名器计算瓶颈；选型需把密钥滚动自动化、监控复用、生产流量镜像纳入硬性指标。工程师在规划 DNSSEC 迁移时，应预留签名端压测窗口，避免上线后被动回滚。
原文: APNIC Blog（2021-02-25）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog