適切な既定のTTLはいくつですか。

3600秒（1時間）が、A、AAAA、MX、TXTレコードの妥当な既定値です。クエリ量を適度に保ちながら、ミスの影響を1時間に抑えられます。変更がごくまれなNSレコードには、86400を使います。

設定できる最小のTTLはいくつですか。

多くのプロバイダーでは60秒まで、1秒まで下げられるものもあります。非常に低い値が役立つことはまれです。多くのリゾルバーが独自の下限を強制していますし、クエリのオーバーヘッドも現実の問題だからです。300秒なら、ほぼどんな移行にも十分に低い値です。

TTLはウェブサイトの速度に影響しますか。

間接的に影響します。キャッシュされたDNSの応答は、接続が始まる前の検索を1回省きます。キャッシュミスの場合、通常20〜120ミリ秒かかります。TTLが高いほどキャッシュヒットが増え、最初の接続がわずかに速くなります。これは、初めて訪れる訪問者にとって最も重要です。

すべてのリゾルバーは、設定したTTLを守りますか。

ほとんどは守りますが、すべてではありません。独自の下限を設けているものや、非常に長い値に上限を設けているもの、小さい数字を完全に無視するものもあります。TTLは保証ではなく、強いヒントとして扱い、常にそれを超える余裕を見込んでください。

TTLの実際の選び方

60-300s移行作業中、反映は速いがクエリ増加

3,600sほとんどの通常レコードに妥当な既定値

86,400sMXやNSなど、変更の少ないレコード

DNSの基礎

DNS TTLとは？最適な値の選び方

2026年7月14日読了時間：2分

TTL は Time To Live（生存時間）の略です。すべてのDNSレコードに付く秒数で、リゾルバーがこの答えを、再度問い合わせずにどれだけ使い回してよいか、という1つの問いに答えます。

DNSの設定の中で、最も軽視されがちな項目です。多くの人は、プロバイダーが設定した既定値をそのまま受け入れ、その存在に気づくのは緊急の移行作業のときで、有効に変更するには手遅れになっています。

TTLの実際の選び方

60-300s移行作業中、反映は速いがクエリ増加

3,600sほとんどの通常レコードに妥当な既定値

86,400sMXやNSなど、変更の少ないレコード

TTLが高いと、クエリが減り、検索が速くなります。TTLが低いと、変更がすぐに反映されます。両方を同時に得ることはできません。

トレードオフ

	高いTTL（86400）	低いTTL（300）
検索の速さ	速い。多くの場合キャッシュされている	遅い。頻繁に再問い合わせされる
クエリ量	少ない	多い
変更が反映されるまで	最大24時間	最大5分
自社のDNSが障害を起こしたときの耐性	高い。キャッシュが守ってくれる	低い。キャッシュがすぐに切れる
最も適したケース	安定したレコード	まもなく変更されるレコード

重要なポイント

高いTTLは、速度と耐障害性に最適化します。低いTTLは、機動性に最適化します。どちらが常に正しいということはなく、正解は、そのレコードがまもなく変更されるかどうかで決まります。

実際のTTLの見え方

INの前の数字が、秒単位のTTLです

example.com.    3600    IN    A     93.184.216.34
example.com.   86400    IN    NS    ns1.example.com.

dig で問い合わせると、設定されたTTLではなく、残りのTTLが表示されます。同じクエリを数秒あけて2回実行し、数字が減っていく様子を見てください。それは、リゾルバーのキャッシュがカウントダウンしていくのをリアルタイムで見ているということです。

キャッシュされたレコードが期限切れになるのを観察する

dig +noall +answer example.com
# wait 10 seconds, then
dig +noall +answer example.com

レコードタイプ別の推奨値

レコード	推奨TTL	理由
`A` / `AAAA`	`3600`（1時間）	適切な既定値です。ミスを修正できる程度に速く、効率的である程度に長い値です。
移行中の `A`	`300`（5分）	変更がすぐに反映されるよう、1日前に設定します。
`MX`	`3600`-`14400`	メールはキューに入れられて再試行されるため、速度はそれほど重要ではありません。
`TXT`（SPF/DKIM/DMARC）	`3600`	変更はまれで、変更するときには十分な速さです。
`NS`	`86400`+	委任はほとんど変更されず、キャッシュすることでTLDの負荷が減ります。
`CNAME`	指す先に合わせる	指す先より早く期限切れにしても、メリットはありません。

移行のパターン

これは、覚えておく価値のある唯一のTTLのワークフローです。丸1日の停止のリスクを、5分のリスクに変えられるからです。

変更の少なくとも古いTTL1周期分前に、TTLを下げる
現在のTTLが3600なら、300に変更し、少なくとも1時間は待ちます。ほかのものは何も変えません。
短いTTLが配信されていることを確認する
レコードを問い合わせ、TTLが300からカウントダウンしていることを確認します。これで、あなたのレコードを保持しているすべてのキャッシュが、5分のタイマーで動いています。
実際の変更を行う
アドレスを更新します。誰にとっても、待ち時間は最大5分になります。
確認してから、TTLを元に戻す
トラフィックが新しいサーバーに移ったら、TTLを3600に戻して、クエリのコストを払い続けないようにします。

TTLと耐障害性

高いTTLには、ほとんど語られない利点があります。DNSプロバイダーが障害を起こしても、あなたのレコードをキャッシュしているリゾルバーは、それを返し続けることです。24時間のTTLなら、数時間に及ぶDNS障害の間も、ほとんど気づかれずにドメインを維持できる可能性があります。60秒のTTLでは、ほぼ即座にドメインが見えなくなります。

安定したレコードのTTLを十分高く保つこと、そして低いTTLを既定の姿勢ではなく、一時的な移行用のツールとして扱うことには、確かな根拠があります。レコードを変更したときに何を待っているのかについては、DNS伝播で説明しています。

ドメインの公開DNSアドレスを調べたい場合は、Domain IP Lookupツールをお試しください。