越来越多组织采用多提供商协同运行 DNS 服务，以在单一提供商彻底故障时实现零停机。若同时部署 DNSSEC，传统的区域传输模型虽能支持标准化资源记录，却无法覆盖全球服务器负载均衡（GSLB）、健康检查故障转移、加权应答等需在权威服务器查询时动态生成签名的“流量管理”特性。本文探讨替代模型如何解决这一矛盾。
区域传输模型的边界：
区域传输模型由后端主服务器持有权威区域数据并完成 DNSSEC 签名，再通过 TSIG 认证的区域传输协议推送至各提供商。该模型成熟稳定，但仅能处理可预先在主服务器确定的标准化资源记录类型。原文指出，当前行业广泛部署的非标准动态机制——统称“流量管理”——要求应答及其 DNSSEC 签名必须在权威服务器查询时依据网络动态状态实时生成，区域传输模型对此无能为力。原文未给出具体部署比例数据。
流量管理与 DNSSEC 的长期博弈：
Paul Vixie 早在 2009 年文章《What the DNS is not》中批评此类“DNS 技巧”增加复杂度、转嫁成本，且主张应在其他层实现。作者认同其观点，但强调 CDN 边缘网络等场景已普遍依赖这些机制，形成长期存在的现实冲突。2018 年 ICANN DNS 会议进一步凸显该议题，推动社区寻找既能保留多提供商冗余、又能支持查询时签名的新模型。原文未给出会议具体决议细节。
对运维工程师的启示：
在多提供商架构下部署 DNSSEC 时，若业务依赖 GSLB、故障转移等动态流量管理，必须超越区域传输模型，转向支持多签名协同的方案。工程师需评估现有 DNS 提供商是否具备查询时签名能力，并在签名密钥管理、密钥滚换同步等环节建立跨提供商的自动化流程，以在保证冗余的前提下实现完整的 DNSSEC 保护。
原文: APNIC Blog（2021-08-25）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog