推奨DNS TTL
私はそれが状況に基づいて非常に異なる可能性があることを知っていますが、ホスティングサーバーを移動する予定のないWebサイトをホスティングする場合、DNSレコードに設定するのに適切なTTL？
私はそれをSlicehostのデフォルトである86,400秒（1日）のままにする傾向があります。保留中の移動がある場合は10分にドロップし、1〜2日待ちます。
編集：最近（2016）私は低く保つ傾向があります-約5分。
標準（1987年にlong時間前に記述）では、最小デフォルトTTLとして86,400秒（1日）が推奨されています。
TTLが適切な値に設定されていることが重要です。 TTLは、リゾルバーがサーバーに再度要求する前にサーバーから取得したデータを使用する時間（秒単位）です。値を低く設定しすぎると、サーバーがロードされます繰り返しリクエストが大量に発生します。設定が高すぎると、変更した情報が妥当な時間内に配信されません。TTLフィールドを空白のままにすると、デフォルトでゾーンのSOAレコードに指定されているもの。
ほとんどのホスト情報は、長期間にわたってあまり変化しません。 TTLを設定する良い方法は、TTLを高い値に設定し、変更が間もなく行われることがわかっている場合は値を下げることです。ほとんどのTTLを1日（86400）から1週間（604800）の間のどこかに設定できます。次に、近い将来に一部のデータが変更されることがわかっている場合は、変更が行われるまでTTL RRを低い値（1時間から1日）に下げてから、以前の値に戻します。
また、同じ名前、クラス、およびタイプのすべてのRRは、同じTTL値を持つ必要があります。
RFC 1033を参照してください： http://tools.ietf.org/html/rfc10
RFC 1912（1996年から）は、SOAレコードには3日がより適切である可能性があることを示唆しています。
緊急事態（特にHA DNS環境内）でより迅速に応答できるように、TTLを短くすることがよりファッショナブルになっていることに気づきました。
なんらかの理由でとんでもなく高すぎたり低すぎたりしない限り、ホストが設定したデフォルトのままにしておきます。次に、移動したい場合は、移動を計画する前に、20分程度まで下げてください。
RFC 1912 の他に、ヨーロッパのユーザーは RIPE-203、 "Recommendations for DNS SOA Values" も参照してください。最小TTL値。
許容できるバランスを提供して、4時間で十分です。ほとんどのゾーンでこれを使用しています。
（注：この投稿は、TTLに適用されます。他の一部のレコードタイプは、同じ方法で単一障害点を表していないため、TTLが長くなる場合があります）。
災害復旧計画の観点から、これについて本当に考える必要があります。サイトを移動するつもりではありません（意図的な移動の場合は、移動の前段階でTTLを減らすことができます）。ホストがインターネットの顔から消えたり、キックしたりするタイミングですあなたはTOS違反のためにあなたを追い出したか、彼らがあなたの道に来たDDOSを処理することができないのであなたを追い出します。
そのような状況で1日ほどサイトがダウンすることを気にしない場合は、先に進んで、TTLはデフォルトで1日のままにします。PIアドレススペースとBGPトランジットがある場合複数のプロバイダーの複数の場所にあり、BGPレベルで災害復旧を処理する予定の場合は、1日のデフォルトのままにしておきます。一方、フェイルオーバーサイトにトラフィックをダイビングするメカニズムとしてDNSを使用している場合は、 TTLをもっと短くしたい場合は、5分が一般的な値です。