域名层次

这一课你将能做到

1. 拆解 www.coderoadmap.cn 每一级标签的归属，指出根、TLD、权威分别管哪一段
2. 读出并解释 SOA 记录七个字段的含义，看懂「区域（Zone）」与「委派（Delegation）」的关系
3. 用 dig 判断一个子域是由本域权威直接回答、还是已委派给另一套权威服务器

为什么要学

很多人把域名理解成「一个字符串」，但 DNS 内部把它当成从右向左逐级归属的标签树。www.coderoadmap.cn 不是一个扁平名字，而是树中 cn → coderoadmap → www 的一条路径。这棵树怎么切分成区域、每段区域由谁负责、子域怎么交出去给别人管——这些决定了为什么改 NS 就能换 DNS 服务商、为什么子域可以挂在完全不同的机房解析。

掌握层级和区域模型后，SOA 不再是一串看不懂的数字，委派也不再是玄学，第 6 课本站配置、第 9 课集群 DNS 都是这套模型的具体应用。

先建立图像

                              根（.）
           ┌──────────┬───────────┼────────────┐
          .com       .cn         .org         .io        ← TLD（顶级域）
           │          │
     example.com   coderoadmap.cn                         ← 二级域（注册得到）
                      │
          ┌───────────┼────────────┐
         www         api          dev                      ← 子域（主机/子区域）
                      │            │
                      │       ┌────┴────┐
                      │      v1.dev   v2.dev
                      │
                   (可委派) dev.coderoadmap.cn 的 NS 指向另一套权威
                            则 dev 以下是独立 Zone，父级不再回答

www . coderoadmap . cn .
 │       │         │   └─ 根（末尾的点，常省略）
 │       │         └───── TLD，由 .cn 注册管理机构运行
 │       └─────────────── 注册的二级域，你的权威服务器负责
 └─────────────────────── 主机名/子域前缀（最左是最细的一级）

概念	人话解释
标签（Label）	用点隔开的每一段，最长 63 字符
区域（Zone）	权威服务器实际管理的一段连续命名空间
委派（Delegation）	父级用 NS 记录把子域「交出去」给别的权威管
FQDN	完整域名，末尾带根点，如 www.coderoadmap.cn.
胶水（Glue）	委派时父级附带的权威 IP（第 3 课讲过）

关键区分：「域（Domain）」是命名空间的逻辑范围，「区域（Zone）」是被某台权威实际配置管理的文件。一个域可以是一个 Zone，也可以切成多个 Zone 分别委派。

跟着做

步骤 1：拆解本站域名的各级标签

# 查 .cn TLD 上 coderoadmap.cn 的委派信息
dig @a.dns.cn coderoadmap.cn NS +norecurse

# 查本站权威如何回答
dig coderoadmap.cn NS +short
dig www.coderoadmap.cn A +short

示例输出：

# 父级 .cn 的回答（AUTHORITY 段）
coderoadmap.cn.  86400  IN  NS  ns1.cloudflare.com.
coderoadmap.cn.  86400  IN  NS  ns2.cloudflare.com.

读法：.cn 不保存 www 的 IP，它只保存「coderoadmap.cn 交给 ns1/ns2.cloudflare.com」这条委派；具体记录要去 Cloudflare 查。

步骤 2：精读 SOA 的七个字段

dig coderoadmap.cn SOA +short

示例输出：

ns1.cloudflare.com. dns.cloudflare.com. 2311100042 10000 2400 604800 3600

按顺序拆解：

字段	示例值	含义
MNAME（主权威）	ns1.cloudflare.com.	区域主服务器（primary）
RNAME（管理员邮箱）	dns.cloudflare.com	邮箱 dns@cloudflare.com，第一个点代替 @
SERIAL（序列号）	2311100042	区域版本号，每次修改必须增大
REFRESH（刷新）	10000	从服务器多久向主服务器核对一次
RETRY（重试）	2400	核对失败后多久重试
EXPIRE（过期）	604800	联系不上主服务器多久后停止回答
MINIMUM（否定TTL）	3600	NXDOMAIN/NODATA 的缓存上限

传统序列号常用 YYYYMMDDNN 日期格式；主从同步靠「从服务器发现 SERIAL 变大 → 拉取新区域（AXFR/IXFR）」工作。

步骤 3：判断子域是否被委派

# 假设 dev 子域委派给了自建权威
dig dev.coderoadmap.cn NS +short

# 对比：未委派的子域查 NS 通常返回父级自己的 SOA（NODATA）
dig www.coderoadmap.cn NS

示例现象：

# dev 已委派：返回它自己的 NS
ns1.dev-source.internal.

# www 未委派（只是 Zone 内一条主机记录）：AUTHORITY 段是父域 SOA
;; AUTHORITY SECTION:
coderoadmap.cn. 3600 IN SOA ns1.cloudflare.com. ...

这就是判断「一个名字到底谁管」的标准方法：看回答里的 NS/AUTHORITY 落在哪一级。

步骤 4：观察区域边界——权威对「界外」只给引荐

# +norecurse 直接问本站权威一个不属于它的名字
dig @ns1.cloudflare.com www.baidu.com A +norecurse

权威对自己区域外的名字不做递归、不返回内容，通常用 REFUSED 或返回根提示类应答。区域边界因此是清晰的：每台权威只「认领」自己 Zone 文件里写的名字。

步骤 5：演练「子域委派」配置（面板/自建两种形态）

Cloudflare/云 DNS 面板形态：在父域添加

类型: NS
主机记录: dev
值: ns1.partner-dns.com.
值: ns2.partner-dns.com.

自建 BIND 形态：在父区域文件里写

dev.coderoadmap.cn.  IN  NS  ns1.devpartner.net.
dev.coderoadmap.cn.  IN  NS  ns2.devpartner.net.
; 若 NS 在本域内，必须补胶水：
ns1.devpartner.net.  IN  A   198.51.100.7

配完用第 3 课的方法验证：dig +trace dev.coderoadmap.cn，链路应在 TLD 之后走到新权威而非 Cloudflare。

步骤 6：核对主从同步（自建权威场景）

# 主、从两台权威分别查 SOA，序列号应一致
dig @ns1.coderoadmap.cn coderoadmap.cn SOA +short
dig @ns2.coderoadmap.cn coderoadmap.cn SOA +short

如果从服务器序列号长时间落后，检查主服务器是否允许区域传送（allow-transfer）、REFRESH 周期以及防火墙 TCP 53。Cloudflare 等托管服务内部自动处理，无需关心。

讲清楚要点

1. DNS 是一棵倒置的树：根在最上（名字末尾隐含的点），向下是 TLD、注册域、子域。查询时解析器沿树从顶向下找，从不「向上」找。
2. TLD 分几类：通用顶级域（gTLD，.com/.org/.dev 等）、国家顶级域（ccTLD，.cn/.io 归属上也是 ccTLD）、新 gTLD（.shop/.app 等）。顶级域由注册管理机构（Registry）运营，注册商（Registrar）是它的代理。
3. 区域是管理单元，不是名字长度：coderoadmap.cn 是一个 Zone；一旦把 dev.coderoadmap.cn 委派出去，它就成为独立 Zone，父级 Zone 文件里只留 NS，不再保留其内部记录。
4. 委派必须在父子两边同时成立：父级写 NS（+必要胶水），子级权威配置好对应区域。只有父级记录、子级权威不接，返回 SERVFAIL。
5. SOA 是每个 Zone 的「身份证」：标明主从、负责人、版本与四类计时参数；排障时它还提供否定缓存时间。
6. 序列号只增不减：主从同步完全依赖它。改错（如把序列号写小）会导致从服务器拒绝更新——常见手滑事故。
7. 权威服务器通常 ≥2 台且分布在不同网络（RFC 2182 的可用性要求），注册商在域名注册时强制校验至少两台。

你可能会懵的地方

• coderoadmap.cn 到底算几级域名？ 标签数是三个（含根）或两个（不含根）。日常说「二级域名」指 .cn 下注册的那一级；www.coderoadmap.cn 习惯被叫做「子域名」，技术上是三级标签。叫法不重要，关键是搞清谁在哪一段做委派。

• 域和 Zone 到底怎么区分？举个例子？ coderoadmap.cn 作为域包含它所有子孙名字；但 Zone 只包含「本权威直接持有数据的部分」。如果 dev 被委派，dev 及以下在逻辑上仍属 coderoadmap 域，却不在 coderoadmap Zone 文件里，而属于独立的 dev Zone。

• SOA 里的邮箱为什么看不到 @？ RNAME 用 DNS 的标签编码，@ 换成点：dns.cloudflare.com. 表示 dns@cloudflare.com。若邮箱本地部分本身含点，要用反斜杠转义 \.。

• 为什么子域委派要改父域，我在自己权威上加 NS 不行吗？ 解析器是从根向下走的，它先到达父级权威；只在你自己的权威上声明，父级不知道、不会引荐，查询永远走不到你那台。委派的入口必须在父级。

• SERIAL 写成 2026100701，会有什么坑？ 日期格式没问题，坑在于一天内多次改 Zone 时后两位序号要递增；以及一旦写过很大的数字（如 9999999999），以后就很难降回来——从服务器只接受更大的值。

错法对照

错法	后果	正确做法
委派了子域却不在父级配 NS	解析链路走不到新权威，SERVFAIL	父级加 NS + 必要胶水，子级权威同步就绪
修改 Zone 后忘记加 SERIAL	从服务器不更新，解析结果主从不一致	每次变更同时递增序列号
胶水记录 IP 填错	NS 名字解析得到、但连不上权威	委派后用 dig 逐跳验证可达性
把区域传送对全网开放	任何人可 AXFR 拉走全部记录（信息泄露）	allow-transfer 仅限从服务器 IP，配合 TSIG
子域权威与父级 TTL/记录不一致	边界处行为飘忽	明确「界内谁管」，以权威应答为准

卡点急救

1. 委派后查询返回 SERVFAIL：按链路逐跳 dig：父级 NS 是否写了、胶水 IP 是否通、子级权威是否真的配置了该 Zone（dig @子权威 子域 SOA）。90% 的 SERVFAIL 是「父级指了、子级没接」。
2. 主从权威记录不一致：对比两边 SOA SERIAL；序列号一致但记录不同，多为从服务器在 SERIAL 未变时手工改过或缓存了旧传送，触发一次序列号递增强制 IXFR/AXFR。
3. 裸域打不开、www 正常：检查根域是否有 A/ALIAS（很多人只给 www 配了记录）。裸域若不做网站，可由 Nginx 配 301 到 www，但前提是裸域先能解析到机器。

面试常问

• DNS 的层级结构是怎样的？一次查询为什么最多走几级？ 自顶向下是根、TLD、注册域权威（必要时再到被委派子域权威）。根给出 TLD 的 NS，TLD 给出域的 NS，权威给出最终记录，所以无委派时固定 3 跳；每次子域委派增加 1 跳。配合递归器缓存，绝大多数查询实际只命中缓存、一跳都不走。

• 什么是 DNS 区域（Zone）？它和域名是什么关系？ Zone 是权威服务器上一份完整配置数据所覆盖的连续命名空间，包含该范围内的所有记录和一条 SOA。域名是逻辑上的整棵子树；一个域名空间可以被切成多个 Zone（通过 NS 委派），每个 Zone 独立管理、独立主从同步。

• SOA 记录有哪些字段？序列号的作用是什么？ 七字段：主权威 MNAME、管理员 RNAME、序列号 SERIAL、刷新 REFRESH、重试 RETRY、过期 EXPIRE、否定缓存 MINIMUM。序列号标识 Zone 数据版本：从服务器周期性比对主服务器序列号，发现变大才拉取增量（IXFR）或全量（AXFR）；因此任何变更都必须同步递增序列号，否则主从不会更新。

自测三问

1. 画出 api.dev.coderoadmap.cn 的标签树，并标注若 dev 被委派，解析到第几跳开始换权威？
2. SOA 的 REFRESH、EXPIRE、MINIMUM 分别控制什么？哪个与「新增子域后别人查不到」直接相关？
3. 只在自己权威上加子域 NS 为什么不能完成委派？缺的那一环在哪里配？

小结一句话

DNS 是根→TLD→权威的标签树，区域是树上被实际托管的数据段，委派用 NS（加胶水）把树枝交出去，SOA 则是每段区域的身份证。

延伸

• RFC 1034 第 3、4 章：名字空间与区域思想
• RFC 2182：主从服务器的选择与运行
• RFC 1995：增量区域传送 IXFR
• IANA：根区域数据库
• 下一课预告：诊断工具——dig/nslookup/host 实战精读，以及 curl --resolve 等绕过 DNS 的验证技巧。