US.KG（DigitalPlat FreeDomain）权威 DNS 迁移实战：换 NS 服务商时如何零中断切换域名解析

在 US.KG / DigitalPlat FreeDomain 这类"注册平台只管委托、记录托管在外部 DNS 服务商"的架构下，更换权威 DNS 服务商会把整个 zone 的权威来源一次性换掉——哪怕网站还能打开，漏迁一条 MX 或 TXT 记录就足以让邮箱、API 或证书续期悄悄中断。本篇基于教程第 5 章的 安全迁移 Nameservers，带你走完整条迁移链路：盘点旧 zone 记录、先建新区再改委托、双服务并行过渡期管理、分层验证与回滚预案；读完后你能独立完成一次可验证、可回滚的权威 DNS 服务商切换。

为什么换 NS 是"全量切换"而不是"单条记录切换"

理解这次操作的前提，是分清域名的三个视角。DNS 委托章节指出同一个域名存在三份"状态"：

1. 注册视角（Registration view）：DigitalPlat 注册侧保存的"预期权威 NS 主机名"；
2. 父级 DNS 视角（Parent DNS view）：父域（.dpdns.org / .us.kg 等）实际发布、递归解析器真正跟随的委托；
3. 子域权威视角（Child authoritative view）：外部权威服务发布的 SOA、NS 和普通资源记录。

三者必须足够一致解析才能工作。换 NS 服务商意味着第 3 层的 zone 整体搬到新服务，随后修改第 1 层，等待第 2 层传播。这与单条 A 记录改值完全不同：单条记录失败只影响一个名称，而 NS 迁移遗漏任何一条记录，都可能让依赖它的服务（邮件、验证、API）在"网站正常"的表象下中断。

DigitalPlat 本身只负责委托——连接外部 Nameservers 章节明确说明其职责止于 delegation，普通 DNS 记录的编辑器在外部 DNS 服务里。因此迁移的"新旧两区"都建在第三方权威 DNS 服务中，注册侧只需改 NS 字段。

第一步：盘点旧 zone（Inventory the Old Zone）

迁移前必须收集旧 zone 的每一条记录并确认归属。5.3 原文档给出的盘点清单覆盖以下类型：

• A 和 AAAA：站点与服务的地址记录
• CNAME：别名（如 www）
• MX：邮件交换器
• TXT：包括 SPF 与各类所有权验证记录
• DKIM 选择器记录（如 selector1._domainkey.example.dpdns.org）
• DMARC 策略（_dmarc.example.dpdns.org）
• CAA：限制可为域名签发证书的 CA
• SRV
• 被委托子域的 NS 记录（子域再委托给其他权威时的委派记录，容易在迁移中整段丢失）

两个关键提醒：

1. 不要用 ANY 查询做 zone 导出。原文档明确指出 ANY query 不是可靠的导出手段——很多权威服务会对 ANY 限流或只返回部分记录。应使用旧 DNS 服务商支持的导出功能或管理接口（控制台导出、API 拉取）。
2. 盘点时记录每条记录的 TTL 值，因为下一步要连 TTL 一起复制。

配合 命令参考 可以逐类核对旧区现状，例如：

# 邮件相关记录
dig MX example.dpdns.org
dig TXT example.dpdns.org
dig TXT selector1._domainkey.example.dpdns.org
dig TXT _dmarc.example.dpdns.org

建议把盘点结果整理成一张"旧区清单"（名称 / 类型 / 值 / TTL），作为后续逐条比对新区的基线。

第二步：先建新区，且不动注册级 NS（Build the New Zone First）

原文档的操作顺序是"先建新区、暂不改注册级 nameserver"，共四步：

1. 在新 DNS 服务中创建 zone，不修改注册侧 nameserver；
2. 逐条复制记录与 TTL 值；
3. 检查新服务自动生成的 SOA 和 NS 记录；
4. 直接查询新权威服务器，确认 zone 已对外可见。

第 4 步尤其重要：权威服务器必须在任何缓存生效之前就能应答，否则等注册侧改完 NS，父级委托指过来时新 NS 根本答不了。原文档给出的验证命令：

dig @new-ns1.dns-service.example A example.dpdns.org
dig @new-ns1.dns-service.example MX example.dpdns.org
dig @new-ns1.dns-service.example TXT _dmarc.example.dpdns.org

补充几点实操细节：

• SOA/NS 要逐个新 NS 验证：外部 Nameserver 检查清单要求"每台外部权威服务器都能应答 SOA"，即 dig @nsA SOA ... 与 dig @nsB SOA ... 都应有应答，避免"一台同步了、另一台还在追"的半迁移状态。命令参考中还有 dig +tcp @ns1.dns-service.example SOA ... 用于在 UDP 被截断时用 TCP 复核。
• 对照旧区清单逐类型核对：A/AAAA、CNAME、MX、TXT、DKIM、DMARC、CAA、SRV、子域 NS 各跑一遍直接查询，与第一步清单逐项打勾。
• 记录格式细节（MX 目标必须是有地址记录的主机名、CNAME 不能与同名的其他记录并存等）参见 DNS 记录类型章节，照抄值时注意这些类型约束在新旧两区都成立。

迁移前降低 TTL，缩短缓存过渡期

DNS 变更不会即时到达每台设备——递归解析器会按 TTL 缓存应答。TTL 与传播章节给出迁移类变更的时间规划：

场景	示例 TTL	权衡
稳定生产记录	3600 ~ 86400	查询少，紧急变更慢
计划内迁移	300 ~ 600	过渡快，查询量增加
临时测试	60 ~ 300	迭代快，查询量更高

其"规划一次 DNS 迁移"的步骤可直接套用到 NS 迁移：

1. 至少提前一个旧 TTL 周期，把将要变动的记录 TTL 调低；
2. 确认降低后的 TTL 能从权威服务器查到；
3. 再执行地址/目标变更（这里对应"改委托"）；
4. 重叠期保持旧服务可用；
5. 分别从权威和递归解析器验证新应答；
6. 迁移稳定后把 TTL 调回正常值。

特别提醒：迁移前一秒才降 TTL 对已经以旧长 TTL 缓存的副本无效。所以"降 TTL → 等满一个 TTL 周期 → 改 NS"这个顺序不能颠倒。

第三步：修改注册侧委托（Change the Delegation）

在 DigitalPlat 的域名管理界面，把旧的权威 nameserver 整套替换为新的完整集合，保存前逐字核对拼写。这里有两个高频错误，1.3 章节的"常见错误"表值得照抄：

错误	正确做法
只填新分配 NS 中的一个	必须填入完整分配集合
把服务器 IP 当作 NS 值	NS 字段只能填权威 nameserver 主机名
在 NS 字段填入 A 记录值 / CNAME 值 / 客户端解析器 IP	这些属于不同上下文，不要混填

2.0 委托章节还专门列了"字段不要混用"的对照：

Nameserver 字段: ns1.dns-service.example
A 记录值:   192.0.2.10
CNAME 值:      another-host.example
解析器地址: 客户端上配置的 IP

四个值分属不同上下文，写错上下文是委托故障的主要人为来源。

过渡期：两套服务同时保留（Keep Both Services Running）

委托改完不等于全网生效。旧委托的应答仍可能被大量解析器缓存，因此原文档要求：

• 旧 zone 在整个过渡期内保持在线且内容一致；
• 不要在 Dashboard 显示新 NS 后就立刻删除旧 zone。

"多久算够"取决于 TTL：父级 NS 应答本身也有 TTL，旧 NS 集合的缓存会持续到期刷新。稳妥做法是观察 dig NS example.dpdns.org（走递归解析）稳定返回新 NS 集合，且至少覆盖原 NS 记录的一个完整 TTL 周期后，再下线旧 zone。期间旧区若有变更（如证书验证 TXT 更新），两边都要同步，避免不同解析路径拿到不一致的应答。

验证：从父级到应用层逐层核对

原文档的验证命令组：

dig +trace NS example.dpdns.org
dig NS example.dpdns.org
dig A example.dpdns.org
dig MX example.dpdns.org
curl -I https://example.dpdns.org

建议按"由上至下"的层次执行，并区分权威态与缓存态：

1. dig +trace NS ...：看父级（注册商/父域）发布的是哪套 NS。若 trace 末尾仍是旧 NS，说明父级委托还没刷新（缓存或注册传播延迟），问题在注册/父级层；
2. dig NS ...：递归解析器视角。与 trace 对比可以区分"父级委托问题"与"子区问题"——这是 2.0 章节强调的 trace 的核心用途；
3. dig @new-ns1... A/MX/TXT ...：直查新权威，确认 zone 内容完整；若权威答新值而递归答旧值，说明 zone 是对的、是缓存还没到期——此时等待比反复改记录更安全（2.3 章节）；
4. 功能面测试：原文档要求实测网站、邮件、API、证书续期、以及各关键子域名。可参考 故障决策树 里的分层排查（域名不可解析 → NS → SOA → 记录存在性 → 递归缓存/TTL）；命令参考 还提供了 curl -I、openssl s_client 查看证书、nc -vz 测连通性等配套命令。

保存一份诊断证据便于复盘（命令参考中的现成模板）：

{
  date -u
  dig NS example.dpdns.org
  dig A example.dpdns.org
  curl -I --max-time 15 https://example.dpdns.org
} > domain-diagnostic.txt 2>&1

2.0 章节还给了一个"证据工作单"格式：记录预期外部 NS、观测到的委托 NS、两台 NS 各自的 SOA 应答、UTC 检查时间与下一步动作——迁移这种高风险变更值得照此留档。

委托故障模式速查

迁移期间出问题时，按 2.0 委托章节的故障模式表定位层次：

现象	可能所在层
父级仍指向旧 NS 主机名	注册或父级委托（等待传播或注册侧未保存成功）
NS 主机名正确但查询超时	外部权威服务或网络问题
一台 NS 应答、另一台不应答	外部 DNS 同步未完成或可用性
SOA 返回"zone 不存在"	新 DNS 服务中 zone 缺失（拼写错误时常见）
NS 正常但 A 记录为空	新 zone 中漏抄普通记录

回滚：委托可逆，前提是双区都在

原文档的回滚原则：若新权威服务不完整或不可用，就在注册服务恢复上一套 nameserver，并让两个 zone 都保持完整，直到委托稳定。

回滚之所以可行，正依赖前面的两条纪律：旧 zone 没删、旧 NS 值留档。实操上建议：

• 改 NS 前把"旧 NS 完整集合"逐字抄进变更单（检查清单模板 中的 "DNS Change Template" 专门有 Rollback value 与 Rollback decision time 两个字段，就是为此设计的）；
• 回滚后同样要验证：dig +trace NS、逐条记录直查、功能面测试，流程与正向验证对称；
• 若旧 zone 在过渡期被改过，回滚前确认旧区内容与回滚目标一致，否则会出现"委托回去了、记录却对不上"。

检查清单 中的"外部 Nameserver 检查清单"可作为迁移收尾的最终验收：zone 拼写与注册域名一致、全部 NS 主机名已记录、NS 字段无 IP、注册侧已保存、dig NS 返回预期值、每台权威 NS 都应答 SOA、普通记录只在外部 zone 管理。

小结：迁移的完整顺序

把全文压成一条可执行时间线：

1. T−n（至少一个旧 TTL 周期）：盘点旧 zone 全量记录与 TTL（用服务商导出，不用 ANY）；把要变动的记录 TTL 降至 300~600 量级；
2. T0：新 DNS 服务建 zone，逐条复制记录与 TTL，核对自动生成的 SOA/NS；直查每台新 NS 验证 A/MX/TXT/DKIM/DMARC 等关键记录；
3. T1（TTL 已传播后）：DigitalPlat 注册侧整套替换为新 NS，逐字核对拼写；
4. T1 ~ T1+1 个完整 TTL：双区并行，旧区保持在线且同步；用 trace + NS + 直查权威 + 递归对比逐层验证；
5. 稳定后：恢复 TTL；实测网站/邮件/API/证书续期/关键子域；留档诊断输出；
6. 异常时：注册侧恢复旧 NS，双区保持完整，等委托稳定后再排查新区问题。

掌握这条链路后，无论是换 DNS 服务商、多服务商冗余，还是故障回切，都只是在"建新区 → 验证 → 改委托 → 观察 → 回滚"同一套动作上的参数替换。下一篇 注册信息与隐私 会继续讲委托之外的注册数据管理。