我最近一直在考虑我们 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 是重要的？
假设顶点 A 记录
example.com.指向一个损坏的 IP 地址，我认识的大多数公司都会更改 A 记录并www完全跳过更改：www.example.comover的管理员来说，这会增加一倍example.com。（提示：我们大多数人都没有）继续您的链接示例，您正在比较苹果和橙子。由于众所周知的 apex CNAME 问题，Web 托管方案中的 Apex DNS 记录是一个巨大的痛苦。在这种情况下只有两个正确的选择：根据需要更改顶点 A 记录以将其指向有效 IP，或者您完全放弃拥有顶点记录。两者之间的任何事情都是半生不熟和不一致的。
不过，所有这些都有些离题：如果您依靠手动记录更改来处理服务的高可用性，那么您做错了。Web 浏览器访问的 IP 地址应该是负载均衡器、任播地址、CDN 或虚拟主机提供商，如果您自己的服务器场无法提供这种高可用性，则它们可以提供这种高可用性。如果您确信使用它们的主要应用程序遵循RFC 6724指南（即最流行的 Web 浏览器），多个地址记录也可以工作，但是许多应用程序是惰性的，并且只使用返回的第一个地址记录。
为了论证的目的，让我们根据自身的优点来检查Google 的 CNAME 链，而不将其置于您最初问题的上下文中。这看起来很熟悉，因为它是我原始答案的文本：
记录类型在这里无关紧要。如果记录需要经常更改，它应该有一个非常低的 TTL。如果不需要频繁更换，按理说它不需要低TTL，你可以使用任何你喜欢的东西。
没有人（除了谷歌）可以真正评论为什么谷歌希望
ghs.l.google.com IN A拥有比指向它的 CNAME 记录更低的 TTL。如果不了解其更大的设计，您将无法得出任何结论，而设计决定了您的活动部件。我同意。
只要“真实服务器”有稳定的 IP 地址，A 记录就应该有很长的 TTL。保持 CNAME 记录上的 TTL 较低，以便在发生故障或其他情况时快速切换到另一台真实服务器。