最適なCNAME TTLフォールオーバースイッチングの戦略
最近、DNSのTTLについて考えています。サーバーのAレコードと、顧客向けの名前のCNAMEレコードがあります。www.example.comCNAMEはサーバーを指します-たとえば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は、サーバーを急いで切り替える必要がある場合に重要なものですか？
example.com.の頂点Aレコードが壊れたIPアドレスを指していると仮定すると、私が知っているほとんどの企業はAレコードを変更し、wwwの変更を完全にスキップします。
- ほとんどの管理者は、wwwプレフィックスなしでWebサイトの名前を入力するユーザーのために、Webサイトを壊したくないと考えています。
- これは、Webアプリケーション開発者が
www.example.comよりもexample.comを一貫して使用することを信頼していない管理者にとっては2倍になります。 （ヒント：私たちのほとんどはしません）
リンクされた例 に移ると、リンゴとオレンジを比較しています。 よく知られているapex CNAMEの問題 のため、WebホスティングシナリオでのApexDNSレコードは非常に苦痛です。この状況では、正しい選択肢は2つだけです。有効なIPを指すように必要に応じて頂点Aレコードを変更するか、頂点レコードを完全に持たないようにします。 2つの間のすべてが中途半端で一貫性がありません。
ただし、これはすべて、やや重要な点を超えています。サービスの高可用性を処理するために手動のレコード変更に依存している場合、何か間違ったことをしています。 WebブラウザがヒットするIPアドレスは、ロードバランサー、エニーキャストアドレス、CDN、または独自のサーバーファームでは提供できない場合にこの高可用性を提供できるWebホスティングプロバイダーである必要があります。複数のアドレスレコードは、それらを消費する主要なアプリケーションが次のガイドラインに従うと確信している場合にも機能します RFC 6724 ガイドライン（つまり、最も人気のあるWebブラウザー）が、多くのアプリケーションは怠惰で、返された最初のアドレスレコードを使用するだけです。
議論のために、元の問題のコンテキストに入れずに、 GoogleのCNAMEチェーン 自体のメリットを調べてみましょう。これは私の元の答えのテキストなので、見覚えがあるでしょう。
ここでは、レコードタイプは重要ではありません。レコードを頻繁に変更する必要がある場合は、TTLを非常に低くする必要があります。頻繁に変更する必要がない場合は、低いTTL）を必要とせず、使いやすいものなら何でも使用できます。
Google以外の誰も、Googleがghs.l.google.com IN Aにそれを指すCNAMEレコードよりも低いTTL）を望んでいる理由について実際にコメントすることはできません。理解せずに結論を出すことはできません。それらのより大きなデザイン、およびdesignは、可動部品を決定するものです。
同意する。
「実サーバー」が安定したIPアドレスを持っている限り、Aレコードは長いTTLを持つ必要があります。 CNAMEレコードのTTLを低く保ち、障害などが発生した場合に別の実サーバーにすばやく切り替えることができるようにします。