ネームサーバー（DNS）変更とTTL設定の基礎 — 切り替えトラブルを防ぐ

TTLとは — キャッシュを保持してよい時間

TTL（Time To Live）は、DNSレコードをキャッシュしてよい時間を秒単位で示す値です（RFC 1035）。利用者が使うキャッシュDNSサーバーは、一度取得したレコードをTTLが切れるまで保持します。そのため、権威サーバー側でレコードを変更しても、キャッシュが残っている間は古い情報が返ることがあります。

ただし、TTLは時間を保証する値ではありません。RFC 2181では、TTLは存続時間の上限であって、その時間だけ保持することを義務づけるものではないとされています。また、RFC 8767は、キャッシュDNSサーバーが権威サーバーから情報を更新できない例外的な場合に、期限切れのデータを使うことを認めています。「○時間で全員に反映される」とは言い切れません。

反映までの時間は何で決まるか

待つ時間を左右するTTLは、変更の種類によって異なります。

ネームサーバーの変更では、親に登録された委任情報（NSレコード）が関わります。親のNSレコードのTTLは、親の権威DNSサーバー側の設定です。お名前.comのヘルプでは、TTLはレコード設定情報の保持時間であり、ネームサーバー自体の変更反映時間とは異なると説明されています。

事業者が公式ページで示している反映時間の目安は、次のとおりです（2026年10月時点）。

お名前.comのヘルプには、接続環境やレジストリ側の事情で反映が遅れる場合があること、事業者側では反映時間の短縮や時間指定の調整ができないことも記載されています。目安は事業者によって異なり、反映時間そのものは保証されません。

サーバー移転時のネームサーバー切り替え手順

JPRS（日本レジストリサービス）の技術解説（2011年6月時点の内容）は、ネームサーバーの切り替えで「DNSが浸透しない」状態を避けるための手順として、新しいゾーンデータで新旧のネームサーバーを並行運用する方法を示しています。解説が想定しているのは、権威DNSサーバーがすべて入れ替わり、Webサーバーやメールサーバーのホスト名は変わらずIPアドレスだけが変わるケースです。

digで切り替え状況を確認する

切り替えの前後は、dig（BIND付属のDNS問い合わせツール）で状況を確認できます。example.com と ns1.old.example.net・ns1.new.example.net は例です。

# 自分の環境が参照しているネームサーバーの答え
dig example.com A +short

# ネームサーバーのNSレコード
dig example.com NS +short

# 旧・新それぞれのネームサーバーに直接問い合わせる
dig @ns1.old.example.net example.com A +short
dig @ns1.new.example.net example.com A +short

# ルートサーバーから委任をたどって確認する
dig +trace example.com NS

• dig はサーバーを指定しない場合、/etc/resolv.conf に設定されたネームサーバーに問い合わせます。キャッシュに古い情報が残っていると、古い値が表示されます。
• @ でネームサーバーを指定すると、そのサーバーが返す内容を直接確認できます。JPRSの解説では、正しい委任には、親と子が示すすべての権威DNSサーバーが権威ある応答を返し、同じ応答を返す必要があるとされています。切り替え後は、新旧のネームサーバーが同じ内容を返しているかを確認します。
• +trace を付けると、ルートサーバーからの委任をたどり、各サーバーの応答を表示します。
• +short を付けると、簡潔な形式で表示します。

Windowsに標準で入っているnslookupでも、問い合わせ先のサーバー（server）やレコードの種類（set type）を指定できます（Microsoft Learn）。

移転作業の全体像と移転先のサーバー選び

ネームサーバーの切り替えは、サーバー移転の工程の一部です。移転の全体の流れはサーバー移転の完全手順、停止を避ける考え方はダウンタイムを出さない切り替えで解説しています。移転先を選ぶときは、サーバー種別の比較ガイドと共用サーバーの選び方ガイドも参考にしてください。

よくある質問（FAQ）