2026年7月8日

Thin Whois のドメインで凍結を避ける手順｜登録者情報の確認先と確認期限の押さえ方

ドメイン管理

.com や .net のような Thin Whois 方式のドメインでは、登録者情報を持っているのはレジストリではなくレジストラです。そのため凍結（clientHold などによる停止）を避けるには、レジストラに登録した情報を正確に保ち、レジストラから届く確認に期限内に応じることが中心になります。この記事では、Thin 方式で凍結が起きる仕組みを説明したうえで、自分のドメインの登録データがどこにあるかを確認する方法と、凍結を防ぐための具体的な手順を順に紹介します。

Thin 方式で凍結が起きる仕組み

Thin 方式のレジストリが持っているのは、ドメイン名・レジストラ・ネームサーバー・ステータス・登録日と有効期限といった、ドメインそのものの情報だけです。登録者の氏名・住所・電話番号・メールアドレスは、ドメインを管理しているレジストラだけが持っています。

ICANN の認定を受けたレジストラは、ICANN との契約（2013年版のレジストラ認定契約、RAA）に基づいて、登録者情報の正確さを確かめる義務を負っています。代表的なのが次の2つです。

登録者情報の検証: 新規登録、移管の受け入れ、登録者情報の変更のあと、レジストラは登録者のメールアドレス（または電話番号）を確認します。契約では 15日以内に確認が取れない場合、レジストラはドメインを停止するなどの対応を取ることになっています。
不正確な情報への対応: 第三者から「登録者情報が不正確だ」と報告された場合や、レジストラが不一致に気づいた場合、レジストラは登録者に確認を求めます。期限内に応じないと停止の理由になります。

これらの確認はレジストラが行うので、Thin 方式では「レジストラに登録した情報」と「レジストラからの連絡を受け取れるか」が凍結を防ぐ鍵になります。契約の文言や運用は改定されることがあるため、細部はレジストラの規約で確認してください（2026年10月現在）。

登録データがどこにあるかを確認する

まず、自分のドメインのレジストラと、そのレジストラの照会先を確かめます。.com の場合は Verisign のレジストリに問い合わせます。

# レジストリ（Verisign）の WHOIS：Registrar の行と照会先を見る
whois -h whois.verisign-grs.com example.com | grep -iE 'Registrar|Status|Expir'

# レジストリの RDAP：rel が related のリンクがレジストラの RDAP
curl -s https://rdap.verisign.com/com/v1/domain/example.com \
  | jq -r '.links[]? | select(.rel == "related") | .href'

2つ目のコマンドで表示された URL を開くと、レジストラが持っている登録データを照会できます。レジストリの応答には連絡先がほとんど含まれず、レジストラの応答に登録者の欄があるのが Thin 方式の特徴です。gTLD では ICANN が 2025年1月に WHOIS（ポート43）の提供義務を終了しており、WHOIS サーバーを止めたレジストラもあるため、照会先が応答しないときは RDAP を使います。

# レジストラの RDAP（上で表示された URL に置き換える）
curl -sL "https://rdap.example-registrar.com/domain/EXAMPLE.COM" \
  | jq '{status, entities: [.entities[]? | {roles, vcardArray}]}'

個人の情報は伏せられて表示されることが多いですが、レジストラは正確な情報を保持しています。表示を見て問題がなくても、次の手順で管理画面の登録情報そのものを点検します。

凍結を避ける手順

手順1: 登録者メールアドレスを点検する

凍結の原因で最も多いのは、確認メールを受け取れないことです。管理画面で登録者のメールアドレスを開き、次の点を確認します。

そのドメイン自身のアドレス（例: info@example.com）になっていないか。ドメインが止まるとメールも受け取れなくなり、確認が終わらない状態に陥ります。
退職者や前任者の個人アドレスになっていないか。
迷惑メールとして振り分けられないか。レジストラのドメインからのメールを受信許可に入れておきます。

変更する場合は、ほかの項目より先にメールアドレスを直し、届いた確認メールに応答してから次へ進みます。

手順2: 登録者情報を実在する正確な値にする

氏名・組織名・住所・電話番号を、実在する現在の情報にします。架空の住所や「test」などの仮の値、明らかに形式が崩れた電話番号は、それ自体が不正確な情報として扱われます。電話番号は国番号付きの形式（例: +81.312345678）で登録するのが一般的です。

手順3: 確認が求められる時期を把握する

新規登録、移管の受け入れ、登録者情報の変更の直後は、確認メールが届く時期です。これらの作業をしたら、その日から2週間ほどは確認メールを待ち、届いたらすぐに応答します。届かない場合は、待たずに管理画面から再送を依頼します。

手順4: 移管の前後で確認をやり直す

Thin 方式では、連絡先の情報はレジストリを経由して引き継がれません。レジストラを移管すると、移管先は登録者から改めて情報を受け取り、検証をやり直すことになります。

移管先の申し込み画面やアカウントに入力する登録者情報を、移管元と同じ正確な内容にします。
移管が完了したら、移管先からの確認メールに応答します。移管直後は確認を見落としやすい時期です。
移管後、レジストリの RDAP で Registrar が移管先に変わったこと、移管先の RDAP で登録者の欄が正しく表示されることを確認します。

手順5: 年に一度の登録情報の確認通知に目を通す

ICANN のポリシーにより、gTLD のレジストラは年に一度、登録者に登録情報の確認を促す通知を送ります。内容が古くなっていないかを見直す機会として使い、変わっている項目があれば修正します。通知を無視しても直ちに停止されるものではありませんが、見直しを習慣にしておくと、後で確認を求められたときに慌てずに済みます。

手順6: ステータスを監視する

それでも停止された場合に早く気づけるよう、ステータスを定期的に確認します。RDAP ではステータスが「client hold」のように小文字の語で返ります。

#!/bin/sh
# 保留（hold）が付いたドメインを知らせる簡単な確認
for d in example.com example.net; do
  st=$(curl -sL "https://rdap.org/domain/$d" | jq -r '.status[]?' | tr '\n' ',')
  case "$st" in
    *hold*) echo "WARN $d: $st" ;;
    *)      echo "OK   $d: $st" ;;
  esac
  sleep 5
done

cron などで1日1回動かし、WARN が出たら通知するようにしておくと、サイトが見えなくなる前後に気づけます。照会しすぎると制限を受けるため、間隔はあけてください。

凍結されてしまった場合

ステータスに clientHold が付いた場合は、レジストラからのメールで停止の理由と求められている対応を確認し、登録者情報の修正や確認に応じます。移管しても解決しないことが多く、今のレジストラで解除するのが近道です。解除後もしばらくは DNS のキャッシュが残るため、表示が戻るまで時間がかかることがあります。

まとめ

Thin 方式では登録者情報はレジストラが持っており、凍結を防ぐにはレジストラの登録情報と連絡手段を整えることが中心になります。
レジストリの RDAP にある related リンクから、レジストラの照会先と登録データを確認できます。
登録者メールアドレスはそのドメイン以外の長く使うアドレスにし、登録者情報は実在する正確な値にします。
新規登録・移管・登録者変更のあとは確認メールが届く時期なので、期限内に応答します。移管すると検証はやり直しになります。
RDAP のステータスを定期的に確認し、hold が付いたらすぐに気づける仕組みを用意します。