子域名解析改动前怎样保存原始状态：先做这五步备份核查
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a05ee28222f9.html
📄
子域名解析改动前怎样保存原始状态：先做这五步备份核查
改动子域名解析前，保存原始状态的核心是“可回滚”：把当前解析记录、TTL、生效范围和变更时间完整留档，并确认导出文件能被再次导入。只截一张图不够，因为截图无法直接还原记录。时间人手有限时，按下面的清单从最关键的一项开始做。
第一步：导出当前解析记录，而不只是截图
要查的是该子域名对应的全部记录类型，常见包括 A、AAAA、CNAME、MX、TXT、NS。怎么查：登录当前 DNS 托管平台，找到对应解析区域，使用导出功能或逐条抄录，字段至少包含主机记录、记录类型、记录值、TTL、优先级。结果说明什么：如果导出文件能覆盖所有记录，回滚时可直接导入；如果平台没有导出功能，就用表格逐条记录，并核对记录条数与页面显示一致。截图只能作为辅助证据，不能作为恢复依据。
第二步：记录 TTL 和变更前的生效状态
要查的是每条记录的 TTL 数值，以及改动前解析是否已经全网生效。怎么查：在本地用 nslookup 子域名 或 dig 子域名 查询，多换几个公共 DNS 再查一次，比较返回结果是否一致。结果说明什么：TTL 越小，改动后传播越快，但回滚窗口也越短；如果多个 DNS 返回结果不一致，说明旧状态本身还没稳定，此时改动会让排查更困难。适用条件是准备调整指向或切换服务商；如果只是改一条 TXT 验证记录，影响范围小，可优先处理。
第三步：确认这个子域名是否被其他地方引用
要查的是子域名是否出现在站点地图、robots.txt、内链、外链或第三方服务配置中。怎么查：在站点源码和 robots.txt 中搜索该子域名，再用站内搜索或日志检查访问来源。结果说明什么：如果它承载的是主站资源或接口，改动影响面大，应排在清单最前；如果只是临时验证记录，优先级可以靠后。这里要区分两件事：robots.txt 的抓取限制不等于可靠的索引移除，子域名改动后即使禁止抓取，已收录页面也不会因此立即消失。站点地图也不保证收录，它只表达希望被抓取的意愿。
第四步：留一份可执行的回滚步骤
要查的是回滚需要哪些操作、由谁执行、大约多久完成。怎么查：把导出文件、TTL 数值、原记录值和操作顺序写在同一份文档里，并注明改动时间点。结果说明什么：如果回滚步骤写得足够具体，任何人按文档都能恢复；如果只能靠记忆，就不算保存了原始状态。示例（假设场景）：原记录为 shop.example.com CNAME old.example.net TTL 300，改动后若新指向异常，按文档把 CNAME 改回原值即可，TTL 300 意味着等待时间相对较短。这只是一个假设例子，不代表任何真实项目结果。
第五步：改动后立即复核，而不是等出问题再查
要查的是改动是否按预期生效、是否有遗漏记录。怎么查：改动完成后立刻用 dig 或在线 DNS 查询工具复查，确认返回值与预期一致，并观察旧值是否还在部分 DNS 中缓存。结果说明什么：如果新旧值同时出现，属于传播过程中的正常现象，等待 TTL 过期后再查；如果长时间只有旧值，可能是记录未保存或查询了缓存节点。HTTPS 不保证安全无漏洞或排名，证书配置与解析改动是两件事，不要因为加了 HTTPS 就跳过解析核查。
下一步：打开当前 DNS 托管平台，先完成第一步导出，再把 TTL 和回滚步骤补进同一份文档，然后才动手改第一条记录。
