故障转移切换的最佳 CNAME TTL 策略

Question

我最近一直在考虑我们 DNS 的 TTL。我们的服务器有 A 记录，然后是面向客户的名称的 CNAME 记录。例如，www.example.com CNAME 指向 server-01.example.com。如果发生故障，我们会将 CNAME 和 A 记录的 TTL 设置为 15 分钟。

然而，我突然意识到这可能不是最佳的。当然应该是A记录是48小时，CNAME是15分钟。如果发生故障，CNAME 只会指向 server-02.example.com。A记录（理论上应该可以缓存很长时间，因为我们使用CNAME作为切换器）。

环顾互联网，我发现很多人的 CNAME 长而 A 记录短： CNAME 和 A 记录具有不同的 TTL。哪个会被缓存？

这似乎与任何人想要的相反。问题是，DNS 是否以我希望的方式工作，因为如果我需要匆忙切换服务器，CNAME 请求 TTL 是重要的？

Answer 1

假设顶点 A 记录example.com.指向损坏的 IP 地址，我知道的大多数公司都会更改 A 记录并www完全跳过更改：

• 对于键入网站名称而没有 www 前缀的用户，大多数管理员宁愿不破坏他们的网站。
• 对于不相信他们的 webapp 开发人员始终使用www.example.comover example.com. （提示：我们大多数人都没有）

继续您的链接示例，您正在比较苹果和橙子。由于众所周知的Apex CNAME 问题，网络托管场景中的 Apex DNS 记录是一个巨大的痛苦。在这种情况下只有两个正确的选择：要么根据需要更改顶点 A 记录以将其指向有效 IP，要么您完全放弃拥有顶点记录。两者之间的任何东西都是半生不熟和不一致的。

不过，所有这些都有些离题：如果您依靠手动记录更改来处理服务的高可用性，那么您就做错了。Web 浏览器命中的 IP 地址应该是负载均衡器、任播地址、CDN 或网络托管服务提供商，如果您自己的服务器场无法提供这种高可用性，则它们可以提供。如果您确信使用它们的主要应用程序遵循RFC 6724准则（即最流行的 Web 浏览器），多个地址记录也可以工作，但许多应用程序是懒惰的，只使用返回的第一个地址记录。

为了论证起见，让我们根据自己的优点检查Google 的 CNAME 链，而不将其置于原始问题的上下文中。这看起来很熟悉，因为它是我原始答案的文本：

记录类型在这里无关紧要。如果需要频繁更改记录，则它的 TTL 应该非常低。如果不需要频繁更改，按理说它不需要低 TTL，您可以使用任何您喜欢的东西。

没有人（除了谷歌）能真正评论为什么谷歌想要ghs.l.google.com IN A拥有比指向它的 CNAME 记录更低的 TTL。如果不了解他们的更大设计，您就无法得出任何结论，而设计决定了您的活动部件。