サイトを移行し、自分の環境では問題なく表示されているのに、一部のユーザーから「まだ古いサイトが表示される」「こちらでは再現できないエラーが出る」といった報告が寄せられることがあります。
こうした状況に直面すると、ついサーバー設定や移行作業のミスを疑ってしまいがちです。しかし、実はその多くはDNSに起因しています。それもDNSが故障しているわけではなく、むしろ「仕様通りに動いている」からこそ発生する現象なのです。
DNSの更新情報は一斉に反映されるわけではありません。サーバーの外側にあるキャッシュやリゾルバなど、複数のレイヤーが絡み合うため、サイト側の準備が万全でも反映タイミングにはバラつきが生じます。
この記事では、DNSが具体的に何を管理しているのか、なぜ反映状況に差が出るのか、そしてトラブルを未然に防いでスムーズにサイト移行を完了させるためのポイントを解説します。
DNSの役割
DNSが答えるのは、非常にシンプルな一つの問いです。それは「このドメインはどこを指すべきか？」という点に集約されます。
ユーザーがブラウザにドメインを入力すると、DNSはその名前をIPアドレスへと翻訳します。このIPアドレスこそが、ブラウザに「どのサーバーに接続すべきか」を教える情報となります。DNS自体がページを読み込んだり、サーバーで何が動いているかを気にすることはありません。あくまで「参照先を教える」という役割に徹しています。
この照会作業を確実に行うため、DNSはいくつかのパーツに分かれており、それぞれが明確な役割を担っています。
-
ドメイン登録会社：ドメインを購入・更新する場所。サイトをホストしたりトラフィックを制御したりするわけではなく、DNSの観点からは、ドメインを正しいネームサーバーに紐付けるのが主な役割。
-
DNSサーバー：DNSレコードを実際に保管している場所。外部からドメインの解決を求められた際、そのドメインの正式な情報を回答。CloudflareのようなDNSサービスや、各サーバーが提供する管理パネルがこの役割を担うのが一般的。
-
ネームサーバー：そのドメインの「権威」がどのDNSサービスにあるのかを伝える役割。ネームサーバー自体にサイトのデータや設定が含まれているわけではなく、DNSクエリを正しい場所へルーティングするのみ。
-
DNSレコード（A、AAAA、CNAMEなど）：トラフィックの行き先を定義する具体的な設定。AレコードはドメインをIPv4アドレスに、AAAAレコードはドメインをIPv6アドレスに、CNAMEレコードはあるドメインを別のドメインの別名（エイリアス）として紐付ける。
これらのレコードが組み合わさることで、訪問者がサイトを読み込んだ際にどのサーバーに到達するかが決まります。
また、注意点として、DNSはファイルの配信やデータベースの移設、コンテンツの同期、あるいはSSL証明書の管理などには一切関与しません。サーバー内部の環境に直接干渉することもありません。
「どこまでがDNSの役割か」という点を明確に理解しておくと、サイト移行の全体像がぐっと整理され、スムーズに進められるようになります。
サイト移行時に変わるものと変わらないもの
サイト移行の際にDNSが混乱の原因となる理由の一つは、実際に変更される設定がごく一部に限られているためです。サイト自体はまったく新しい環境に移る場合でも、それ以外の多くの部分は以前と同じままになります。
一般的なサイト移行では、以下のような要素が変更されます。
- IPアドレス：サイトが別のサーバー上で稼働することになるため、ほぼ確実に変更される。DNSに関連する更新の中で最も一般的なものであり、最終的にトラフィックをどこへ送るかを決定する重要な要素。
- サーバー環境：これにはサイトを動かしているサーバー、インフラストラクチャ、プラットフォームなどが含まれる。パフォーマンスや安定性に影響するが、DNSとは別の要素であり、DNSを更新する前に完全に準備が整っている必要がある。
- 特定のDNSレコード：通常はAレコードやAAAAレコードが新たなIPアドレスを指すように更新される。サイトの構成によっては、代わりにCNAMEレコードが調整されることもある。
一方で、以下のような要素は通常変わりません。
- ドメイン名：訪問者はこれまでと同じURLにアクセスする。公開されているアドレスを変更する必要もない。
- ネームサーバー：DNSサービス自体を切り替える場合を除いて、多くの移行ではネームサーバーの変更は不要。サーバーが変わる場合も同様。
そのため、DNSの更新はほとんどの場合、移行作業の最後のステップになります。まずは新しい環境を構築して動作確認を行い、すべての準備が整い、トラフィックを受け入れられる状態になってからDNSを更新します。
DNSを最後のステップとして扱うことで、不確実性を減らし、リスクを最小限に抑え、サイトダウンの発生も大幅に避けやすくなります。
DNS伝播とその予測が難しい理由
DNS伝播とは、インターネット全体が一斉にドメイン情報を「更新する」ことを意味するわけではありません。DNSの変更が多くの独立したシステムに取り込まれ、キャッシュされ、再利用されるまでにどれくらい時間がかかるかを表します。
ユーザーがサイトにアクセスする際、そのリクエストが毎回直接DNSサービスに送られるわけではありません。通常は再帰リゾルバを経由します。これはISP、企業ネットワーク、あるいはGoogleやCloudflareのようなパブリックDNSサービスによって運用されているのが一般的です。このリゾルバはまず権威DNSサーバーに問い合わせを行い、その結果を取得すると、後で使えるようにキャッシュとして保存します。
一度リゾルバがDNSの応答をキャッシュすると、そのキャッシュが期限切れになるまで同じ情報を使い続けます。リゾルバごとにDNSデータをキャッシュする時間は異なり、TTL（Time to Live）の値を正確に守るものもあれば、独自の制限を適用したり、想定より長くキャッシュを再利用するものもあります。この違いが、DNS伝播の予測が難しくなる理由です。
さらに、ブラウザやオペレーティングシステムもDNSの結果をローカルにキャッシュする場合があります。たとえDNSレコードがすでに更新されていても、ユーザーのデバイスではローカルキャッシュがクリアされるか期限切れになるまで、古い情報が使われ続けることがあります。
このような多層的なキャッシュ構造があるため、異なる場所にいる2人のユーザーが同じ時間に同じサイトへアクセスしても、異なる状態のサイトを見ることがあります。たとえば、あるリゾルバはすでに新しいIPアドレスを取得している一方で、別のリゾルバはまだ古いサーバーを指している、といったことが起こります。
一般に言われる「24〜48時間」という目安は、実際の仕組みをかなり単純化したもので、多くの場合は数分以内に更新を確認できますが、リゾルバやローカルキャッシュの挙動によっては、もっと長くかかる場合もあります。
サイトダウンの回避に重要なTTL（Time to Live）
TTL（Time to Live）は、DNSの応答がリゾルバによってキャッシュされる時間を制御する仕組みです。TTLは更新を早めるものではありませんが、古い情報がどれくらい長く再利用されるかの上限を決める役割があります。
DNSレコードにはそれぞれTTLが設定されており、値は秒単位で指定されます。たとえばTTLが300の場合、リゾルバは最大5分間その情報を再利用してから、新しい情報を取得するために再度問い合わせを行います。TTLが86400であれば、最大24時間キャッシュされることになります。
そのため、サイト移行の前にTTLを下げておくことが重要です。リゾルバがすでに短いTTLのDNS応答を保持していれば、レコードを変更した際により頻繁に情報が更新されます。その結果、切り替え後に訪問者が古いサーバーへ送られてしまう可能性のある時間を短くできます。
多くの移行では、TTLを300〜600秒程度に設定するのが適切なバランスです。DNSインフラに不要な負荷をかけることなく、伝播の遅れを抑えるのに十分な短さです。
ただし、TTLを極端に短くすると問題が生じる場合もあります。短いTTLを設定しても更新が即座に反映されるとは限らず、リゾルバによっては極端に小さい値を無視することがあります。また、リクエストを制限したり、結局キャッシュされたデータを使い続けたりする場合も。さらに、直前になってTTLを下げるのもよくあるミスです。すでに長いTTLのレコードがキャッシュされている場合、それらのキャッシュが期限切れになるまでは新たなTTLの設定は反映されません。
最も安全なの方法としては、タイミングを意識することです。移行の少なくとも24時間前にはTTLを下げて、新たな値が反映されていることを確認してからDNSの変更を実施するのが理想です。
DNS移行を安全に進めるための手順
スムーズなDNS移行には、スピードよりも手順の順序が重要です。各手順を以下の正しい順序で進めていけば、確実にDNSを変更することができます。
1. 新たなサーバー環境を準備する
DNSに変更を加える前に、移行先のサイト環境を準備しておきます。これには、依存関係のインストール、キャッシュ設定、リダイレクトの構成、そしてパフォーマンスの確認などが挙げられます。
一時URLやローカルのhostsファイルを使ってサイトをテストし、DNSがすでに移行先のサーバーに紐づいている場合と同じ状態で確認できるようにします。特にHTTPSを設定している場合は、SSL証明書が導入され有効であることを必ず確認してください。DNSの変更を行う段階で、設定ミスに気付くような状態は避けるべきです。
KinstaのコントロールパネルであるMyKinstaでは、ダッシュボードから「DNS管理」に移動し、「最初のドメインを追加」をクリックして、DNS情報を簡単に設定することができます。
2. TTLを事前に下げる
次に、移行に関係するDNSレコードのTTLをあらかじめ下げておきます。先に触れた通り、少なくとも移行予定日時の24時間前に実施しておくのが理想です。
TTLを変更した後は、DNSルックアップツールを使って変更した値が反映されていることを確認します。これにより、IPアドレスを変更する前の段階で、リゾルバがより短いTTLのDNS応答をキャッシュし始めていることがわかります。
3. リスクのある変更は控える
サイトが単一のデータベースに依存している場合は、コンテンツ編集、ECサイトの注文、フォーム送信などを一時的に停止します。DNSはデータを移動する仕組みではないため、移行用のスナップショットを取得した後に旧サイトで行われた変更は失われる可能性があります。
移行時に発生するデータの問題の多くは、DNSの遅延ではなく、データの同時書き込みが重なることによって起こります。変更を一時停止することで、このリスクを回避できます。
4. DNSレコードを更新する
更新が必要なレコードのみを変更します。通常はサイトを指しているAレコード、AAAAレコード、またはCNAMEレコードです。同じタイミングで、関係のないレコードまで変更するのは避けましょう。MyKinstaでは、先ほどと同じ「DNS管理」画面で「DNSレコード」セクションの「レコードを追加」をクリックして、この手順を実行できます。
IPアドレス、レコードタイプ、ホスト名に誤りがないかを再確認し、競合を防ぎます。更新後は、ブラウザでの確認だけに頼らず、DNSクエリを直接実行して変更内容を検証してください。
また、「自動スキャン」セクションの「スキャンを開始」をクリックすると、DNSレコードの自動スキャンを実行できます。
5. DNS伝播の状況をリアルタイムで監視する
複数の地域からDNSの名前解決を確認し、トラフィックが新しいサーバーに届いているかを追跡します。切り替えの途中では、結果が混在することがありますが、これは正常な状態です。
重要なのは、すべてのユーザーが同時に更新されることではなく、新しいトラフィックがエラーや中断なく、安定して正しい宛先に解決されていることです。
この手順に沿って進めることで、DNSの挙動を予測しやすくなります。各手順がリスクを抑え、不確実性を減らし、急いだ変更や重複する作業によって発生するサイトのダウンを防ぐことにつながります。
サイトがダウンする主な原因とその対策
移行中にサイトがダウンすると、原因はDNSだと思われがちですが、問題の多くは別のところにあります。
DNSの問題は基本的にシンプルで、レコードが正しい場所を指しているかどうかの二択です。多くの障害は、DNS・サーバー環境・アプリケーションの間にある設定のずれによって発生します。
- IPアドレスの誤り：入力ミスや古い値のままになっているだけでも、トラフィックが別のサーバーへ送られてしまう。その結果、DNS自体は正常に解決されていても、ユーザーからはサイトがダウンしているように見えることがある。
- DNSレコードの不足や設定漏れ：変更作業の際に、メール用レコード、wwwサブドメイン、ドメイン認証用レコードなどが見落とされることがあり、その結果、サイトの一部機能が使えなくなったり、部分的な障害が発生したりすることがある。
- SSLの設定の不一致：DNSは移行先のサーバーを指していても、証明書がまだインストールされていない、あるいは正しいドメインに反映されていない場合がある。その場合は、ブラウザが接続をブロックし、訪問者にはサイトがダウンしているように見えてしまう。
- キャッシュされたコンテンツやリダイレクト：DNS更新後でも、古いサーバーに紐づいていることがあり、特にリバースプロキシやCDNを利用している場合、新しい環境と設定がそろっていないとこのような問題が起こりやすくなる。
こうした問題を防ぐ最も確実な方法は、新旧の環境をしばらく並行して稼働させることです。トラフィックが明確に新しい環境へ移行したことを確認できるまでは、旧環境と新環境の両方を正常に動作させておきます。両方のサーバーが安全にリクエストを処理できる状態にしておけば、DNS伝播の影響によるリスクも大幅に小さくなります。
マネージドサーバーがDNS関連のリスクを減らす仕組み
マネージドサーバーを利用すると、DNS変更の前に移行先の環境が完全に準備されていることを確認できるため、移行時のリスクを減らすことができます。多くのマネージドサーバーでは、ステージング環境や一時URL、事前に構成されたサーバースタック、SSLの準備状況の確認機能などが提供されています。そのため、旧サイトが引き続き訪問者にサービスを提供している間に、新しいサイトを本番と同じ条件でテストできます。
また、移行サポートも重要です。専任のスタッフが担当してくれる移行サポートを利用できれば、DNSレコードの確認、IPアドレスの割り当ての検証、そしてサイトダウンの原因になりやすい設定ミスのチェックを代行してくれます。問題がDNSなのか、SSLなのか、それともアプリケーション側なのかを自分で手探りで判断する必要はなく、移行プロセスの早い段階で問題を特定して解決できます。
Kinstaでは、移行時に新旧の環境が一定期間並行して稼働することを前提に構成されています。旧サイトがトラフィックを処理し続けている間に、新しいサイトを準備し検証します。DNSの更新が行われる時点では、両方の環境がリクエストを処理できる状態になっています。
不必要な混乱を招くDNSの誤解
よく目にするDNSに関する情報の中には、誤ったものもあります。こうした誤解を解消しておくと、変更がすぐに反映されない場合でも落ち着いて対応できるようになります。
「DNSの変更はすぐに反映される」
DNSの更新はインターネット全体にリアルタイムで反映されるわけではありません。キャッシュが期限切れになり、リゾルバが情報を更新するタイミングで徐々に反映されていきます。設定が正しく行われていても、反映は段階的に進みます。
「サイトが表示されない＝DNSが壊れている」
移行時にサイトダウンが発生する原因は、ほとんどの場合DNSではありません。SSLエラー、サーバー設定の問題、アプリケーションの不具合などが原因でも、ユーザーにはサイトが表示されないためDNSの問題のように見えることがあります。
「キャッシュをクリアすれば伝播が早くなる」
ブラウザのキャッシュをクリアすると、最新版のサイトを確認できる場合がありますが、リゾルバやISPが保持しているキャッシュには影響しません。DNS伝播はそれらの更新タイミングによって進むものであり、ユーザー側でコントロールすることはできません。
「移行のたびにネームサーバーを変更する必要がある」
ネームサーバーの変更が必要なのは、DNSサービスを切り替える場合のみです。多くのサイト移行では、ネームサーバーを変更する必要はありません。
ネームサーバーの変更が必要な場合は、MyKinstaの「DNS管理」画面から、「レジストラでのネームサーバーの変更」セクションを確認して、Kinstaのネームサーバーを参照できます。
DNSが予測どおりに動かないように見える場合でも、実際にDNSが壊れていることはほとんどありません。DNSは誤解されやすいルールに従って、基本的には予測可能な動きをしています。そうしたルールを理解しておくことで、移行時に感じやすい不安の多くを減らすことができます。
DNS更新後に確認したい移行後のチェックリスト
DNSの変更が完了した後は、トラフィックが確実に新しい環境へ届いているか、そして裏側で問題が発生していないかを確認することも必要不可欠です。
- トラフィックが移行先のサーバーに届いているかを確認：サーバーログ、アクセス解析、またはサーバーのコントロールパネルを確認し、リクエストが正しいIPアドレスと環境に到達しているかを確認。移行直後は旧サイトと新サイトの両方にトラフィックが届くことがあるが、徐々に新サイトへ完全に移行していく。
- SSLとリダイレクトの動作を確認：すべての対象ドメインで証明書が有効になっているか、またHTTPからHTTPSへのリダイレクトや旧URLからのリダイレクトが意図どおりに機能しているかを確認する。証明書エラーやリダイレクトループは、実際のトラフィックが流れ始めてから初めて発覚することも。
- ログとエラー率を監視：404エラー、500番台エラー、ブロックされたリクエストなどが急増していないかを確認。これらの兆候は、テスト環境では見つからなかった設定ミスが残っている可能性を示していることがある。
- トラフィックが安定したらTTLを元の値に戻す：TTLを長めに設定するとDNSクエリの回数が減り、リゾルバの効率が向上。この作業は忘れられがちですが、長期的な安定性のためには重要。
- 旧環境を安全に停止：旧サーバーに意味のあるトラフィックが届いていないことを確認するまでは、停止しないようにする。新旧環境を一定期間並行して稼働させることで、想定外のケースが発生してもサイトダウンにつながるリスクを防ぐことができる。
このような最終確認を行うことで、DNS更新だけでなく、移行全体を安定した状態で完了させることができます。
移行時にサイト停止を防ぐために
サイト移行中に発生するサイトダウンの多くは、変更作業を急ぎすぎたり、担当作業が重なったり、DNSをプレッシャーの中で「急いで修正すべきもの」として扱ったりしてしまうことによって起こります。
安全な移行では、スピードよりも事前準備が重視されます。まずサーバー境、アプリケーションの設定、SSLの状態を確認し、その後にDNSを更新します。また、DNS伝播やキャッシュには時間がかかる可能性があることを前提に進めることも重要です。
適切なワークフローとサポートがあれば、サイト移行は必ずしもストレスやリスクを伴うものではありません。Kinstaのマネージドサーバーのような安定した環境の上でDNS変更を行えば、移行時のサイトダウンはほぼ確実に回避できるようになります。
