DNS 修改没有生效时该怎么办

DNS 修改似乎没有生效，是日常基础设施工作中最常见的烦恼之一，主要原因在于其底层系统（带有逐条记录过期机制的分布式缓存）是看不见的，除非您特意去查看。

在断定出故障之前，先逐项排查

1. 确认修改确实已在权威端保存：直接查询该域名自己的权威名称服务器，而不是通用的公共解析器，以排除保存悄悄失败，或尚未同步到服务商自身基础设施的情况。
2. 检查该记录之前的 TTL：如果它被设置为 86400 秒（24 小时），那么在您修改前几分钟缓存了旧答案的解析器，最长要等一整天才会再次询问。
3. 排除浏览器或操作系统层面的 DNS 缓存：它们比您配置的解析器离您更近，可以独立于解析器保存一份答案。
4. 核实您修改的确实是您以为的那条记录：一个出人意料的常见错误，是不小心更新了预发布或非生产环境的 DNS 区域。
5. 从多个观察点检查：单个解析器显示旧答案，并不能说明修改是否已传播到其他各处。

一个不太明显的原因：从属名称服务器落后了

较大的 DNS 部署通常会运行一台主（或称“master”）名称服务器，修改实际在这里进行，另有一台或多台从属（“slave”）名称服务器，通过区域传送定期从主服务器复制区域数据。如果从属服务器还没有获取到最新的传送，原因可能是传送计划配置错误、主从之间存在网络问题，或者只是传送间隔还没到，那么恰好查询这台从属服务器的解析器会一直得到旧答案，即使主服务器本身已完全更新，且每个解析器基于 TTL 的缓存也都已过期。这种情况比单纯的缓存问题少见，但当同一域名的不同权威名称服务器彼此不一致时，而不仅仅是公共解析器之间不一致时，尤其值得专门排除。

提前规划可以避免大部分问题

对于有计划的变更，比如迁移、更换服务商或切换，提前一两天降低 TTL，是您能做的杠杆效应最高的一件事。它只会多付出少量的额外查询量，换来的是变更最终在几分钟内传播完成，而不是可能长达一整天。先设置，等旧 TTL 的时间窗口完全过去，再做变更，确认一切正常后再把 TTL 调回去。

清除本机缓存，当它确实是罪魁祸首时

如果权威名称服务器和您检查的每一个公共解析器都已经一致返回新答案，但某一台特定机器仍然显示旧答案，那么这台机器自身的本地缓存就是剩下的嫌疑对象。

建议只在确认权威端已经正确之后才做这些操作：如果真实记录其实还没有更新，就清空本地缓存，只会得到同一个旧答案的全新副本，看起来就像清除没有成功一样。