2026年8月4日
2026年8月4日
WHOIS精度ポリシーの確認手順|自分のドメインの登録情報が要件を満たしているかを点検する
WHOIS 精度ポリシーとは、ドメインの登録者情報を正確に保つためのルールの総称で、gTLD(.com など)では ICANN とレジストラの契約、.jp では JPRS の規則が土台になっています。確認の手順は、どのルールが自分のドメインに適用されるかを特定し、レジストラに登録した情報をその要件に照らして点検し、確認の状態と通知を見落とさない運用を整える、という流れです。この記事では、その手順を順に説明し、他人のドメインの情報が不正確だと気づいたときの報告方法にも触れます。
WHOIS 精度ポリシーの中身
gTLD の場合、主に次のルールが関係します。
- レジストラ認定契約(RAA): ICANN と認定レジストラの契約です。登録者は正確な連絡先を提供し、変更があれば速やかに更新することが求められます。故意に不正確な情報を登録したり、レジストラからの照会に 15日以内に応じなかったりすると、ドメインの停止や取り消しの理由になると定められています。
- 登録者情報の検証の仕様: 2013年版の RAA に含まれる仕様で、レジストラは新規登録・移管の受け入れ・登録者情報の変更のあと、メールアドレスなどを確認し、住所や電話番号の形式も確かめます。
- 年次の確認通知: レジストラは年に一度、登録者に登録情報の見直しを促す通知を送ります。
- 登録データに関するポリシー: GDPR 施行後に整備された ICANN の方針で、どの情報を集めて公開するかが定められています。2025年に全面的に施行されました。
公開表示が伏せられるようになっても、レジストラが持つ情報の正確さの要件は変わっていません。一方、.jp などの国別 TLD は、それぞれのレジストリが独自の規則を定めています。ルールの文言や運用は改定されることがあるため、ここでは概要にとどめます(2026年10月現在)。
手順1: TLD とレジストラを特定する
まず、自分のドメインがどのルールの下にあるかを確かめます。gTLD なら RDAP で、レジストラの名称と ICANN の認定番号(IANA ID)が分かります。
# レジストラの名称を確認する(gTLD)
curl -sL https://rdap.org/domain/example.com \
| jq -r '.entities[]? | select(.roles | index("registrar")) | .vcardArray[1][] | select(.[0] == "fn") | .[3]'
# 状態と有効期限もあわせて見る
curl -sL https://rdap.org/domain/example.com | jq -r '.status[]?'
# .jp は JPRS の WHOIS
whois -h whois.jprs.jp example.jp
ブラウザで確認したい場合は、ICANN の照会サービス(lookup.icann.org)でも gTLD の登録データを表示できます。リセラー(販売代理店)経由で契約している場合、表示されるレジストラは契約先の会社と異なることがあります。その場合、精度の確認を実際に行うのは表示されたレジストラですが、連絡は契約先の会社から届くこともあります。
手順2: 適用されるルールと規約を確認する
- gTLD: ICANN の RAA と、契約先のレジストラの利用規約が適用されます。規約には、登録情報の確認の方法や、確認が取れない場合の扱いが書かれています。
- .jp: JPRS の登録規則と、契約先のレジストラ(指定事業者)の規約が適用されます。登録者情報が事実と異なる場合の扱いや、属性型 JP(.co.jp など)の登録資格の要件が定められています。
- そのほかの国別 TLD: TLD ごとにレジストリの規則を確認します。居住地や事業所の要件がある TLD もあります。
規約を全部読み込む必要はありませんが、「確認の連絡がどこに届くか」「何日以内に応答が必要か」「応答しないとどうなるか」の3点は把握しておきます。
手順3: レジストラに登録している情報を点検する
管理画面で、公開表示ではなくレジストラが保持している登録情報そのものを開き、次の観点で点検します。プライバシー保護(公開代行)を使っている場合も、本人の情報は別に保存されています。
- 氏名・組織名: 実在する人や組織の正式な名称か。法人のドメインなら、担当者個人ではなく法人名で登録されているか。
- 住所: 実在する現在の住所か。引っ越し前の住所や、番地の抜けがないか。
- 電話番号: 国番号付きの形式(例:
+81.312345678)で、実際につながる番号か。 - メールアドレス: 受信できるアドレスか。そのドメイン自身のアドレスになっていないか。ドメインが止まると確認メールも受け取れなくなるため、別ドメインのアドレスにしておきます。
- 管理担当・技術担当: 項目がある場合、退職者や過去の制作会社のままになっていないか。
「test」などの仮の値や、明らかに形式が崩れた値は、それ自体が不正確な情報として扱われます。修正する場合は、メールアドレスを先に直し、確認メールに応答してからほかの項目を直すと、途中で連絡が途切れずに済みます。登録者名や組織名を大きく変えると、gTLD では「登録者の変更」として扱われ、一定期間移管できなくなることがある点にも注意します。
手順4: 確認(検証)の状態を見る
レジストラの管理画面には、登録者メールアドレスの確認状態が表示されていることがあります。「未確認」「確認待ち」のような表示があれば、確認メールを再送して応答します。新規登録・移管・登録者情報の変更の直後は確認が求められる時期で、期限内に応答しないとドメインが停止される場合があります。
手順5: 通知を受け取れる運用にする
- レジストラからのメールが迷惑メールに振り分けられないよう、受信設定を確認します。
- 年に一度の登録情報の確認通知が届いたら、内容を見直す機会として使います。
- 担当者の交代や組織変更の手順書に「ドメインの登録者情報の更新」を入れておきます。
- 複数人で管理する場合は、個人ではなく役割用のアドレス(例:
domain-admin@で始まる共有アドレス)を登録します。
他人のドメインの情報が不正確だと気づいたとき
なりすましサイトなどで登録者情報が明らかに虚偽だと考えられる場合、gTLD ではまずそのドメインのレジストラの不正利用窓口(RDAP の abuse 連絡先)に報告します。レジストラが対応しない場合は、ICANN のコンプライアンス窓口に登録データの不正確さについて申し立てる手段があります。報告の際は、照会結果など客観的な根拠を添えます。.jp の場合は、JPRS や指定事業者の案内に従います。
まとめ
- WHOIS 精度ポリシーは、gTLD では ICANN の RAA と関連ポリシー、.jp では JPRS の規則が土台です。公開表示が伏せられても、正確さの要件は変わりません。
- RDAP や JPRS の WHOIS でレジストラを特定し、適用される規約の「連絡先」「応答期限」「応答しない場合の扱い」を把握します。
- 管理画面でレジストラが保持する登録情報そのものを点検し、仮の値や古い情報を修正します。修正はメールアドレスから先に行います。
- 確認状態の表示と年次の確認通知を見落とさないよう、受信設定と担当交代時の手順を整えます。
- 他人のドメインの虚偽情報は、まずレジストラの不正利用窓口へ、根拠を添えて報告します。