13 组的由来
DNS 树的根「.」由 13 组逻辑服务器名 a.root-servers.net 到 m.root-servers.net 服务。13 这个数字来自早期 UDP 报文尺寸下的容量计算，如今每一组都通过 anycast 在全球部署了大量实例，实际节点数量远超 13 台。
根的工作方式
根服务器不回答「example.com 的地址是多少」，它只回答「.com 由谁负责」。日常没有人直连根：真实流量走就近的 anycast 实例与各级缓存。自建递归器需要一份根提示文件（root hints），把它当作解析的起点。
基本信息
| 组数 | 13 组逻辑服务器，标识 a 到 m |
|---|---|
| 部署方式 | anycast，同一地址在全球有大量实例 |
| 作用 | 把查询者指向对应 TLD 的权威服务器 |
| 自建递归器 | 需要 root hints 文件，并在变更时更新 |
典型使用场景
- 初始化自建递归解析器（如 unbound）时导入根提示
- 学习与排障：用 +trace 观察从根开始的完整委派链
- 核对递归器使用的根列表是否最新、是否被本地篡改
- 理解为什么「把根打瘫」在现实中极难成立
直接向根提问
直接向根提问
dig +norecurse @198.41.0.4 example.com NS # 向 a 根提问且不要求递归
dig ns . # 列出全部 13 组根名
dig +short a.root-servers.net A # 看某一组的解析结果
dig +trace example.com | head -20 # 从根开始看整条委派链常见根实例
| 标识 | 运营方 | 地址示例 |
|---|---|---|
| a | Verisign | 198.41.0.4 / 2001:503:ba3e::2:30 |
| b | USC-ISI | 170.247.170.2 |
| f | ISC | 192.5.5.241 |
| i | Netnod | 192.36.148.17 |
| j | Verisign | 192.58.128.30 |
| m | WIDE | 202.12.27.33 |
只有各级缓存全部落空时才会走到根，所以根的实际负载远低于直觉。讨论「根扛不扛得住」时，先把缓存命中这一层算进去。
根提示文件过期会让自建递归器解析新 TLD 失败：定期更新，或依赖发行版与软件自带的更新机制，别把它当成一次性配置。
自建递归器的维护动作
- 定期更新根提示文件，或启用软件自带的更新机制
- 监控解析失败率，尤其是新顶级域的解析是否正常
- 保留可用的上游做兜底，但不把根提示当成可选项
- 记录变更时间与文件版本，便于回溯解析异常
根提示文件是冷启动的起点，而不是运行时的查询目标：递归器平时靠缓存工作，只有缓存未命中且需要走到根时才会真正用到它。