ISP 不遵守 TTL 时的 Route53 传播时间

ISP 不遵守 TTL 时的 Route53 传播时间

我在 AWS Route53 中制定了基于延迟的 DNS 规则(TTL 设置为 60 秒),指向位于不同区域的 AWS NLB。我希望能够通过修改 Route53 规则将流量重定向到其他区域,并确保 DNS 故障转移策略适用于所有客户端。

我听说尽管 Route53 传播时间相当不错,但各种互联网服务提供商可能不会尊重它,因为他们会进行自己的缓存和/或简单地忽略我的 TTL 规则(甚至长达几天)。

这句话是真的吗?考虑到我需要确保我的路由更改应在 15 分钟内传播,使用 Route53 是否安全,或者我应该实现允许我的客户端应用程序动态获取我的服务器地址的机制(而不是更改路由)。

答案1

DNS 传播不存在,它是不正确的术语,因为 DNS 不是自上而下的,而只是由基于记录的 TTL(和其他更复杂的规则,如 DNSSEC RRSIG 到期、DNS 负 TTL 等)更新其条目的缓存管理。

理论上,TTL 给出了最大限度缓存可以保留条目的时间量。因此,理论上缓存可以自由地在条目之前执行操作,从而降低条目数。

再次从理论上讲,缓存应该尊重它而不是增加它。

实际上,众所周知,某些缓存会覆盖该值,尤其是当该值太小的时候。各种名称服务器软件都有配置选项来执行此操作。

虽然我不知道关于这个问题的权威研究,但我的粗略建议是不要将 TTL 设置为低于 5 分钟,否则您将面临某些缓存不遵守该时间的风险。其他消息来源比我更乐观,并表示任何超过 30(秒)的时间都是可以的。YMMV。

至少有一项使用 RIPE 探针进行的 2017 年研究: https://labs.ripe.net/Members/giovane_moura/dns-ttl-violations-in-the-wild-with-ripe-atlas-2 它重复了同样的观点:“众所周知,一些云提供商和 CDN 会覆盖其网络内权威服务器提供的原始值。”基于研究中的这一结果:“我们在表 2 中看到,4.17% 的解析器实际上会在这次测量中增加我们的 RR 的 TTL 值。”

为了进一步调试,您将需要提供有关特定缓存的更多详细信息,在这些缓存中,您会发现行为与您的 TTL 配置相矛盾,并且您(和/或您的客户)可能需要尝试联系他们的管理员,看看他们的规则是否可以更改(成功的可能性非常低,但如果您甚至不尝试联系他们,事情发生变化的可能性绝对为零)。

相关内容