清洗网络切换时，即使权威DNS已经发布新记录，部分用户仍可能连到旧地址。原因通常不是记录没有更新，而是不同层级的缓存尚未过期，或客户端继续复用已有连接。评估清洗网络切换期间DNS TTL与客户端缓存影响评估，重点是确认各层缓存的剩余时间，并用真实查询验证新旧地址的变化。
先分清记录变更与解析收敛
DNS记录中的TTL以秒为单位，告诉递归解析器在一段时间内可以复用缓存。假设某记录原TTL为3600秒，在变更前一秒被解析器缓存，那么该解析器理论上还可能使用旧结果接近一小时；切换时把TTL改成60秒，不能追溯缩短已经缓存的旧TTL。
实际链路还包括递归解析器、操作系统和应用程序缓存。公共递归解析器可能按剩余TTL返回缓存结果；Windows DNS Client、systemd-resolved及Java应用也可能保留解析结果，具体时长受系统和运行时配置影响。已有TCP连接不会因为DNS更新自动断开，因此“查到新地址”不等于“业务流量已全部迁移”。
切换前后怎样评估
记录基线与预计窗口
先检查涉及的A、AAAA或CNAME记录、当前权威TTL、备用地址以及负责解析的权威服务器。记录变更前的TTL，并确认变更计划、回退方式和清洗网络入口的可用状态。若旧TTL为一小时，宜按其剩余有效期规划观察窗口；不能只按刚设置的新TTL估算。
分层验证解析结果
- 变更前降低TTL：如业务允许，提前至少一个旧TTL周期调整TTL，让递归解析器逐步缓存较短时长的新设置。若无法提前操作，就把旧TTL作为收敛上限的重要参考。
- 发布并核对权威记录：切换时确认权威DNS返回预期地址，分别查询相关记录类型，避免只检查A记录而遗漏AAAA记录。
- 从多个网络查询：使用dig或nslookup分别查询权威服务器和常用递归解析器，记录响应地址与TTL剩余值。随后从不同地区或运营商的实际客户端抽样，区分权威数据正确和递归缓存已更新。
- 观察客户端及连接：在Windows可用ipconfig /displaydns查看本机缓存；systemd-resolved环境可查看解析统计。对应用进程，还要核实其解析缓存策略，并关注旧连接何时结束。
- 达到条件后再回收旧入口：确认主要解析路径已转向新地址、旧入口流量持续下降且新入口运行正常，再按预案决定是否停止旧入口。保留回退能力，避免单凭一处查询结果结束切换。
哪些因素会拉长收敛
首先是缓存层不一致：递归解析器、终端和应用可能分别缓存，TTL也可能被本地策略设定上限或下限。其次是负缓存：如果此前查询得到不存在记录，递归解析器可依据SOA信息缓存这一结果；新增记录后，负缓存未过期的客户端仍可能暂时查不到。最后是连接复用与重试机制，它们会让流量表现落后于DNS查询结果。
TTL设置需要权衡。切换前将TTL降至约60至300秒，可缩短一部分递归缓存的等待时间，但会增加查询频率；对低变更频率的记录，数百至数千秒更常见，也能减少重复查询。合适范围取决于解析服务承载能力、切换速度要求和客户端行为，不代表所有递归解析器都会严格按该数值执行。若记录已经缓存较长TTL，临时调低TTL不能立即产生效果。
用观测结果决定完成时点
建立简单记录表，按时间记下权威响应、不同递归解析器返回的地址与TTL、客户端抽样结果，以及旧入口和新入口的连接变化。若权威记录正确但某些解析器仍返回旧地址，继续观察其剩余TTL；若TTL已过而应用仍访问旧地址，应检查本地或应用缓存、长连接和重试配置。这样评估清洗网络切换期间DNS TTL与客户端缓存影响评估，比假设“改完记录立即生效”更可靠。
收敛时间不是单一TTL数字，而是旧记录缓存、负缓存和连接生命周期共同作用的结果。把变更前TTL作为下限参考，按解析层级抽样，并结合流量确认，才能审慎判断切换是否完成。
常见问题
改小TTL后，旧地址会马上消失吗？
不会。已缓存的记录仍按当时的TTL计时，通常要等其剩余时间结束。
只查询权威DNS够不够？
不够。权威查询只能确认新记录已发布，不能证明递归解析器和客户端缓存已更新。
TTL过期后客户端一定重新解析吗？
通常需要重新查询，但应用缓存、连接复用或本地解析策略可能影响实际访问行为。
怎样判断可以撤掉旧入口？
结合多网络解析抽样、新入口健康状况和旧入口流量变化判断，并遵循预设观察窗口与回退条件。