DNS 委派、TLD 与胶水记录：把新域名 NS 切到 Cloudflare 的实战与原理

本文整理自一次真实的排查：一个当天刚注册的 .asia 域名（下文以 demo.asia 代称），要把它从阿里云默认 NS 切换到 Cloudflare。过程用浏览器调试控制台 + dig 逐级实测，把 DNS 教科书里含糊带过的几个概念（TLD 委派、glue、权威副本、serverHold）全部落到了实验上。文中所有命令输出均为真实实测，域名已做替换。

一、背景：一次"改 NS"引出的连环追问

起因很简单：把 demo.asia 的 DNS 从阿里云（dns21.hichina.com / dns22.hichina.com）切到 Cloudflare。但顺着操作往下验证，问题一个接一个：

1. 注册商侧 NS 改完了，为什么全网 dig 还是查不到？
2. NS 填的是域名（aaa.ns.cloudflare.com），它自己还要解析成 IP，会不会死循环？
3. .com 顶层服务器凭什么知道 ns3.cloudflare.com 的 IP？
4. 在阿里云「云解析」里改记录，改的到底是不是顶级域名的数据？

这四个问题正好覆盖 DNS 的核心机制，下文逐一用实验回答。

二、域名层级：从右到左，逐级变小

以 blog.user.example.com 为例：

两个易混点：

• com.cn 不是顶级域名。它是 .cn 下的一个二级域，但注册局（CNNIC）把它作为独立注册类别开放，所以能注册 example.com.cn。
• hb.cn 的结构是「二级.顶级」，和 baidu.com 同构——hb 是二级域名，cn 是顶级域名。

DNS 命名空间是一棵倒树，每一层是一个「区」（zone），每层区由一组专门的权威服务器负责，只存下一层的「指路牌」。这张表贯穿全文：

三、TLD 服务器：顶级域名的"通讯录"

3.1 它存什么？

只存委派（NS 记录），不存 A 记录。

• NS 记录：告诉递归解析器"这个域名的权威服务器是谁"。
• A 记录：具体 IP，存在权威服务器的区数据里，TLD 一概不管。

3.2 注册局 vs 注册商

这一对角色经常被混为一谈：

• 注册局（Registry）：运营 TLD 区文件、跑 TLD 服务器。.asia 的注册局是 Identity Digital（前身 Afilias），TLD 服务器实测为 a0/b2.asia.afilias-nst.{info,org,asia} 六台。
• 注册商（Registrar，如阿里云）：卖你域名，把你的 NS、联系人等信息经 EPP 协议提交给注册局，写进 TLD 区。

所以「改 NS」本质上是：改 .asia 顶级区文件里，属于你域名的那条委派记录。入口在域名注册商控制台，而不是云解析控制台。

3.3 解析流程（referral 逐级引荐）

用户输入 blog.example.com
        ↓
递归解析器问根：example.com 谁管？ → 根：".com 由这些 TLD 服务器管"（referral）
        ↓
问 .com TLD：example.com 谁管？ → TLD："NS 指向 xxx.xxx.com"（referral）
        ↓
问该权威服务器：blog.example.com 的 A？ → 权威："x.x.x.x"（权威应答）

一句话总结：TLD 服务器不存 IP，只存"去问谁"。

客户端 → 本地递归解析器（如 223.5.5.5）这一段叫递归（resolver 替你跑全程）；resolver → 根 → TLD → 权威那一段实际是迭代（resolver 逐级问、逐级拿指路牌）。教科书把两者画成一条链，容易让人以为是同一过程。

四、实测：一次解析卡在了哪一步

新域名 NS 切到 Cloudflare 后，dig 验证结果：

$ dig NS demo.asia +short          # 全网视角：空
$ dig SOA demo.asia @aaa.ns.cloudflare.com   # 直接问 Cloudflare：有答案！
aaa.ns.cloudflare.com. dns.cloudflare.com. 2417099281 10000 2400 604800 1800
$ dig NS demo.asia @b2.asia.afilias-nst.org  # 直接问 .asia TLD
;; ANSWER: 0, AUTHORITY: 1 (只有 .asia 的 SOA，没有本域的 NS)

三个观察拼出完整结论：

1. Cloudflare 侧已就绪——直接指定它的 NS 查询，能返回权威 SOA（aa 标志）。
2. TLD 侧委派未发布——问 .asia 的服务器，返回空答案 + 顶层 SOA，即"这个域名在 .asia 区里不存在"。
3. 原因在 whois：

$ whois demo.asia | grep -i status
Domain Status: serverHold https://icann.org/epp#serverHold
Domain Status: addPeriod https://icann.org/epp#addPeriod

addPeriod 是新注册的缓冲期；serverHold 表示注册局拒绝把该域名发布进 TLD 区——通常是实名审核未通过。这就是为什么注册商侧 NS 显示已改、Cloudflare zone 已激活，但全网解析就是不通：委派链条在第 2 步（TLD）断了，查询根本走不到第 3 步（Cloudflare）。

serverHold 解除后委派立即写入 .asia 区，解析即刻走通，Cloudflare 侧无需任何操作。唯一的小延迟是 .asia 负缓存（查不到的 NXDOMAIN/NODATA 结论会被缓存，本例 SOA TTL 3600 秒），通常几分钟到一小时全网可见。

顺带纠正一个流行说法：「改 NS 要 24-48 小时生效」针对的是老域名换 NS、旧委派已被缓存的场景。新域名没有旧缓存，卡住的时间完全取决于审核（serverHold），跟"全球缓存刷新"无关。

五、鸡生蛋问题：NS 是域名，它自己怎么解析？

NS 填的是 aaa.ns.cloudflare.com 这样的域名。解析它得先拿到 IP，而拿 IP 似乎又要先完成域名解析——这不是死循环吗？

DNS 用两道保险解开，各自覆盖一种情况。

5.1 保险一：NS 主机名在"别人家"时，是一条独立且有限的短链

aaa.ns.cloudflare.com 位于 .com 分支，解析它与 demo.asia 毫无关系：

根 → .com → cloudflare.com 区 → ns.cloudflare.com 区 → aaa 的 A 记录

• 每一步都严格向下走（从更靠近根的层往叶子走），从不回头引用 demo.asia，链长有限（≤4 跳）→ 是链，不是环。
• 解析器对每层结果都有长缓存（dig 输出里 TTL 172800 = 2 天），这条链实际很少真走全程。

5.2 保险二：glue（胶水记录）——NS 主机名长在自家肚子里时

如果 NS 叫 ns1.demo.asia，那才是真死结：查它得先知道 demo.asia 的 NS，而 NS 就是它自己。权威记录"存在"和"可达"在这里分家了——A 记录确实存在于 demo.asia 区里，但查它得先连上 demo.asia 的权威服务器，而连接恰恰需要这个 IP。

解法：父区写委派记录时，顺带把这类主机名的 IP 直接写进响应的 ADDITIONAL 段。这就是 glue（胶水）记录。

实测根区给 .asia 的委派（dig NS asia. @198.41.0.4），其中 d0/b0.asia.afilias-nst.asia 两个名字就长在 .asia 区内（跳不出去），根区直接附上了它们的 IP：

d0.asia.afilias-nst.asia. 172800 IN A    199.254.30.1
b0.asia.afilias-nst.asia. 172800 IN AAAA 2001:500:16::1
...

六、glue 是申报制：TLD 不是"知道"，是"被告知"

一个自然的追问：.com 顶层服务器凭什么知道 ns3.cloudflare.com 的 IP？

答案是它不"知道"，是 Cloudflare 主动申报写进 .com 区文件的。 TLD 区文件里关于一个域名的数据只有两类，全都是域名所有者经注册商提交的：

注册局从不自己"发现"这些 IP——它也没资格，因为 ns3.cloudflare.com 的真实答案归 cloudflare.com 区管，不归 .com 管。数据流是单向的：域名所有者 → 注册商 → 注册局区文件。

6.1 对照实验：没申报的，一个 IP 都不给

github.com 的 NS 大部分长在别人家：

$ dig NS github.com @a.gtld-servers.net +noall +authority +additional
github.com.  172800 IN NS ns-520.awsdns-01.net.      ← .net，.com 管不着
github.com.  172800 IN NS ns-421.awsdns-52.com.    ← 唯一在 .com 肚子里的
github.com.  172800 IN NS dns1.p08.nsone.net.      ← .net
...
ns-421.awsdns-52.com. 172800 IN A 205.251.193.165  ← 只给这一个 IP

.com 只给了一个 IP——恰好是唯一长在 .com 区内的那个名字。其余一个都不给，resolver 得自己去 .net/.org/.co.uk 各自解析（保险一的独立短链）。一行不多、一行不少：.com 区文件里存了什么，完全取决于当初所有者申报了什么。

6.2 glue 是"提示"，不是"权威"

直接问 .com 服务器「ns3.cloudflare.com 的 A 记录」，它拒绝正面回答：

$ dig ns3.cloudflare.com A @a.gtld-servers.net
;; status: NOERROR, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 21

ANSWER: 0——glue 永远不出现在权威应答里，只作为 referral 的搭车数据。glue 填错不会冒充答案，只会连不上（lame delegation）。resolver 拿 glue 的 IP 去建立连接，真正的解析答案以权威服务器的应答为准（DNSSEC 下还有签名保护）。

这也解释了为什么 Cloudflare 的 NS anycast IP 几乎永不变：glue 散落在全世界各个 TLD 的区文件里，改一次 IP = 通知所有客户重新申报，所以干脆把 NS 地址做成 anycast、永久稳定。

七、双副本：同一份 A 记录存在两个地方

把上一节推到底会发现：ns3.cloudflare.com 的 A 记录同时存在于两个地方，角色完全不同：

实测验证（②的应答 IP 与 ①的 glue 完全一致）：

$ dig ns3.cloudflare.com A @ns3.cloudflare.com   # 问权威服务器自己
;; flags: qr aa rd, ANSWER: 2
ns3.cloudflare.com. 86353 IN A 162.159.0.33
ns3.cloudflare.com. 86353 IN A 162.159.7.226

这个双副本设计是刻意为之：每一次委派在结构上都是循环的（子区的数据在子区的服务器上，找服务器又要经过子区）。NS 记录同样是双副本——父区存委派 NS（AUTHORITY 段），子区 apex 上再存一份自己的 NS（ANSWER 段）。系统靠「父区一份非权威提示 + 子区一份权威真身」才转得起来。RFC 8499 对 glue 的定义说得很直白：它是区里的数据，但不是权威数据。

八、缺 glue 会怎样：精确的失效边界

只有 NS 主机名长在**自家 zone 内（in-bailiwick）**时，缺 glue 才致命：

递归器拿到 referral："cloudflare.com 去问 ns3.cloudflare.com"
  → 要连 ns3 就得先有它的 IP
  → 发起解析 ns3.cloudflare.com → 又问到 .com
  → .com："ns3.cloudflare.com 由 ns3.cloudflare.com 管"  ← 原地打转
  → resolver 检测到 referral 环（跳数上限）→ SERVFAIL，整域瘫痪

三个补充：

• 部分申报也能活：5 台 NS 只要有 1 台有 glue，递归器就能绕过去——这是 NS 配多台的容灾意义。
• out-of-bailiwick 无此问题：aaa.ns.cloudflare.com 之于 demo.asia，不需要 glue，缺了也不影响。
• 所以 EPP 协议强制：创建 in-bailiwick 主机对象必须带 IP。注册商控制台里「自定义 DNS Host」功能那个必填的 IP 输入框，就是这个约束的 UI——它登记的就是 glue。

九、纠正一个合并误区：改 NS ≠ 改解析记录

「我通过阿里云 DNS 改记录，最后实际修改的就是顶级域名的数据，对吧？」——不对。这是两种修改，落点完全不同：

实测证据：

$ dig A qq.com @b2.asia.afilias-nst.org        # 问 TLD 要二级域的 A
;; status: REFUSED                              # TLD 根本没有这种数据

$ dig A demo.asia @dns21.hichina.com            # 问阿里云旧权威
;; status: NOERROR, flags: aa, ANSWER: 0        # 旧区还完整活着（僵尸区）

$ dig A demo.asia @aaa.ns.cloudflare.com        # 问 Cloudflare 新权威
;; status: NOERROR, flags: aa, ANSWER: 0        # 新区也已就绪，还没加记录

解析记录从来不在 TLD。TLD 只存「这个域名的记录去问谁」一句指路牌；真正的 A/MX 存在被指的那个权威服务器上。区数据跟着委派走：谁被委派，谁手里那份才是全网唯一生效的，另一份就是无人查询的僵尸（hichina 上那份）。

「没有开放给我修改，要通过注册商」——这句话只对 TLD 区数据（NS 委派、glue、DNSSEC 的 DS 记录）成立：注册局接口不对公众开放，必须经 ICANN 认证的注册商用 EPP 操作。而解析记录从来没在注册局那里，你在任意 DNS 服务商控制台直接增删改，不经注册商。

实际影响：NS 切到 Cloudflare 后，旧服务商控制台里改的任何记录全网没人再查询了——生效的区在 Cloudflare，解析记录要在 Cloudflare 重新配好。

十、SOA 记录：区的"户口本首页"

SOA（Start of Authority）定义一个 DNS 区域的权威信息，每个区有且仅有一条：

和你操作的关系：把 NS 从服务商 A 换到 B，本质是更换权威来源——之前 SOA 由 A 的服务器应答，之后由 B 应答。SOA 不需要手动创建，DNS 服务商自动生成。本文用到的两处 SOA 数据顺手可查：负缓存时长（判断"查不到"要多久过期）、Serial（判断两侧区数据是否同步）。

十一、NS 委派 vs 直接加 A 记录

委派不只是"换 DNS 服务商"用的——在自己的区里给子域名写 NS 记录，就能把子域管理权下放：

示例：你拥有 example.com，给 user1.example.com 添加两条 NS 记录指向 ns1.otherdns.com / ns2.otherdns.com，此后 user1.example.com 及其所有下级的解析完全由对方负责。

为什么"平台提供三级域名给用户"场景标配 NS 委派：

1. 用户拥有完整控制权（A/CNAME/MX/TXT 全套）；
2. 平台只维护"谁拥有哪个子域"这一层，不碰用户数据；
3. 用户可以把子域再委派到 Cloudflare 等服务，享受 CDN/防护；
4. 解析压力分散到用户各自的 DNS 服务器。

延伸玩法：用 NS 委派搭一个"三级域名分发服务"

顺着上面的思路推：既然 NS 记录可以逐级委派，那能不能注册一个域名，把它的子域分发给别人当独立域名用？逻辑上完全成立，这正是很多免费二级/三级域名服务和域名分发平台的核心原理：

1. 你注册 example.com；
2. 为每个用户划出 user1.example.com 这样的子域，把它的 NS 委派给你自建的 DNS 系统（或第三方平台，甚至直接委派给 Cloudflare，让用户在 Cloudflare 后台自助管理）；
3. 在这套系统里自由创建 blog.user1.example.com、shop.user1.example.com 等，分配给不同用户；
4. 用户拿到的是一个完整、可独立解析的三级域名。

但有几个现实限制

1. 得有一套能跑自动化的 DNS 权威：批量分发意味着程序化增删区数据。阿里云/Cloudflare 的网页控制台只能手动加记录，撑不起"注册即开通"；要做自动化，得用带 API 的 DNS 服务或自建权威（BIND/PowerDNS/CoreDNS + 注册流程）。
2. 证书链路的控制权：CA 逐名验证（见第十二节）——三级域名 a.b.example.com 的 DNS-01 验证记录要加在 a.b.example.com 名下。委派出去后用户能自助完成；没委派时每次签发/续期都要平台配合，或用 CNAME 把 _acme-challenge 引到用户自己的验证区。
3. 浏览器与邮件生态的信任折扣：三级域名 URL 长、与主域共享信誉，免费子域名服务是滥用重灾区，容易被搜索引擎降权、被邮件服务商拉黑。
4. 委派稳定性 = 你的责任：被委派的那组 NS 一旦挂掉，该子域下所有三级域名全部解析失败——用户把命脉交给了你的基础设施。

一句话总结：NS 记录可以逐级委派，每一级都能把下一级的解析权交出去——这是 DNS 分层管理的精髓；但"逻辑上能做"与"运营得好"之间，隔着自动化基础设施和长期信任建设。

顺带一提：本文 demo.asia 这种情况就是委派的逆操作——注册局在 .asia 区里给整个二级域做委派，而 serverHold 就是注册局暂时扣住这条委派不发。

十二、SSL 证书验证：逐名验证，不是只验二级域名

常见误区："申请证书时都是检验二级域名的控制权吗？"不是。 CA 验证的是你申请的那个完整域名（FQDN）本身。无论申请 example.com 还是 a.b.example.com，验证对象都是提交申请的那个完整名字：

要完成 a.b.example.com 的验证，你必须在 a.b.example.com 下添加记录——前提是你拥有该域所属 DNS 区域的管理权限或委派权限。这正好印证 NS 委派的价值：把 b.example.com 委派给用户后，用户就能自己完成 DNS-01 验证；DNS 还在你手里时，用户每张证书都得找你。

和本文主线的呼应：改 NS 到 Cloudflare 后，DNS-01 验证走的就是 Cloudflare 的 TXT 记录；若用 acme.sh 等 ACME 客户端配合 Cloudflare API Token，续期全自动。

十三、完整操作：把注册在阿里云的域名切到 Cloudflare

13.1 操作前准备

备份现有解析记录：进入云解析控制台，把 A/CNAME/MX/TXT 记录导出或截图。特别是 MX 和 TXT，遗漏会导致邮箱收不到信。

13.2 第一步：在 Cloudflare 添加域名

1. 登录 Cloudflare，点「添加站点」，输入根域名（如 demo.com，不要带 www 或协议头）。
2. 选 Free 套餐。
3. 核对自动扫描出的记录；MX/TXT 务必保持「仅 DNS」（灰色云朵），橙色云朵是 Cloudflare 代理，只该给需要 CDN 的网站记录开。
4. 复制 Cloudflare 分配的两个专属 NS（形如 xxx.ns.cloudflare.com，每个域名按哈希分配一对，同账号不同域名的对子也不同）。

只能用分配给这个域名的那对：Cloudflare 的激活检查按分配对校验注册局委派，对不上 zone 会一直卡在 Pending Nameserver Update。把上一个域名用过的 NS 抄过来、或者填 4 个（分配对 + 旧对子）都不可靠——所有 *.ns.cloudflare.com 背后是同一套 anycast 集群，旧对子没有任何额外价值。

13.3 第二步：在注册商控制台修改 DNS 服务器

1. 登录阿里云域名控制台（不是云解析控制台），找到域名 →「管理」。
2. 左侧菜单「DNS 管理」→「DNS 修改」→「修改DNS服务器」。
3. 替换为 Cloudflare 的两个 NS，提交。注册商侧立即反映；TLD 侧写入时间取决于注册局（新域名还要等实名审核的 serverHold 解除）。

13.4 第三步：验证与等待

分四层逐一确认，哪层断了修哪层：

$ whois demo.asia | grep -i status        # ① 注册局：serverHold 是否已解除
$ dig NS demo.asia @b2.asia.afilias-nst.org   # ② TLD：委派是否已发布
$ dig SOA demo.asia @xxx.ns.cloudflare.com    # ③ Cloudflare：zone 是否激活
$ dig demo.asia +short                        # ④ 全网：端到端是否解析

③可先行：zone 在 Cloudflare 激活后即开始应答，②发布后全网立即可达（受负缓存影响最多等一个 SOA TTL）。

十四、国内主流注册商速览

注册商只影响"改 NS 的入口好不好找"，解析质量取决于 NS 指向谁——反正都要切 Cloudflare 的话，差别不大。注意：NS 切走后，原注册商的「云解析」产品就闲置了，别再两头改记录。

十五、核心总结

1. 域名层级：从右到左逐级变小；每层是一个 zone，由对应权威服务器负责。
2. TLD 服务器：注册局运营，只存 NS 委派不存 A 记录，「改 NS」改的就是 TLD 区里自己域名那条委派。
3. 委派链是 referral 逐级引荐：客户端→resolver 是递归，resolver 逐级问各级权威是迭代；任何一环缺失（如 serverHold）整链即断。
4. 鸡生蛋有两道保险：NS 主机名在别人家时走独立向下短链；在自己家时靠父区 glue。glue 是申报制的非权威提示，只用于建立连接，永不作为答案。
5. 权威数据双副本：委派 NS 和 NS 主机名的 IP 都同时存在于父区（提示）和子区（真身），这是结构性循环得以运转的关键。
6. 改 NS ≠ 改解析记录：前者动 TLD 区（经注册商），后者动权威区（在 DNS 服务商）；区跟着委派走，谁被委派谁生效。
7. serverHold：实名审核未过时注册局扣住委派，与"缓存传播"无关；审核一过分钟级生效。
8. SOA：区的户口本，换 NS 即换权威来源，自动生成无需手管。
9. SSL 验证逐名进行：验证的是申请的完整 FQDN，前提是能控制该名字所属的 DNS 区（直管或被委派）。
10. 切换 Cloudflare 三步：备份记录 → Cloudflare 添加站点拿专属 NS 对 → 注册商改 NS；只能用分配对，按 ①whois ②TLD ③zone ④全网 四层验证。

文中实测基于 2026-10 的 dig (9.18) 与阿里云/Cloudflare 控制台现状，输出已将真实域名替换为 demo.asia。