DNSSEC 验证端必须支持签名端使用的所有算法，这种“全算法兼容”约束导致新算法引入陷入先有鸡还是先有蛋的僵局。ECDSA P-256 虽在密钥长度与签名体积上优于 RSA，但 2014 年测量显示其验证端支持率极低，无法在 DNSSEC 大规模落地。
算法多样性与协商机制缺失
密码学标准刻意不指定单一算法，由签名方或软件开发者自行选择。RPKI 与 DNSSEC 等公共基础设施要求验证端预装所有可能用到的算法，无法像 TLS 那样通过实时协商达成一致。这意味着签名方若采用新算法，必须等待全网验证端升级完成才能生效；反之，验证端添加新算法支持若无签名方使用则无实际收益。双方缺乏主动迁移动力，除非出现明确弱点暴露。
ECDSA P-256 的早期测量结果
2014 年针对 ECDSA P-256 的测量研究得出结论：当时该算法不具备 DNSSEC 生产可用性。原文未给出具体验证端支持率数据，但明确指出“太少的 DNS 验证器支持该算法”，导致签名方不愿采用。相比之下，RSA 因早期广泛部署、库支持成熟，仍占据主导地位。量子抗性、计算开销等理论优势在部署现实面前无法转化为推动力。
对运维工程师的启示
算法迁移在 DNSSEC 中本质是协调问题而非技术问题。部署新算法前需评估验证端覆盖率、递归解析器软件版本分布、密钥滚换流程兼容性。若无强制性弱点披露或标准强制迁移期限，建议维持 RSA 部署，配合密钥长度提升（如 2048→4096 位）应对近期风险；仅在验证端支持率接近全网覆盖时，才考虑并行签名或双算法过渡。
原文: APNIC Blog（2021-11-10）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog