Thick WHOISは、ドメインの登録者情報（連絡先）をレジストラだけでなくTLDを管理するレジストリも保持し、レジストリのWHOISから返す方式です。どこに自分の情報が置かれ、何が公開されるかを知っておくと、WHOIS情報公開代行や連絡先の選び方で個人情報を守れます。この記事では、ThickとThinの違い、近年の制度の変化、自分のドメインで何が見えているかの確認方法、具体的な保護の手順を説明します。
Thick WHOISとThin WHOISの違い
ドメインの情報は、登録を受け付けるレジストラと、TLD全体を管理するレジストリの両方に記録されます。どちらが登録者の連絡先まで持つかで、2つの方式に分かれます。
- Thin（シン）: レジストリは、ドメイン名、担当レジストラ、ネームサーバー、ステータス、登録日・有効期限などの技術的な情報だけを持つ。登録者の連絡先はレジストラが持つ。.com と .net が長くこの方式だった
- Thick（シック）: レジストリが登録者・管理担当・技術担当の連絡先まで保持する。多くのgTLDや、.jp などの国別TLDはこちらに近い
Thickでは情報が一か所にまとまり、レジストラを移管しても登録者情報が引き継がれやすいという利点があります。その反面、個人情報を持つ組織が増えることになり、プライバシーの面ではどこまで公開するかが問題になります。
制度の変化：GDPRとRDAP
かつてはWHOISで登録者の氏名・住所・電話番号が誰でも見られるのが普通でした。2018年に欧州のGDPRが施行されてから状況が大きく変わり、現在は次のようになっています（2026年10月現在）。
- 個人の連絡先は非公開が基本: gTLDでは、多くのレジストラとレジストリが個人の連絡先を伏せて表示する。ただし組織名の欄など、公開される項目は残る
- .com/.net のThick化は見送り: ICANNは .com/.net をThickに移行する方針を決めていたが、GDPR以降の議論で前提が変わり、登録データの扱いはICANNの登録データポリシーの枠組みで整理された。詳細はICANNの公開資料で確認してほしい
- WHOISからRDAPへ: gTLDでは2025年1月に従来のWHOIS（ポート43）の提供義務がなくなり、JSON形式で情報を返すRDAPが正式な手段になった。whoisコマンドが応答しないTLDが出てきている
ただし、これはgTLDの話です。.jpはJPRSの規則で運用されており、登録者名など公開される項目がgTLDとは異なります。
自分のドメインで何が見えているか確認する
保護を考える前に、いま公開されている情報を確かめます。レジストリ側とレジストラ側の両方を見るのがポイントです。
# whois（gTLDでは応答しない場合もある）
whois example.com
# RDAP：レジストリ側（.com の例）
curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq '.entities'
# RDAP：レジストラ側（レジストリの応答の links に記載された URL を使う）
curl -s https://rdap.verisign.com/com/v1/domain/example.com \
| jq -r '.links[] | select(.rel=="related") | .href'
# .jp（JPRS の whois。末尾 /e で英語表示）
whois -h whois.jprs.jp example.jp/e他のTLDのRDAPの問い合わせ先は、IANAが公開している一覧（https://data.iana.org/rdap/dns.json）で調べられます。結果の entities に、氏名・組織名・住所・電話番号・メールアドレスが実際の値で出ていないかを確認します。伏せ字や「REDACTED」、代行業者の情報になっていれば保護されています。
登録者情報を守る手順
1. WHOIS情報公開代行を有効にする
レジストラの代行サービスを使うと、登録者情報の欄に代行業者の情報が登録され、自分の住所や電話番号は表に出ません。Thickのレジストリにも代行業者の情報が渡るため、レジストリ側から自分の情報が公開されることも防げます。
注意点は、代行の仕組みによっては法的な登録者が代行業者になることです。信頼できるレジストラの代行を使い、規約で権利関係を確認してください。TLDによっては代行を使えない、または範囲が限られることもあります。
2. 組織名の欄に個人情報を書かない
個人の連絡先が伏せられる場合でも、組織名の欄は公開されることがあります。個人で登録するときに、組織名に自分のフルネームや自宅住所の一部を入れると、そのまま公開される可能性があります。個人なら組織名は空欄にし、事業者なら公開されて困らない正式名称を入れます。
3. 連絡用メールアドレスを分ける
登録者のメールアドレスは、ドメイン管理専用のアドレスを用意すると、公開や漏えいがあったときの影響を限定できます。多くのレジストラは、問い合わせ用に転送アドレスやWebフォームを表示します。なお、そのドメイン自身のアドレスにすると、ドメインが止まったときに連絡を受け取れなくなるため、別ドメインのアドレスを選びます。
4. 公開情報を狙った攻撃に備える
公開されている有効期限やレジストラ名を使って、「ドメインの更新が必要です」「WHOIS情報の確認が必要です」と装う詐欺メールや、他社への移管を促す請求書風の郵便が届くことがあります。通知はレジストラの管理画面で真偽を確かめ、メールのリンクからはログインしません。あわせて次の対策もしておきます。
- レジストラのアカウントで二要素認証を有効にする
- 移管ロック（clientTransferProhibited）を有効にしておく
- 事業上重要なドメインは、レジストラが提供していればレジストリロックも検討する
5. 過去の情報が残っていることを前提にする
代行を後から有効にしても、それ以前に公開されていた情報は、第三者のWHOIS履歴サービスなどに記録が残っていることがあります。消すことは難しいため、新しくドメインを取るときは最初から代行を設定し、既に公開されていた場合は、そこに載っていた電話番号やメールアドレスに不審な連絡が来る可能性を念頭に置きます。
代行を使うときの注意
- 移管時: 移管元によっては、移管の前に代行の解除が必要なことがある。移管先で改めて設定する
- 登録者情報の変更: 代行の有効化・解除が登録者の変更とみなされ、gTLDでは60日間の移管ロックがかかる場合がある。移管の予定がある時期は避ける
- 法的な開示: 代行を使っていても、正当な法的手続きがあれば情報が開示されることがある。代行は不正の隠れみのにはならない
まとめ
- Thick WHOISはレジストリも登録者の連絡先を持つ方式。どこに情報があるかを知ることが保護の出発点
- GDPR以降、gTLDでは個人の連絡先の非公開が基本になり、WHOISからRDAPへの移行も進んだ。.jpは別の規則で動いている
- RDAPとwhoisで、レジストリ側とレジストラ側の両方の公開内容を確認する
- 代行の利用、組織名の欄の扱い、専用のメールアドレス、二要素認証と移管ロックで、情報とドメインを守る