先记住这个答案
DNS 记录变更生效延迟由缓存导致：解析器、操作系统、浏览器以及中间递归服务器都会按 TTL 缓存记录，TTL 过期前不会重新查询。要缩短切换时间，应提前降低 TTL 至一个较小值（如 300 秒），等待旧 TTL 自然过期后再修改记录，这样全球生效时间可控制在分钟级。
- 生效延迟来自各级缓存的 TTL
- 提前降 TTL 可缩短切换窗口
- TTL 过短会增加解析压力
生效延迟的机制：缓存与 TTL 交互
DNS 记录在权威服务器上修改后，递归解析器、操作系统和浏览器各自维护缓存，缓存条目携带从权威服务器响应中获得的 TTL 值。只有当某个层级收到查询且缓存中条目未过期时，它才直接返回旧 IP；TTL 归零后，该层级才会发起新的迭代查询，从权威获取最新记录。因此，生效时间 = 所有缓存路径中剩余 TTL 的最大值，而不是一个固定的“全球传播”延迟。
例如，原 TTL 为 86400 秒（一天），修改记录后，某个用户的递归解析器在修改前 23 小时缓存过旧记录，则需要再等 23 小时才会重新查询。这解释了为何同一时刻不同用户看到新旧 IP 并存。关键推论：提前将 TTL 降低，能迫使旧缓存较早过期，使新旧切换发生在可控的时间窗口内。
迁移线上服务的一次完整切换流程
假设要把 api.example.com 的 A 记录从 203.0.113.10 迁移到 198.51.100.20。当前 TTL 为 86400，计划在周五 22:00 切换。处理：周一上午先将 TTL 改为 300 并发布，到周二上午所有旧 TTL 缓存已自然过期（最迟在周一上午前缓存的旧条目也会在周二上午过期）。之后（如周四）再次修改记录，替换 IP，并保持 TTL 300。切换后约 5 分钟内，全球主流公共解析器都会重新向权威查询并获得新 IP。
为何要等旧 TTL 过期？因为 TTL 的缩短对已缓存的条目无效，旧条目仍按原始 TTL 剩余时间淘汰。只有等已出现的缓存全部过期后，再改记录才能让新记录被尽快获取。若直接在原 TTL 下改 IP，旧记录可能在用户侧存留长达一天。此操作将切换风险窗口从“最多 24 小时”压缩到“最多 5 分钟”，代价是切换后数天内解析压力增加约 288 倍，需确保权威和中间层可承受。
无法控制的缓存与 TTL 的副作用
此方案并非万能：一些浏览器或应用会独立缓存 DNS 结果，忽略 TTL（如 Chrome 曾用过期记录应对故障）；企业内网的 DNS 服务器可能不遵循权威 TTL 而强制设置最小缓存时长；某些运营商甚至跨越 TTL 刷新。另外，若修改的是 NS 或 SOA 记录，因胶水记录和父级区域的额外缓存，生效时间可能远长于子域 TTL。
另一个边界是 TTL 不能无限降低：TTL 太低会让所有缓存失效，每次查询都直达权威，CDN 的全局负载均衡失效，权威服务器压力陡增，并放大 DDoS 风险。建议在变更前 24-48 小时开始降 TTL，如 300，变更完成后可逐步恢复至常规值（如 3600 或更高）。同时应利用 dig 观察权威 TTL 与本地缓存差异，验证是否已生效。
容易答错的地方
- 误以为 DNS 像“全网广播”
- 许多人认为修改后需要 24-72 小时让全世界“感知”。实际 DNS 是分级缓存体系，不存在从权威向所有节点推播的机制。延迟由每个节点的 TTL 剩余时间决定，只要权威响应了查询，新记录就生效于该会话。
- 改了 TTL 马上改 IP
- 把记录 TTL 从 86400 改为 300 后立即更换 IP，并不能立刻生效，因为旧记录仍被缓存且剩余 TTL 仍按原来计算。正确做法是先把 TTL 降下来，等待至少原来的 TTL 时长，让所有旧记录淘汰，再修改 IP。
面试官还会怎么问？
如何验证自己的递归服务器是否还缓存旧记录？
用 dig A api.example.com 查看响应中的 TTL 剩余秒数和 IP，若 IP 仍为旧值且 TTL 在递减，说明命中了旧缓存；或指定权威服务器查询 dig @ns1.example.com A api.example.com 对比权威的当前记录。
降 TTL 期间服务访问负载增加，如何缓解？
先评估权威服务器 QPS 水位，可临时增加边缘缓存节点或使用 Anycast 分流；同时监控 DNS 查询量和错误率，若压力过大可把 TTL 降至 600 而非 300，等待期延长但够用。
若某运营商强制忽略 TTL，该怎么办？
无法强制清除，只能等其内部缓存策略过期（通常数小时）。为缩短影响，可提前联系运营商刷新缓存，或使用 HTTP 302 跳转让旧 IP 上的服务器返回新地址作为后备。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。