本人も驚きで、28年も利用していたレジストラが突然ダウンしてしまい、3週間後に復旧しましたが、その対応に不信感を抱き、レジストラを変更することを決めました。しかし、レジストラを変更するにあたりAuthCodeの請求が必要なのですが、こちらからの問い合わせにはノーリアクションで困り果ててしまいました。結果として［.com］のため上位ドメインレジストラとのやりとりなど難関が山積みでしたが、友人たちの知識と協力により、なんとか別のドメインレジストラに移管できたため、移管の確認も兼ねてサイトをリニューアルしました。そこで、ここに至るまでの騒動と移管後の残務処理を備忘録として整理してみました。なお、できるだけ詳細に記載していますが、私や友人の個人および登録情報等に触れてしまう部分は曖昧な表現としています。そのため、何のことか分からない記述もありますが、ご理解ください。また、いろいろと憤ったことは否定できませんが、特定のレジストラを非難あるいは宣伝を目的としていませんので、レジストラ名は伏せています。なお、国内ドメインレジストラはレジストラ、上位ドメインレジストラは［.com］の管轄が北米の会社のため、Registrarと記述しています。


突然kaizu.comがダウン？してしまい完全にアクセスができなくなってしまう。FTPソフトでも自分のサイトに入っることができない。レジストラKが倒産？　なにがなんだか分からずに狼狽してしまう。同じレジストラKを利用している友人Yさんからは「メールもダメになった」と連絡が入る。まだメールは使えているので一時的なトラブルなのか？　いや、私だけ使えるのはサーバーが違うから？

昨日からXで情報が幾つか上がり始めてプチ炎上？状態。何がどうなっているのか大混乱です。状況が分からないので炎上には参戦せず。

一時的なトラブルによるシステムダウンだと信じていたが、何のアナウンスもなく、ついにkaizu.comのメールも利用できなくなる。これでは、kaizu.comメールを認証コード確認の発送先などにしているため、色々と不都合が出るので、登録しているそのメールアドレスを予備メールに切り替える。

情報収集に奔走するとともに、Yさんとの情報交換を密に行う。完全にサスペンスドラマの状態。ここで、急遽サポートを名乗り出てくれたネット関連のプロである友人Sさんと打ち合わせを開始する。連絡と相談はFacebook Messengerを活用する。

SさんとTeamsで1回目のオンラインミーティングを行う。

［.com］のトラブルのため、Registrar Tへ問い合わせを行うと、「レジストラKに問い合わせをするので、数日お待ちいただきたい」との返信。

Sさん、Yさんの参加でFacebook Messengerにチャットグループを作成する。Sさん、YさんとTeamsで2回目のオンラインミーティングを行う。とにかくレジストラを移管することについて模索する。そのためにはAuthCodeが必要。ただし、レジストラKがダウンしているので上位レジストラへの対応となる。ダメ元でレジストラSに救済を相談しましたが管轄外ということで断られてしまいました。［.com］なので当然の結果です。

［.com］のトラブルのため、Registrar TへAuthCode発行の問い合わせをするが、返事はない。アドレスの乗っ取りと勘違いされたのだろうか？

20日から25日の間に復活するというアナウンスをレジストラKの臨時サイトで確認する。関係者への個別メールはまったくなく、復活も怪しい感じ。レジストラKが復活することが事前に分かっていたので、こちらからのAutuCode請求は、Registrar Tからの返信がなかったのかもしれない。

レジストラKからの個別説明は一切なく、サイトおよびメールが3週間ぶりに復活する。本当に復活したのか激しく心配。

今回のレジストラKへの不信感と将来への不安から、レジストラ変更を決意し、AuthCode請求を英文併記でレジストラKに送付する。 最初の申請後、祝休日を除く5日（11月5日）以内に提示する義務があるので、英文併記は最終的にRegistrar Tに通告する際の保険。

AuthCode請求を英文併記でレジストラKへ再送する。

レジストラKへの最初のAuthCode請求後、祝休日を除く5日目となっても返事はない。

ICANNのドメイン移管ポリシーに基づき、レジストラKがAuthCode請求に最初の申請後、祝休日を除く5日（11月5日）以内に対応しないことをRegistrar Tに通告。

2025/11/06の通告に対し、Registrar Tから「レジストラKに問い合わせをするので、数日待ってほしい」との返信。2025/11/07の返信に対して、Registrar Tから、「レジストラKが対応しないので、登録時の個人情報を求めるかもしれない」と返信。

2025/11/07のRegistrar Tから「登録時の情報についての確認」の返信。レジストラKが6月30日の時点で連絡が取れない業者にリストアップされていたことが判明。レジストラKとの過去のやり取りを思い出し、レジストラKのスタッフ個人宛にAuthCode請求を英文併記で送付するも返事はない。もしかして年末に計画倒産なのかと疑ってしまう。

登録時のデータと私が思い込んでいたデータの違いから、古いデータが見つからず、Registrar Tとのやり取りに難航する。

Registrar Tから添付した一部のPDFが開けないとの連絡が入ったので、JPG画像を送る。メールで送付したPDFが開けないというリアクションは人生初。

Registrar Tへ現在までの流れを整理して再度報告を行う。なんだか、問い合わせがイタチごっこのスパイラルに陥った感じ。問題は28年前のやりとりのメールを発見出来れば解決するのですが、レジストラKとの契約メールデータが発見できず、やり取りは難航する。

偶然に予想外の場所から見つけた古いバックアップHDDから、以下の情報を発見。
　1997年02月28日　A社のUSサイトで紹介されることになったので、慌てて英文サイトを作成する。
　1997年04月21日　Gさんの紹介でRegistrar Xにてkaizu.comを取得。
　1997年10月15日　Yさんの紹介でレジストラKに移管。
なので28年目の悪夢？　取りあえずレジストラKに移管したときにInterNICから送られてきたメールをRegistrar Tへ送付。 ちなみにレジストラKに移管したときは簡単に移管できたのですが、それはAuthCode処理がなかった時代だったからだそうです。

Registrar Tから、確認ができたので、現時点で提出できる限りのデータとして、「固有番号を隠した身分証明書の提示」を求められたので送信。YさんからAuthCodeの取得に成功したとの報告。私もあと少しの辛抱。

AuthCodeを取得。ただし、指定された一部のリンクが切れており、パスワードのリセットに失敗。Registrar Tへ問い合わせは、時差14時間なので先方は18時の退勤時間というバッドタイミング。翌朝は土曜日なので、返事は日本時間で17日の月曜日23時以降になるか？　Sさん、YさんとTeamsで3回目のオンラインミーティングを行う。移管先に決めているレジストラMの情報収集を行う。

時差14時間なので、メールが届くのは日本時間の翌日23時〜7時。朝起きてメールがないと翌日まで落ち着かない。Registrar Tからの返事がないので、再度問い合わせを行う。

今頃になってレジストラKから10月8日から27日にかけてのトラブルの謝罪と、システム移転のため22日から数時間のサービス停止と、メンテナンス期間に入るとの連絡。
　> 11月22日23時～11月23日02時予定（システム移転に伴う全サービスの停止）
　> 11月29日23時以降（ウェブ、メールサービスの復旧）
　> 12月8日23時以降（各サービスの順次復旧）
ここは日本だよね〜。伝説級のひどさに脱力感が半端ない。この処理に入る前に移管できればベストだけど心配。SさんとTeamsで4回目の緊急オンラインミーティング。レジストラK側の問題ゆえ、Registrar Tから返事が来ないのかもしれない。パスワードのリセットは移管後でもOKとの情報で、レジストラMで移管手続きに入る。勘違いから4日無駄にしてしまったが、とにかく今は問題なく移管できることを祈る。

Registrar Tから、移管手続きに入ったことの連絡があり、まずは一安心。1997年10月にレジストラKへ移管した時は1週間ほどかかった記憶があるので、祝休日を除くと1週間後の12月1日あたりがXデーか？ちなみに、英語でのやり取りで苦労しましたが、Registrar Tの対応は親切でした。

Yさんからレジストラ移管完了の報告が入る。申請から土日を挟んで1週間なので、私は祝休日を挟むため28日頃かな？　Yさん、SさんとTeamsで5回目の緊急オンラインミーティングを行う。YさんのレジストラMでの設定に立ち会いましたが、新規ドメイン作成ではなく移管のため、Sさんの専門知識がなかったら大苦戦は必至です。でも、レジストラMはのインターフェースはレジストラKより慣れると親切設計。私もSさんに来週お世話になることに・・・。

Yさんに登録に関するちょっとした問題が発生しました。具体的な内容は伏せますが、私も含めて2002年以前に.comドメインを作成した人は避けて通れない手続きかもしれません。

予告よりも1時間ほど遅れて0時よりkaizu.comがダウン。せめてメールの復旧に入る29日までに移管できることを祈りたい気持ち。

kaizu.comメールは使えているのに、なぜか謎のエラーが出始める？　まるで救助が来ないのに沈没船に取り残された気分。

レジストラMよりレジストラ移管完了の連絡が入る。予想より仕事が早くて大興奮。SさんとTeamsで6回目の緊急オンラインミーティングを行う。なんとか移管手続きと諸設定が完了しました。直ぐにレジストラMより登録者名義変更メールが2通届くので対応。名義変更という内容ですが、以前の設定を引き継ぐので無修正で処理。

レジストラMより登録者名義変更承認メールが届いたので、事前に用意していた改装後のサイトデータをアップするも、なかなか表示されず、今朝なんとか表示されるも、サイトがhttpsで安定しないので、[.htaccess]ファイルでhttp→httpsのリダイレクト設定にて作業完全終了。Blogとfacebookで告知。これにて50日間に及ぶドメイントラブルは一件落着です。自分一人での対応であれば、あと数ヶ月かかったかもしれません。SさんとYさんに感謝。

レジストラMより、AuthCodeを取得時に指定された一部のリンクが切れており、パスワードのリセットに失敗した件について、移管が完了していれば特に問題はないと説明を受ける。これで移管に関するすべての問題が解決。

安全のために ほとんどのレジストラがデフォルトで有効にしているので、WHOIS情報を個人情報から代理公開に変更。代理公開とは、ドメインの登録者の個人情報を公開する代わりに、ドメイン管理サービス会社の情報を代わりに表示させ、プライバシーを保護します。レジストラMより、登録者名義変更承認メールが届く。

以前のレジストラKではドメイン使用料がメール込み？だったので、勘違いによる問題が発生。移管先レジストラMのメール料金の支払いが未定と気がつき慌てて支払いを行う。あと6日の猶予があったので安心しました。ドメイン使用料は、移管前のレジストラKとの契約終了日からの計算になります。例えばレジストラKとの契約終了日が2026年4月1日で、レジストラTと2年契約なら、契約は2026年4月2日からのカウントとなります。よって契約締め切り日は2028年4月3日というわけです。メールはこの計算が当てはまらずストレートに契約日から計算されます。レジストラMのメールサポートが親切すぎて安心感が10倍増です。ちなみに移管後の利用料金は移管前の1/10以下でビックリ。

Gmailからのkaizu.comの送信で受け手側に「このメールは認証情報のドメインとFromアドレスのドメインが一致していません」と表示または送信されない問題を確認し、SMTPサーバー設定を再構築。レジストラKは旧式？だったようです。

SさんとTeamsで7回目の緊急オンラインミーティングを行う。電子メールのなりすましや改ざんを防ぐための送信ドメイン認証技術であるDKIM (DomainKeys Identified Mail)は既に設定済みですが、更に電子メールの送信元ドメインが詐称されていないかを検査するSPF (Sender Policy Framework)と、メールの送信元ドメインの偽装を防ぐセキュリティ技術のDMARC「Domain-based Message Authentication, Reporting and Conformance」を確認・調整・追加設定しました。残務処理はコレで完了だと思います。

Yさんの登録に関するちょっとした問題が無事に解決したと連絡が入る。コレで私とYさんは移管に成功しました。2ヶ月間の攻防は、本当に大変な日々でしたが、私一人では3ヶ月以上かかっていたかもしれません。Sさん、Yさんに感謝です。

落ち着いて振り返ると、一連の立役者であるSさんには本当に助けられました。しかし、当のSさんにとっては「役所行って住所とりもどす、新しい家さがす、表札かける、郵便受け設置する、送付する場合のポストの位置確認する程度のこと」ということで、あまりにかっこよすぎて尊敬のまなざしになってしまいました。

今頃になって古いデータが発掘され、最初にドメインを取得したのはUSのRegistrar Xではなく、国内のレジストラT（既に倒産？）であることが判明。私の勘違いだったようですが、当時英文メールで苦労していたのは別の案件だったのだろうか？　結局、以下の流れが私のサイトの歴史です。
　1997年02月28日　A社のUSサイトで紹介されることになったので、慌てて英文サイトを作成する。
　1997年04月21日　Gさんの紹介でレジストラTにてkaizu.comを取得。
　1997年10月15日　Yさんの紹介でレジストラKに移管。
　2025年11月25日　Sさん、YさんのフォローでレジストラMに移管。

このページを一般公開。

年内でGmailのPOP3機能が終了するための対策は設定していましたが、念のためにWindowsだけでなくmacOSでも利用できるThunderbirdで送受信できるように設定しました。あくまでもサブです。レジストラのWebMail＞Gmail＞Thunderbirdという感じです。

一度でも利用したメールアドレスを調べていたら、1997年02月以前に国内向けのサイトを作成していたことが判明。ただし、それがいつ頃からだったかを確認できる資料をまだ発見できていません。パソコン通信時代から色々と使っていたメールアドレスで契約終了やキャリア変更などにより失効しているものは22個でした。そして現在常用のアドレスはドメインで複数設定も含めて13個ですが、頻繁に使っているのは実質8個です。1987年あたりからネット（※）を利用していたので、そのくらいになりますね。インターネットは1995年あたりからで、それ以前はパソコン通信。

GmailとレジストラのWebMailで問題ないのでThunderbirdの使用を止めました。Gmailの利便性に慣れてしまうと・・・ですね。



［.com］を利用している現レジストラから移管先レジストラに移管したい場合は、現レジストラへAuthCodeを請求します。ICANNのドメイン移管ポリシーで、申請後の祝休日を除いた5日以内に発行する義務があります。もし請求に応じない場合は、ICANN WHOISで自分のドメインを検索し、Registrar Informationの上位レジストラへ現レジストラがAuthCode請求に応じない旨を説明し、請求を行います。その後、現レジストラとの契約書および支払い明細を請求されるので、メールをPDF化したものを英文に翻訳したテキストデータとともに送付します。問題がなければ最後に固有番号を隠した身分証明書の提示を求められるので、スキャンデータを添付して送付します。これでAuthCodeとパスワードのリセットに関する手順メールなど4通のメールが届きます。パスワードのリセットは移管先レジストラでの手続きが問題なく進行していれば、処理に失敗しても特に問題はありません。移管手続き後、直ぐに移管先レジストラより登録者名義変更メールが2通届くので対応すれば翌日には登録者名義変更承認メールが届きます。これで完全に移管が完了したことになります。