「NSレコードのTTLはいくつに設定すべきか？」
「DNS切り替え時の浸透待ちが予想以上に長いのはなぜか？」
インフラエンジニアやWeb担当者が一度は悩むこの問題について、推奨値と、意外と知られていない 「親（レジストラ）」と「子（DNSサーバー）」のTTL不整合による挙動についてまとめました。
結論：推奨設定値
まずは結論から。運用フェーズによって推奨値は異なります。
| フェーズ | 推奨TTL値 | 秒数表記 | 理由 |
|---|---|---|---|
| 通常運用時 | 24時間 〜 48時間 | 86400 / 172800 | キャッシュ効率向上、安定性確保、サーバー負荷軽減 |
| DNS移行時 | 5分 〜 1時間 | 300 / 3600 | 切り替えを素早く反映させるため |
基本は 24時間（86400秒） にしておき、DNSサーバーの引っ越しなど「これから設定を変えるぞ」という時だけ、事前に短くするのが鉄則です。
なぜ「親」と「子」を意識する必要があるのか？
NSレコードには2つの設定場所が存在します。
- 親（Parent）： レジストラ（お名前.com, Route53 Domains等）に登録するネームサーバー情報。上位のTLDサーバーが答える情報。
- 子（Child）： 実際のDNSサーバー（Route53, Cloudflare等）のゾーンファイルに書くNSレコード。権威サーバーが答える情報。
私たちが手動でTTLを自由に変更できるのは、主に 2. 子（DNSサーバー） 側ですが、DNSの仕組み上、親の設定がボトルネックになるケースがあります。
ケース1：親が長く、子が短い場合（よくあるパターン）
- 設定： 親(48時間) / 子(5分)
- 状況： 「DNS移行をするから、あらかじめ自分のサーバー(子)のTTLを5分に下げておいた！準備万端！」
この状態でDNS切り替えを行うと、最大48時間切り替わらないユーザーが出てきます。
▼ なぜ？
リゾルバ（キャッシュサーバー）はまず親に聞きに行き、「あそこのサーバーに行け（有効期限48時間）」という情報をキャッシュします。このキャッシュが生きている48時間は、そもそも子（TTL 5分）を見に来てくれないため、子の設定が無視される形になります。
教訓： 子のTTLを下げても、親のTTL（変更できないことが多い）が長い場合、移行準備期間は「親のTTL」分だけ待つ必要がある。
ケース2：親が短く、子が長い場合
- 設定： 親(5分) / 子(24時間)
- 状況： 「親の設定が短いから、いざという時はすぐに切り替わるだろう」
この状態でDNS切り替えを行うと、最大24時間切り替わりません。
▼ なぜ？
DNSには 「紹介（親）よりも本人（子）の確定情報を信じる」というルールがあります。
リゾルバは親から「5分有効」として紹介されても、その後に子から「私は管理者です。この情報は24時間有効です」と言われると、キャッシュを24時間で上書きします。これを「権威ある回答（Authoritative Answer）」と呼びます。
結果、古いサーバーへのパスが24時間残り続け、いわゆる「幽霊ドメイン現象」が起きます。
【図解】TTL不整合の勝敗ルール
覚え方はシンプルです。
「基本的に、長い方のTTLに引きずられる（悪い方に作用する）」 と覚えてください。
まとめ表
| あなたの設定 | 親の設定（固定多し） | 結果（実際の反映待ち時間） | 解説 |
|---|---|---|---|
| 5分 (短) | 48時間 (長) | 48時間 | 親のキャッシュが消えるまで、子を見に来てくれない。 |
| 24時間 (長) | 5分 (短) | 24時間 | 子の「権威ある回答」でキャッシュ期間が上書きされる。 |
正しいDNS移行のステップ
上記を踏まえた、事故らないためのDNS移行スケジュールは以下の通りです。
-
【移行の2〜3日前】
現行のDNSサーバー（子）で、NSレコードのTTLを 300（5分） に下げる。
- ※ここで「親のTTL（例：48時間）」が切れるのをじっくり待つのが重要です。
-
【移行当日】
レジストラ側（親）の設定を変更し、新DNSサーバーへ向ける。
- ※すでに子のキャッシュは5分になっているため、親のキャッシュが切れ次第、スムーズに新サーバーへ流れます。
-
【移行完了後】
新DNSサーバー（子）で、NSレコードのTTLを 86400（24時間） に戻す。
最後に
「DNSは浸透するまで待つしかない」と言われますが、仕組みを理解していれば、その待ち時間が「親のせい」なのか「子のせい」なのかを判断し、ある程度コントロール（または予測）することができます。
普段は 24時間（86400） でどっしりと構え、移行時だけ 親のTTLを計算に入れた上で 短く設定する。これがベストプラクティスです。