更换域名NS与迁移DNS解析服务
更换NS是在改变“由谁回答这个域名的DNS查询”，不是修改某一条A记录，也不会自动搬走网站文件、数据库或邮件。先查明当前权威NS及其实际DNS托管位置，再确定需要迁入的新DNS服务；域名注册仍由注册商管理。DNS记录应在当前权威NS对应的托管服务中管理，与购买服务器的位置无关。
切换前保存完整记录
确认你能管理注册商、当前DNS托管服务和新DNS服务的账号，并记录当前权威NS。先从旧DNS导出完整区域作为备份；不支持导出时逐条整理完整名称、类型、值、TTL、MX优先级及特殊设置。不能只复制根域名和www：邮件MX及其目标A/AAAA、SPF/DKIM/DMARC等TXT、证书或服务验证TXT、CAA、SRV及子域名委派都可能仍在使用。SRV还要保留优先级、权重、端口和目标；不要把各字段合并丢失。原服务若有分线路、地域、权重、代理或智能解析规则，应先确认新服务具备等效能力，把它们抄成普通记录不等于迁移了原路由效果。
| 需要留存 | 为什么要保存 |
|---|---|
| 旧NS和DNSSEC状态 | 核对切换前委派，并为受控回退留依据。 |
| 完整DNS记录 | 自动扫描可能遗漏未被发现的子域名或验证用途。 |
| 业务检查清单 | 至少包含网站、接口、邮件收发及第三方验证。 |
| 原服务有效期与访问权限 | 切换期间仍需保留旧区数据，不能先注销旧服务。 |
先在新DNS准备记录，再改NS
- 在选定的新DNS服务创建自己控制的域名区域，例如example.com；域名不带网址协议或页面路径。具体入口以该服务实际界面为准，不照抄其他平台菜单。
- 导入或逐条创建旧区业务记录，与完整清单逐项比对；自动扫描只能作为起点，不能据此断言没有遗漏。新服务自动生成的SOA、区顶NS及DNSSEC签名数据应按其迁移方案处理，不把旧密钥和签名当普通业务记录照搬。
- 保持记录的实际用途与访问方式。纯DNS迁移先不同时启用新的代理、CDN或流量策略；已有这些功能时，先确认迁移方案能保留业务所需行为，不能一律关闭或开启。
- 从新服务为这个域名实际分配的结果中记录整组NS。不同域名的分配可能不同，不能照抄教程、另一个域名的NS，也不把新服务的任意服务器地址当成分配结果。
改NS前先预检新权威记录
先不要改注册商NS。把example.com换成自己的域名，NS_NAME换成新DNS分配的真实NS主机名，在Windows、macOS或已提供nslookup的Linux终端执行；对整组新NS分别核对：
nslookup -type=a example.com NS_NAME
nslookup -type=mx example.com NS_NAME根据清单继续核对实际使用的AAAA、TXT、CAA、SRV及子域名委派，名称、值及MX/SRV参数均应符合预期。对新旧NS分别核对，并在过渡窗口内同步仍需变更的业务记录，避免两边回答不同数据。缺记录、错误或查询失败时先修正再切换；直接查询新权威只证明新区域准备情况，不表示公共委派已经改变。
检查DNSSEC，再修改注册商委派
现有域名启用了DNSSEC时，普通迁移先在注册商按官方流程撤销旧DS委派；不能只在旧DNS服务商停止签名，就认定父区DS已移除。先记录旧DS的TTL，确认注册商处理完成，并等待旧DS缓存按原TTL到期后，再修改NS；在此之前保留旧DNS正常回答与签名。注册商状态、DS移除结果或等待条件不明确时，先停止切换并向注册商核实。
macOS或有dig的Linux可辅助查询，示例域名必须替换：
dig DS example.com保留完整状态和答案；仍返回旧DS时不能继续切换。NOERROR下的空答案仅表示当前查询未返回DS，还需结合注册商确认和原DS TTL判断；超时、SERVFAIL或工具报错不等于DS已撤销。保留旧DS却换到不匹配的新密钥，可能使校验解析器返回SERVFAIL。普通迁移在移除DS的过渡期失去DNSSEC验证保护；业务依赖DNSSEC真实性保证时，不应直接采用这一流程，应先制定新旧DNS和注册商共同支持的协调迁移方案。新DNS稳定后，再按实际服务流程启用签名并提交匹配的新DS；保持DNSSEC连续开启的高级迁移不能自行混合密钥或省略等待条件。
在管理域名注册的服务商处修改DNS服务器（Nameservers/NS）设置，用新DNS分配的整组NS替换旧组并保存。此处不是在旧DNS记录表里随意新增同名NS。如果宝乐云所购域名没有提供可用的自助修改入口，通过工单核实支持的办理方式，不借用另一个域名的设置。
用查询验证，不只看控制台提示
新权威预检通过、旧DS已按前述流程处理并保存新NS后，再查询公共递归解析结果。将example.com换成自己的域名，在已提供nslookup的终端执行：
nslookup -type=ns example.commacOS或有dig的Linux可用下面命令检查委派路径：
dig example.com NS +trace检查最终委派是否指向新NS，并从不同网络或所选递归DNS对照结果与查询时间。业务允许时，可提前调整将变更记录的TTL，并等待原TTL覆盖的缓存过渡后再切换；只降低某条A记录的TTL不会清掉已缓存的父区NS或DS，父区委派的TTL也未必由自己控制。查询为空、超时和SERVFAIL要分别排查，不承诺固定几分钟全网生效。控制台已保存和外部查询已更新是两个状态。
切换后的验收与回退
- 按清单测试网站、接口和邮件；不要只看首页。
- 检查TXT验证、子域名及证书续期所依赖的记录。
- 新DNS稳定后按实际服务流程重新启用DNSSEC，核对父区DS与新服务的DNSKEY及签名匹配，再验证支持DNSSEC的递归查询无校验错误。
- 确认相关NS、DS与业务记录缓存及各项业务均已完成过渡，且不再需要旧区回退后，才考虑结束旧DNS服务。
出现缺记录时优先补齐新DNS，不要不停来回改NS。必须回退时，先确认旧NS仍能权威回答且旧业务记录已同步；若已经发布新DS，必须先按注册商和DNS服务支持的流程处理DS与旧密钥的匹配，不能直接切回一套无法通过当前DS验证的旧区。NS和DS回退同样受原TTL与缓存影响，不代表立即恢复。仅更换服务器IP、不更换DNS服务时，通常应修改对应A/AAAA记录，参见DNS解析配置。