VPSの引っ越しが終わって、DNSの画面を開く。Aレコードを変えるのか、ネームサーバーも変えるのか。ここで手が止まるなら、先に移すものを分けておきましょう。
Webの置き場所だけを変えるなら、DNSの管理先まで同時に移す必要があるとは限りません。DNSの管理先を変える場合は、Web以外のメールや認証用のレコードも確認します。自分なら、同時に変える範囲をできるだけ小さくします。失敗した場所と戻す場所が見えやすいからです。
Webの移転とDNSの移転を分ける
Webの行き先だけを移すならA・AAAAなどの対象レコード、DNS管理そのものを移すなら参照するネームサーバーとゾーン全体を確認します。「ConoHaへ移す」という言葉だけで、変更する場所を決めないでください。
| 今回移すもの | 主に確認する対象 | 変更前に控えるもの |
|---|---|---|
| Webを動かすVPSだけ | 現在使われているDNSのWeb向けA・AAAA・CNAME | 旧Web向けの値とTTL、対象の名前 |
| DNSを管理する場所だけ | レジストラ側の参照NSと、移管先のレコード一式 | MX・TXT・各サブドメインを含む全体 |
| WebとDNSの両方 | Webの行き先とDNSの参照先 | どちらの変更を先に戻すか |
| Webだけ移してメールは残す | Webのレコードとメール配送・認証の依存関係 | メールの行き先と認証用の値 |
ConoHaのDNS操作案内と、Cloudflareのレコード種別の解説を2026-10-25に照合し、変更範囲ごとに整理しました。
ConoHaの画面で保存しても、ドメインが参照するDNSの管理先が別なら公開先は変わりません。
AはIPv4、AAAAはIPv6の行き先を表します。MXはメール配送先、TXTはメール認証などに使う文字列を置く種類です。Webだけのつもりでゾーンを作り直し、MXやTXTを落とさないようにします。
たとえばMXの配送先が mail.example.com で、今回その名前のAやAAAAも新しいVPSへ向けるなら、MXの値を残していてもメールの接続先は変わります。これは説明用の名前です。Webだけを移すときは、MXが指すホスト名をたどり、そのA・AAAAまで以前のメール環境を指しているか照合します。「MXを触っていないから大丈夫」で確認を止めないでください。DNSレコードの役割を説明する資料として参照しており、Cloudflare独自の設定値はConoHaへ当てはめていません。
V2とV3のNSをコピーし間違えない
ConoHaの公式案内では、バージョン2.0と3.0で既定のネームサーバーが異なります。別の環境の記事や過去の設定をコピーする前に、自分が使う環境を確かめます。
| ConoHaの環境 | 公式案内のネームサーバー |
|---|---|
| バージョン2.0 | ns-a1.conoha.io、ns-a2.conoha.io、ns-a3.conoha.io |
| バージョン3.0 | a.conoha-dns.com、b.conoha-dns.org |
公式の環境別の案内（2026-10-25確認）を参照してください。この表はDNS管理をConoHaへ移す場合の確認材料です。WebサーバーをConoHa VPSへ移すだけで、必ずこのNSへ変更するという意味ではありません。
現在の権威DNSへWebの新しい値を設定する構成も考えられます。どのDNSが実際に答えるかを確かめてから、操作する管理画面を一つに決めます。使われていない画面を何度保存しても、利用者の行き先は変わりません。
DNSSECを使っている場合の移行操作はここでは扱いません。レジストラと移管先の公式移行手順も確認し、署名に関わる設定を含めて計画してから進めてください。
切り替える前に、新しいVPSだけで確かめる
公開前のテスト、メールを残す範囲、切替後の書込みを一つの予定表へ並べます。ファイル転送の後に残る作業も、ここで確かめましょう。
| 段階 | 確認すること | 次へ進む条件 |
|---|---|---|
| 新環境を準備 | アプリ・画像・設定・DBがそろうか | 新環境だけを確認する経路がある |
| 公開前テスト | ログイン・保存・メール・外部連携 | 必要な操作と受信結果を確かめた |
| 切替直前 | 最後の書込みをどこへ集めるか | 更新停止または同期の方法を決めた |
| 切替後 | 新旧のアクセスと新しいデータ | 新環境の正常動作と書込み先が分かる |
| 旧環境を終了 | 戻す必要と残った依存 | 旧環境に必要なデータや通信が残っていない |
これは移行手順を組むための確認票で、実際にVPSを契約して移行した記録ではありません。新環境だけの確認経路は、使用するWebサーバーやTLSの構成に合わせて用意します。確認用のURLが開いたことだけで、本番のドメインでも証明書やログインが動くとは決めません。
TTLを短くしても、全員が一斉には切り替わらない
TTLはDNSの応答をキャッシュする期間です。変更前に長いTTLで控えた利用者がいれば、新しい設定を保存しても旧情報が残る場合があります。短くする作業も、切替の瞬間に行えばそれ以前のキャッシュまで消せる、というものではありません。
CloudflareのTTL解説（2026-10-25確認）は、長いTTLほど変更反映に時間がかかり、利用者側のキャッシュにも左右されると説明しています。DNSの切替時間は、変更前のTTLや利用者側のキャッシュによって変わります。
そこで旧環境をすぐ消す前に、旧環境へ来ている通信が残っていないかを見ます。AAAAが残っていてIPv6だけ旧VPSへ向く場合なども、設定値と接続経路を分けて確認したいところです。「自分のパソコンで新しい画面が見えた」を、利用者全員の切替完了にしないためです。
DNSを戻すだけでは、投稿や注文は戻らない
切替後に新しい環境へ投稿や注文が入った場合、DNSを旧VPSへ戻しても、そのデータが旧環境へ自動で移るわけではありません。これはDNSの行き先変更と、アプリのデータ更新を分けると見えてくる問題です。
戻す可能性があるなら、切替後の書込みを止める担当、回収するデータ、旧環境へ反映する方法も先に決めます。戻したとたんに古い状態へ戻り、新しい注文が見えなくなるような計画は避けたいです。
書込みを整理する方法がない、短い停止時間も取れない、DNSとメールの管理先も分からない。この状態では一度に移す範囲が大きすぎます。管理を任せるか、段階を分けた移行へ見直します。
Webだけか、DNS管理もか。最初にこの二つを分け、現行の値を控え、新環境での確認と書込みの戻し方を準備する。そのうえで切り替えれば、何を見て完了とするかが決まります。