故障轉移切換的最佳 CNAME TTL 策略
我最近一直在考慮我們 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 前綴的網站名稱的使用者破壞。
- 對於那些不相信他們的 webapp 開發者持續使用
www.example.comover的管理員來說，這會增加一倍example.com。（提示：我們大多數人都沒有）繼續您的連結範例，您正在比較蘋果和橙子。由於眾所周知的 apex CNAME 問題，Web 託管方案中的 Apex DNS 記錄是一個巨大的痛苦。在這種情況下只有兩個正確的選擇：根據需要更改頂點 A 記錄以將其指向有效 IP，或者您完全放棄擁有頂點記錄。兩者之間的任何事情都是半生不熟和不一致的。
不過，所有這些都有些離題：如果您依靠手動記錄更改來處理服務的高可用性，那麼您做錯了。Web 瀏覽器訪問的 IP 地址應該是負載均衡器、任播地址、CDN 或虛擬主機提供商，如果您自己的伺服器場無法提供這種高可用性，則它們可以提供這種高可用性。如果您確信使用它們的主要應用程序遵循RFC 6724指南（即最流行的 Web 瀏覽器），多個地址記錄也可以工作，但是許多應用程序是惰性的，並且只使用返回的第一個地址記錄。
為了論證的目的，讓我們根據自身的優點來檢查Google 的 CNAME 鏈，而不將其置於您最初問題的上下文中。這看起來很熟悉，因為它是我原始答案的文本：
記錄類型在這裡無關緊要。如果記錄需要經常更改，它應該有一個非常低的 TTL。如果不需要經常更換，按理說它不需要低TTL，你可以使用任何你喜歡的東西。
沒有人（除了Google）可以真正評論為什麼Google希望
ghs.l.google.com IN A擁有比指向它的 CNAME 記錄更低的 TTL。如果不了解其更大的設計，您將無法得出任何結論，而設計決定了您的活動元件。