凌晨把域名切到新机房后，权威NS已返回新地址，监控却仍看到旧站承接流量：部分用户落在旧站，支付回调甚至超时。迁站最棘手的不是“DNS改了没有”，而是递归缓存中的旧答案仍按原TTL活着；若旧记录曾设72小时TTL，故障窗口可能接近三天。此时删旧机或立即全量回切，都未必能止血。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：serverastra（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
一次递归查询通常先经过递归缓存，再访问权威NS。命中旧A/AAAA记录后，解析器按原TTL倒计时；即使权威端改成新IP，缓存也不会主动刷新，只能等旧TTL耗尽后重查。因此，“权威查询已变化”不等于“客户端已收敛”。若迁移前未降TTL，旧缓存可能继续存活72小时甚至更久；父区委派、NS与glue记录也各有缓存，客户端可能沿旧权威链路查询。
还要留意负缓存：新主机未上线、域名不存在或CNAME目标报错时，解析器会按SOA中的最小TTL缓存NXDOMAIN或NODATA。后来记录补齐，递归节点仍可能返回失败。IPv4与IPv6、CNAME链及不同递归节点还可能保留不同年龄的答案，所以一次查询成功不代表全网完成切换。
切站前先把TTL降到24至48小时，等待原TTL上限完全耗尽，再做分阶段切流：先验证新源站健康，再按地域、权重或用户分组逐步放量，同时保留旧源站。判断时不要只dig权威端，应对照多地递归结果、旧/新源站访问日志和业务回调，记录旧IP流量占比、错误率及最后命中时间。可将日志汇入 ServLlama，观察各阶段查询与真实流量是否一致。
回退需要量化门槛。例如计划已放量到80%，旧入口流量仍连续10分钟高于5%，且超过原TTL加15分钟安全窗，业务错误率同时抬升，就先在流量层切回旧源站，不必等缓存自然过期。若必须回改DNS，应恢复旧记录、保持低TTL，并等待新答案也走完TTL；此时删旧机尤其危险。常见误判是只看一次dig便宣告完成，或把解析失败当作收敛。每次放量都应写明观察窗、停止条件和责任人，避免TTL衰减、负缓存与真实用户路径不同步。
递归缓存中的记录并不会因为权威端改值而立即消失。每台递归解析器都独立执行 TTL衰减：命中缓存后，倒计时按原剩余 TTL 继续，而不是重新读取权威数据。因此，切换前已经缓存 300 秒且已使用 280 秒的旧记录，仍可能继续存活 20 秒。若在切换时直接把权威 TTL 从 300 秒改为 60 秒，已存在的缓存对象通常仍沿用原到期时间；新 TTL 只对后续查询生效，这是“明明改了，流量还没切”的常见误区。
另一条时间线来自 负缓存。权威区若返回 NXDOMAIN、NODATA 或 SERVFAIL，递归解析器可能依据 SOA 的 minimum、负缓存 TTL 或自身重试策略保存失败结果。此时即使立即补回记录，也要等待负缓存过期，并确认递归侧没有因暂时性故障延长重试时间。委派信息还会缓存到 权威NS：NS 记录、胶水地址以及父区委派可能分别具有独立生命周期。只改 A 记录并不足以替换委派链路，尤其跨注册商或跨 NS 迁移时，旧权威仍可能持续回答。
稳妥做法是把变更拆成“预降 TTL、等待旧缓存自然失效、发布新配置、逐步放量、恢复 TTL”五段。预降阶段应覆盖现网最大正 TTL，并额外预留 SOA 负缓存、CNAME 链和权威 NS 委派的寿命；等待窗口内可通过分散查询验证旧答案已完全出清。切流阶段应先小比例接入新端，观察递归命中率、旧端流量、延迟和错误码，再按比例放量；新旧端都健康时也不要过早恢复高 TTL，否则下一次变更会重现同样的收敛延迟。若迁移权威 NS，应先确认父区委派、胶水地址和所有子区委派同步生效，再下线旧 NS。
可执行检查清单：①在权威端与至少三类递归入口核对目标 A/AAAA、TTL、SOA minimum 和 NS 委派；②对正常域名、刚删除域名、CNAME 目标分别查询，确认正缓存与 负缓存 均按预期过期；③持续采样客户端解析结果和权威日志，定位仍返回旧地址的具体递归节点；④检查旧 权威NS 是否仍有入站查询，并确认下线顺序不会形成无委派状态；⑤切流稳定后按约定恢复 TTL，并再次验证全链路。
最终验收不应只看权威端“已经改了”，而应同时证明旧答案、旧失败结果和旧委派链路都已退出缓存，并且各阶段流量比例符合预期。只有递归缓存、负缓存与权威 NS 三条时间线都完成收敛，DNS 切换才算真正结束。
