DNS 缓存：为什么改了域名却不能立即生效

“我已经把域名指向新服务器了，为什么有人能打开新站，有人还在访问旧站？”这不是 DNS 修改失败，而是 DNS 的缓存机制正在按各自的计时器工作。DNS 记录带有 TTL（Time To Live），递归解析器可以在这段时间内复用旧答案；RFC 1034 把 TTL 定义为资源记录在缓存中可以保留的时间。RFC 1034

DNS 不是“改一个中心表格，全世界立即刷新”。它更像一套分层的分布式目录：权威服务器保存源数据，递归解析器代替大量客户端查询并缓存结果，操作系统和浏览器还可能保留更近一层的缓存。

从域名到 IP，查询经过哪些人

当浏览器访问 www.example.com，客户端通常不会直接询问根服务器。一个简化过程是：

1. 浏览器和操作系统先检查本地缓存。
2. Stub Resolver 把请求交给配置好的递归解析器。
3. 递归解析器若没有可用缓存，先问根服务器“.com 在哪”。
4. 再问 .com 顶级域服务器“example.com 的权威服务器在哪”。
5. 最后问 example.com 的权威服务器“www 的 A 或 AAAA 记录是什么”。
6. 递归解析器缓存结果，并把答案返回给客户端。

实际系统还会处理 CNAME 链、IPv4 与 IPv6 双栈、DNSSEC、负面缓存和超时重试。图里的层级是帮助理解的骨架，不代表每次查询都必须完整走一遍。

TTL 不是“全世界刷新时间”

假设一条 A 记录的 TTL 是 300 秒。一个递归解析器在 12:00 查询到旧 IP 后，通常可以把它缓存到 12:05 左右。另一个解析器可能在 12:02 才首次查询，于是它的缓存会保留到 12:07。不同解析器的查询时间不同，就会出现用户在不同网络看到不同结果。

TTL 还不一定决定所有本地缓存行为。操作系统、浏览器、应用内 DNS 缓存、CDN 和中间网络设备都可能有自己的策略。TTL 是缓存资源记录的重要依据，但不是一个能精确控制所有客户端的遥控器。

为什么迁移前要提前降低 TTL

域名迁移常见做法是提前把旧记录的 TTL 降低，等待旧的长缓存自然过期，再切换到新 IP。切换后保留旧服务器一段时间，让仍持有旧答案的客户端继续得到服务；等观察窗口过去，再下线旧站。

降低 TTL 不能追溯性地清除已经缓存的旧记录。如果一条记录昨天的 TTL 是 86400 秒，今天才改成 300 秒，昨天已经拿到旧值的解析器仍可能继续使用旧值，直到原来的缓存周期结束。

迁移前：降低 TTL → 等旧缓存逐渐过期
切换时：修改权威记录 → 新查询获得新地址
观察期：新旧服务器同时可用 → 监控错误与流量
收尾：确认旧缓存基本消退 → 下线旧服务

A、AAAA、CNAME 有什么区别

• A 记录把名称指向 IPv4 地址。
• AAAA 记录把名称指向 IPv6 地址。
• CNAME 记录把一个名称指向另一个名称，解析器还要继续解析目标名称。

使用 CNAME 能让多个服务共享一个目标，但会增加解析链和故障排查复杂度。根域、CDN、邮件和证书验证还可能受到不同记录类型与服务商限制，不能只记住“域名就是一个 IP”。

DNSSEC 能解决什么

DNSSEC 通过签名验证 DNS 数据来源和完整性，帮助客户端判断答案是否被篡改。但 DNSSEC 不会让缓存更快失效，也不会把旧的合法记录变成新的合法记录。它解决的是“这个答案是否经过权威签名验证”，不是“这个答案是不是最新”。

一份迁移与排查清单

• 先确认修改的是权威 DNS，而不是只改了本地 hosts 文件。
• 同时检查 A、AAAA、CNAME 和 CDN 配置。
• 用多个递归解析器查询，比较它们的 TTL 剩余时间。
• 保留旧服务，直到旧缓存和长尾客户端明显下降。
• 修改 DNS 后不要立刻把所有问题归因于 DNS，TLS、缓存、CDN 和应用路由也可能指向旧目标。

一句话带走

DNS 的“传播慢”本质上是分布式缓存按不同时间开始、不同时间过期。理解权威服务器、递归解析器和 TTL 三层关系，就能把“玄学等待”变成可观测的迁移流程。

延伸阅读

• RFC 1034：Domain Names—Concepts and Facilities
• DNS 层级结构图