根区与根服务器
根区很小——只有一千多个顶级域的委派——却是每次从零开始解析的起点。它的数据由谁编辑、谁签名、谁分发，是三件分开的事。
根区里有什么#
根区基本只做一件事：告诉解析器每个顶级域（com、org、cn、au 等）由哪些服务器负责。所以它的内容主要是各顶级域的 NS 记录、这些服务器的胶水地址、各顶级域的 DS 记录，以及根区自身的 SOA、NS、DNSKEY 和签名。
根区文件是公开的，可以从 https://www.internic.net/domain/root.zone 下载。区里还带有 ZONEMD 记录（RFC 8976），下载者可以据此校验整个文件没有被改动。
谁负责哪一部分#
- IANA 职能：受理顶级域运营者的变更请求（换 NS、换 DS 等），核对后提交。目前由 ICANN 的附属机构 PTI（Public Technical Identifiers）执行。
- 根区维护者：Verisign 根据批准的变更编辑根区文件，用区签名密钥（ZSK）签名并发布给各根服务器运营方。
- 根区 KSK：由 ICANN 保管，存放在美国加州埃尔塞贡多（El Segundo）和弗吉尼亚州卡尔佩珀（Culpeper）两处设施的硬件安全模块里，定期举行公开的密钥仪式，对 ZSK 进行签名。
- 根服务器运营方：12 家相互独立的机构，各自决定部署方式，只负责把同一份根区原样提供出去，不能修改内容。
13 个名字，12 家运营方#
根服务器的名字是 a.root-servers.net 到 m.root-servers.net。下表地址取自 2026 年 10 月的根提示文件 named.root。
| 名字 | 运营方 | IPv4 | IPv6 |
|---|---|---|---|
a | Verisign | 198.41.0.4 | 2001:503:ba3e::2:30 |
b | 南加州大学信息科学研究所（USC-ISI） | 170.247.170.2 | 2801:1b8:10::b |
c | Cogent Communications | 192.33.4.12 | 2001:500:2::c |
d | 马里兰大学 | 199.7.91.13 | 2001:500:2d::d |
e | NASA | 192.203.230.10 | 2001:500:a8::e |
f | Internet Systems Consortium（ISC） | 192.5.5.241 | 2001:500:2f::f |
g | 美国国防信息系统局（DISA） | 192.112.36.4 | 2001:500:12::d0d |
h | 美国陆军研究实验室（DEVCOM ARL） | 198.97.190.53 | 2001:500:1::53 |
i | Netnod | 192.36.148.17 | 2001:7fe::53 |
j | Verisign | 192.58.128.30 | 2001:503:c27::2:30 |
k | RIPE NCC | 193.0.14.129 | 2001:7fd::1 |
l | ICANN | 199.7.83.42 | 2001:500:9f::42 |
m | WIDE Project | 202.12.27.33 | 2001:dc3::35 |
b 根在 2023 年更换了 IPv4 和 IPv6 地址，旧地址保留了一段过渡期。地址会变，这正是解析器不应该把根地址写死在代码里、而应定期更新根提示的原因。
为什么是 13 个#
常见的解释来自 UDP 512 字节的老限制：对“根有哪些 NS”的应答，要连同地址一起装进 512 字节，13 个名字（用了名字压缩，同在 root-servers.net 下）加上它们的 IPv4 地址差不多正好放满。后来加入的 IPv6 地址已经让完整应答超过 512 字节，但支持 EDNS 的解析器不受影响。
“13 个名字”不等于“13 台机器”。今天的根服务器服务数量由任播决定，与名字数量无关。
任播#
同一个根服务器地址由分布在世界各地的许多实例同时宣告，路由系统把每个查询送到网络拓扑上最近的那一个。好处很直接：离用户近、单点故障影响小、攻击流量被分散到各地吸收。按 root-servers.org 在 2026 年 10 月的统计，13 个名字背后共有约 2,049 个实例。
用 NSID 选项可以看到你实际打到的是哪个实例：
$ dig @k.root-servers.net . SOA +nsid +norecurse根提示与启动探询#
解析器冷启动时，靠根提示文件（常叫 named.root、root.hints）知道去哪里找根。随后它会向其中一个地址发一次“启动探询”（priming query，RFC 8109）：查询 . 的 NS，用得到的最新列表替换提示文件里的内容。所以提示文件稍微过时一点通常无妨，只要其中还有一个地址能用。
根区 KSK 与信任锚#
根区 2010 年 7 月 15 日开始签名。验证型解析器把根区 KSK（或者说它的摘要）作为信任锚内置，所有 DNSSEC 验证最终都追溯到它。
| 密钥 | 密钥标签 | 状态 |
|---|---|---|
| KSK-2010 | 19036 | 2018 年 10 月 11 日完成首次轮换后停用 |
| KSK-2017 | 20326 | 2018 年 10 月起签名根区 DNSKEY 集合 |
| KSK-2024 | 38696 | 已发布在根区中；按 IANA 公布的计划，自 2026 年 10 月 11 日起由它单独签名，KSK-2017 计划于 2027 年第一季度撤销 |
信任锚的权威来源是 IANA 发布的 https://data.iana.org/root-anchors/root-anchors.xml（格式见 RFC 7958）。运行中的解析器多数通过 RFC 5011 自动更新：新密钥在根区里出现并持续被旧密钥签名满一段“保持期”后，解析器才会信任它。容易出问题的是长时间离线、或用镜像固化了旧配置的系统——它们开机时手里只有旧锚。
检查自己的解析器是否已经认识新密钥，看它实际加载的信任锚文件即可：BIND 是 bind.keys 或 managed-keys 数据库，Unbound 常见是 root.key，Knot Resolver 是 root.keys。只看配置文件不够，要确认运行中的进程加载了它。
在解析器本地运行根区#
RFC 8806 描述了一种做法：解析器自己下载并校验根区，直接在本机回答原本要发给根服务器的问题。好处是少一跳延迟，对根服务器的依赖降低，还能减少把“拼写错误的顶级域”这类查询泄露到网络上。代价是要可靠地更新和校验区文件（ZONEMD 正好用于这个），出错时的后果也落在自己身上。
另一个效果相近、成本更低的手段是 RFC 8198 的“积极使用 NSEC 缓存”：根区签了名，解析器缓存的 NSEC 记录能直接证明某个顶级域不存在，大量发往根的垃圾查询因此不必发出。