ドメインのレジストラを移管した直後に、Webサイトが見えれば作業完了だと考えるのは危険です。レジストラの管理先が変わっても、ネームサーバー、DNSゾーン、Webの宛先、メールの受信先、TLS証明書は別々の層で動いています。どこか一つだけ古い設定を返すと、利用者の地域や利用するリゾルバーによって結果が分かれ、サイトは見えるのにメールだけ届かない、またはAPIの一部だけ接続できない状態になります。移管を作業ではなく検証可能な切替として扱い、変更前の事実、変更後の事実、まだ確認できない事実を分けて記録しましょう。
まず移管の種類と権限を確定する
「移管」という言葉には、レジストラ間の移管、登録者の変更、指定事業者の変更、DNSホスティングの変更、Webサーバーの移転が混在します。最初に何が変わり、何を変えない契約なのかを一覧にしてください。gTLDのレジストラ間移管では、登録者の承認、Auth-Code、移管禁止ステータス、登録直後や登録者情報変更後の制限などが関係します。ICANNのFAQも、認証コードが不正な移管を防ぐために使われることや、一定期間のロックが移管を妨げる場合を説明しています。JPドメイン名など別の制度が適用される名前は、該当するレジストリや指定事業者の手順を優先してください。
- 対象となる正規化済みドメイン名とTLD
- レジストラ、登録者、管理アカウントの変更範囲
- Auth-Codeや移管承認の完了日時
- 移管前後のステータスと次に解除できる制限
- DNSゾーンを管理する権限者と緊急連絡先
- Web、メール、API、証明書の各担当者
切替前の基準値を保存する
切替の成否を判断するには、変更前の状態が必要です。AとAAAAの値、CNAMEの最終名、NSの委任先、MXの優先順位、TXTにあるSPFや検証値、CAA、DNSSECの状態を確認時刻とともに保存します。Webはhttpとhttps、wwwありとなし、代表的な古いURL、ログイン、決済、問い合わせの応答とリダイレクトを記録します。メールは送信元ドメイン、受信先MX、SPF、DKIM、DMARCの公開状態を別々に残します。レコードが空だったことも重要な観測値です。記録がない状態で切替後の差分を推測すると、意図した変更と事故を見分けられません。
{
"domain": "example.jp",
"checked_at": "2026-09-28T09:00:00Z",
"registrar_transfer": "completed",
"nameservers": ["ns1.example.net", "ns2.example.net"],
"web": "pending_verification",
"mail": "pending_verification",
"unknowns": ["dnssec_key_rollover"]
}ネームサーバーと権威DNSを順番に確認する
次に、レジストリが返すネームサーバーと、そのネームサーバーが返すゾーンの内容を分けて確認します。レジストラの画面で新しいNSを保存しただけでは、権威DNSが正しいゾーンを返すとは限りません。親側の委任が旧NSのまま、片方のNSだけ新しい、あるいは新しいゾーンにMXや検証用TXTが欠けていることがあります。複数の権威NSへ直接問い合わせ、SOAのシリアル、NS集合、主要レコードの値とTTLを比較してください。片方だけが異なる場合は、伝播中と決めつけず、ゾーン同期や委任の設定を確認します。
公開リゾルバーからの結果も、権威DNSの回答と同じ意味ではありません。キャッシュに残った旧値、NXDOMAIN、SERVFAIL、タイムアウトを別の状態として記録し、検索元と時刻を保存します。TTLはすべての利用者が同時に更新する約束ではなく、既存キャッシュがいつまで残り得るかを考える材料です。切替の判断は一つの地域、一つのブラウザー、一回の検索だけで下さず、権威回答と複数地点の公開結果が期待する状態に近づいたことを確認します。
WebとTLSをホスト名ごとに検証する
Webの確認では、代表ページが200を返すことだけを合格条件にしません。www、API、管理画面、画像配信、コールバックなど実際に使われるホスト名を台帳から取り出し、HTTPからHTTPSへのリダイレクト、正規ホストへの転送、主要なパス、レスポンスヘッダーを確認します。DNSが新しい宛先を返していても、仮想ホスト設定が旧名のままなら別サイトを返すことがあります。逆に、403や認証要求はサービス停止と同義ではありません。期待する認証状態とエラー状態を事前に定義し、通常のアクセス制御を障害と誤認しないでください。
TLSでは対象ホスト名との名前一致、有効期間、SAN、証明書チェーン、TLS接続を確認します。移管と同じ日に証明書を交換するなら、変更を一度に増やさず、登録、DNS、Web、証明書のどの層で失敗したか追跡できるようにします。証明書が返ったことは所有権やアプリケーションの正常性を保証しないため、TLSの観測とHTTPの観測は別々に保存します。
メールを止めないための確認
メールはDNS移管で最も見落とされやすい領域です。MXが新しい受信サービスを向いているかだけでなく、優先順位、サブドメインのメール、SPFの許可範囲、DKIMセレクター、DMARCポリシーとレポート先を確認します。受信テストは一つの宛先だけで済ませず、社内外の経路、転送、バウンス処理を含めます。送信側の認証が旧DNSのTXTに依存していると、サイトが正常でもメールの到達性が変わります。TXTの削除や統合は、現在の送信サービスを確認してから行い、未知の値を意味なしと決めつけないことが安全です。
切替判定、切戻し、移管後の再確認
合格条件は、すべての検索結果が一瞬で同じになることではありません。所有者が意図したNSとゾーンが権威DNSから返り、重要ホストのWebとTLSが期待どおりで、メールの送受信経路が確認でき、残る不明点に期限と担当者が付いていることを条件にします。逆に、片方の権威NSが異なる、重要なMXが消えた、対象ホストの証明書名が一致しない、管理権限を回収できない場合は切戻しまたは作業停止を選びます。切戻しもDNSとWebだけでなくメールと認証設定を含む手順にしてください。
移管完了の通知を受け取った日で作業を閉じず、短い間隔の再確認と翌営業日の棚卸しを行います。確認結果には、対象、時刻、観測元、期待値、実測値、状態、証拠、次の行動を持たせます。候補が一つなら手作業でも、複数の顧客ドメインや拠点を扱うなら同じ項目を機械的に比較できるプロファイルが必要です。DomScanのDNS検索、DNS履歴、ドメインプロファイルを使って切替前後の情報をまとめ、必要に応じてAPIで台帳やチケットへ取り込むと、確認漏れを減らせます。結果が不明なときは成功に寄せず、再確認が必要な状態として残してください。