DNS切り替えの注意点｜トラブルを防ぐための重要ポイントを実例付きで解説！

 

Webサイトを新しいサーバーへ引っ越す際、多くの場合に必要となるのが「DNS切り替え」です。
専門用語のように聞こえますが、簡単に言うとドメインの接続先を古いサーバーから新しいサーバーへ変更する作業です。

 

この作業は、手順やタイミングを間違えると「一時的にサイトが表示されなくなる」「会社宛ての重要なメールが届かなくなる」といったビジネス上のトラブルにつながるリスクがあります。そのため、事前の準備が欠かせません。
本記事では、新任のWeb担当者の方や、これからWebの仕組みを学びたい方に向けて、DNS切り替えを安全に行うための注意点やトラブルを防ぐポイントを解説します。

1. DNS切り替えとは？基礎知識と仕組み

サーバーの引っ越しを安全に進めるためには、まず「DNSが普段どのような役割を果たしているのか」という基本を理解しておくことが大切です。仕組みが分かれば、なぜ切り替え時に注意が必要なのかが見えてきます。

 

1.1. DNSの役割と切り替えが必要なタイミング

DNS（Domain Name System）とは、「ドメイン名」と「IPアドレス」を紐付けるインターネット上のシステムのことです。

 

1.1.1. DNSの基本的な役割（ドメインとIPアドレスの翻訳）

私たちがWebサイトを見るときは、ブラウザに「example.co.jp」のような分かりやすい文字列「ドメイン名」を入力します。しかし、コンピュータ同士は「192.0.2.1」といった数字の羅列「IPアドレス」を使って、通信の相手先を特定しています。
この人間がアクセスするためのドメイン名を、コンピュータ用の数字の住所であるIPアドレスに翻訳し、正しい接続先に案内してくれる役割をDNSが担っています。この案内先を古いサーバーから新しいサーバーへと書き換える作業が「DNS切り替え」です。

 

 

1.1.2. DNS切り替えが発生する主なケース

DNS切り替えが発生するシチュエーションは多岐にわたりますが、代表的な例としては以下のようなケースが挙げられます。

 

切り替えが必要なケース	具体的な状況と目的
Web・メールサーバーの引っ越し	現在利用しているレンタルサーバーから、よりスペックの高い別のサーバーへWebサイトやメールサーバーを引っ越す場合。
メールシステムのみの変更	Webサイトは今のサーバーに残したまま、会社のメールシステムだけをGoogle WorkspaceやMicrosoft 365などのクラウドサービスへ移行する場合。
セキュリティ対策の導入	サイバー攻撃からサイトを守るため、アクセスを専用のセキュリティシステム（WAFなど）経由に変更する場合。

 

1.2. DNSの仕組みを支える「2つのサーバー」

DNSには複数の仕組みが関係していますが、サーバーの引っ越し時に特に押さえておきたいのが、役割の異なる次の2つのDNSサーバーです。

 

 

1.2.1. ネームサーバー（正式な住所を「管理・登録」する台帳）

ドメイン名とIPアドレスの紐付けを記録した「台帳」を持っているサーバーです。 外部からの「このドメインのIPアドレス（住所）を教えてほしい」という問い合わせに対して、台帳の内容を確認して正しい情報を回答する役割を持ちます。
※補足：実務や専門書では「権威DNSサーバー」と呼ばれることもあります。

 

1.2.2. フルサービスリゾルバ（ユーザーの代わりに住所を「調べる案内役」）

ユーザーのパソコンやスマートフォンの代わりに、上記のネームサーバーへIPアドレスを問い合わせに行ってくれるサーバーです。
フルサービスリゾルバには、「一度確認した回答を、一定期間手元に記憶（一時保存）しておく機能」があります。再度同じ問い合わせがあった際、わざわざネームサーバーに聞き直す手間を省くことで、Webサイトの表示を高速化し、ネットワーク全体の負荷を軽減しています。
※補足：「DNSキャッシュサーバー」と呼ばれることもあります。

 

1.3. DNS情報の「反映待ち期間」とは

DNS切り替えを行う上で、最も慎重に扱わなければならないのが、変更した情報がインターネット全体に行き渡るまでの「反映待ち期間（プロパゲーション）」です。

 

1.3.1. なぜ切り替えにタイムラグが発生するのか

1.2で解説した通り、インターネットの世界ではフルサービスリゾルバが過去の案内情報を手元に記憶しているため、DNSの設定を新しく書き換えても世界中のすべての環境にその情報が即時に100%反映されるわけではありません。

 

1.3.2. 反映待ち期間中に起こる「アクセスの分散」

そのため、DNSを切り替えた直後は以下のようにユーザーの通信環境によって見ている情報が異なる状態が生まれます。

• 古い記憶（キャッシュ）を頼りにアクセスする人： 古いサーバーにつながる
• 最新の情報を受け取った人： 新しいサーバーにつながる

 

多くの環境では数分〜数十時間程度で新しい情報に切り替わりますが、一部の環境では古い情報が72時間程度残る場合があります。

2. DNS切り替えの注意点と事前準備

計画なしにDNS切り替えを行ってしまうと、Webサイトが一時的に閲覧できなくなったり、重要なビジネスメールが迷子になったりするリスクが生じます。
こうした移行時のトラブルを抑え、安全に新しいサーバーへの切り替えを完了させるためには、事前の準備が欠かせません。ここでは、実務において特に重要な3つの注意点と具体的な準備について解説します。

 

2.1. TTLの値を事前に短く設定する

2.1.1. TTL（キャッシュの有効期限）とは何か

 

 

第1章で解説した通り、案内役のフルサービスリゾルバは、過去の住所情報を手元に一定期間記憶（キャッシュ）しています。この「記憶しておく時間の長さ」の設定値が「TTL」です。
もし、このTTLが「86400秒（24時間）」に設定されたままDNS切り替えを行ってしまうと、案内役は最大で丸1日間古い住所をユーザーに案内し続けてしまいます。これでは新しいサーバーへの切り替えがなかなか進みません。

そこで、切り替え作業をスムーズに行うために、作業の数日前からTTLの値を短く変更しておくことが重要なポイントとなります。あらかじめ期限を「5分」などへ縮めておけば、フルサービスリゾルバがすぐに古い情報を忘れて、ネームサーバー（大元の台帳）へ新しい住所を確認しに行ってくれます。
また、TTLやDNSの設定を変更する前に、現在のネームサーバーやDNS設定の内容を、スクリーンショットやメモで残しておきましょう。万が一設定を間違えても、変更前の状態が分かれば元に戻しやすくなります。

 

2.1.2. 切り替え前後のTTL設定スケジュール（目安）

 

タイミング	TTLの設定値（目安）	目的と作業内容
切り替えの数日前（2～3日前）	300秒〜600秒	あらかじめキャッシュの有効期限を短くし、切り替え時の反映を早める準備をします。
DNS切り替え当日	短い値のまま維持	Webサイトの接続先に関するDNS設定を、新しいサーバーの情報へ変更します。
切り替え完了の数日後	3600秒〜86400秒	新サーバーへのアクセスが安定したことを確認後、DNSサーバーの負荷を軽減するために元の長さに戻します。

 

2.1.3. よくある質問：TTLが短いと、設定ミスもすぐに広がりませんか？

TTLが短いと、DNS切り替え後の情報がすぐに反映されてしまうので、万が一ミスした時に一瞬でサイトが映らなくなったりするのでは？とお考えではないでしょうか。
結論ですが、万が一設定を間違えてしまったときほど、TTLを短くしておいた方が安全です。

TTLが長いままだと、フルサービスリゾルバが「間違った住所」を何時間も記憶し続けてしまいます。途中で間違いに気づいてネームサーバーを直しても、TTLが切れるまではWebサイトが完全には復旧しません。
事前にTTLを5分などの短い時間に縮めておけば、万が一ミスをしても、台帳を修正すれば数分〜十数分程度で反映が進みやすくなり、迅速に復旧させることができます。

 

2.2. 新旧サーバーの並行稼働期間を設ける

2.2.1. なぜ古いサーバーをすぐに解約・停止してはいけないのか

DNSの設定を新しく書き換えても、世界中のインターネット環境にその情報が行き渡るまでには、数時間から最大で72時間（3日）程度の時間がかかります。
この期間中は、ユーザーの通信環境によって「新しいサーバーにつながる人」と「古いサーバーにつながる人」が混在する、非常に不安定な状態になります。

そのため、DNSを切り替えた直後に「もう使わないから」と古いサーバーを解約・停止してしまうと、旧サーバーにつながってしまったユーザーに対して、Webサイトが表示されないエラー画面が出てしまいます。

 

2.2.2. 並行稼働期間の目安

これを防ぐためには、新旧どちらのサーバーにアクセスされても同じようにWebサイトが表示されるよう、両方のサーバーを同時に動かしておく「並行稼働期間」を必ず設けてください。
少なくとも、新しいサーバーへのアクセスが安定したことを確認するまでは、古いサーバーを停止しないようにしましょう。余裕を持たせる場合は、切り替え後1〜2週間程度を並行稼働期間とすると安心です。

WordPressやECサイトなど、投稿・注文・会員登録といったデータが増えるサイトでは注意が必要です。新旧両方のサーバーで更新を受け付けると、データが別々に保存されることがあります。移行中の更新方法について、事前に取引先・制作会社・サーバー会社と連携を取り確認しておきましょう。

 

2.3. メールの取りこぼしを防ぐための対策

2.3.1. メール配送先（MXレコード）とキャッシュの影響

Webサイトの表示と同じように、メールの届け先に関する設定「MXレコード」もキャッシュの影響を受けます。
DNSの反映待ち期間中は、メールを送る側が参照しているDNS情報によって新しいメールサーバーか古いメールサーバーのどちらかに届くことがあります。

重要なビジネスメールの紛失（取りこぼし）を防ぐためには、新旧どちらのサーバーにメールが届いても受信できる体制を整えておく必要があります。

 

2.3.2. 実務における具体的なメール対策

対策①：旧サーバーの「Webメール機能」を活用する
多くのレンタルサーバーには、ブラウザ上でメールの送受信ができる「Webメール機能」が備わっています。 普段使っているメールソフト（Outlookなど）は新しいサーバーの設定に書き換えておき、切り替え期間中に古いサーバーへ迷い込んでしまったメールは、ブラウザから旧サーバーのWebメール画面にログインしてしばらくは直接確認するという方法です。

対策②：メールソフトに新旧両方のアカウントを登録する
お使いのメールソフトの設定画面から、新サーバー用のメールアカウントを追加し別登録します。（※ソフトの仕様上、同じアドレスを2つ登録できない場合もあるため注意が必要です）これにより1つのメールソフトで新旧両方のサーバーに届いたメールを同時に受信確認できます。

 

注意： 既存の設定を新しいサーバーの情報で上書きしてしまうと、古いサーバーに残されたメールを受け取れなくなってしまうため注意が必要です。
並行稼働期間が終了し、数日間にわたって古いサーバーへのメール到着が完全にゼロになったことを確認したうえで、古いサーバーの解約手続きに進むようにしましょう。

3. 【実例】DNS切り替えでよくあるトラブルと原因

DNS切り替え作業は、手順を一つ間違えるだけでWebサイトの閲覧やメールの送受信に大きな影響を与えます。ここでは、実際に現場でよく起こるトラブルの実例とその根本的な原因について詳しく解説します。

 

 

3.1. 初心者が陥りがちな「定番ミスと現象」まとめ

実務において発生しやすい設定ミスと、それによって引き起こされる代表的な現象をまとめました。トラブルの多くは、DNSレコードの設定ミス、あるいは反映待ち期間（プロパゲーション）に対する理解不足が原因で引き起こされます。原因は一つとは限らないため、表の内容はあくまで代表的な一例として捉え、様々な可能性を念頭に置いて確認を進めましょう。

 

発生する現象の例	考えられる主な原因（一例）	対策と注意点
画面に「サーバーが見つかりません」などのエラーが出る	・新しいWebサーバーのIPアドレスの入力ミス ・ネームサーバーでの紐付け設定ミス など	入力した数字や文字列に間違いがないか、ドメイン管理画面の設定を再確認しましょう。 万が一レコードを間違えてしまった際の対策としてTTLをあらかじめ短く設定しておきましょう。
画面に「プライバシーが保護されていません」などの警告が出る	・新しいサーバー側での「SSL証明書」の準備漏れ	新サーバー側でSSLの設定が正しく完了しているか、hostsファイルを設定するなどしてあらかじめ新サーバー側のWebサイトを確認しましょう。
送信元に「宛先が見つからない」などのエラーメールが返ってくる	・新しいサーバー側でのメールアカウントの作成漏れ ・DNSでのメール配送先（MXレコードなど）の設定ミス など	DNSの設定だけでなく、新しいサーバー側に社員全員分のメールアカウントが用意されているかを必ず確認しましょう。 メール関係のレコードがすべて漏れなく設定されているか確認しましょう。
トラブルは見当たらないのに、一部のメールが届いていない	・メーラー（メールソフト）の接続先を新サーバー情報で「上書き」したことによる、旧サーバー側のメールの確認漏れ など	メーラーの設定を早く書き換えすぎると、古いサーバーに届いているメールを見落とします。新アカウントを作成し旧アカウントと併用するか、切り替え期間中は旧サーバーの「Webメール」を併用するなどの対策をしましょう。
送信したメールが迷惑メールに入る、または送信を拒否される	メールの送信元を確認するための設定に不備がある	Gmailなどのサービスを利用している場合は、サービスの案内に従い、SPF・DKIM・DMARCなどの設定を確認しましょう。

 

3.2. 【実例1】当日は成功したように見え、翌朝に発覚した「時間差の罠」

とあるサーバー移行の現場で起きた事例です。

• 切り替え作業： 担当者がドメインの管理画面からDNSの切り替えを行った。
• 直後の確認： 自分のパソコン（オフィスのネットワーク）で確認したところ、Webサイトが正常に表示されたため安心した。
• 業務終了： 「無事に切り替えが成功した」と判断し、その日の業務を終えて帰宅した。
• 翌朝のトラブル： 翌朝出社すると、取引先から「サイトが見られない」「メールが届かない」という連絡が相次ぎ、トラブルが発覚した。

 

3.2.1. なぜWebサイトやメールが止まってしまったのか？

根本的な原因は「DNSの設定ミス」（入力間違いなど）でした。では、なぜ作業直後にそのミスへ気づくことができなかったのでしょうか。それには次の2つの理由があります。

キャッシュの影響： 切り替え直後、担当者のパソコンには変更前のDNS情報（キャッシュ）が残っており、正常に動いている古いサーバーのサイトが表示されていました。そのため、DNSの設定ミスに気づくことができませんでした。
その後、ほかの環境に残っていたキャッシュが順番に消え、DNSで設定した間違った接続先が参照されるようになったことで「サイトが見られない」という問題が広がりました。

ダブルチェックをしていなかった： 作業直後、オフィスの固定回線（PC）だけで確認を終えてしまい、スマートフォンなどのキャリア回線を使った別環境からの確認テストを怠っていました。

 

3.2.2. よくある落とし穴：hostsファイルの設定消し忘れ

事前テストのためにパソコンの「hostsファイル」を書き換えて新サーバーへ接続させていた場合、その設定を消し忘れたままDNS切り替えおよびチェック作業をしてしまうケースが多発しています。
自分だけはhostsファイルの設定のおかげで新サイトが見えているため、DNS切り替えが成功したと錯覚し、一般ユーザーには旧サイトが表示されたり、エラー画面が表示されている事に気づけない危険な盲点です。

 

3.3. 【実例2】サイトは表示されるのにシステムが動かない！「ネームサーバー」の変更ミス

DNS切り替えを担当したWeb担当者が、ドメインの管理画面の仕様とDNSの仕組みの理解が不足していたことで起きた事例です。

• 申し込み時の想定： サーバー引っ越しに伴い、新サーバー会社のネームサーバー（台帳）を利用する前提で申し込んだ。
• サーバー会社からの指示： サーバー会社から、自社のネームサーバー情報（例：ns1.example.jp など）が案内され、「ネームサーバーを切り替えて利用してください」と連絡があった。
• 方針の変更： ところが後日、取引先のWeb担当者から「現在のドメイン会社（お名前.comなど）のDNSサーバーをそのまま残して運用したい」と連絡が入った。
• 担当者の誤認： 担当者は、新サーバー会社から送られてきたネームサーバー情報（例：ns1.example.jp など）を、現行のDNSサーバーで書き換えてしまった。
• 不具合の発生： Webサイト自体は一見問題なく表示されたものの、問い合わせフォームが動かない、サイト内のシステムの一部でエラーが出るなどの不具合が発生した。

 

3.3.1. なぜシステムの一部に不具合が起きてしまったのか？

原因は、DNSサーバーの仕組みとレコードに関する理解不足による設定ミスです。
実務では、Webサイトを入れる「Webサーバー」と、住所の台帳である「DNSサーバー」を別々の会社で運用しているケースが多くあります。今回のケースでは、現在利用しているDNSサーバーをそのまま使い続けるべきだったため、ネームサーバー自体を変更してはいけませんでした。

新サーバー会社のネームサーバーに切り替えたことで、Webサイトを表示する基本設定はサーバー会社側で設定されていたため、サイト自体は映りました。しかし、外部のフォームやECサイトのカート、セキュリティシステムなどを動かすための「特殊な設定データ（レコード）」がすべて抜け落ちてしまったため、システムの一部が動かなくなってしまいました。

 

3.3.2. 管理画面の仕様：ネームサーバー変更とレコード設定の違い

正解は、「ネームサーバー（台帳の場所）は変更せず、現行のDNSサーバーの中身（必要なデータ）だけを書き換える」ことでした。
実務でDNSの設定を行う際は、以下の2つを明確に区別して考える必要があります。ドメイン管理会社のコントロールパネル（管理画面）でも、これらを設定するメニューは全く別の場所に分かれているのが一般的です。

• ① ネームサーバーの変更メニュー：ドメインが利用するネームサーバー（例：ns1.example.jp など）を変更するメニュー
• ② DNSレコードの設定メニュー： DNSサーバー内に登録する「データの中身」（Webの住所やメールの接続情報、外部システム用の設定など）を個別に追加・編集するメニュー

 

3.3.3. 実務での正しい対応手順と防衛策

実務でこのような失敗を防ぐためには、以下の手順を意識する必要があります。

• 事前のチェックを徹底する： 申し込みをする前に、現在のDNSサーバーはどこにあるか、特殊なレコード（外部システムやセキュリティ用の設定）が登録されていないかを確認します。
• 新サーバー会社に必要なデータを請求する： 申し込み時に「他社のDNSサーバーを使う」を選択するか、後から変更になった場合は、サーバー会社に「現在のDNSサーバーをそのまま利用するので、設定に必要な細かいレコードを教えてほしい」と申し出ます。
• 必要な部分だけを書き換え、外部用は残す： 共有されたレコードを現行のDNSサーバーに追記・修正します。この際、既存の外部システム用のレコードを誤って削除しないよう注意が必要です。

 

実務のポイント：どのレコードが「Web」か「メール」の領域かを見極める

サーバー移転の際、「メールはすでにGoogle WorkspaceやMicrosoft 365のシステムを使っているため、今回はWebサーバーだけを引っ越す」というケースは非常によくあります。
新サーバー会社から送られてくるデータはWebとメールのレコードが一式すべて送られてくるケースが多いです。送られてきたデータのうち、どれがWebサイトの切り替えに必要なデータなのかを事前に正しく把握しておくことがトラブルを防ぐ重要なポイントです。

4. DNS切り替え後に正しく反映されているかチェックする方法

DNS切り替えが完了したら、新しい環境へ正常に切り替わっているかをチェックする作業に移ります。
万が一これまでの工程で設定ミスや準備不足があったとしても、この段階でいち早く異常に気づくことができれば、大惨事になる前に迅速にリカバーできます。

 

 

4.1. Webツールを使った反映確認

作業を行ったパソコンの回線環境はキャッシュが残りやすいため、まずは自身の環境に左右されない「Web上の確認ツール」を使って、客観的な反映状況を調べるのが有効なアプローチです。
※ただし、これらのWebツール自体への反映にも若干のタイムラグ（数分〜数時間程度）が発生することがあります。

 

4.1.1. ネームサーバー（台帳の場所）を変更した場合：Whois検索

大元のネームサーバー自体を新サーバー会社のものへ切り替えた場合は、Web上で無料で使える「Whois検索サービス」を利用します。ドメイン名を入力して検索し、出力された情報の「Name Server」の項目が新サーバー会社のものに変わっていれば、ネームサーバーの変更手続きが反映され始めています。

 

4.1.2. DNSレコード（データ中身）を書き換えた場合：DNSチェッカー等のWebサイト

ネームサーバーは変えず、既存のDNSサーバーの中でデータ（AレコードやMXレコードなど）だけを書き換えた場合はWhoisを見ても情報は変わりません。この場合は「DNS Checker」などの世界各地の代表的なDNSサーバーから確認できます。

調べたいドメイン名を入力して検索すると、世界中の案内所で新しいIPアドレスへの書き換えが今どれくらい浸透しているかが一目でわかります。もし時間を置いても全く意図しないIPアドレスが表示され続ける場合は、入力ミスの可能性を疑い設定の再確認・修正などに移ることができます。

 

4.2. 「hostsファイル」の設定を元に戻し、複数環境でのサイト確認

4.2.1. テストで使ったhostsファイルの設定を元に戻す

もし切り替え前の事前テストのために、パソコンの「hostsファイル」を書き換えて新サーバーへ接続させていた場合は、必ず記述を削除して元の状態に戻してください。消し忘れると、切り替えが失敗していても自分だけは正常に見えてしまうためトラブルの発見が遅れます。

 

4.2.2. スマートフォンなどの「キャリア回線」で確認する

hostsファイルをきれいにした状態で、オフィスの固定回線だけでなくスマートフォンのキャリア回線を使った別環境から実際にサイトにアクセスし、エラーなく正常に表示されるか確認します。

 

4.2.3. 問い合わせフォームやサイト内の機能を確認する

トップページが表示されていても、サイト内のすべての機能が正常に動いているとは限りません。問い合わせフォームの送信、管理画面へのログイン、会員登録、商品の購入など、サイト内の主な機能も実際に操作して確認しましょう。
特に問い合わせフォームは送信後の完了画面だけでなく、管理者宛てと利用者宛てのメールが正しく届いているかまで確認することが重要です。

 

4.3. メールの送受信テストと「Webメール」の監視

4.3.1. 新サーバーでの送受信テスト

メールはDNSのキャッシュの影響を非常に受けやすいため、切り替え直後は送受信の反映に時間がかかることも多いです。少し時間を置きつつ、以下の2つのテストを行いましょう。

• 受信テスト： 新サーバーに設定した自社のメールアドレス宛てに、個人のGmailなどの「別ドメイン」からメールを送り、新サーバー側で正しく受信できるか確認します。
• 送信テスト： 新サーバー情報を設定したメーラー（Outlookなど）や新サーバーのWebメールから外部へメールを送り、問題なく相手へ届くか確認します。

 

新しいサーバー側の設定（メールアカウントの作成漏れやDNSの設定など）に間違いがあった場合は、送信元へ「メールが届きませんでした」と伝えるエラーメールが返ってきます。エラーメールが返ってきた場合は書かれている内容を確認し、メールアカウントやDNS設定に間違いがないか見直しましょう。

 

4.3.2. 旧サーバーに届くメールの確認

切り替え直後の数日間（反映待ち期間）は、メールを送る側が参照しているDNS情報によって、古いメールサーバーへ届く状態が続きます。 メールの取りこぼしを防ぐため、以下の方法で古いサーバー側の新着メールも合わせて確認してください。

• 旧アカウントが残っている場合： メーラーに古いサーバー接続用のアカウントが残っているまたは追加できている場合は、そちらの受信ボックスを確認・回収します。
• アカウントを追加できなかった場合： すでに設定を新しい情報へ上書きしてしまった場合やアカウントを追加できなかった場合は、ブラウザから旧サーバーのWebメール画面を開いて直接確認・回収します。

5. まとめ

DNS切り替えは、目に見えない仕組みだからこそ難しく感じられますが、押さえるべきポイントさえ知っていれば決して怖い作業ではありません。
サーバー移行を安全に進めるための鍵は「数日前からの入念な事前準備」「DNSの仕組みを正しく理解すること」「切り替え後の確実なチェック」の3つです。

万が一設定ミスが発生しても事前準備と確認手順が整っていれば、問題を早く発見し影響を抑えながら復旧につなげられます。本記事の内容を役立てていただき、安全でスムーズなサーバー移行を進めてください。