セキュリティ対策
サブドメイン乗っ取り（dangling DNS）— 自分のサーバーを一切触られずに、自社ドメインが敵の手に渡る
使い終わったクラウド資源を消したのにDNSのCNAMEを消し忘れると、そのサブドメインは第三者が同じ名前の資源を作るだけで乗っ取れます。自社サーバーは一切侵害されません。Microsoftの公式ドキュメントにもとづき、仕組み、セッションCookieが抜かれる理由、『SSL証明書があるから安全』が誤解である理由、そして削除の順番と検出の仕組みを解説します。
自社のサブドメインが、ある日から攻撃者のコンテンツを配り始める——しかも自分のサーバーには誰も触れていない。パッチも認証も監視も、この経路の上には存在しません。原因は侵入ではなく、消し忘れです。
何が起きているのか（3段階）
① 作る
クラウド上に資源を作り、そのFQDN（例：app-xxxx.<プロバイダのドメイン>）を指すCNAMEレコードを自社ゾーンに置く。sub.example.comでサービスが公開される。② 消す（片方だけ）
不要になった資源を削除する。ここでsub.example.comのCNAMEも消すべきだが、残ってしまう。DNS上は生きているのに、行き先が存在しない状態＝dangling DNS。③ 乗っ取られる
攻撃者が、公開情報から宙に浮いたサブドメインを見つけ、あなたが使っていたのと同じFQDNの資源を自分の契約で作成する。以後、sub.example.com宛ての通信は攻撃者の資源へ届き、中身は攻撃者が決める。
自社DNSゾーン（無傷）
sub.example.com CNAME→ app-xxxx.provider.example
↓ 指している先だけが消えた
クラウド資源：削除済み
この名前は誰でも取得できる状態に戻る
↓ 攻撃者が同じ名前で作成
攻撃者の資源（別契約）
sub.example.com の中身を攻撃者が決める。自社サーバーには一度も触れていない
CNAMEが特に危ないのは「名前で指しているから」
IPアドレスで指す A レコードと違い、CNAMEは「名前」を指します。そして多くのクラウドサービスでは、その名前は先着順で誰でも取得できる——あなたが手放した瞬間に、他人が同じ名前を取れるのです。公式ドキュメントも「CNAMEレコードはとりわけこの脅威に弱い」としています。なお同じ理屈は MXレコードにも当てはまり、その場合はそのサブドメイン宛てのメールを受け取られる可能性が生じます。
「見た目が偽物になるだけ」ではない
- サブドメインの支配権の喪失
- 自社ドメインの一部で、自社が管理していないコンテンツが配られる。ブランド毀損と信頼の失墜
- セッションCookieの窃取
- WebアプリはセッションCookieをワイルドカード（
*.example.com）でサブドメインに晒していることが多く、どのサブドメインからも読める。乗っ取ったサブドメインに本物そっくりのページを作り、利用者を誘導してCookieを収集できる——Secure属性のCookieであっても - フィッシングの土台
- 「本物のドメイン」であることが確認できてしまうため、フィッシングの説得力が跳ね上がる
最大の誤解：「HTTPSだから／証明書があるから安全」
公式ドキュメントは、この点を「よくある誤解」として明示的に否定しています。乗っ取った側は、そのサブドメインを支配している状態で正規の証明書を申請し、取得できます。ドメイン検証型の証明書は「その名前を今この瞬間に支配していること」を確認する仕組みなので、支配者が入れ替わったこと自体は検出しません。
結果として、有効な証明書は攻撃者の側に立ちます——鍵マークが付き、Secure属性のCookieも送られ、偽サイトの見た目の正当性はむしろ上がる。証明書は「通信の相手が誰か」ではなく「その名前を持っているのは誰か」を示すものだと理解しておいてください。
防ぎ方は「削除の順番」を仕組みにすること
原因は技術的な難しさではなく、廃止作業の順番です。資源を先に消し、DNSを後回しにする——その隙間が攻撃面になります。
事故が起きる順番
資源を削除 → DNSはあとで → 忘れる
このとき、DNS上は「生きている正規のサブドメイン」として広告され続けます。監視は「サーバーが落ちた」とは言いません——落ちていないからです。
安全な順番
DNSレコードを先に消す → それから資源を削除
公式ドキュメントは、カスタムDNS名を持つ資源に「削除ロック」を掛けることを勧めています。ロック自体が「消す前にDNSを外す必要がある」という目印になるからです（ただし社内教育と組み合わせて初めて効くとも明記されています）。
廃止チェックリストに「DNSレコードの削除」を必須項目として入れる
公式が最初に挙げている予防策がこれです。サービス廃止の必須チェック項目に「DNSレコードを消す」を入れる。開発者には「資源を消すときは経路も張り替える」と教育する。順番を個人の記憶に委ねない、が要点です。
DNSレコードの寿命を、資源の寿命に結びつける
プロバイダによっては、DNSレコードを資源そのものに紐づけられる仕組み（エイリアスレコード等）があります。資源を消すとレコードも空になるので、構造的に宙に浮きません。対応サービスは限られますが、使えるところでは使うのが確実です。「消し忘れ」を運用ではなく設計で潰す発想です。
所有の証明を要求する仕組みを使う
サービスによっては、カスタムドメインを使う際に所有証明用のTXTレコードを要求できます。これがあると、他の契約者が同じ名前で当該カスタムドメインを主張できません。同じ名前の資源を作ること自体は防げませんが、所有を証明できない相手は通信を受け取れない——境界が「名前の早い者勝ち」から「所有の証明」に変わります。
DNSゾーンを定期的に棚卸しする（存在するか／自分のものか）
公式が挙げる確認の観点は2つです——①その向き先は存在するか ②それは自分が所有しているか。②が重要で、「応答が返るから正常」ではありません。応答しているのが他人の資源である可能性こそが、この攻撃そのものだからです。FQDNと担当者の対応表（サービスカタログ）を持ち、資産棚卸しの一部として定期的に書き出してください。
見つけたら「消して終わり」にしない
公式の是正手順は、レコードの削除だけでは終わりません——アプリのコードに残っている古いサブドメイン参照を更新し、実際に侵害が起きていなかったかを調査し、そしてなぜ廃止時にDNSが消されなかったのかを突き止めて再発を防ぐ。とくに、OAuthの認証情報のような秘密や個人情報を、その宙に浮いたサブドメインへ送っていた場合、それは第三者に渡っている可能性があります。
当サイトの視点：攻撃面は「増やしたもの」より「やめたもの」から生える
セキュリティの議論は新しく作るものに集中しがちですが、実際に穴になるのはやめたのに残っているものです。使わなくなったサブドメイン、退職者のアカウント、試して放置した検証環境、解約したのに削除されていない会員情報——いずれも「もう使っていない」という認識が、監視と点検の対象から外すという共通点を持っています。やめたものは、消すまで資産のままです。 だから当サイトは、棚卸しの単位を「稼働中のもの」ではなく「かつて作ったもの全部」に置くことを勧めます。事業者側の事故で「解約したのに対象だった」人が出たのも同じ構図でした（レンタルサーバーが不正アクセスされたとき、利用者は何をすべきか）。
出典（一次情報）
- Microsoft「Prevent dangling DNS entries and avoid subdomain takeover」（Microsoft Learn / Azure セキュリティ基礎） — learn.microsoft.com（乗っ取りの3段階、CNAMEが特に弱い理由、Cookie窃取とMXレコードの危険、証明書に関する「よくある誤解」の否定、削除ロック・エイリアスレコード・所有証明TXT・定期棚卸しといった予防策、是正手順は、いずれもこの文書の記述にもとづきます）
次に読む
- 棚卸し：資産棚卸しチェックリスト（「かつて作ったもの」まで含める）
- 置き場所：クラウドストレージの公開設定ミス（同じ「設定で漏れる」型）
- 用語：フィッシングとは / XSS とは / CSRF とは
よくある質問
Qサブドメイン乗っ取りは、自社サーバーが侵害されたということですか？
いいえ。そこがこの攻撃の厄介な点です。侵害されるのは『DNSが指している先』であって、あなたのサーバーではありません。使い終わったクラウド資源を削除したあと、そこを指すCNAMEレコードをDNSゾーンに残したままにすると、第三者が同じFQDN（例：`app-....azurewebsites.net`）の資源を自分の契約で作るだけで、あなたのサブドメイン宛ての通信が相手のところへ届くようになります。パッチも認証も監視も、この経路の上にありません。
QHTTPSにしていれば防げますか？ 証明書があれば安全では？
防げません。Microsoftの公式ドキュメントはこれを『よくある誤解』として名指しで否定しています——乗っ取った側は、そのサブドメインを乗っ取った状態で正規の証明書を申請して取得できるからです。証明書は『通信相手が、その名前を今この瞬間に支配していること』しか証明しません。支配しているのが誰なのかは証明しないのです。むしろ有効な証明書は、偽サイトの見た目の正当性を上げてしまいます。
Q見た目が偽物になるだけなら、被害は限定的では？
セッションが抜かれます。多くのWebアプリはセッションCookieをワイルドカード（`*.example.com`）でサブドメインに晒しており、その場合はどのサブドメインからも読めます。乗っ取られたサブドメインに利用者を誘導できれば、Secure属性のCookieであっても攻撃者側に渡り得ます。加えて、MXレコードが宙に浮いていれば、そのサブドメイン宛てのメールを受け取られる可能性もあります。
Qどうすれば根本的に防げますか？
削除の順番を『人の記憶』ではなく『手順と仕組み』にすることです。公式ドキュメントは、サービス廃止時の必須チェック項目に『DNSレコードの削除』を入れること、カスタムDNS名を持つ資源には削除ロックを掛けて『先にDNSを消す必要がある』という目印にすること、可能ならDNSレコードの寿命を資源の寿命に結びつける仕組み（エイリアスレコード等）を使うこと、そしてDNSゾーンを定期的に棚卸しして『存在する資源を指しているか』『それは自分が所有しているか』を確認することを挙げています。