ダングリングDNSとは？サブドメインテイクオーバーの原因・確認方法・対策

ダングリングDNSとは何か

Microsoft Learn は、削除済みクラウドリソースや無効化済みサービスを参照したまま DNS レコードが残る状態を dangling DNS として扱い、 典型的には CNAME の取り残しが問題になると説明しています。Azure の subdomain takeover 対策ガイド↗とAzure App Service の防止策↗の両方で、DNS の削除漏れと所有確認不足が takeover の起点になることが明記されています。

重要なのは、サーバー侵害やアプリ脆弱性がなくても、公開面の所有権がずれるだけで事故になることです。ダングリングDNSは 設定ミスというより、資産台帳、廃止フロー、所有確認のズレで起きやすい運用事故です。だからこそ、脆弱性診断の前段として外部公開資産を 棚卸しする価値があります。

ダングリングDNSが危険になる条件

DNS レコードが残っているだけで、すべて即座に乗っ取られるわけではありません。実務では、次の条件が重なったときに危険度が上がります。

よくある発生シーン

現場で多いのは、高度な攻撃よりも「廃止したつもりの公開面」が残るケースです。とくにカスタムドメインを外部サービスへ向けていた環境は、 サービス削除と DNS 更新の責任が分かれると取り残されやすくなります。

放置すると何が起きるか

Microsoft Learn は、subdomain takeover の影響として、偽コンテンツの公開、フィッシング、cookie harvesting、XSS、CSRF、CORS bypass、 さらには SSL 証明書取得までを挙げています。つまり「空ページが出るだけ」の問題ではなく、信用されたサブドメインが第三者の配下に入ること自体が実害です。

とくに危ないのは、過去にメールや広告で配布した URL、ログイン導線に近いサブドメイン、ブランド名を強く含むサブドメインです。使っていない名前でも、 ユーザーや取引先から見ると「まだ正規だろう」と判断されやすく、事故が長引きます。

自社で確認したいポイント

検索流入で最も知りたいのは「自社が今危ないかどうか」のはずです。判断は、DNS だけでなく、参照先サービスの状態と所有確認を突合して行います。

1. 用途不明の CNAME やサブドメインが残っていないか

まずは DNS 台帳と公開中サブドメインを突合し、管理責任者が空欄の名前、用途不明の CNAME、数か月以上更新のないホスト名を洗います。サブドメイン棚卸し とDNS 棚卸しの両方を見ないと、「存在」と「設定」が分離したままになります。

2. 削除済み・無効化済みサービスを参照していないか

GitHub Pages なら repo / Pages site の有効状態、Azure App Service なら対象 site や custom domain の残存状態を確認します。DNS 応答だけ見て 「生きている・死んでいる」を判断するのではなく、参照先サービスがまだ自社管理下にあるか を確認することが重要です。

3. カスタムドメインの所有確認が入っているか

GitHub Pages の custom domain verification や Azure App Service の domain verification ID（「asuid」）のように、プロバイダが用意する 所有確認を省略していないかを見ます。所有確認は Verified 運用の延長ではなく、カスタムドメインの再取得を難しくする安全装置です。

4. ワイルドカード DNS を安易に残していないか

GitHub Docs は、verification 済みドメインでもワイルドカード DNS は immediate risk of domain takeovers だと警告しています。利便性のために 「*.example.com」を使っている場合は、実際に必要なホストだけへ絞れるかを見直してください。

すぐできる対策

1. 削除前に DNS を更新する

Azure App Service の公式ドキュメントは、site を削除する前に DNS レコードを更新するよう明示しています。現場では「サービス削除完了」を先に 閉じてしまいがちですが、DNS 更新まで終えて初めて廃止完了と定義した方が事故を減らせます。

2. 所有確認 TXT を必ず使う

GitHub Pages の custom domain verification、Azure の「asuid」のような TXT ベースの所有確認は、見た目の追加手順ではなく takeover 抑止策です。 自社でもTXT 認証を日常運用へ組み込むと、誰が何を所有しているかを残しやすくなります。

3. 廃止フローに DNS と外部導線を入れる

削除時チェックには、DNS、証明書、広告URL、メールテンプレート、ブックマーク誘導の停止まで含めてください。ダングリングDNSは技術的に難しい攻撃より、引き継ぎ漏れで起きることが多いため、廃止チェックリストの質がそのまま防御になります。

4. 単発棚卸しで終わらせず継続監視する

Microsoft Learn の Azure ガイドは、Azure 管理の DNS とリソースなら alias record の利用や「Get-DanglingDnsRecords」の活用を勧めています。 重要なのは、1回洗って終わりではなく、新規露出と再発を継続的に見つけることです。外部公開資産は人事異動、キャンペーン、SaaS導入で すぐ増えるためです。

ASM診断 PRO での見つけ方

ASM診断 PRO は、ドメイン、サブドメイン、DNS、HTTP、TLS を横断して外部観点の棚卸しを行うため、用途不明の公開面や放置サブドメインを洗う入口に向いています。 ダングリングDNSは「DNS だけで断定できる問題」ではないため、公開面の発見 →管理責任者確認 → 所有確認 → 継続監視 の流れで扱うのが現実的です。

まず Public 診断で外部公開面の一覧を取り、次に Verified 管理で所有確認済みドメインへ寄せると、「正規の公開面」と「見直すべき公開面」を分けやすくなります。 そのうえで、サブドメイン棚卸し や外部公開資産台帳とつなぎ、削除判断と継続監視へ落とすのが最も無駄の少ない流れです。

よくある質問

まとめ

ダングリングDNSは「DNS の小さな残骸」ではなく、公開面の管理責任がずれた状態です。危険なのは、DNS が残り、参照先が消え、第三者が再取得でき、 所有確認も弱い条件が重なるときです。

• まずは用途不明の CNAME と外部サービス参照を洗う
• 所有確認 TXT とワイルドカード DNS の扱いを見直す
• サービス削除前に DNS 更新まで終える運用へ変える
• 単発確認で終わらせず、継続監視に載せる

自社で本当に危ない状態かを見分けたいなら、内部台帳だけでは足りません。まず外から見える公開面を確認し、そこからサブドメイン棚卸し、DNS 棚卸し、TXT 認証へつないでください。