IETF90 DNSOP 会议讨论了两份关于根区分发的草案，核心是让递归解析器直接获取签名后的根区数据，减少对 13 组根服务器标签的依赖。Google 与 VPN Consortium 的草案采取极度审慎路径，移除 AA 位不宣称权威；另一份草案提议扩展根 priming 消息引入类 AS112 机制。两者均以 DNSSEC 签名区为信任基础，通过协议原生方式同步更新。
Kumari-Hoffman 草案：递归解析器直取根区
Warren Kumari（Google）与 Paul Hoffman（VPN Consortium）提交的 draft-wkumari-dnsop-dist-root-01 提出，允许递归解析器主动抓取完整的签名根区并在本地服务。当前根区由 13 个标签（label）发布，实际通过 Anycast 部署约 500 个实例。草案刻意去除权威位（AA），不声称扩展根权威，仅提供一种将根数据引入缓存解析器社区的机制。这种克制更多源于政治考量——避免踩到根运营商的脚趾，而非技术限制。
Lee 草案：扩展 priming 引入 AS112 模式
竞争草案 draft-lee-dnsop-scalingroot-00 走另一条路：修改根 priming 消息，预留额外 NS 地址槽位，由 IANA 持有所有权并允许任意机构 Anycast 部署。这使根服务架构更接近 AS112——任何愿意运行的节点均可加入。两份草案都要求区数据必须签名，因为信任锚点在于签名内容而非服务者身份。
共同依赖：DNSSEC 签名区与协议原生同步
两个方案均以 DNSSEC 签名的根区为信任基础，利用 DNS 协议自带的签名更新机制传播变更，无需额外同步或分发层。原文未给出具体部署时间表、测量数据或根运营商的正式回应。
对运维工程师而言，这两个方向预示根区获取可能从集中式查询转向分布式缓存，降低根服务器查询压力的同时，依赖 DNSSEC 验证保证数据真实性。实际部署需评估递归解析器存储完整根区的内存开销、签名验证 CPU 消耗，以及 IANA 与根运营商之间的协调进度。
原文: APNIC Blog（2014-08-25）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog