who-owns-this-domain

このドメインの所有者を調べる

登録情報からは誰がその名前を購入したかが分かり、DNS からは誰がサービスを運営しているかが分かります。この両者は別の当事者であることが多く、混同すると帰属の特定を誤ります。ここに記載する調査は、明記されている箇所を除きすべてパッシブです。ただし、対象のネームサーバーに向けて dig を実行すると、そのクエリは対象のログに残るため、気付かれずに調べたい場合は、公開再帰リゾルバーまたはパッシブ DNS 経由で名前を解決してください。

まず使う情報源

手元にあるもの	調べるもの	理由
ドメインのみ	RDAP、次にレジストラーの WHOIS	構造化されており、一度の照会で日付、レジストラー、ステータスを確認できます
マスキングされた WHOIS	過去の WHOIS とパッシブ DNS	アーカイブ上の情報は遡ってマスキングされません
多数のドメインのうちの一つと思われるドメイン	ネームサーバーのペア、MX、逆引き WHOIS	インフラの再利用は連絡先のプライバシーより長く続きます
IP	RIR の IP RDAP、次に ASN の検索	ネットブロックの保有者が分かりますが、サイトの所有者は分かりません
ccTLD	レジストリ独自の WHOIS／ウェブサービス	ccTLD は gTLD のポリシーに従わず、情報の網羅性には大きな差があります
新規登録されたばかりのドメイン	作成日、レジストラー、NS	ドメインの新しさと一括登録しやすいレジストラーの組み合わせは、フィッシングの兆候です

WHOIS と RDAP の違い

WHOIS は TCP/43 を使う、スキーマのないプレーンテキストプロトコルです。レジストリごとに出力されるフィールドの形式が異なり、クライアントによるレジストリからレジストラーへの照会先のたどり方にもばらつきがあります。また、レート制限は通知されないため、エラーとして解析できる情報が返るのではなく、応答が途中で切れるか、ブロックされます。

RDAP は同じ登録情報を JSON として HTTPS 経由で提供し、適切な HTTP セマンティクスを備えています。該当オブジェクトがない場合は 404、レート制限時は 429 が返り、ドメイン、ネームサーバー、エンティティ、IP、AS 番号ごとのエンドポイントがあります。ブートストラップリダイレクターまたはレジストリに直接問い合わせてください。

curl -s https://rdap.org/domain/example.com | jq .
curl -s https://rdap.org/ip/203.0.113.10 | jq '.name, .handle, .country'
curl -s https://rdap.org/autnum/64500 | jq '.name, .entities'

以下のフィールドを確認してください。

• events — registration、expiration、last changed、transfer。登録からかなり後の日付の transfer イベントは、現在のレジストラーの記録がその時点から始まっていることを意味します。それ以前の情報は、過去の WHOIS にしか残っていません。
• entities[].roles — registrant、technical、abuse、registrar。レジストラーのエンティティには、publicIds に IANA ID が含まれています。
• status — EPP コードです。clientTransferProhibited は通常の状態です。clientHold は、レジストラーがドメインを DNS から外したことを意味します（未払いまたは不正利用に関する苦情が原因です）。serverHold はレジストリが外したことを意味し、通常は法的措置または法執行機関の措置によるものです。redemptionPeriod と pendingDelete は、ドメインの有効期限が切れ、まもなく利用可能になることを意味します。
• nameservers と secureDNS — 運用者の特徴と DNSSEC の状態です。

一部のサーバーは、どのフィールドがマスキングされたかを機械可読形式のリストでも返します。これは、REDACTED FOR PRIVACY という文字列から推測するよりも役立ちます。

.com と .net のレジストリが返す情報は限定的で、レジストラー、日付、ステータス、ネームサーバーのみです。連絡先情報が提供される場合は、レジストラー独自のサーバーから取得します。両者の情報が異なる場合は、両方に問い合わせてください。日付と移管についてはレジストリが、連絡先についてはレジストラーが権威を持ちます。

レッドアクションによって実際に削除される情報

現在の gTLD 登録データポリシーでは、登録者の氏名、住所、電話番号、メールアドレスは通常削除され、転送先住所またはウェブフォームに置き換えられます。残り、強力な手掛かりとなる情報は、登録を管理するレジストラとその IANA ID、存在する場合はリセラー欄、作成・更新・有効期限・移管の日付、ネームサーバー、DNSSEC のステータス、EPP ステータスコード、登録者の州・地域と国（多くのレジストラがこれらを保持しています）、登録者の組織（法人については、会社名は個人データではないという主張から、一部のレジストラが保持しています）、そしてレジストラの不正利用窓口です。不正利用窓口は決してレッドアクションされず、報告の適切な窓口です。

登録を管理するレジストラ（Tucows、PDR、Namecheap などの ICANN 認定事業者）と、実際にドメインを販売したリセラーを区別してください。また、それらの両方と、独自の法人名と管轄地で登録者欄に表示されるプライバシーサービスも区別してください。プライバシーサービスの身元自体が手掛かりになります。利用されているレジストラのエコシステムが分かり、情報開示請求をどこに送ればよいかも分かります。

DNS の調査

dig +short example.com A; dig +short example.com NS
dig example.com MX +noall +answer
dig example.com SOA +noall +answer          # RNAME mailbox, serial often YYYYMMDDnn
dig example.com TXT +short                  # SPF and verification tokens
dig _dmarc.example.com TXT +short
dig google._domainkey.example.com TXT +short
dig example.com CAA +short
dig -x 203.0.113.10 +short

ANY を使うワークフローは構築しないでください。現在、ほとんどの権威サーバーは、完全なレコードセットの代わりに最小限の応答または合成された応答を返します。

各レコードタイプから得られる情報は異なります。解釈表はreference/dns-record-types.mdにあり、SPF の include ホスト、DKIM セレクター、TXT トークンとベンダー名の対応表はreference/vendor-fingerprints.mdにあります。要点をまとめると、TXT は組織の SaaS 環境の公開インベントリであり、MX からはメールセキュリティベンダーが分かり、DMARC の rua からは利用している DMARC レポートベンダーが分かり、CAA からは標準として採用した CA が分かります。

IP、ASN、共有ホスティングによる代償

whois -h whois.cymru.com " -v 203.0.113.10"        # ASN, prefix, country, AS name
whois -h whois.radb.net -- '-i origin AS64500'     # prefixes routed by that AS

RIR レコードからは、ネットブロックの保有者が分かります。それがホスティングプロバイダーやクラウドのリージョンであれば、所有者について新たに分かったことはありません。共有 IP は、ドメインを無関係な何千ものテナントと結び付けるため、「同じ IP」は帰属を示す証拠として役に立ちません。RIR レコードに、特定顧客への再割り当てやサブアロケーションが記載されている場合、またはブロックが小さく組織名が調査対象と一致する場合には、証拠になります。

PTR はドメイン所有者ではなく、IP を管理する側が設定します。クラウドではアドレスから機械的に生成されるため、分かるのはプラットフォームだけです。コロケーションや企業のブロックには顧客名が付いていることが多く、既知のホストが含まれる /24 の PTR を調べることで、組織のラック全体が明らかになる場合があります。

過去の WHOIS とパッシブ DNS

ここに、実際に有効な手掛かりがあります。レッドアクションはある時点から始まったため、それ以前のレコードを保存しているデータベースには、今も氏名、メールアドレス、電話番号が残っています。パッシブ DNS には観測されたすべての応答が保存されるため、ゾーンが現在提供していない IP やホスト名も取得できます。次の 3 つの質問をしてください。非公開になる前、登録者欄には何が記載されていたか、その登録者のメールアドレスまたは氏名を共有するドメインはほかにあるか（逆引き WHOIS）、そしてこの名前は時系列でどの IP に解決されてきたか。DomainTools、SecurityTrails、WhoisXML、Validin、Silent Push、VirusTotal のドメインレポートでは、この 2 種類のデータの一部を参照できますが、ほとんどのサービスでは有用な詳細情報を有料のキーで制限しています。

ゾーン転送とゾーンウォーキング

dig AXFR example.com @ns1.example.com は、ネームサーバーにゾーン全体を要求します。これは対象が管理するインフラへの対話型 TCP リクエストであり、ログに記録されるため、パッシブ調査の範囲外です。認可された調査の内部でのみ実施してください。また、拒否されることを想定してください。NSEC3 ではなく NSEC で署名されたゾーンも同様にウォーキングしてすべての名前を列挙できます。また、NSEC3 ハッシュはオフラインで解読できます。どちらも権威サーバーへの直接クエリが必要です。どちらもアクティブな調査として扱い、パッシブな状態を維持する必要がある場合は find-hidden-subdomains を使用してください。

ここで誤った判断につながります

• 登録者情報は代行業者のものです。 大量登録業者、再販業者、プライバシー保護サービス、法人向け登録業者は、すべて連絡先フィールドに自社の情報を記載します。複数のドメインで登録者の文字列が一致しても、所有者が同じなのか、再販業者が同じなのかは分かりません。
• 日付は登録期間を正しく示しません。 期限切れ後に再登録されたドメインは、レジストリ上の作成日がリセットされます。そのため、アーカイブに長い履歴があるのに作成日が最近なら、ドロップを経てドメインの所有者が変わったことを意味します。
• DNS はキャッシュされ、隠されます。 DNS の応答は TTL の範囲内で有効なスナップショットであり、プロバイダーは地域やリゾルバーによって異なるレコードを提供します。また、外部からは見えないスプリットホライズンビューもあります。1 つのリゾルバーから得られるのは、1 つの視点にすぎません。
• SPF レコードと TXT レコードは古くなります。 SPF に存在するということは「設定されていた」という意味であり、「現在も使われている」という意味ではありません。検証トークンは、ほとんどの場合、削除されずに残っています。
• MX と NS は外部委託されています。 これらが示すのはベンダーです。割り当てられた特定のネームサーバーの組み合わせやメールテナントのラベルが複数のドメインで繰り返し現れる場合に限り、所有者を特定する手がかりになります。
• パーキングされたドメインには、レジストラーの DNS とマーケットプレイスの IP アドレスが表示されます。調査対象となる所有者のインフラはありません。スクワッターは正規のドメインに見せかけるため、標的の SPF と MX を丸ごとコピーすることがあります。そのため、レコードが一致しても関係があるとは限りません。

確度の評価

• 確証あり — レジストリまたは RIR が直接提示しており、連絡先フィールドではない情報です。作成日、レジストラー、EPP ステータス、ネームサーバー、ネットブロックの保有者などが該当します。 または、非公開化されていない登録者情報が、別の独立した情報源（法人登記、過去のスナップショット、アーカイブされたページなど）によって裏付けられている場合です。
• 可能性が高い — 複数のドメインにまたがって特徴的な共通フィンガープリントが見られる場合です。同じ割り当て済みネームサーバーの組み合わせ、同じメールテナントのラベル、同じ DKIM キー、同じ CAA accounturi、同じ珍しい TXT トークンなどが該当します。同じ運用者であり、おそらく所有者も同じです。
• 未確認 — 共有ホスティング上の共通 IP、共通のレジストラー、共通の公開 DNS プロバイダー、または再販業者の可能性がある登録者の文字列です。また、元のレコードを確認していない過去のデータベースの情報も該当します。

照会のタイムスタンプと、応答したサーバーを必ず記録してください。取得時刻のない WHOIS レコードは証拠になりません。

実例

対象：northwind-logistics.example。詐欺対策チームからの紹介です。

RDAP：作成から 11 か月、レジストラーは Namecheap、登録者は非公開ですが、国は PA、ステータスは clientTransferProhibited、ネームサーバーは Cloudflare の組み合わせ（dana、rex）です。作成から日が浅く、安価なレジストラーを利用し、プロキシ経由で、オリジンは隠されています。

DNS：MX がまったくないため、「このドメインから請求書を送っている」という仮説は否定されます。TXT には 1 つの google-site-verification トークンと、トランザクションメールのベンダーのみを include する SPF レコードがあります。DMARC は p=none で rua もないため、手がかりとなるレポートベンダーもありません。メール関連の調査はここで行き詰まります。

突破口は過去の WHOIS です。登録から 2 か月後のスナップショットには、プライバシー保護サービスが適用される前の Gmail アドレスと名前が記載されています。このアドレスを使ったリバース WHOIS では、さらに 6 つのドメインが見つかり、そのうち 4 つが同じ dana／rex の組み合わせを共有しています。Cloudflare はこの組み合わせをアカウント単位で割り当てるため、偶然の一致ではなく、同じ運用者によるものです。

評価：登録者の身元は可能性が高い（スナップショットは 1 つのみで、ネームサーバーのクラスタによって裏付けられていますが、登記資料による裏付けはまだありません）。7 ドメインのクラスタは、同じ運用者によるものとして確証ありです。

次の調査先

新しい検索対象	次の調査先
サブドメイン、共有証明書上の兄弟ドメイン	find-hidden-subdomains
IP、ネットブロック、ASN	find-exposed-servers
登録者のメールアドレス、メールベンダー、転送先住所	what-an-email-reveals
登録者の組織、プライバシー保護サービスの管轄区域	who-really-owns-it、x-ray-a-company
非公開化前のスナップショットに記録された登録者の電話番号	whose-number-is-this
復元した IP とホスト名にある過去のコンテンツ	read-deleted-pages
発見したホスト名上でインデックスされたファイル	google-like-a-spy
図式化するドメイン、IP、登録者のクラスタ	graph-the-network

法務および利用規約に関する注意事項

WHOIS の一括アクセスは、契約上制限されています。レジストリおよびレジストラは、マーケティングや再配布可能なデータベースの構築を目的とした利用を禁じており、レート制限やブロックによってこれを徹底しています。RDAP ではアクセスに差が設けられており、審査を受けた認証済みのリクエスターは、匿名のリクエスターより多くの情報を閲覧できます。この審査があるのは、個人データを匿名で一括収集できないようにするためです。過去のデータベースから取得した、編集前の登録者データも GDPR 上の個人データであり、適法な根拠が必要です。また、../../ETHICS.md に記載されたデータ最小化のルールが適用されます。書面による許可なしに AXFR を実行すると、不正アクセスに該当する可能性があります。