Cloudflare 托管 DNS 的注意事项
把域名的 NS 指向 Cloudflare，动作只有一步，影响却很宽：从这一刻起，这个域的所有解析由 Cloudflare 的权威服务器回答，注册商面板里的记录不再生效，代理开关开始改变流量路径。读完这篇，你能判断接管前后哪些行为会变，能避开几类改完才发现问题的操作，也知道出问题时怎么退回去。
前置动作是把域名加进账号，流程见 49-add-domain-to-cloudflare.md；记录本身的写法见 50-dns-records-tutorial.md。
1. 接管发生在注册商那一侧
Cloudflare 不会去抢你的域，它只是拿到一组 NS 名字，等你在注册商处把域名的 NS 改成这两个名字。加域时分配到的 NS 是固定的一对，本机查到的两个真实例子：
| 域名 | 权威 NS | 查询方式 |
|---|---|---|
| example.com | ELLIOTT.NS.CLOUDFLARE.COM、HERA.NS.CLOUDFLARE.COM | RDAP secureDNS 与 nameservers 字段 |
| hono.dev | leland.ns.cloudflare.com、gemma.ns.cloudflare.com | Resolve-DnsName -Type NS |
名字是随机分配的，同一账号下不同域也可能是不同的一对，抄别人的 NS 名字没有意义。免费版给两个 NS，付费版会多给，这是冗余度差别，不是功能差别。
改完 NS 之后，解析开始由 Cloudflare 回答，注册商面板里原来那套记录停止生效。这一步没有"两边同时生效"的中间态，只有传播窗口里新旧权威服务器各回答一部分查询的过渡期。
2. 四件会跟着变的事
第一件是 SOA 与 NS 的答案。接管后查 SOA，管理员邮箱字段会变成 dns.cloudflare.com，这是判断"到底谁在回答"最快的方法，比看 NS 记录更准，因为 NS 记录可能被缓存。
第二件是 TTL。代理开着的记录，控制台里显示的 TTL 是 300 秒，但边缘实际返回的 TTL 往往更短，本机用 DoH 查到的两个值：example.com 的 A 记录 TTL 170，cloudflare.com 的 A 记录 TTL 10。这个数值由边缘按自己的策略给，不受你填的数字控制。想控制缓存时长，要去缓存规则里做，不是在 DNS 面板。
第三件是根域可以填 CNAME。这叫 CNAME flattening，Cloudflare 在回答时把 CNAME 展开成 A/AAAA，所以根域能挂到 SaaS 给的域名上。代价是这个能力只有 Cloudflare 认，将来把 NS 换走，这条记录会直接失效。
第四件是记录只能在这一处改。注册商的 DNS 面板变成摆设，任何人从那边加记录都不会生效。团队协作时这点要写进交接文档，否则会出现"我在注册商加了记录怎么没用"的排查弯路。
3. 哪些记录不能开代理
代理（橙色云）本质是把域名解析到 Cloudflare 的任播地址，由边缘回源。它只处理 HTTP/HTTPS 流量，所以下面这些记录一旦开代理就会坏：
| 记录 | 开代理的后果 |
|---|---|
| MX | 邮件投递到边缘，收不到信 |
邮件相关 A（如 mail） | SMTP、IMAP 端口不代理，客户端连不上 |
| TXT、NS、SRV、CAA | 无代理选项，强行理解成代理没有意义 |
| 非 80/443 的服务端口 | 端口不通，表现为连接超时 |
纯 DNS 的 A 记录不会隐藏源站，但也不会因为边缘策略变动而出问题。做邮件、做游戏服务端、做 SSH 入口的子域，一律用仅 DNS。
4. 子域可以单独委派出去
如果某个子域要交给别人管，在 Cloudflare 里加一条 NS 记录指向对方的权威服务器即可，这叫子域委派。委派出去之后，那个子域下所有记录由对方回答，你在这边加的记录不起作用。
反过来的用法也成立：把 dev.example.com 委派给另一台自建 DNS，主域继续由 Cloudflare 管。这条记录的 TTL 建议给长一点，委派关系不常变，频繁变动会让下游缓存混乱。
5. 改 NS 之前的准备清单
- 在旧 DNS 处导出全部记录，多数商家提供 BIND 格式导出，导出的文本比截图可靠。
- 把要保留记录的 TTL 提前降到 300，等一个旧 TTL 周期再动 NS，切换窗口能从小时级压到分钟级。
- 把邮箱验证类记录（SPF、DKIM、DMARC、各种 site-verification）逐条抄过去，这类记录漏掉不会报错，只会让邮件进垃圾箱或验证失败，处理方式见 89-spf-dkim-dmarc.md。
- 记下当前 SOA 与 NS 的查询结果，出问题时用来对比是谁在回答。
- 保留旧 DNS 服务至少一周，不急着退订。
回滚路径同样简单：把注册商的 NS 改回旧值。前提是旧 DNS 那边的记录还没删，这也是要保留一周的原因。
常见问题
改完 NS 多久生效？
取决于旧 NS 记录的 TTL，通常是 24 到 48 小时内陆续完成。期间用不同网络查同一个域可能得到不同结果，属于正常现象。用 95-dns-troubleshooting-dig.md 里的方法分别问权威服务器和公共解析，能看清卡在哪一段。
能不能两家 DNS 同时用？
一个域只能有一组权威 NS，做不到"两家都生效"。想要分流只有两种办法：按子域委派，或者把整域交给其中一家，另一家只做备份的只读副本。
把域从账号里删掉会怎样？
Zone 删除后 Cloudflare 不再回答这个域的查询，而注册商的 NS 还指着 Cloudflare，结果就是全域名解析失败。删 Zone 之前先把 NS 改回注册商默认值。
小结
托管 DNS 的核心不是记录怎么写，是权限边界变了：解析权、TTL 策略、根域 CNAME 这些能力一起转移到了 Cloudflare 一侧，注册商只剩 NS 指向这一件事。理解这一点，很多"为什么改了没用"的问题会自己消失。
操作上真正需要谨慎的只有三处：改 NS 前的导出与降 TTL、邮件类记录不能开代理、以及根域 CNAME 的不可迁移性。这三处做对，剩下的都是日常增删记录。域名续费与转移的坑在 93-domain-transfer-renewal.md 里单独讲。
数据来源与检索时间
检索时间 2026-11-10。DNS 查询为本机实跑，DoH 走 https://cloudflare-dns.com/dns-query。
| 来源 | URL | 对应数据 |
|---|---|---|
| Cloudflare 名称服务器文档 | https://developers.cloudflare.com/dns/zone-setups/full-setup/setup/ | NS 分配、注册商处改 NS 的流程、生效时间 |
| Cloudflare 代理状态说明 | https://developers.cloudflare.com/dns/proxy-status/ | 代理只处理 HTTP/HTTPS、仅 DNS 的适用场景 |
| Cloudflare CNAME flattening | https://developers.cloudflare.com/dns/cname-flattening/ | 根域 CNAME 的展开机制与限制 |
| Verisign RDAP | https://rdap.verisign.com/com/v1/domain/example.com | example.com 的 NS 与 secureDNS 字段 |
核验说明
- 实查：
example.com、hono.dev、cloudflare.com的 NS；example.com的 SOA 管理员字段（dns.cloudflare.com）；example.com与cloudflare.com的 A 记录 TTL（170 与 10），经 DoH JSON 取得。RDAP 返回的nameservers与secureDNS字段一并核对过。 - 依据文档：代理状态对邮件端口的影响、CNAME flattening 的展开行为、子域委派的 NS 记录写法。这些需要真实 Zone 权限才能实测。
- 未执行：改 NS、加删记录、删 Zone、子域委派，本机没有该域的 Zone 管理权限，全部只按文档描述，未在账号里落地。