我最近一直在考虑我们 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 是最重要的？
答案1
假设顶点 A 记录example.com.指向一个损坏的 IP 地址，我知道的大多数公司都会更改 A 记录并www完全跳过更改：
- 大多数管理员都不希望看到用户输入不带 www 前缀的网站名称导致自己的网站瘫痪。
- 对于那些不信任他们的 web 应用程序开发人员持续使用 的管理员来说，情况更是如此
www.example.com。example.com（提示：我们大多数人都不信任）
继续链接示例，您正在比较苹果和橘子。网络托管场景中的 Apex DNS 记录非常麻烦，因为知名顶级 CNAME 问题。在这种情况下，只有两个正确的选择：要么根据需要更改顶点 A 记录以将其指向有效 IP，要么完全放弃顶点记录。两者之间的任何选择都是不成熟和不一致的。
不过，所有这些都有点偏离主题：如果你依靠手动记录更改来处理服务的高可用性，你做错了。Web 浏览器访问的 IP 地址应该是负载均衡器、任播地址、CDN 或网站托管提供商，如果您自己的服务器场无法提供这种高可用性，他们可以提供这种高可用性。如果您确信使用它们的主应用程序遵循遵循，则多个地址记录也可以工作RFC 6724指南（即大多数流行的网络浏览器），但许多应用程序很懒，只是使用返回的第一个地址记录。
为了论证的目的，我们来检查一下Google 的 CNAME 链就其本身而言，没有将其纳入您原始问题的上下文中。这看起来很熟悉，因为它是我原始答案的文本：
记录类型在这里并不重要。如果记录需要频繁更改，则其 TTL 应该非常低。如果不需要频繁更改，则理所当然地不需要低 TTL，您可以使用任何您喜欢的类型。
除了谷歌，没有人能真正评论为什么谷歌希望ghs.l.google.com IN A拥有比指向它的 CNAME 记录更低的 TTL。如果不了解他们的更大设计，你就无法得出任何结论，设计决定了你的运动部件。
答案2
我同意。
只要“真实服务器”有稳定的 IP 地址，A 记录就应该有较长的 TTL。将 CNAME 记录上的 TTL 保持在较低水平，以便在发生故障或其他情况时快速切换到另一台真实服务器。