DNS履歴でドメイン調査: MXとNSレコードからわかること

DNSレコードはドメインが残す足跡です。MXとNSの履歴は、そのドメインのメールとDNSを誰が担当していたかを示し、サイトが何に使われていたか、いつ所有者が変わったかの手がかりになることがよくあります。墓地で死んだプロジェクトのドメインを吟味するときや、自分のドメインを埋葬するかどうかを決めるときに役立ちます。

DNS履歴調査とは？

DNS履歴調査とは、過去のDNSレコード、特にMXとNSを照会してドメインの運用履歴を再構築する手法です。公開データベースやパッシブDNSツールを使って、ドメインが時間とともにどのメールサーバーやネームサーバーを指していたかを確認します。変更の一つひとつが、所有権、ホスティング、目的に関する手がかりになります。

ステップ1: 現在のDNSベースラインをどう集めるか

まずはライブのレコードから始めて、何と比較するのかを把握します。ターミナルで dig MX example.com +short と dig NS example.com +short を実行するか、Google Public DNS lookupやMXToolboxのようなWebツールを使います。出力をタイムスタンプとともに保存してください。このベースラインが、以後のすべての履歴比較の基準になります。

ドメインにMXレコードがまったくない場合、それ自体がデータポイントです。現在メールを受け取る設定になっていないということで、パーキング中や燃え尽きたプロジェクトではよくあることです。

ステップ2: 過去のMXとNSレコードを表示するツールは？

ライブのルックアップだけでなく、パッシブDNSデータベースが必要です。SecurityTrails、ViewDNS.info、DNSDumpsterはいずれも履歴ビューを提供しており、無料のものも有料のものもあります。SecurityTrailsの無料プランはクエリ数が限られ、有料プランは月額約50ドルからです。ViewDNS.infoの履歴DNSツールは無料ですがレート制限があります。一度きりの確認なら、通常はそれで十分です。

単一の情報源を信用しないでください。結論を出す前に2つのツールでクロスチェックしましょう。パッシブDNSのカバレッジはプロバイダーや地域によって異なるからです。

ステップ3: MXレコードの履歴をどう読むか

MXレコードは、ドメインのメールを受け取るメールサーバーを指します。Google Workspace（ASPMX.L.GOOGLE.COM）を示す履歴があれば、かつてそこで本物のビジネスが運営されていた可能性が高いです。数週間ごとにランダムなメールサーバーが入れ替わるような履歴は、スパムインフラや使い捨てプロジェクトなど、あまり合法的でないものを示唆します。

パターンを探しましょう。長年にわたって安定したMXプロバイダーがあれば、安定した運営者がいたことを意味します。頻繁なMXの入れ替わりはその逆です。どちらも自動的に悪いわけではありませんが、どちらもどんなプロジェクトを引き継ぐのかを教えてくれます。

ステップ4: NSレコードの履歴をどう読むか

NSレコードは、ドメインのDNSを管理していた企業を示します。通常はレジストラ、ホスティングプロバイダー、またはCDNです。あるNSプロバイダーから別のプロバイダーへの移動は移行イベントであり、移行は所有権の変更やリブランドと同時に起こることがよくあります。

NS履歴が長年Cloudflareを示した後、突然格安レジストラのデフォルトネームサーバーに切り替わった場合、それはドメインが放棄されたか売却されたシグナルです。インディーハッカーが気にすべき理由は、その切り替えが活発な開発の終わりを示すことが多いからです。

ステップ5: DNS履歴をWHOISやウェブアーカイブとどう照合するか

DNS履歴だけでは薄い情報です。WHOIS履歴（DomainToolsが提供しており、多くのレジストラも限られた記録を保持しています）とWayback Machineを組み合わせましょう。NSの変更日がWHOISの登録者変更やアーカイブスナップショットの空白と一致すれば、一貫したストーリーが得られます。

この三角測量が、本物のDNS履歴調査と気軽なルックアップを分けます。1つの記録は手がかりです。3つの記録が揃えば証拠になります。

ステップ6: MXとNS履歴の危険信号をどう見つけるか

危険信号には、既知のスパムに寛容なホストを指すMXレコード、数か月ごとに無関係なプロバイダー間を移動するNSレコード、レコードがまったくない長い空白期間などがあります。MX履歴がなくNSの入れ替わりが頻繁なドメインは、おそらく本物の製品をホストしたことがありません。

逆に、長年にわたって安定したGoogle MXとCloudflare NSを持つドメインは、本物のビジネスに属していた可能性が高いです。他人の死んだプロジェクトからドメインを買うとき、そういう履歴が欲しいものです。

ステップ7: DNS履歴をドメインの価値評価にどう使うか

DNS履歴は価格を決めませんが、価格に影響を与えます。メールとホスティングの履歴がきれいで安定しているドメインは、スパムの評判を引き継がないため再ローンチが容易です。MXの過去が乱雑なドメインは、修正に数か月かかるメール配信の問題を抱えている可能性があります。

契約する前に、Spamhausのような主要なブロックリストでドメインを確認しましょう。MX履歴が怪しければ、評判も怪しいと想定し、それに応じて価格を設定します。

ステップ8: プロジェクトを埋葬する前に自分のDNS履歴をどう保存するか

プロジェクトを引退させる前に、現在のMXとNSレコードをエクスポートし、日付とともに保存します。レジストラのDNSパネルのスクリーンショットを撮ります。その記録はプロジェクトのストーリーの一部になり、売却時にドメインがきれいな履歴を持っていたことを証明したいときに役立ちます。

死んだプロジェクトを1ドルで埋葬するとき、その履歴は買い手が評価するものの一部です。整ったDNSの足跡は脚注ではなく、売りポイントです。

DNS履歴調査で何がうまくいかないことがあるか

パッシブDNSデータは不完全です。一部のプロバイダーは最近ログを取り始めたばかりで、無料ツールはせいぜい数年分しか表示しないことがよくあります。データの欠落をきれいな履歴と誤解しやすいです。

第二に、DNSレコードは偽装されたり、実際のビジネスが背後にないまま前の所有者から引き継がれたりすることがあります。Google MXレコードは会社が存在したことを証明しません。誰かがGoogle Workspaceにサインアップしたことを証明するだけです。すべてのレコードを事実ではなくヒントとして扱いましょう。

第三に、プライバシーサービスやレジストラの移管はWHOISの連続性を消し去り、クロスリファレンスのステップを壊すことがあります。そうなったら、ウェブアーカイブに頼る比重を増やし、埋まらない空白もあると受け入れましょう。

DNS履歴調査の前提条件

ドメイン名、ターミナルまたはWebベースのDNSルックアップツール、そして少なくとも1つのパッシブDNSサービスアカウントが必要です。無料のSecurityTrailsまたはViewDNS.infoアカウントで、ほとんどの気軽なチェックはカバーできます。より深い作業には、有料プランと、WHOIS履歴が重要ならDomainToolsのサブスクリプションの予算を組みましょう。

また、ドメインの現在のレジストラと、期限切れかパーキング中かを知っておくべきです。そのコンテキストが、見つけたすべての履歴レコードの解釈を形作ります。

購入を検討しているドメインから始めて、そのMXとNS履歴をさかのぼって調べましょう。墓地を閲覧して、どれが利用可能か確認してください。