凌晨收到告警：同一个域名已经完成解析切换，但部分请求仍然访问旧节点，旧节点在十分钟内涌入大量连接，随后出现超时和5xx。运维团队通常会先怀疑新机器、负载均衡或应用发布，甚至把TTL临时改成几十秒，却仍然无法解释为什么部分用户持续命中旧地址。问题的关键在于，DNS结果不是一次写入、全网瞬时读取的开关，而是一套由权威端、递归服务商的缓存和客户端本地缓存共同组成的分层状态。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：tudcloud（低价云服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
一次递归查询通常沿着客户端、递归解析器、权威DNS逐层发生。客户端可能保存浏览器、操作系统或运行库中的结果；递归解析器则按照各记录自己的TTL缓存结果；权威记录只负责提供当前配置，不能主动清除已经存在于上游或客户端的旧值。因此，递归缓存残留与客户端缓存不是同一种问题。前者主要影响经过该递归节点的请求，后者可能让特定设备、应用连接池或本地代理长期使用旧结果。
还要注意TTL作用域。SOA中的Minimum TTL可能覆盖某些子域记录的TTL，CNAME链路又会受到每一跳缓存行为影响；同一条A记录在不同权威集群、不同递归入口甚至不同地域，未必拥有相同的剩余生存时间。若旧记录TTL为86400秒，而新记录TTL为60秒，切换后并不会得到“只残留60秒”的理想效果。反过来，频繁降低TTL也会增加查询量和切换期间的配置变更次数。
因此，权威记录切换只是改变源数据，旧答案仍可能按照各自的作用域继续存活。要判断影响范围，不能只看权威面板上的记录值，还要把递归缓存残留时间、客户端缓存策略、CNAME或NS链路，以及业务连接是否复用长连接放在同一张时间轴上。
第一步是确认新旧地址是否真的发生变化。在权威侧记录变更时间，同时从不同地域、不同递归入口和不同客户端发起查询，对比返回IP、TTL、CNAME链路及查询日志。递归节点返回旧IP且TTL持续递减，说明旧值主要卡在递归缓存；若权威端已经是新IP，但特定客户端仍访问旧IP，则应检查客户端缓存、长连接池或本地DNS代理。
第二步是给访问链路加上可追踪信号，例如按域名、解析版本和目标节点记录请求量，观察旧节点流量是否随TTL下降而逐步归零。第三步是为灰度下线流程设置明确的验收条件：旧地址流量连续观察窗口内降至允许阈值，关键地域解析结果稳定指向新目标，新旧版本都能独立回滚。只看“解析已经改了”不能作为下线依据，因为缓存和连接复用都可能让旧流量继续存在。
常见踩坑包括只修改主区域、遗漏灰度区域；把CNAME目标变更误认为所有客户端会立即刷新；在旧节点仍有连接时直接删除机器；以及把TTL设为极短却没有同步权威链路和递归入口。更稳妥的做法是先以可验证的灰度下线流程逐批降低旧端流量，结合随身服务器等小型环境做指定地域或指定客户端的解析与回滚演练，再依据旧IP访问量、TTL曲线和错误率决定是否继续下线。这样才能把“DNS已切换”与“业务已完成迁移”分开判断，避免缓存放大故障。p>
从DNS缓存分层看，缓存同时存在于客户端、操作系统/容器 DNS、本地递归、运营商递归和公共解析服务中，各层记录的缓存年龄不同。权威区的 TTL作用域只限制递归服务器后续保存该 RRset 的时间，递归会返回剩余 TTL，客户端还可能设置自己的上下限。修改权威 TTL 不会清除已缓存记录；这种递归缓存残留意味着，从 300 秒降到 60 秒，只影响新获取或重新校验的答案，不能让旧值立即消失。
同一名称下的 A、AAAA、CNAME 应采用一致策略。还要检查 NXDOMAIN 的否定缓存、SOA 的 MIN TTL、NS/DS 委派，以及 CDN、安全设备是否重写 TTL。低 TTL 能缩短收敛时间，却会增加查询与递归负载；遗漏辅助区域或隐藏配置，也会造成权威答案不一致。
权威记录切换应按“先增后切、逐步导流、观测后退役”执行：先发布并验证新目标，再用权重或分批解析灰度。CNAME 链各层可独立缓存，替换 CNAME 不会立即刷新旧目标；地域解析、ECS、Anycast 或固定出口也可能绕开预期权重。A 与 AAAA 不同步，会出现 IPv4 正常而 IPv6 失败。
完整的灰度下线流程不能只看解析结果，还要按地区、运营商、终端和版本观察真实连接。权重调整可能因递归缓存而被放大或滞后，因此每档都应设定停留时间、流量阈值与回滚条件，避免一次把全量流量推向尚未验证的新目标。
变更完成的判据不是 DNS 已修改，而是缓存残余可控、流量稳定且旧目标可安全回滚；这些证据应写入同一变更单。
