推奨DNS TTL

状況によって大きく異なる可能性がありますが、ホスティングサーバーを移動する予定のないWebサイトをホストする場合、DNSレコードに設定するのに適したTTLは何ですか？

Slicehostのデフォルトである86,400秒（1日）のままにする傾向があります。保留中の移動がある場合は10分にドロップダウンし、1〜2日待ちます。

編集：最近（2016）私はそれを低く保つ傾向があります-〜5分。

標準（1987年にかなり前に書かれた）は、最小のデフォルトTTLとして86,400秒（1日）を提案しています。

TTLを適切な値に設定することが重要です。TTLは、リゾルバーがサーバーに再度要求するまでにサーバーから取得したデータを使用する時間（秒単位）です。値を低く設定しすぎると、サーバーに多数の繰り返し要求がロードされます。設定した値が高すぎると、変更した情報が適切な時間内に配信されません。TTLフィールドを空白のままにすると、ゾーンのSOAレコードで指定されているものがデフォルトになります。

ほとんどのホスト情報は、長期間にわたってあまり変化しません。TTLを設定する良い方法は、それらを高い値に設定し、変更がすぐに来るとわかっている場合は値を下げることです。ほとんどのTTLは、1日（86400）から1週間（604800）の間に設定できます。その後、近い将来に一部のデータが変更されることがわかっている場合、変更が発生するまでそのRRのTTLを低い値（1時間から1日）に設定してから、以前の値に戻します。

また、同じ名前、クラス、およびタイプを持つすべてのRRは、同じTTL値を持つ必要があります。

RFC 1033を参照：http : //tools.ietf.org/html/rfc1033

RFC 1912（1996年から）は、3日間の方がSOA記録に適していると示唆しています。

http://www.ietf.org/rfc/rfc1912.txt

緊急事態（特にHA DNS環境内）でより迅速に応答できるように、TTLを短くすることがよりファッショナブルになっていることに気付きました。

なんらかの理由でとんでもなく高いか低い場合を除き、ホストによって設定されたデフォルトのままにしておきます。次に、移動する予定がある場合は、移動を計画する数日前に20分程度に下げます。

許容できるバランスを提供するために、4時間で十分です。それがほとんどのゾーンで使用しているものです。

RFC 1912に加えて、ヨーロッパのユーザーは、最小のTTL値として2日間を推奨するRIPE-203「DNS SOA値の推奨事項」も参照する必要があります。

（注：この投稿は、個々のA / AAAAレコードのTTLに適用されます。他のレコードタイプには、同じように単一障害点を表さないため、より長いTTLを持つことができるものがあります）。

災害復旧計画の観点から、これについて本当に考える必要があります。いつサイトを移動するのかは重要ではありません（意図的な移動の場合、移動までのTTLを短縮できます）。ホストがインターネットの表面から消えたり、TOS違反で追い出されたり、来たDDOSを処理できないために追い出されたりするときです。

そのような状況でサイトが1日程度ダウンすることを気にしない場合は、先に進み、TTLを1日のデフォルトのままにしておきます。複数のプロバイダーからの複数の場所にPIアドレススペースとBGPトランジットがあり、BGPレベルで災害復​​旧を処理する場合は、先に進み、1日のデフォルトのままにします。一方、DNSをフェールオーバーサイトに掘り下げるメカニズムとしてDNSを使用している場合、はるかに短いTTLである5分が非常に一般的な値です。