ドメインのレジストラ変更：移管ロック、認証コード、DNSの継続を確認する

ドメインを一つのアカウントでまとめて管理したい、あるいは操作しやすいレジストラに変えたい場合、通常はWebサイト全体を作り直す必要はありません。主に行うのは、ドメイン登録の管理を別のサービスに引き継ぐことです。関連するDNSサービスが継続して動作すれば、既存のWebサーバーやメールボックスは元の場所に残せます。

引き継ぎは二つの確認表に分けると整理できます。一つはドメインの管理者、有効期限、更新方法。もう一つは、その名前が現在Webサイトやメールをどこへ向けているかです。両方を確認すれば、新しいアカウントにドメインは表示されるのに、顧客がサイトを開けず、メールも送れないといった事態を避けやすくなります。

必要なのがレジストラ移管か確認する

サーバーの変更、DNS管理サービスの変更、ドメイン登録者の変更、別のレジストラへの移管は、それぞれ異なる操作です。既存のドメインを新しいサーバーに接続するだけなら、Webサイト用のDNS設定変更で済む場合があります。同じドメインを別の管理プラットフォームに移したいときに、レジストラ移管を検討します。目的を先に確認し、不要な変更を同時に始めないようにしましょう。

新しいレジストラが、利用中のドメインの末尾と現在の状態に対応していることも必要です。移管料金だけでなく、その後の更新、通貨、支払方法、DNS機能も確認します。ネームサーバーの利用方法に独自の条件を設けるサービスもあります。初年度の価格だけを比べて、移管後も既存の設定をすべて維持できるとは考えないでください。

1. 現在のレジストラ、ドメインの末尾、有効期限、管理アカウントを確認する。
2. 新しいレジストラが対象ドメインを受け入れることを確認し、移管と更新の条件を読む。
3. DNSも同時に変更するか決める。変更する場合は、名前解決の引き継ぎを別途計画する。

解除ボタンだけでなく、移管条件とロック理由を見る

ICANNのポリシーが適用される一般的なトップレベルドメインを例にすると、確認日時点で有効な公式ポリシーには、新規登録後、前回のレジストラ移管後、特定の登録者変更後に関する六十日の制限が記載されています。それぞれ条件や選択可能な対応が異なるため、「六十日経過した」ことだけで、あらゆるドメインが必ず移管可能になるとは判断できません。

登録者が通常の操作で解除できる移管ロックと、ポリシー、紛争、その他の状態による制限も別です。アカウントに表示される理由と移管可能日を確認し、情報が食い違う場合は現在のレジストラに説明を求めます。すでに移管を準備しているなら、影響を読まずについでに登録者情報を変更しないでください。変更内容によっては新たなロックが発生します。

本記事のICANNの手順を、すべての国別コードドメインにそのまま適用することはできません。.tw、.台灣などは、管理機関と受付レジストラの現行規則を確認してください。有効期限切れ、復旧期間、紛争などの状態なら、まずその状態に必要な対処を把握してから移管を計画します。サイトが停止してから、レジストラ変更で解決しようとしないことが大切です。

移管前にDNS設定とメールの依存関係を保存する

ネームサーバー、Webサイト用のAまたはAAAAレコード、CNAME、メール用のMX、関連するTXTレコードを読みやすい一覧として保存します。サブドメインや認証用レコードも含めてください。この一覧が引き継ぎの基準になるため、現在値、用途、担当サービスを記録します。トップページのスクリーンショットだけでは、後からどのメール認証レコードが抜けたのか判断できません。

ネームサーバー名が変わらなくても、移管元のレジストラが移管後もDNSを提供し続けるとは限りません。例えばNamecheapの公式移管案内では、外部で管理するDNSと、移管元レジストラの標準DNSを区別しています。元のサービスに、移管後も名前解決を利用できるか確認しましょう。DNSを変更する必要があれば、完全なレコードを先に作成して検証し、その後に登録管理の移管を進めます。

DNSSECを有効にしているドメインや独自のネームサーバーを使うドメインは、それらの設定も別途記録し、新旧サービスの文書に従って引き継ぎます。すべてのセキュリティ機能を無条件で無効にすることを共通手順にしないでください。何を更新し、いつ確認し、どう通常の保護状態に戻すかを理解しておきます。不慣れであれば設定一覧を両方のサポートに提示し、確認を依頼します。

認証コードを取得し、新しいレジストラで申請する

認証コードはAuth-Code、AuthInfo、EPP code、transfer codeなどと呼ばれ、移管の権限確認に使われます。現在のレジストラのアカウント手順で取得し、必要に応じて操作可能な移管ロックを解除します。コードを入力するのは、正規のものと確認できた新しいレジストラの公式移管画面だけにしてください。公開するスクリーンショットや一般的な共同作業文書に載せないようにします。

新しいレジストラでドメイン名を省略せず入力し、綴りと末尾を確認してから認証コードを入力し、支払項目を確認します。移管中は通知への確認操作や例外対応が必要になる場合があります。公式アカウントへ直接ログインして状態を確認し、現在の連絡先メールで受信できるようにしておきましょう。メールが届かない場合は、迷惑メールやアカウント内通知を確認し、申請を何度も送信しないでください。

1. 現在のレジストラにログインし、移管条件を確認して認証コードを取得し、手順に従って移管ロックを解除する。
2. 新しいレジストラの移管画面にログインし、ドメイン、管理サービスの条件、料金、申請内容を確認する。
3. 送信後は注文番号や案件番号を保存し、両サービスの状態と必要な確認操作を追跡する。

実際の状態に応じて待機や失敗に対応する

支払完了、申請送信済み、レジストラ変更済みは、それぞれ異なる状態です。課金されたからといって元のアカウントを閉じたり、一日変化がないだけで取り消して最初からやり直したりしないでください。サービスが示す処理見込み時間を基準に確認します。時間を超えた場合は案件番号、状態、エラーメッセージを伝え、サポートが同じ申請を調べられるようにします。

認証コードが誤っていると表示されたら、余分な空白がないか、最新のコードを使っているか、正しいドメインの欄に入力したかを確認します。ロック、登録者の確認、ドメインの状態が原因なら、その原因に対応してください。コードを再発行するだけでは解決しない場合があります。公式手順で必要とされない限り、同じドメインの移管を複数のレジストラへ同時に申請しないでください。

移管中に既存のサイトやメールが突然使えなくなった場合、まずDNS応答と元のDNSサービスの状態を確認し、その後にサーバーを調べます。登録管理の移管はWebサイトのコンテンツのデプロイではなく、障害を示す証拠も異なります。発生時刻と変更履歴を残すと、申請、DNSの引き継ぎ、その他のサービスのどこに問題があるか判断しやすくなります。

完了後に管理、名前解決、請求を確認する

新しいレジストラのアカウントで対象ドメインを管理できることを確認し、適切な公式照会サービスでレジストラの状態も確かめます。次にネームサーバーと重要なレコードを確認し、異なるネットワークからサイトを開き、外部のメールボックスから送信して返信も試します。移管完了通知が示すのは登録管理の引き継ぎであり、サイトとメールの動作確認を代替するものではありません。

有効期限、自動更新、支払方法、連絡先、アカウント保護を再確認します。移管料金に登録期間の延長が含まれるか、どれだけ延長されるか、更新直後の移管にどんな例外があるかは、ドメインとサービスの条件ごとに確認してください。「必ず一年無料で追加される」と一般化しないことが大切です。次回更新日をカレンダーに登録し、支払と移管の記録を保存します。

最後に、元のアカウントに残るサーバー、DNS、メール、他のドメインを整理します。不要になった項目だけを停止し、利用中のサービスまでまとめて解約しないようにしてください。更新したドメイン引き継ぎ表を残しておけば、後で担当者が交代しても、レジストラ、DNS、Webサーバーをそれぞれ誰が担当しているか分かります。

詳しい説明を読む

移管条件の確認、DNSとメールの一覧保存、認証コードによる申請、登録管理・サイト・メールの検証という四段階を示すオリジナル図解。

ドメイン登録と管理の基本

DNSレコードと障害の見分け方

ドメインとサーバーの更新チェックリスト

• チュートリアル
• アプリ・ソフト
• サイト構築・EC
• ドメイン・ホスティング・フロントエンド