何を移行するのかを明確にする
レジストラの変更、権威 DNS サーバーの変更、Web サイトの移転、メール事業者の変更は別々の作業です。どれを依頼するか、開始前に書き出してください。Web ホスティングの変更だけで、メールまで移す必要が生じるわけではありません。
引き継ぎ表を、ドメイン管理、DNS、Web サイト、メールの四項目に分けることを勧めます。それぞれに旧事業者、新事業者、担当者、必要なアクセス権を記載します。「ドメインの移行」という曖昧な表現を、具体的な変更範囲にできます。
現状を保存
名前、値、TTL、サービス、担当者を記録。
接続先を切り替え
合意した変更を実施し、サービスの動作を確認。
旧環境を整理
参照先と権限を整理してから旧リソースを解放。
確認可能な新しい状態
新しい接続先を確認し、必要なメールサービスを維持し、廃止したサービスへの意図しない参照を残しません。
管理された移行のための作業モデルです。台帳、切り替え、旧環境の終了を個別に承認します。
メールなどの依存関係を明示して残す
DNS の自動インポート結果は既存の台帳と照合します。Cloudflare は、利用するサービスのレコードを確認し、メール設定値を事業者へ確認するよう案内しています。
変更前に旧ゾーンを保存し、用途不明のレコードには確認担当者を付けます。新しい制作会社が、複雑な TXT 値の必要性を推測するべきではありません。関係者へ根拠のある判断を依頼します。「不明」は削除の十分な理由になりません。 [1]
表は左右にスクロールできます。
| レコード・対象 | 移行前の確認 | 受入確認 |
|---|---|---|
| Web の A・AAAA・CNAME | どの名前を新サイトへ向けるか。 | 主ドメイン、www、合意したサブドメインを確認。 |
| MX とメールの接続先名 | 既存のメール事業者を維持するか。 | 承認されたテストで送受信を確認。 |
| SPF・DKIM・DMARC | どの稼働中サービスが必要としているか。 | 送信経路ごとにドメイン認証を確認。 |
| サービス・所有確認用の値 | どのサービスとアカウントに属するか。 | 維持、置換、根拠のある削除を判断。 |
| DNSSEC と委任 | サーバーや署名鍵が変わるか。 | 名前解決と信頼の連鎖を別途確認。 |
短い TTL だけでは移行計画にならない
TTL は DNS 応答をキャッシュできる時間を示します。後から短くしても、保存済みの応答が遡って消えるわけではありません。
これは計画例であり、一律の待機時間ではありません。あるレコードを 3,600 秒から 300 秒へ変更するとします。切り替えと同時に短縮しても、以前の最大 1 時間のキャッシュはなくなりません。事前に変更し、合意した移行期間は旧サービスを維持します。別のキャッシュ層、サーバーの委任、DNSSEC には個別の時間条件があり得ます。 [2]
旧サブドメインを解放済みサービスへ向けない
廃止後に第三者が取得できるリソースへの DNS 参照が残ると、サブドメインの乗っ取りにつながる場合があります。ただし、接続先の名前解決に失敗しただけでは、乗っ取り可能とは証明できません。
廃止するサービスごとに、名前、接続先、旧アカウント、担当者、終了判断を記録します。参照を計画的に変更・削除し、残るキャッシュ期間を考慮してから旧リソースを解放します。その後、アプリや文書内のリンクも確認します。同じ名前を正当に使う新サービスを誤って止めないようにします。 [3]
DNSSEC も変更計画に含める
DNS サーバーの変更時には、親ゾーンの DS レコードと DNSSEC 鍵の整合が必要です。古い信頼の連鎖が残ると、検証するリゾルバーが SERVFAIL を返すことがあります。
具体的な手順は DNS 担当者が計画します。事業者によっては、署名を有効にしたまま連携して移行できます。それ以外では、一時的な無効化と再有効化を同じ変更計画に含めます。DNSSEC を無効のまま残すことは、適切な完了ではありません。Web のみを移転し、DNS 運用者や鍵が変わらない場合は、信頼の連鎖への変更が必要かを先に確認します。 [4] [5]
受入確認を終えてから作業を閉じる
新しいトップページの画像は、受入確認の一部にすぎません。確認日時、担当者、復旧方法を決めます。記録では確認済みの項目と未完了の項目を区別し、未実施のメールテストは未完了として残します。
- 変更前後の DNS 台帳を比較する。
- サイト、www、リダイレクト、合意したサブドメインを開く。
- 承認されたメールテストと送信元認証を記録する。
- 影響がある場合は DNSSEC と委任を確認する。
- 旧参照を整理してから不要なリソースを解放する。
- 不要になった制作会社の権限と API キーを失効させる。
- 新しい担当者と再確認日を記録する。
記入用 DNS 移行引き継ぎシート
移行の内容を共通の記録にまとめます。CSV テンプレートには、ウェブサイト、メール、所有権などの確認レコード、DNSSEC の項目があります。実際に使用している DNS レコードごとに行を追加してください。テンプレートにテスト結果は含まれず、問い合わせや設定変更も実行しません。
現在の値と変更予定値は、該当する事業者のアカウントで確認します。承認、期待する結果、実際に得られた証拠を記録してください。未実施のテストは未確認のままにします。TTL が短いことやホームページが表示できることだけでは、移行全体の受入確認にはなりません。
記入後のファイルは、ご自身の保護された保存先で管理してください。パスワード、API キー、その他の認証情報は記入しないでください。インフラの詳細を公開の問い合わせフォームで送信しないでください。 [1] [2] [3] [5]
表は左右にスクロールできます。
| 対象 | 変更前に記録すること | 変更後に確認する証拠 |
|---|---|---|
| ウェブサイトと www | 名前、現在と変更予定の接続先、担当者 | 到達性と合意したリダイレクト |
| メール | 送信経路ごとの MX、SPF、DKIM、DMARC | 承認済みの送受信テストと送信ドメイン認証 |
| その他のサービス | 確認レコードの目的と管理アカウント | 維持、変更、削除の確定した判断 |
| DNSSEC と廃止するサービス | 委任、対象の鍵、廃止と切り戻しの計画 | 名前解決の整合性と旧参照の適切な整理 |
ネームサーバー変更後にメールが届かない場合
まず受信、送信、特定の送信サービスのどこに影響があるかを区別し、時刻と正確なエラーを記録します。新しい権威DNSゾーンを、保存した旧記録とメール事業者の要件に照らして確認します。
推測で複数の保護設定を変えないでください。配送障害は、DMARCの一律無効化や用途不明のレコード削除の根拠にはなりません。原因、対象を絞った修正、実測した結果を別々に記録します。 [1] [2] [4] [5]
表は左右にスクロールできます。
| 観測した状況 | 最初に確認する点 | 次に確かめること |
|---|---|---|
| Webサイトは開くが受信できない | 現在のゾーンのMXと宛先ホスト名は正しいか。 | 許可された受信テストと事業者の稼働状況を確認する。 |
| メールは届くが認証に失敗する | SPFとDKIMは対象の送信サービスに対応しているか。 | 元のヘッダーでSPF・DKIM・DMARCアラインメントを確認する。 |
| DNSがSERVFAILを返す | 委任・DSレコード・DNSSEC署名が整合しているか。 | キャッシュ待ちだけでなく信頼の連鎖を確認する。 |
| 一部のネットワークだけ旧値が見える | 権威サーバーの応答とキャッシュ応答を区別する。 | TTL・照会時刻・リゾルバーを記録する。 |