Thin Whois と Thick Whois の違いは、登録者の連絡先などの登録データを「どこが持っているか」です。Thin 方式ではレジストリ（TLD の管理者）が持つのはドメイン名・レジストラ・ネームサーバー・状態・日付などの最小限の情報で、連絡先はレジストラが持ちます。Thick 方式ではレジストリが連絡先まで一括して持ちます。この違いによって、照会の流れと、古い情報や食い違いがどこで生まれるかが変わります。この記事では、2つの方式での照会の流れを、WHOIS と RDAP のコマンドで実際にたどる方法を説明します。
2つの方式の違い
ドメインの登録には、TLD ごとに1つあるレジストリと、利用者が契約するレジストラが関わります。
- Thin 方式: レジストリはドメインを管理するための最小限の情報（ドメイン名、担当レジストラ、ネームサーバー、ステータス、登録日・期限など）だけを持ちます。登録者の氏名や連絡先はレジストラが持ち、照会にもレジストラが答えます。
- Thick 方式: レジストラが登録者の情報をレジストリにも送り、レジストリが連絡先を含めた登録データを持ちます。照会はレジストリだけで完結します。
長く Thin 方式で運用されてきた代表が .com と .net です。ICANN では、これらを Thick 方式に移す方針がいったん決まりましたが、期限の延期を経て、GDPR 施行後の登録データの扱いをめぐる議論の中で位置付けが見直されました。2012年以降に始まった新しい gTLD の多くは、最初から Thick 方式です。.jp は JPRS がレジストリとして登録データを管理しており、照会も JPRS の WHOIS が答えます。移行の扱いは変わる可能性があるため、TLD ごとの現在の方式は、照会結果で実際に確かめるのが手早い方法です（2026年10月現在）。
WHOIS から RDAP への移り変わり
照会の手段も変わっています。従来の WHOIS（ポート43の文字ベースの照会）に代わり、gTLD では RDAP が正式な照会手段になり、2025年1月以降、gTLD のレジストリとレジストラは WHOIS の提供を求められなくなりました。WHOIS サーバーを動かし続けているところもありますが、応答がない・内容が古いといったことが増えています。RDAP は結果を JSON で返し、レジストリの応答からレジストラの照会先へのリンクを含むため、Thin 方式の照会の流れも追いやすくなっています。
WHOIS で照会の流れをたどる
Thin 方式では、照会が段階的に進みます。多くの環境の whois コマンドは自動で照会先をたどりますが、手で順にたどると、どの段階の情報を見ているのかが分かります。
# 1. IANA に TLD のレジストリの WHOIS サーバーを尋ねる（whois: の行）
whois -h whois.iana.org com | grep -i '^whois:'
# 2. レジストリに照会する（.com の場合）
whois -h whois.verisign-grs.com example.com
# 3. 2 の結果にある Registrar WHOIS Server に照会する
whois -h whois.registrar.example example.com2 のレジストリの結果には、レジストラ名、ネームサーバー、ステータス、日付は出ますが、登録者の連絡先は出てきません。Registrar WHOIS Server: の行に、次に問い合わせるレジストラの照会先が書かれています（3 の whois.registrar.example は、その値に置き換えます）。
Thick 方式の TLD では、2 の段階で連絡先の項目まで返ってきます。ただし、GDPR 以降は個人の情報が伏せ字で返ることが多いため、「連絡先の項目があるかどうか」と「中身が見えるかどうか」は分けて見ます。
RDAP で照会の流れをたどる
RDAP では、IANA が公開している一覧（ブートストラップファイル）から、TLD ごとのレジストリの RDAP サーバーを調べられます。
# TLD 「com」 の RDAP サーバーを調べる
curl -s https://data.iana.org/rdap/dns.json \
| jq -r '.services[] | select(.[0] | any(. == "com")) | .[1][]'
# レジストリの RDAP に照会する
curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq '{ldhName, status, events}'
# レジストラの RDAP へのリンクを取り出す
curl -s https://rdap.verisign.com/com/v1/domain/example.com \
| jq -r '.links[]? | select(.rel == "related") | .href'Thin 方式のレジストリの応答では、links の中に rel が related のリンクがあり、それがレジストラ側の RDAP での照会先です。このリンクを開くと、レジストラが持つ登録データ（公開が許される範囲）が返ってきます。Thick 方式の TLD では、レジストリの応答の entities に登録者などの役割を持つ項目が含まれます。
毎回これをたどるのが手間であれば、https://rdap.org/domain/example.com のような転送サービスも使えます。ただし第三者のサービスなので、業務で継続的に使う場合は、レジストリの RDAP サーバーに直接照会するほうが挙動を把握しやすくなります。
方式の違いが運用に与える影響
情報を直す場所はレジストラ
どちらの方式でも、登録者情報を変更する窓口はレジストラです。Thick 方式では、レジストラで変更した内容がレジストリにも送られて、照会結果に反映されます。Thin 方式で「レジストリの結果は新しいのに、連絡先は古い」「その逆」といった食い違いが見えた場合、どちらの段階の情報を見ているかを確認すると、問い合わせ先を判断しやすくなります。
移管の前後で見え方が変わる
Thin 方式の TLD では、移管の直後にレジストリの結果は新しいレジストラを指していても、照会の手段によっては旧レジストラの情報が残って見えることがあります。移管後は、レジストリの応答に含まれるレジストラ名とリンクを起点に確認します。
スクリプトでの一括照会
ドメインの期限を監視するスクリプトなどで WHOIS を使っている場合、提供終了による応答なしや、照会回数の制限で失敗することがあります。期限やステータスの確認であれば、レジストリの RDAP に照会し、events の expiration を読む形に変えると、Thin・Thick のどちらでも同じ処理で扱えます。照会の間隔は空け、短時間に大量の照会を送らないようにします。
curl -s https://rdap.verisign.com/com/v1/domain/example.com \
| jq -r '.events[] | select(.eventAction == "expiration") | .eventDate'まとめ
- Thin 方式は連絡先をレジストラが持ち、Thick 方式はレジストリが連絡先まで持ちます。
- .com・.net は長く Thin 方式で、Thick 化の方針は見直しを経ています。現在の方式は照会結果で確かめます。
- gTLD の照会手段は WHOIS から RDAP に移っており、RDAP ではレジストリの応答のリンクからレジストラの照会先をたどれます。
- 登録者情報を直す窓口はどちらの方式でもレジストラです。
- 期限の監視などには、レジストリの RDAP の
eventsを使うと方式の違いを気にせず扱えます。