根服务器系统与全球解析体系

01 · 根服务器系统的架构地位

根服务器系统（Root Server System）是全球DNS解析的自举锚点：递归解析器通过根提示（root hints）获得13个逻辑根标识的地址，再以引导查询（priming）刷新根NS记录集与胶水记录。根层回答的内容极少——只是各顶级域（TLD）的NS记录委托——但它是每一次缓存未命中解析的起点。正因为所有递归器都依赖它，根层的可用性设计必须是"绝对保守"的：改动任何根区行为都需全球协调（DNS Flag Day式的全行业协同即为例证）。

02 · 13个逻辑根标识与12家运营机构

根服务器的运营权分配给12家机构（其中Verisign运营A、J两个标识），均为非营利或公共性质的研究/基础设施机构，长期遵循开放的运营方针：

注：运营格局以IANA根区数据库与root-servers.org公开信息为准，长期稳定。各运营方对单实例负载、查询量有各自的公开统计口径（如Verisign对A/J根的公开仪表盘）。

2.1 任播实例的全球规模

自ISC于2002年为F根、Netnod与RIPE NCC于2003年为I/K根率先部署任播以来，根实例规模持续增长。根据root-servers.org聚合统计，截至2026年9月，13个逻辑标识的任播实例合计已超过2,000个，分布于全球数十个国家（2025年已超1,700个；精确数字实时变动，以root-servers.org为准）。从区域分布看，北美与欧洲实例密度最高，亚太次之，非洲与南美相对稀疏——分布不均本身即是一个韧性议题：区域性网络切割时，稀疏区域的解析延迟与可达性将首先恶化。

03 · 根区规模、签名与应答体量

3.1 根区内容规模

根区仅包含顶级域委托记录与根NS/胶水，体量极小但增长显著：2012年新通用顶级域（gTLD）计划启动前根区仅约300个TLD；截至2025年，根区TLD数量已超过1,500个（含gTLD与ccTLD；历年曾有TLD退役，精确数量以IANA根区数据库每日版本为准）。根区文件完整大小为数MB量级（含DNSSEC记录），增量（IXFR）通常在KB量级。

说明：以上字节数为公开技术文档与测量报告中的常用量级（如NLnet Labs、DNS Flag Day资料），实际随根区版本略有浮动。

3.2 DNSSEC与2018年KSK rollover的韧性教训

根区自2010年7月15日起正式签名。2018年10月11日，根区完成史上首次KSK（密钥签名密钥）更换——该计划最初定于2017年10月，但因测量发现大量递归器（据ICANN当时估计约数千台实例）未按RFC 5011自动更新信任锚，ICANN在2017年9月宣布推迟一年。事件揭示三个韧性要点：

• 慢速生态的兼容风险：协议设计假设"验证方会跟踪密钥更新"，但现实网络中存在大量冻结的嵌入式解析器与陈旧镜像；任何全局性变更的实际生效时间以"最慢一环"计。
• 测量先行：ICANN与社区通过RFC 8145定义的"信任锚信标"（Trust Anchor Signaling）被动测量全网rollover就绪度——这种"先测后改"的治理流程已成为根系统变更的标准范式。
• 验证关闭的真实规模：大量解析器在面对Bogus数据时选择关闭验证（而非修复）——这从韧性角度是理性选择（可用性优先于完整性），但也意味着DNSSEC对劫持的防护上限受运营现实约束。

3.3 第二次根KSK轮换前瞻（2026年10月，KSK-2017→KSK-2024）

ICANN已公告第二次根区KSK轮换将于2026年10月进行：2018年首次轮换生成的KSK-2017沿用至今，因HSM（硬件安全模块）升级生成的新密钥KSK-2024将接任信任锚角色。与首次轮换一致，ICANN沿用"测量先行"治理范式：2026年7月已发布"What to Expect"指南，建议各递归运营方核对RFC 5011自动更新信任锚配置，并通过RFC 8145信标与根DNSKEY查询率监测观察全网就绪度。对国内运营方的直接行动项：轮换前完成信任锚核查与回退预案演练；轮换窗口期加强对Bogus应答与DNSKEY查询异常的监控——这是2018年教训在实战中的第二次检验。

04 · 根解析路径优化：降低对根的实时依赖

根层韧性设计的第一原则不是"把根做得更强"，而是"让递归器更少、更智能地访问根"。以下机制共同将根查询占比压缩到递归器流量的极小比例：

4.1 本地根（RFC 7706）的工程要点

本地根通过将IANA发布的根区副本（含DNSSEC签名）加载到本地权威服务（如NSD），并把unbound的引导配置指向127.0.0.1，使根查询在本地闭环。其韧性收益包括：根实例全不可达时递归器仍可完成引导与TLD委托迭代；根查询时延降至微秒级。代价是引入新的运营组件（根区同步失败即构成新的故障面），故RFC 7706明确建议保留外部根作为回退，且同步频率应与根区SOA刷新节奏匹配。该模式已被部分国家级递归基础设施（如日本WIDE、欧洲部分学术网络）长期实践。

# unbound.conf 片段：RFC 7706 本地根配置示例（需配合本地根区权威服务）
server:
  # 引导查询指向本地服务，而非外部根
  do-not-query-localhost: no
  domain-insecure: "."        # 若本地根未签名验证，按部署实际调整
stub-zone:
  name: "."
  stub-addr: 127.0.0.1@5353   # 本地nsd/authoritative 承载 IANA 根区副本

05 · 根服务负载与可用性观测

从运营方公开数据看，单个逻辑根标识的查询速率通常在每秒数万查询量级（各根因实例数量与位置而异，Verisign对A/J根的公开仪表盘提供实时视图）。值得关注的是无用负载：测量研究长期表明，相当比例的根查询是单一来源IP地址对不存在TLD的随机查询（如嵌入式设备固件中的"探测性"查询），根服务器为此投入的处理与带宽成本远大于其委托功能的理论最小值——这也是RFC 9156、RFC 8198等优化被广泛部署的现实驱动力。

治理层面：根系统的长期演进由ICANN根服务器系统咨询委员会（RSSAC）提供咨询，其发布的RSSAC咨询意见与根服务器系统测量报告（如根查询特性研究）是理解根层负载形态的重要公开文献。IANA对根区变更（新增TLD、KSK管理）实行多机构交叉控制的变更管理流程（如TLD变更需经ICANN技术团队与NTIA（历史角色）/PMA流程的双重核验），其变更管控本身即是韧性的组织保障。

06 · 面向国内网络的观察

• 境内根可达性：国内递归器对13个逻辑根的可达性总体良好；部分运营方通过本地合作在境内或近邻区域部署任播节点（以各运营方公开信息为准）。历史上曾出现个别根实例在国内特定网络不可达的情况（路由策略或链路原因），递归器的多根轮询机制对此天然容错——这印证了"13个标识本身就是冗余设计"的原始意图。
• 根镜像的治理属性：根镜像/本地根在国内落地涉及跨境数据与技术治理议题，须同时满足《网络安全法》与行业监管要求；本课题仅从纯技术角度评估其可用性收益，不构成部署建议。
• 度量参与：国内学术与产业界可通过RIPE Atlas探针部署、OpenINTEL测量合作等方式参与全球解析测量，积累本土化的韧性数据（第8页详述）。

本节参考来源（第2页）