深夜のデスクでDNSの管理画面を開き、レコードを書き換える直前に手を止めて段取りを確かめている一人運用の保守担当者
リリース・変更管理約21分

DNS切り替えを含むリリースの段取り｜TTL短縮と切り戻しの手順

新しいサーバーの準備は終わった。データも移した。動作確認も通った。 あとは、DNSのAレコードを新しいIPに書き換えるだけ——。

作業そのものは1行です。それなのに、保存ボタンの上でマウスが止まる。この感覚、たぶん一度は味わったことがあると思います。

止まる理由ははっきりしています。DNSの切り替えは、押した瞬間から自分の手を離れるからです。反映のタイミングを決めるのは、世界中のキャッシュDNSと、利用者のブラウザと、社内システムのライブラリです。しかも困ったことに、戻すときも同じだけ時間がかかります。「押してダメなら戻せばいい」が、そのままでは通じません。

だからこの記事では、DNS切り替えを「一発勝負」から「段取りのある作業」に変えます。難しい技術は使いません。いつ何をやるかの順番を決めるだけです。

結論：DNS切り替えは、次の5つをこの順番で通します。①切り替えの「今のTTL以上前」にTTLを短くしておく → ②hosts や curl --resolve で、DNSを触らずに新環境を通しで確認する → ③切り替え後は権威DNSとキャッシュDNSを分けて確認する → ④二重稼働の時間を前提に、データの行き先を1つに寄せておく → ⑤旧環境をしばらく生かしたまま残し、落ち着いたらTTLを元に戻す。とくに効くのは①と④です。切り戻しの本命はDNSを戻すことではなく、旧環境を落とさずに置いておくこと——ここだけ押さえておけば、あとは落ち着いて進められます。

なお、以下はあくまで進め方の型です。レコードの編集画面・TTLの下限・使えるレコード種別は、DNSサービスやレジストラによってかなり違います。本番で実行する前に、必ずご利用中のサービスの公式ドキュメントで確かめてください。

何が起きているか：「浸透」という言葉が、話をわかりにくくしている

DNSの切り替えを説明するとき、「浸透するまで待つ」という言い方をよく見かけます。霧が広がるように、じわじわと世界に伝わっていくイメージです。

でも実際に起きていることは、もっと単純で、もっと予測できます。

キャッシュDNSは、一度受け取った答えを、TTLで指定された秒数だけ覚えているだけです（RFC 1035）。TTLが3600なら、そのキャッシュは1時間、古いIPを返し続けます。1時間経てば、次の問い合わせで新しい答えを取りに行きます。

つまり、こうなります。

ここが大事なところです。「浸透待ち」は運任せに聞こえますが、実体はタイマーです。タイマーは、事前に短くしておけます。 DNS切り替えの段取りは、ほぼこの一点に集約されます。

もうひとつ、知っておくと気が楽になることがあります。

切り戻しも、同じタイマーに縛られます。 切り替えて問題が出たので慌ててレコードを戻しても、すでに新しいIPをキャッシュした相手は、TTLが切れるまで新環境を見続けます。DNSの切り戻しは、即効薬ではありません。 だから本当の備えは別のところにあります（後述の手順5）。

手順1：TTLを、切り替えの「今のTTL以上前」に短くする

いちばん効く一手であり、いちばん忘れられやすい一手です。

やることは単純で、切り替えの前にTTLを短い値（300秒＝5分など）に変更しておくこと。ただし、タイミングに条件があります。

TTLを短くする作業は、「今設定されているTTLの秒数」以上前に済ませておく必要があります。

理由は、すでに配られてしまった答えです。キャッシュDNSが昨日受け取った答えには、昨日時点のTTL（たとえば86400秒）がくっついています。今日あなたがTTLを300に変えても、昨日配った答えの期限が短くなるわけではありません。その相手は、あと数時間は古い設定のまま動きます。

具体的にはこうなります。

今のTTLいつまでにTTLを短くしておくか
86400秒（24時間）切り替えの24時間以上前
3600秒（1時間）切り替えの1時間以上前
300秒（5分）切り替えの5分以上前（実質そのままでよい）

現在のTTLは dig で確認できます。

# 権威DNSに直接聞いて、設定されているTTLを見る
dig @ns1.example-dns.jp example.com A +noall +answer

# キャッシュ側（残り秒数が返る）
dig @8.8.8.8 example.com A +noall +answer

ANSWER SECTION の左から2つ目の数字がTTLです。権威DNSに直接聞いたときは設定値そのもの、キャッシュDNSに聞いたときは「残り秒数」が返る、という違いだけ覚えておけば十分です。同じコマンドを2回打って数字が減っていたら、それはキャッシュを見ています。

短くしたTTLは、切り替えが終わるまで戻さない

「前日に短くして、当日の朝に戻す」はやりません。切り戻しが必要になったとき、短いTTLが命綱になります。元に戻すのは、切り替えが落ち着いてからです（手順5）。

ネームサーバー（NS）ごと移す場合は、別物として扱う

Aレコードを書き換えるのと、レジストラでネームサーバーそのものを変えるのは、難易度がまったく違います。

NSの切り替えは、上位（レジストリ側）が持つNSレコードのTTLに従います。これは自分では短くできません。ドメインによっては1〜2日かかると見ておく必要があります。

対処は決まっています。新旧どちらのネームサーバーにも同じ内容のゾーンを用意しておき、どちらを見ても正しく答えられる状態にしてから切り替える。 そうすれば、待ち時間が長くても事故になりません。「移行のついでにDNSサービスも乗り換える」ときは、この2つを同じ日にやらないのが安全です。

手順2：DNSを触らずに、新環境を通しで確認する

切り替える前に、新環境が本当に動くかを確かめます。ここでDNSを使ってしまうと後戻りできないので、自分の端末だけが新環境を見る状態を作ります。

方法A：hostsファイルに書く

# /etc/hosts （Windows は C:\Windows\System32\drivers\etc\hosts）
203.0.113.45   example.com
203.0.113.45   www.example.com

自分のPCだけが新IPを見るようになります。確認が終わったら必ず消してください。消し忘れると、切り替え後に「自分だけ何をやっても表示が変わらない」という不思議な現象に悩むことになります。

ひとつ注意があります。最近のブラウザはセキュアDNS（DNS over HTTPS）が有効だと、hostsを見ないことがあります。 「hostsを書いたのに切り替わらない」ときは、ブラウザ設定でセキュアDNSを一時的にオフにしてください。

方法B：curl で名前解決先だけ差し替える（こちらが確実）

# example.com という名前のまま、接続先IPだけ新サーバーにする
curl -I --resolve example.com:443:203.0.113.45 https://example.com/

hostsを書き換えずに済み、消し忘れも起きません。ブラウザの挙動にも左右されないので、コマンドで確認できるものはこちらが確実です。

何を確認するか

トップページが出た、で終わらせないのがコツです。

証明書は「切り替え前」に新環境へ用意しておく

見落としやすいのがここです。切り替えた瞬間に証明書エラーが出ると、利用者から見れば障害と変わりません。

Let's Encrypt を使っている場合、HTTP-01 という検証方式は、本番のDNSが新サーバーに向いていないと通りません（実際にそのドメインへアクセスして確認する方式のため）。切り替え前に新環境で証明書を取りたいときは、次のどちらかになります。

そのうえで、切り替え後に新環境側の自動更新が正しく動くかを、あらためて確認します。証明書の期限管理そのものはSSL/TLS証明書の期限切れを防ぐ更新と監視にまとめています。

手順3：切り替えたら、権威DNSとキャッシュDNSを分けて確認する

TTLを短くしてから切り替え、落ち着いてからTTLを元に戻すという3つの段階を左から右へ時間の流れで示した図
TTLは切り替えの前に短くしておき、落ち着いてから元に戻す。この前後の2手が、当日の余裕をつくる

レコードを書き換えたら、2種類の確認を分けて行います。ここを分けられると、トラブルの原因がすぐ絞れます。

確認1：権威DNSに直接聞く（設定が入ったか）

dig @ns1.example-dns.jp example.com A +noall +answer

ここで新しいIPが返らなければ、そもそも設定が保存されていないか、編集したゾーンが違います。キャッシュのせいではありません。まずここを見ます。

確認2：パブリックなキャッシュDNSに聞く（外から見えるか）

dig @8.8.8.8 example.com A +noall +answer
dig @1.1.1.1 example.com A +noall +answer

権威では新IPなのにこちらが古いままなら、それはTTLの残りを待っている状態です。異常ではありません。返ってくるTTLの数字が、あと何秒古いままかを教えてくれます。

確認3：親からたどって、経路そのものを見る

dig example.com A +trace

ネームサーバーごと変えたときや、「どこで古い答えが出ているのか分からない」ときに効きます。

確認4：実際にアクセスする

curl -I https://example.com/

応答コードと、新環境のアクセスログの両方を見ます。新環境のログに自分のアクセスが記録されていれば、切り替わっています。

このあたりの調べ方をもう少し詳しく知りたいときは、名前解決できない障害の切り分け｜DNSを疑う順番と確認手順に基本の道具立てをまとめています。

「自分の環境で切り替わった」は「全員切り替わった」ではない

これは何度でも言う価値があります。自分のPCが新環境を見たとしても、それは自分が使っているキャッシュDNSの期限が切れただけです。社内の別のネットワーク、利用者の自宅回線、携帯回線は、それぞれ別のタイミングで切り替わります。

だから、切り替え直後に旧環境を落としてはいけません。ここが次の手順につながります。

手順4：二重稼働の時間を前提に、データの行き先を1つに寄せる

DNS切り替えでいちばん怖いのは、実は表示が切り替わらないことではありません。新旧の両方が同時に動いていて、どちらにも書き込みが起きることです。

TTLが5分でも、その5分の間に注文が入るかもしれません。問い合わせフォームが送信されるかもしれません。旧環境のDBに入ったそのデータは、新環境からは見えません。気づくのは数日後、「送ったはずの問い合わせが届いていない」という連絡で、というのがよくある流れです。

対策は3つあり、上から順に安全です。

A. データの置き場所を1つに寄せる（いちばん安全）

切り替え前に、旧環境のアプリも新しいDBを見るように設定を変えておきます。こうすると、どちらのサーバーにアクセスが来ても、書き込み先は1か所です。二重稼働そのものが問題でなくなります。

アプリとDBを一緒に移す構成なら、「先にDBだけ移して旧アプリから新DBを参照させる → 数日おいてアプリを切り替える」と2段階に分けると、リスクがぐっと下がります。

B. 旧環境を読み取り専用、またはメンテナンス画面にする

切り替えと同時に、旧環境側を書き込めない状態にします。まだ旧環境を見ている人には「ただいまメンテナンス中です」と出るので、データが割れるより誠実です。告知画面の用意はメンテナンス告知の出し方とメンテナンス画面の用意にまとめています。

C. 旧環境のログを見張り、落とすタイミングを判断する

AもBも取れない場合は、旧環境のアクセスログを見て、まだ実利用のアクセスが来ているかを確認します。監視botや自分のアクセスを除いて、実際の利用が止まったのを見てから次に進みます。

メール（MXレコード）を含むときは、さらに慎重に

Webと同じ感覚でMXレコードを切り替えると、切り替え中に届いたメールが旧サーバーのメールボックスに入ったままになります。Webと違い、利用者はそれに気づけません。

送信側の設定はメールが届かない障害の切り分け｜SMTP・SPF・DKIMの確認、なりすまし対策まで含めた考え方はDMARCの設定にまとめています。MXの切り替えは、Webの切り替えとは別日に分けるのが、一人運用ではいちばん楽です。

手順5：切り戻しの本命は、旧環境を落とさないこと

ここが、この記事でいちばんお伝えしたいところです。

切り替えたあと、新環境で問題が見つかったとします。慌ててDNSを旧IPに戻す——それ自体は正しい対応です。ただし、戻した効果が全員に行き渡るまでには、またTTLぶんの時間がかかります。TTLを300秒にしておけば5分ですが、86400のままだったら丸1日です。

だから、DNS切り替えにおける本当の切り戻し手段はこうなります。

旧環境を、動いたまま残しておくこと。

新環境が不調でも、旧環境が生きていれば、まだ旧を見ている人には何も起きていません。DNSを戻せば、残りの人も順次戻ってきます。旧環境を落とさない限り、サービス全体が止まることはない——この状態を作っておくのが、段取りの目的です。

保持期間の目安はこのくらいです。

一部のアプリケーションは、TTLを無視して起動中ずっと同じIPを覚え続けることがあります（Javaの一部設定などが有名です）。連携先が社内システムなら、切り替え後に「そちらのシステム、再起動をお願いできますか」と一言添えるだけで解決することが多いです。

落ち着いたら、TTLを元に戻す

そして最後の1手。短くしたTTLを、元の値（3600など）に戻します。

これを忘れると、権威DNSへの問い合わせが増え続けます。さらに、権威DNSに障害が起きたときの影響が大きくなります。TTLが長ければ、キャッシュがしばらく答えを返し続けてくれる（＝耐えられる）からです。TTLが短いということは、その余裕がないということでもあります。

切り替えから1〜2週間、問題が出ないことを確認できたら戻します。「TTLを戻す」をカレンダーに入れておくのが、いちばん確実です。

戻す判断そのものの型はすぐ戻せるリリース設計｜ロールバック手順の用意、記録の残し方は変更管理台帳の付け方が使えます。

具体例：会社サイトと問い合わせフォームを、一人で移設した週

社内システムと会社サイトを兼務で見ている担当者の例で、時間の流れを追ってみます。旧サーバーがEOLを迎えるための移設で、Webと問い合わせフォームのみ、メールは別サービスなのでMXは触りません。

この流れで効いたのは、高度な技術ではありません。3日前にTTLを短くしたことと、前日にDBの行き先を1つに寄せたこと。この2つだけです。当日の作業は1分で、あとは確認の時間でした。

段取りが効いている作業は、当日が退屈になります。退屈な切り替えが、いい切り替えです。

影響：段取りを決めると、何が変わるか

一方で、増える手間もあります。準備が数日前から始まるので、「今日中に切り替えたい」という依頼には応えにくくなります。ここは正直なところです。

ただ、TTLが86400のまま切り替えて問題が出た1回は、丸1日の不安定さになります。数日の前倒しのほうが、ずっと安く済みます。

明日やること：TTLを見るところから

切り替えの予定がなくても、今日できることがあります。5分で終わります。

  1. 管理しているドメインのTTLを、dig で1回見てみる。
   dig example.com A +noall +answer

数字が86400なら、いざというとき丸1日かかる設定だ、と知っておくだけで違います。

  1. 権威DNSがどこか、レジストラのログイン方法をメモに1行残す。

切り替えのとき、いちばん時間を取られるのが「どこの管理画面で編集するんだっけ」です。この1行はサーバー構成ドキュメントに置いておくと、引き継ぎでもそのまま使えます。

  1. 切り替え予定があるなら、「TTL短縮日」を逆算してカレンダーに入れる。

今のTTLの秒数を日数に直して、切り替え日から引き算するだけです。86400なら1日前、余裕を見て2〜3日前。

この3つは、サーバーの状態を1ミリも変えません。今日からでも安全に始められます。

DNS切り替えチェックリスト

全部そろえる前提ではありません。上から優先順位で並べています。

切り替えの数日前

前日まで

当日

後日

「切り替えの数日前」の最初の2つが埋まっていれば、多くの場面で戻れます。残りに○が付かない日があっても大丈夫です。

よければ、こちらも

DNS切り替えは、前後の手順とつなげると一段楽になります。

切り替えの翌朝、新環境が問題なく動いていることをログで確認して安心している保守運用担当者

DNSの切り替えで手が止まるのは、慎重さが足りないからではありません。押したあとの時間を自分で握れないと分かっているからです。その感覚は、正しい怖がり方だと思います。

ただ、その時間は、実は事前に短くしておけます。TTLを300にした瞬間、「戻れない1日」は「戻れる5分」に変わります。怖さを消す必要はありません。戻り道の長さだけ、先に縮めておけば大丈夫です。

明日、自分が管理しているドメインに dig を1回打つところからで十分です。今の数字を知っておくだけで、次の切り替えはずいぶん違う顔になります。

ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。

関連用語