個人の登録事業者アカウントからイベント用ドメインを引き継ぐ手順

引き継ぎ表を取得する

ドメインアカウント引き継ぎ表をダウンロード（Markdown・英語）

登録済みドメインごとに表を一枚作ります。現在のアカウント、登録連絡先、請求担当、DNS運用担当、通知先、引き継ぎ後の責任者、検証した日時を記録します。パスワード、認証の復旧コード、移管コード、カード番号、本人確認書類の画像はこの共有表に記載しません。これらは組織が認めた安全な保管場所だけで扱います。表に残すのは証拠そのものではなく、確認できる場所と担当者です。

この表は公開してはいけません。会場名やイベント名を記入しても、登録事業者の顧客番号、担当者の連絡先、復旧経路は内部情報です。共有先を限定し、担当者が変わったときに誰が表を更新するか決めます。管理対象が複数ある場合は、一つのドメインを変更して終わりにせず、古い転送用やメール専用の登録も一覧と照合します。

四つの管理上の役割を分ける

登録事業者へのログイン、登録上の名義、DNSを変更できる権限、更新費用を支払う担当は同じとは限りません。ウェブサイトやDNSの管理画面に入れるだけでは、登録情報を変更する正当な権限があると判断できません。対象ドメイン、登録事業者、アカウントの参照情報、登録連絡先、期限、更新方法を、権限を持つ担当者と一緒に確認します。ICANNは、事業者からの重要な通知を受け取るため登録連絡先を最新に保つよう説明しています。公開検索の情報だけでログイン権限を証明しないでください。[2]

ドメイン登録、DNSホスティング、ウェブサイトのホスティング、チケット販売は別のサービスであることが多いです。登録事業者のアカウントを整理しても、外部のDNS運用権限やサイト編集権限は自動で移りません。反対に、ウェブサイトの管理者になっても登録名義は変わりません。各管理画面で確認した事実と、未確認の事項を混ぜずに記録します。

組織が管理できる経路を設計する

英国NCSCは、組織の公開ドメインを個人のメールアカウントに依存させず、信頼できる複数の人が安全に管理できるよう勧めています。組織が維持するアカウントまたは役割用メールを選び、責任者と代行者を明確にします。ただし、共有パスワードを複数人に配るという意味ではありません。個別権限や多要素認証など、登録事業者が提供する管理方法を確認します。復旧メールが管理対象の同じドメインにしか届かない場合、そのドメインの障害時に連絡を受け取れない可能性があります。事業者が認める独立した復旧経路も確認してください。[1]

役割用メールを使う場合は、閲覧者の追加や削除を誰が承認するか定めます。重要な通知が迷惑メールに入らないか、異動後も届くかを確認します。複数人が同じパスワードを共有する方式より、提供されている個別の管理者権限や監査記録を利用できるかを調べます。利用できない機能をあるものとして設計せず、現行プランと事業者の文書で確認してください。

登録事業者に必要な変更を確認する

ログイン用メールの変更、登録名義の変更、二つのアカウント間での登録移動、別の登録事業者への移管は、それぞれ違う操作です。現在の状況にどの操作が必要か、誰の承認や確認が求められるかを登録事業者に尋ねます。たとえばCloudflareは、同社内のアカウント間移動について、移す側と受け取る側の確認を伴う手順を公開しています。これは同社の実装例であり、どの登録事業者にも共通する操作順ではありません。口頭の推測ではなく、該当サービスの現行文書やサポート回答を表に残します。[3]

変更の前後でサイトとメールが動いているかを見るだけでは十分ではありません。どのアカウントに登録が表示されるか、登録連絡先がどこに設定されたか、更新通知がどこへ届くかも確認します。変更が登録名義の変更や事業者間の移管に当たる可能性があるなら、承認や待機などの条件を事前に問い合わせます。作業日時と連絡窓口を記録し、確認が保留なら旧経路を維持します。

旧アクセスを外す前に新経路を検証する

以前の個人アカウントをすぐに削除しないでください。新しいアカウントで対象ドメインと期限を確認でき、変更通知が届き、必要時に登録事業者のサポートへ連絡できることを先に確かめます。ネームサーバー、DNS、メール配信、サイト表示は別の管理領域として確認します。登録アカウントを変えたことと、公開サービスが正しく動いていることを混同しません。事業者が要求する確認を完了し、結果と担当者を記録した後、不要になった個人アクセスを取り除きます。

引き継ぎ後に新しい管理者がログインできることを、権限者が安全な方法で確かめます。アカウントの画面で有効期限、更新方法、登録連絡先、ネームサーバーを確認し、予定外の差異があれば作業を止めて問い合わせます。旧担当者を外す前に、新担当者だけで次の更新やサポート連絡を進められるか、責任者同士で確認してください。口頭の「移しました」だけを完了条件にしません。

更新と復旧の通知を確認する

更新通知とアカウント変更通知が、意図した組織の担当者に届くか確認します。自動更新の設定や請求担当は実際の登録事業者の画面で確認し、支払情報を引き継ぎ表にコピーしません。連絡先と復旧経路を次に見直す担当者も決めます。役割用メールを作っただけで、誰もその受信箱を監視しなければ問題は解決しません。担当者の退職やイベントシリーズの終了時にも確認できるよう、運用の責任を部署または組織内の役割として残してください。[2]

イベント開催日が近い場合でも、期限切れや支払い方法の不備を後回しにしないでください。自動更新が表示されても、支払い手段が有効で管理者へ通知が届くかを別々に確認します。更新期日を一覧に反映し、担当者が休暇中や退職後に誰が対応するか決めます。ICANNの案内は連絡先の更新が通知の受信に重要だと説明しますが、個々の更新条件は登録事業者の契約で確認します。

権限が争われる場合は停止する

現在の保有者が権限に異議を唱える、必要な証拠がない、登録事業者の記録と組織の記録が一致しない場合は、変更を止めます。アカウントのパスワードを借りたり、連絡先を先に書き換えて権限を得ようとしたりしないでください。登録事業者の正式な支援または紛争処理の経路を使い、必要なら地域の専門家に相談します。この表は確認した操作と未解決事項を整理する資料であり、法的な所有権を判定する書類ではありません。

外部制作者が過去に取得したドメインについて、組織側の説明と登録事業者の記録が食い違う場合があります。その場でどちらが所有者かを決め付けないでください。契約、請求、登録時の連絡先など、正当に参照できる資料の所在を整理して、権限ある窓口で相談します。緊急性があっても、本人になりすましたり、回復コードを無断で使ったりしないことが重要です。