WHOIS検索ガイド：ドメイン所有者の調べ方とWHOIS情報の見方

WHOIS検索とは？

WHOIS検索とは、ドメイン名の公開登録データベースに対する問い合わせのことです。.com、.net、.orgといった分野別トップレベルドメイン（gTLD）のドメインは、レジストリとレジストラが登録情報を保持することを義務づけられており、その公開部分は誰でも読めます。検索結果からは、レジストラがどこか、ドメインがいつ作成されいつ期限切れになるか、どのネームサーバーを使っているか、そしてロック中か・保留中か・削除が近いかを示すステータスコードが分かります。

名前の由来はもともとUnixのコマンドです。1982年にRFC 812が、TCPポート43で動くARPANETのNICNAME/WHOISサービスを記述しており、whoisに続けて名前を入力して照会しました。現在このプレーンテキストのプロトコルの仕様となっているのがRFC 3912です。裏側のプロトコルは変わったのに、呼び名だけは残っています。2025年1月28日以降、ICANNはgTLDのレジストリとレジストラにポート43のWHOISの運用を求めておらず（.com、.name、.postを除く）、同じデータはJSON APIであるRDAPで提供されています。DNS RobotのWHOIS Lookupをはじめ、ほとんどのツールはまずRDAPに問い合わせ、その結果を今でもWHOIS情報と呼んでいます。

一方、WHOIS検索で今はもう返ってこないのが、ドメイン所有者の氏名・住所・メールアドレスです。2018年5月にGDPRが施行されて以降、レジストラは世界中で個人の連絡先情報をデフォルトで伏せるようになりました。このガイドでは、それでも残っている情報、その読み方、そして連絡先欄がREDACTED FOR PRIVACYになっているときに所有者へ連絡する方法を解説します。

WHOIS情報に含まれる項目

こちらはexample.comの実際のレジストリのレコードで、2026年10月27日にmacOSのwhoisコマンドで取得したものです。gTLDのレコードはどれも同じ形をしているので、これが読めればどのレコードも読めます。

Domain Name: EXAMPLE.COM
Registry Domain ID: 2336799_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.iana.org
Registrar URL: http://res-dom.iana.org
Updated Date: 2026-08-14T08:01:43Z
Creation Date: 1995-08-14T04:00:00Z
Registry Expiry Date: 2027-08-13T04:00:00Z
Registrar: RESERVED-Internet Assigned Numbers Authority
Registrar IANA ID: 376
Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited
Name Server: ELLIOTT.NS.CLOUDFLARE.COM
Name Server: HERA.NS.CLOUDFLARE.COM
DNSSEC: signedDelegation
DNSSEC DS Data: 2371 13 2 C988EC423E3880EB8DD8A46FE06CA230EE23F35B578D64E78B29C3E1C83D245A
>>> Last update of whois database: 2026-10-26T19:13:27Z <<<

レコードは5つのグループに分かれ、それぞれが別の疑問に答えます。

• 識別情報 — Domain NameとRegistry Domain ID。IDはレジストリ内部のキーで、ドメインの持ち主が変わっても変化しません。
• レジストラ — 所有者が料金を支払っている会社です。Registrar IANA IDはIANAのレジストラ一覧における固有番号、Registrar WHOIS Serverは連絡先情報が置かれている場所を示します。.comと.netではレジストリ自身が連絡先を保持していないためです。
• 日付 — Creation Date、Updated Date、Registry Expiry Dateの3つ。いずれもUTCです。作成日はドメイン年齢チェッカーが表示する日付でもあります。
• ステータス — 1つ以上のEPPステータスコード。レコードの中で最も役に立ち、同時に最も誤読されやすい部分なので、後ろに専用のセクションを設けています。
• 委任情報 — ネームサーバーとDNSSECのフラグ。ここがWHOISとDNSの接点です。ここでネームサーバーを変えれば、そのドメインのDNSレコードはすべて新しいネームサーバー側へ移ります。

WHOIS検索のやり方

検索の方法は3つあり、返ってくるデータは同じです。どれくらいの頻度で使うか、生の出力が必要かどうかで選んでください。

方法1：オンラインのWHOISツールを使う

DNS RobotのWHOIS Lookupを開き、ドメインを入力してEnterを押します（URLやメールアドレスを貼り付けても、登録ドメインとして読み取られます）。ツールはまずレジストリ自身のRDAPサーバー（IANAのリストにあるもの、およびリスト外でRDAPを運用するDENICなどのレジストリ）に問い合わせ、続いて連絡先項目についてレジストラのレコードを参照します。RDAPのないTLD、つまり国別コードのおよそ3つに2つ（.jp、.ru、.it、.euなど）では、代わりにレジストリのポート43サーバーに問い合わせます。結果として、不正利用の連絡先付きのレジストラ、作成日・更新日・有効期限、意味を添えたステータスコード、ネームサーバー、DNSSECの状態、ドメインの年齢が分かります。

ICANN Lookupは公式の代替手段です。すべてのgTLDについて権威がありますが、対応するのはレジストリがRDAPを運用している国別ドメインだけで、履歴も一括照会もDNSデータへのリンクもありません。GoDaddyやNamecheapなどのレジストラのサイトにも、同じ公開レコードを読むWHOISページがあります。使えますが、ドメインが空いていれば売りつけるための作りになっています。

方法2：whoisコマンド（macOS・Linux・Windows）

macOSにはwhoisクライアントが入っており、Linuxのディストリビューションにもパッケージがあります。ポート43のWHOISで通信し、レジストラへの参照を自動でたどって、各レコードを続けて表示します（macOSはIANAから始まるので3件出ます）。

# Basic lookup (follows registry -> registrar referral)
whois example.com

# Query one specific server and skip the referral
whois -h whois.verisign-grs.com example.com

# Only the lines you usually care about
whois example.com | grep -iE 'Registrar:|Creation Date|Expiry|Domain Status|Name Server'

# Debian/Ubuntu: install if missing
sudo apt install whois

Windowsにはwhoisが標準で入っていません。すっきりした選択肢は2つ、Microsoft純正のSysinternalsツールを使うか、Windows 10・11に同梱のcurlでRDAPに問い合わせるかです。

Windows：Sysinternalsのwhoisまたはcurl

Sysinternalsスイートからwhois.exeをダウンロードし、PATHの通った場所に置きます。-vでレジストラへの参照をたどれます。特定のサーバーを指定するときは、-hではなくドメインの後ろに書きます（whois example.com whois.verisign-grs.com）。何もインストールしたくない場合は、RDAPサーバーに直接問い合わせ、JSONの整形はPowerShellに任せます。

# Sysinternals whois (after download)
whois -v example.com

# No install: query RDAP and pretty-print the JSON
curl.exe -sL -H "Accept: application/rdap+json" https://rdap.org/domain/example.com | ConvertFrom-Json | Select-Object ldhName, status, events, nameservers

方法3：RDAPに直接問い合わせる（スクリプト向け）

スクリプトでWHOISのデータを扱うなら、テキスト形式ではなくRDAPを呼び出しましょう。応答はスキーマが決まったJSONなので、正規表現を書かずにフィールドを取り出せます。.comのレジストリはrdap.verisign.comが応答します。それ以外のTLDでは、rdap.orgがIANAのブートストラップファイルから正しいサーバーを探してリダイレクトしてくれます。

# Registry record for a .com, straight from Verisign
curl -s -H 'Accept: application/rdap+json' \
  https://rdap.verisign.com/com/v1/domain/example.com | jq '{status, events, nameservers: [.nameservers[].ldhName]}'

# Any TLD: let rdap.org find the authoritative server
curl -sL https://rdap.org/domain/example.org | jq '.events'

# Output of the first command (trimmed: Verisign also returns a "last update of RDAP database" event)
{
  "status": ["client delete prohibited", "client transfer prohibited", "client update prohibited"],
  "events": [
    { "eventAction": "registration", "eventDate": "1995-08-14T04:00:00Z" },
    { "eventAction": "expiration",   "eventDate": "2027-08-13T04:00:00Z" },
    { "eventAction": "last changed", "eventDate": "2026-08-14T08:01:43Z" }
  ],
  "nameservers": ["ELLIOTT.NS.CLOUDFLARE.COM", "HERA.NS.CLOUDFLARE.COM"]
}

レジストリの応答に含まれるlinks配列には、レジストラ自身のRDAPサーバーへのrelatedリンクが入っています。これを辿ると、伏せられているかどうかはともかく、連絡先のオブジェクトが得られます。よくできたWebツールは、この一連の処理を1回のリクエストで肩代わりしてくれます。自分で組み込むなら、公開APIエンドポイントのテスト方法で紹介した6ステップの手順は、他のJSON APIと同じくRDAPサーバーにもそのまま当てはまります。

WHOIS情報の見方（フィールド別）

多くの人がWHOIS検索を実行する動機は、次の4つの疑問のどれかです。答えがレコードのどこにあるかを見ていきましょう。

そのドメインは取得済みか？ レコードが返ってくれば、答えは「はい」です。登録済みのドメインには必ずCreation Dateがあります。レジストリがNo match for domainを返すか、RDAPがHTTP 404を返した場合、その名前は未登録——あるいはレジストリの予約名です。短い単語や辞書に載っている単語では予約がよくあります。両者を見分けるにはドメイン取得可否チェッカーを使ってください。DNSでも併せて確認してくれます。

いつ期限切れになり、開放されるのか？ まず有効期限を読み、次にステータスコードを読みます。autoRenewPeriodやredemptionPeriodのドメインはまだ開放されていません。所有者は更新または復元できます。開放されることを意味するのはpendingDeleteだけで、そこからさらに5日ほどかかります。全体の流れは後述のライフサイクルのセクションで追います。レジストリの日付だけで判断しないでください。gTLDのドメインが期限切れになると、レジストリが自動的に1年分更新するため、Registry Expiry Dateはすでに翌年を示していても、レジストラ自身のレコード（Registrar Registration Expiration Date）には所有者が支払いをやめた日がそのまま残っていることがあります。両者が食い違うときは、ドメインが開放されるかどうかをステータスコードが決めます。

誰が管理しているのか？ 連絡すべき相手はRegistrarです。Registrar Abuse Contact Emailと電話番号は、他がすべて伏せられていても公開されています。これは意図した設計で、ICANNの登録データポリシーがこれらの項目を公開し続けるよう定めています。

最近変更されたか？ Updated Dateは、レジストラが何らかの変更を反映するたびに動きます。更新、ネームサーバーの切り替え、ロックの追加や解除などです。先週ネームサーバーが変わり来月期限切れになるドメインと、2015年から何も触られていないドメインとでは、リスクの性格がまるで違います。ネームサーバーが変わっていたら、NSルックアップでDNSの現在地が分かります。

ドメインのステータスコード（EPP）を読み解く

ステータスコードは、WHOIS情報の中で最も価値のある行であり、同時に最も誤読される行でもあります。EPPプロトコルで定義され、各コードの意味はICANNが公開しています。clientで始まるコードはレジストラが設定したもの（通常は所有者の求めに応じて）、serverで始まるコードはレジストリが設定したもので、解除できるのはレジストリだけです。

覚えておきたいパターンはこれです。clientTransferProhibited + clientUpdateProhibited + clientDeleteProhibitedは、健全で何の問題もない状態です。突然どこにも名前解決できなくなりclientHoldが付いているドメインは、DNSではなく所有者の受信トレイを確認する必要があります。また、誰かが放置して失効したドメインを買おうと待っているなら、pendingDeleteより前の段階を見ていても意味がありません。

WHOISに「REDACTED FOR PRIVACY」と出る理由

2018年まで、.comのWHOISレコードには通常、登録者の氏名、住所、電話番号、メールアドレスがすべて載っていました。レジストラはWHOISプライバシーを有料オプションとして販売し、これらの項目をプロキシサービスの情報に置き換えていました。その後、2018年5月25日にEUのGDPRが施行されました。ICANNが1週間前に採択した暫定仕様（Temporary Specification）も同じ日に発効し、レジストラは、誰が対象かを判断しようとするのをやめて、全員の個人データを伏せるようになりました。この暫定ルールは、ICANNの登録データポリシーに置き換えられ、2025年8月21日から完全に適用されています。レジストラはプライバシー法が求める場合に個人データを伏せなければならず、それ以外の人についても伏せてかまいません。

cloudflare.comのレジストラレベルのRDAPレコードが、現在、登録者について返す内容は次のとおりです（一部省略）。

{
  "objectClassName": "entity",
  "roles": ["registrant"],
  "vcardArray": ["vcard", [
    ["fn",  {}, "text", "DATA REDACTED"],
    ["org", {"type": "work"}, "text", "DATA REDACTED"],
    ["adr", {"cc": "US", "type": "work"}, "text",
      ["", "", ["DATA REDACTED", "DATA REDACTED"], "DATA REDACTED", "CA", "DATA REDACTED", ""]],
    ["contact-uri", {}, "uri", "https://domaincontact.registrar.cloudflare.com/cloudflare.com"]
  ]],
  "remarks": [{ "title": "REDACTED FOR PRIVACY",
                "description": ["Some of the data in this object has been removed"] }]
}

ポリシーは、何が公開のまま残るかを明確に定めています。gTLDのドメインでは、次の項目は必ず公開されなければなりません。ドメイン名、レジストラ名とIANA ID、レジストラのURL、レジストラの不正利用連絡先のメールアドレスと電話番号、作成日、有効期限、ネームサーバー、ステータスコードです。さらに、伏せ字化が完全になることはありません。ポリシーは、登録者の州・都道府県と国を公開するよう求めており、登録者が公開に同意した場合は組織名も公開されます。そのため、伏せられたレコードでも、所有者がカリフォルニアやバイエルンにいることは分かります。上のレコードでは、それがCAとUSで、加えてCloudflareの問い合わせフォームへのcontact-uriリンクがあります。

プライバシーと伏せ字化の実務上の違いはこうです。有料のWHOISプライバシーサービスは、プロキシのアドレス宛てに送られたメールを転送し続けます。一方、単なる伏せ字化ではメールアドレスが削除され、レジストラによって問い合わせフォームへのリンクか匿名化された転送用アドレスに置き換えられます。どちらの場合も、第三者は所有者が誰かを知らないまま、所有者に連絡する手段を得られます。

WHOISが伏せられているときにドメイン所有者を調べる方法

非表示によって正面玄関は閉じましたが、ドメインは他のあらゆる場所に痕跡を残します。上から順に試してください。1つあたり1分ほどです。

• 伏せられていない項目を読む。 州・都道府県と国は常に公開されており、登録者が同意していれば組織名も公開されます。レジストラ自体も手がかりです。MarkMonitorやCSCにあるドメインは大企業の保有で、Cloudflare Registrarにあるものは開発者やスタートアップである可能性が高いです。
• レジストラの連絡リレーを使う。 レジストラは登録者へ連絡する手段を必ず用意しています。abc123@contact.gandi.netのような匿名メールアドレスか、WHOISの出力からリンクされたWebフォームです。正当な内容であれば転送されます。
• SSL証明書を確認する。 企業実在認証（OV）と拡張認証（EV）の証明書には、Subject欄に法人名が入っています。SSLチェッカーでドメインを調べ、証明書チェーンを読んでください。組織名がどこに入るかはSSL証明書チェーンの解説で説明しています。
• DNSを見る。 SOAレコードのRNAME欄は、ゾーン管理者のメールアドレスの@をドットに置き換えたものです。TXTレコードからは、利用しているメールプロバイダー、Google・Microsoft・Facebookの所有権確認トークン、ときには社名そのものが読み取れます。SOAとTXTのDNSルックアップは数秒で終わり、サブドメイン検索を使えばmail.、crm.、jira.のように、その会社が使っているツールを物語るホスト名が見つかります。
• WHOIS履歴を調べる。 2018年5月より前のレコードは公開されており、複数の商用サービスがアーカイブしています。それよりかなり前に登録されたドメインなら、当初の登録者が写った非表示前の履歴が残っていることがよくあります。ただし、当時からプライバシーサービスを使っていた場合は別です。
• 逆引きWHOIS。 社名や生き残ったメールアドレスなど、確かな手がかりが1つあれば、逆引きWHOISサービスがそれを登録情報に使ったことのあるドメインをすべて洗い出します。高価ですが、ブランド保護チームがスクワッターの保有ドメインを地図化するのはこの方法です。
• 開示請求を出す。 商標紛争、フィッシング、詐欺など法的な必要がある場合は、ICANNの登録データ請求サービス（RDRS）が正式な開示請求をレジストラへ取り次ぎます。対象はgTLDのみで、参加しているレジストラに限られます。2年間の試験運用（2023年11月28日から2025年11月30日）では3,700件を超える請求があり、26%が承認、55%が却下されました（ICANN）。ICANNは、コミュニティが今後を決めるあいだも運用を続けています。

WHOISとRDAPの違い：2025年に何が変わったか

RDAP（Registration Data Access Protocol）は、ポート43のWHOISが抱えていた問題をすべて解消するためにIETFが設計したもので、いまのWHOIS検索ツールが実際に使っているのはこちらです。データを使って何かを作るなら、違いは押さえておく価値があります。

実務上の帰結は2つあります。1つ目は、whoisのテキスト出力を解析しているスクリプトは、猶予付きで動いているということです。.com、.name、.post以外では、レジストリやレジストラがポート43のサービスをいつでも止められ、すでに止めたところもあります。.appと.devを扱っていたGoogle Registryのwhois.nic.googleは名前解決すらできなくなり、レジストラGoDaddyのWHOISサーバーはどの問い合わせにも「This WHOIS server is being retired. Please use our RDAP service instead.」と返します（いずれも2026年10月27日に確認）。

2つ目は、RDAPのブートストラップが、WHOISが解決できなかった問題を解くことです。example.museumが与えられたら、クライアントはdata.iana.org/rdap/dns.jsonを一度ダウンロードし、museumのエントリを見つけて、ハードコードされた知識なしに権威サーバーへ問い合わせます。切り替わりはトラフィックにも表れています。ICANNの月次レポートでは、gTLDへのRDAP問い合わせが2025年1月の月約70億件から2025年8月には650億件に増え、2025年6月にポート43のWHOISを追い抜きました（APNIC）。

国別ドメイン：レジストリごとにルールが違う

ICANNのポリシーが拘束するのはgTLDだけです。国別コードTLD（.de、.uk、.br、.jpなど約300）は独自のルールを定めており、ccTLDへのWHOIS検索では、検証済みの完全な身元から、ほとんど何も返らない場合まで、さまざまな結果になります。2026年10月27日に8つのレジストリで公開検索を行った結果は次のとおりです。

目盛りの反対の端にあるのが、example.deに対するDENICのポート43の応答のすべてです。

% The DENIC whois service on port 43 doesn't disclose any information concerning
% the domain holder, general request and abuse contact.
% This information can be obtained through use of our web-based whois service
% available at the DENIC website:
% https://webwhois.denic.de/?lang=en

Domain: example.de
Nserver: ns1078.ui-dns.biz
Nserver: ns1078.ui-dns.com
Nserver: ns1078.ui-dns.de
Nserver: ns1078.ui-dns.org
Status: connect
Changed: 2018-08-10T05:24:12+02:00

レジストラも、作成日も有効期限も、所有者もありません。しかもステータスの語彙（connect）は、EPPではなくDENIC独自のものです。

IPのWHOIS検索：IPアドレスの保有者を調べる

同じwhoisコマンドはIPアドレスにも使えますが、答えが返ってくるデータベースは別物です。ドメイン名を管理するのはレジストリとレジストラですが、IPアドレスのブロックを割り当てているのは5つの地域インターネットレジストリ（RIR）——北米のARIN、欧州・中東のRIPE NCC、アジア太平洋のAPNIC、中南米のLACNIC、アフリカのAFRINIC——です。IPのWHOIS情報からは、そのブロックをどの組織が保有しているか、ブロックのサイズ、割り当て先の国、そして不正利用の報告先が分かります。サーバーを攻撃してくるアドレスやスパムの送信元を調べるときに必要になるのは、まさにこれです。

# Port-43 WHOIS: the client finds the right RIR automatically
whois 1.1.1.1

# RDAP: rdap.org redirects to the right RIR (APNIC here)
curl -sL https://rdap.org/ip/1.1.1.1 | jq '{name, handle, startAddress, endAddress, country, type}'

# Output
{
  "name": "APNIC-LABS",
  "handle": "1.1.1.0 - 1.1.1.255",
  "startAddress": "1.1.1.0",
  "endAddress": "1.1.1.255",
  "country": "AU",
  "type": "ASSIGNED PORTABLE"
}

IPのレコードからは、そのアドレスでどのWebサイトがホストされているかは分かりません。クラウドのIP 1つが数千のドメインを受け持つこともあるからです。利用者の物理的な所在地も分からず、分かるのはブロックが登録された場所だけです。コマンドラインを使わずに手早く調べたいときは、IPルックアップがRIRのデータと位置情報をまとめて表示し、ASN検索ではそのブロックがどのネットワークから広告されているかが分かります。IPからホスト名を逆に辿るには、WHOISではなくPTRレコードを読む逆引きDNSを使ってください。

有効期限の読み方：ドメインのライフサイクル

ステータスコードは、所有者が支払いをやめた後にgTLDドメインが辿るタイムラインと合わせて見ないと意味が分かりません。ICANNの期限切れ登録回復ポリシーが最低ラインを定め、レジストリとレジストラがそれぞれ独自の余裕を上乗せするため、多くの人が思うよりずっと長い道のりになります。

• About 30 days and again about 7 days before expiry — the registrar must email the owner. A third notice follows within 5 days after expiry.
• Day 0 (expiry) — the registry auto-renews the domain and sets autoRenewPeriod. The registrar has up to 45 days to keep it or delete it. Before deleting it, the registrar must stop it resolving for at least the last 8 days (or from expiry, if it deletes sooner), so the site goes dark; many registrars park it on a page that says the domain has expired.
• Day 1–45 (registrar grace) — the owner can still renew. ICANN only guarantees this while the domain is interrupted (ERRP); how long the registrar allows beyond that, and at what price, is its own policy, and it must publish its post-expiry fees on its website.
• Deletion → redemptionPeriod (30 days) — the registrar deleted it. The owner can still restore it, for a restore fee the registrar must show on its website, on top of the renewal. Nobody else can register it.
• pendingDelete (5 days) — restoration is no longer possible. At the end of this window, at a time the registry does not announce, the name is purged and becomes available.
• Drop — the domain is free to register, and drop-catching services that have been polling the registry compete for it within milliseconds.

したがって、レジストラのレコードの有効期限が2週間前のドメインは、実際に取得可能になるまでまだ35〜66日ほどあるかもしれず、そもそも取得可能にならないかもしれません。所有者はpendingDeleteまでいつでも取り戻せるからです。見るべきは有効期限ではなくステータス行です。1日1回WHOIS検索を実行して、ステータスの変化を控えておけば十分です。

WHOIS検索は実際に何に使われているか

「この名前は空いているか」以外にも、サポート窓口やセキュリティチームで繰り返し出てくる用途がいくつかあります。

信頼していいサイトかどうかの確認。 創業10年をうたうショップのドメインが3週間前に作成されていたら、それは何かを物語っています。作成日、レジストラ、ネームサーバーの確認は10秒で済み、レジストリのレコードは偽装できません。

名前解決しなくなったサイトの切り分け。 DNSに触る前に、ドメインが期限切れでないか、clientHoldになっていないかを確認してください。そうなっていたら、DNSをどういじっても直りません。ネームサーバーを移行した後は、WHOISのName Server行を見れば、レジストラが実際に変更を反映したかどうかが分かります。リゾルバーは古いネームサーバーを最長48時間（.comの委任レコードのTTL）キャッシュすることがあります。NSルックアップを使えば、いま世界から見えている内容が分かります。

取得済みドメインの買い取り。 WHOISからは、レジストラ（仲介サービスを持つところもあります）、ドメインがロックされているか、現在の所有者がどれくらい長く保有しているか、期限切れに向かっていないかが分かります。

フィッシングや不正利用の調査。 Registrar Abuse Contact Emailが公開されているのは、悪意あるドメインを停止できる当事者に報告してもらうためです。ホスティング事業者については、IPのWHOISにある不正利用報告先と併せて使ってください。

自社ドメインの棚卸し。 ドメインを失う原因は、ハッカーだけでなくクレジットカードの期限切れもあります。保有するすべてのドメインについて四半期に一度WHOISで有効期限とロック状態を確認しておけば、安上がりな保険になります。

WHOISフィールド早見表

gTLDのレコードで目にするすべてのフィールドと、JSONを解析する人向けにRDAPでの対応箇所をまとめました。

目の前のレコードがこの表に当てはまらないなら、ほぼ間違いなくccTLDです。その場合は、レジストリ自身のドキュメントが拠り所になります。