![Google 缓存中的 BIND / 旧 DNS 条目](https://linux22.com/image/9701/Google%20%E7%BC%93%E5%AD%98%E4%B8%AD%E7%9A%84%20BIND%20%2F%20%E6%97%A7%20DNS%20%E6%9D%A1%E7%9B%AE.png)
今天我遇到了一个有趣的问题;有人匆忙更改了 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 数据。