2026年7月13日

Thick Whois が原因で起きるトラブル｜登録データがレジストリにある仕組みと症状別の対処

ドメイン管理

Thick Whois（シック WHOIS）は、ドメインの登録者情報をレジストラだけでなくレジストリ（TLD を管理する組織）も保持し、レジストリへの照会だけで登録データ全体が分かる方式です。データの出どころが一か所にまとまる反面、「変更したのに表示が古い」「公開代行が効いていないように見える」「移管後に情報が食い違う」といった、仕組みを知らないと原因をつかみにくいトラブルが起きます。この記事では Thick 方式の仕組みを押さえたうえで、よくある症状を起こりやすい順に取り上げ、それぞれの確認方法と対処を説明します。

Thick 方式と Thin 方式の違い

ドメインの登録データは、大きく2種類に分かれます。ひとつはドメイン名・レジストラ・ネームサーバー・ステータス・登録日と有効期限といった「ドメインそのものの情報」、もうひとつは登録者や管理担当者の氏名・住所・メールアドレスといった「連絡先の情報」です。

Thin 方式: レジストリはドメインそのものの情報だけを持ち、連絡先はレジストラが持ちます。照会するときは、レジストリの応答に書かれたレジストラの照会先をもう一度たどります。.com と .net はこの方式で運用されてきました。
Thick 方式: レジストリが連絡先まで保持し、レジストリへの照会で全体が分かります。.org や多くの新 gTLD がこの方式で、.jp（JPRS）もレジストリが登録者情報を管理する点で同じ考え方です。

.com / .net も Thick 方式へ移行する方針が ICANN で決まっていましたが、GDPR 施行後の個人データの扱いをめぐる議論で延期が重なり、当初の計画どおりには進んでいません。.com / .net は実質的に Thin 方式のまま運用されているとみてよい状況です（2026年10月現在）。最新の扱いは ICANN の公表資料で確認してください。

また gTLD では、ICANN が 2025年1月に従来の WHOIS（ポート43）の提供義務を終了し、RDAP を正式な照会手段にしました。WHOIS サーバーを停止したレジストリやレジストラもあるため、トラブルの調査には RDAP を併用します。

まずレジストリの登録データを直接照会する

この種のトラブルの多くは「どこの情報を見ているか」の取り違えから始まります。第三者の WHOIS 検索サイトは結果をキャッシュしていることがあるため、レジストリの応答を直接確認するのが出発点です。

# RDAP（gTLD）：IANA の登録情報をもとに、そのTLDのレジストリの RDAP へ転送される
curl -sL https://rdap.org/domain/example.org | jq -r '.status[]?'
curl -sL https://rdap.org/domain/example.org | jq -r '.events[]? | "\(.eventAction)\t\(.eventDate)"'

# 従来の WHOIS（レジストリが提供を続けている場合）
whois example.org

# .jp は JPRS の WHOIS を直接指定する（/e を付けると英語表記）
whois -h whois.jprs.jp example.jp
whois -h whois.jprs.jp "example.jp/e"

RDAP の events には登録日（registration）、有効期限（expiration）、最終変更（last changed）などの日時が入ります。登録者情報を変えたのに表示が変わらないときは、まず「last changed」が変更した日時になっているかを見ます。日時が古いままなら、変更がレジストリまで届いていません。

症状別の原因と対処（起こりやすい順）

1. 登録者情報を変更したのに表示が古いまま

最もよく相談される症状です。原因は次の3つが考えられます。

変更が確定していない: gTLD では登録者情報を変更すると、登録者メールアドレスの確認を求められることがあります。確認を終えるまで変更が保留されるレジストラもあります。管理画面に「確認待ち」などの表示がないか、確認メールが迷惑メールフォルダに入っていないかを見ます。
照会サービスのキャッシュ: 第三者の検索サイトや、ブラウザ拡張の WHOIS 表示は古い結果を返すことがあります。上のコマンドでレジストリの応答と見比べます。
レジストラからレジストリへの反映待ち: 通常は短時間で反映されますが、レジストラの処理方式によっては時間差があります。RDAP の最終変更日時が更新されるまで待ち、1日たっても変わらなければレジストラに問い合わせます。

問い合わせるときは「管理画面ではこう表示されているが、レジストリの RDAP（または JPRS の WHOIS）ではこう表示される」と、照会結果を添えて伝えると話が早く進みます。

2. 公開代行を申し込んだのに本人の情報が見える

Thick 方式で第三者に表示されるのは、レジストリに登録されている値です。レジストラの公開代行は、レジストリに送る連絡先を代行者の情報に差し替える形で実現されることが多いため、申し込みがレジストリまで反映されていなければ本人の情報が表示されたままになります。

確認すること: 管理画面で、公開代行がドメインごとに「適用済み」になっているかを見ます。複数のドメインを持っている場合、一部のドメインだけ申し込みが漏れていることがよくあります。
TLD の規則による制限: TLD によっては、代行できる項目が限られていたり、そもそも代行を認めていなかったりします。.jp でも、代行の対象になる項目や扱いはドメインの種別やレジストラによって異なります。レジストラの案内で、そのドメインで何が伏せられるのかを確認します。
過去の記録: 公開代行を有効にする前の情報は、第三者の WHOIS 履歴サービスに残っていることがあります。現在の表示が正しく変わっていれば、それ以上は消せないものと割り切るしかありません。

3. 移管や登録者変更のあとで情報が食い違う

Thick 方式では、登録データはレジストリにあるため、レジストラを移管しても登録者情報は基本的にそのまま引き継がれます。このため、移管先のアカウントに登録した情報と、レジストリに残っている移管前の情報（移管元の公開代行者の情報を含む）が食い違うことがあります。

確認すること: 移管が完了したら、レジストリの RDAP や WHOIS で登録者・連絡先の欄を確認します。移管元の公開代行者の名前が残っていないかが要点です。
対処: 移管先の管理画面で登録者情報を正しく入れ直し、必要なら公開代行を設定し直します。
注意点: 登録者名や組織名を変えると、gTLD では「登録者の変更」として扱われ、確認メールが届いたり、一定期間ほかのレジストラへ移管できなくなったりすることがあります。ICANN の移管ポリシーは見直しが進められているため、ロックの有無や期間は移管先のレジストラの案内で確認してください。

4. 公開された連絡先に営業メールや偽の更新通知が届く

レジストリが連絡先を持ち、その連絡先が公開される TLD では、取得直後から登録者宛てに営業メールや電話が届くことがあります。なかには「ドメインの更新期限が迫っています」「検索エンジン登録の請求」などと称して、契約しているレジストラとは無関係の請求書を送ってくるものもあります。

確認すること: 差出人が、自分が契約しているレジストラかどうかを確かめます。RDAP の Registrar 欄で契約先を確認できます。
対処: 心当たりのない請求には応じず、更新はレジストラの管理画面から直接行います。メール内のリンクからログインしないことも大切です。今後の露出を減らすには、公開代行の利用や、登録メールアドレスを役割用のアドレスに切り替えることを検討します。

5. スクリプトでの一括照会が失敗する・空の結果になる

ドメインの有効期限を監視するスクリプトなどで WHOIS を繰り返し照会していると、ある日から結果が空になったり、接続を拒否されたりすることがあります。原因は、照会先が WHOIS サーバーを停止したことか、短時間に照会しすぎて制限を受けたことのどちらかであることが大半です。

# RDAP に切り替え、間隔をあけて照会する例（domains.txt に1行1ドメイン）
while read -r d; do
  code=$(curl -sL -o "rdap_${d}.json" -w '%{http_code}' "https://rdap.org/domain/${d}")
  echo "${code} ${d}"
  sleep 5
done < domains.txt

HTTP 429 が返る場合は照会の頻度が高すぎます。間隔を広げ、結果をファイルに保存して使い回します。有効期限のように日に何度も変わらない情報は、1日1回の照会で十分です。

WordPress サイトを運用するうえでの備え

レジストラに登録するメールアドレスは、そのドメイン自身のアドレスにしないようにします。ドメインが止まると確認メールも受け取れなくなるためです。
有効期限とステータスは、上の RDAP の結果から定期的に確認できます。サイトの監視と同じ仕組みに組み込んでおくと、更新漏れや保留状態に早く気づけます。
移管や登録者変更の作業は、サイトのリニューアルなど大きな作業と時期をずらし、変更後にレジストリの照会結果を確認する手順をチェックリストに入れておきます。

まとめ

Thick 方式では登録者情報をレジストリが持つため、第三者に見えるのはレジストリに登録された値です。調査はレジストリの RDAP（.jp は JPRS の WHOIS）を直接照会することから始めます。
変更が反映されないときは、確認メールの未完了、照会サービスのキャッシュ、反映待ちの順に疑い、RDAP の最終変更日時で切り分けます。
公開代行が効いていないように見えるときは、ドメインごとの適用状態と、TLD の規則で伏せられる範囲を確認します。
移管しても登録データは引き継がれるため、移管後は移管元の代行者情報が残っていないかを確認し、必要なら入れ直します。
一括照会は RDAP に切り替え、照会間隔をあけて結果を使い回します。