今天我遇到了一个有趣的问题；有人匆忙更改了 DNS/BIND 中的两条 MX 记录，作为我们两个域 xxx1.pt 和 xxx2.pt 中另一种情况的权宜之计。
因此，没有采取提前减少该记录的特定 TTL 的措施。
更改是在 2 周的 TTL 内完成的。
有趣的是，有人向我指出 Google DNS 公共服务器的答案并不完全相同。
使用 8.8.8.8 进行测试仍然可以使用旧地址解决该问题，并返回新地址的奇怪答案。
SOA 系列肯定已更新，因为通过本地过程/配置，它会自动更新以防止人们忘记这样做。
所以有人问我为什么这个奇怪的答案，以及是否可以做点什么在 BIND 一侧。
还有特别紧急关于解决 Google 方面的缓存问题，原因与此问题无关。
BIND 端可以做什么？
答案1
这里显而易见的是，BIND 方面无能为力。
如果 RR 记录的 TTL 为 2 周，则始终存在 DNS 服务器在缓存中仍保留该地址的风险。
谷歌也似乎隐约暗示着在一些帮助页面中，它尊重长 TTL至少最多 3 天。
更有趣的是，新地址的奇怪答案可能是因为 Google DNS CDN/集群上的一些 DNS 服务器可能已经刷新了缓存并获取了新地址，或者可能从未见过我们的域，或者可能是在更改并且实际上从未见过旧地址）。或者可能是因为有时是 CDN/另一个 DNS 集群的另一个点返回答案。没有调查过。
言归正传，有不同的答案并不特别令人惊讶，因为 8.8.8.8 DNS 服务不是由单个服务器提供服务，并且其背后有复杂的基础设施。
至于Google DNS服务端的缓存，我找到了一个非常有趣的页面，该页面允许公众刷新全局任意DNS RR记录这里
手动刷新问题域的 MX 记录缓存后，再次使用 测试 Google 公共 DNS 服务器dig，答案已经是新的 RR 数据。