速報

X.Orgのクライアントライブラリーで17件を修正!Linux端末と画像処理の利用範囲を点検

CATEGORY

使っていないサブドメインを放置しない!外部サービス廃止時の安全な手順

※本ページのリンクにはプロモーションが含まれています。

不要なDNS参照と廃止する外部サービスを整理する青緑背景の概念イラスト

目次

キャンペーンを終了して外部サービスを削除した。でも、campaign.example.comのDNS設定は残ったまま。このような廃止作業の隙間が、条件によっては自社のサブドメインを第三者に使われる入口になります。契約を止める作業と、名前の参照をなくす作業を一緒に管理する必要があります。

本記事は2026年10月18日にOWASPの一次資料を確認した実務解説です。特定企業の乗っ取り事件の速報ではありません。ドメイン登録者の保護を扱う既存記事とは分け、外部サービスを指す参照が残る問題を中心にします。以下のサイトと作業計画は仮想例で、点検手順は本サイトの提案です。

スポンサーリンク

DNSが残るだけで必ず成立するわけではない

サブドメインテイクオーバーでは、DNSが外部資源を参照し続け、元の資源がなくなり、第三者がその名前や参照先を取得できるといった条件が関わります。参照先が存在しないことだけで、直ちに乗っ取り可能だと断定してはいけません。

提供元によって、名前の再利用、独自ドメインの所有確認、削除後の扱いは異なります。エラーページやDNSの応答は調査の手掛かりですが、成立の証明とは区別します。第三者の資源を実際に取得して確かめる必要もありません。

本サイトは、まず自分が管理するDNSと契約の記録を照合し、提供元の公開仕様や正規の窓口で状態を確認する方法を勧めます。自社の管理範囲が不明な資源や他社の名前を勝手に登録する確認は行わないようにします。

出典:OWASP Subdomain Takeover Prevention Cheat Sheet。

DNSと契約・クラウド資源を一つの台帳へ結ぶ

DNSだけの一覧では、その参照をなぜ作ったのかが分かりません。ホスト名、参照先、サービス、契約アカウント、担当者、利用目的、終了予定を対応させると、不要な参照を見つけやすくなります。

外部ホスティングだけでなく、ストレージ、フォーム、サポート窓口、メール、委任したDNSなども確認対象になります。CNAMEだけを調べればすべての条件を網羅できると考えず、提供元と構成に応じた参照を確認します。

IaCや自動デプロイで作った資源は、削除の処理まで確認します。クラウド側の資源を消すコードと、別のDNS管理画面の設定が独立していると、片方だけが完了しやすくなります。どの作業が完了条件を満たすかを明記します。

スポンサーリンク

終了前に残す機能と消す参照を決める

仮想のキャンペーンを廃止するなら、過去のURLを残す必要があるか、案内を表示するか、完全に終了するかを先に決めます。削除を急いで利用者向けのエラーを増やすより、移行期間の表示と連絡先を用意することが有効です。

本サイトは、関連するWebページ、メール、外部連携、リダイレクト、アプリの許可設定も一緒に調べることを勧めます。DNSだけ消しても、古いリンクや連携先の登録が残れば、障害や別の誤設定の原因になります。

一方で、不要なサービスを永久に契約し続けることが唯一の解決ではありません。安全に参照を外す計画と、必要な案内を別の管理下の場所へ移す方法を決め、担当者がいなくなる前に実施します。

参照を外し伝播を考慮して資源を解放する

OWASPは、案内や移行を用意し、DNSの参照を変更または削除し、伝播を待ってからクラウド資源を廃止する順序を説明しています。先に再取得可能な資源を解放して参照だけを残す状態を避けることが重要です。

実際の待ち時間と作業は、現在のTTL、既存のキャッシュ、提供元の手順を確認して決めます。すべての環境で一律の数分待てば十分だと扱わないでください。移行前にTTLを変える場合も、以前の値で保存された応答の存在を考慮します。

外部サービスの独自ドメイン設定を解除する手順も提供元ごとに確認します。契約、DNS、サービス内の紐付けをどの順で処理すれば、利用者への影響と参照の空白を減らせるかを計画します。

スポンサーリンク

Cookieと許可設定の影響を別に見直す

あるサブドメインが第三者に使われると、そのホストで自社らしい内容を表示されるおそれがあります。さらに、親ドメインを広く対象とするCookieや、信頼するオリジンの設定などがあれば、別の機能にも影響する場合があります。

本サイトは、不要なサブドメインを廃止するときに、CookieのDomain指定、CORSの許可リスト、埋め込み許可、認証連携の戻り先も確認することを勧めます。各機能が持つ信頼を、昔は自社が管理していたという理由だけで残さないようにします。

実際の影響は設定次第です。サブドメインが取得されたら必ず親サイトのログインがすべて奪われる、といった断定は避けます。どの資格情報や許可条件がそのホストへ関係するかを調べ、確認できた範囲で対応します。

安全な確認は管理下の情報で進める

自分のDNSから必要な情報を取得し、現在の契約や資源一覧と照合します。不明な参照は担当者と提供元へ確認し、不要なら正規の変更手続きで整理します。エラーの出るホストを見つけただけで公表や攻撃の再現へ進むべきではありません。

監視を導入する場合も、エラー表示の変化を検知する機能と、乗っ取り可能性を判断する作業を分けます。誤検知を処理できる窓口を用意し、同じ通知を放置し続ける状態を避けます。

外部診断を依頼するなら、対象のドメイン、許可する検証、資源の取得を伴う操作の扱いを事前に定めます。検出した条件、未確認の条件、推奨する修正を分けて受け取ると、不要な主張や作業を減らせます。

確認対象突き合わせる情報完了の条件
外部ホスティング参照契約と資源の所有者管理中の資源と対応する
終了予定のホスト案内先とDNS変更計画不要な参照が残らない
資源の削除DNSの伝播と提供元の手順参照だけの空白を作らない
関連する許可設定Cookie・CORS・認証連携不要な信頼を取り除く

廃止の依頼から完了までを一件の作業にする

仮想の作業票には、対象ホスト、関係するDNS、サービス内の設定、契約の停止、残す案内、確認担当を記載します。DNSの担当と契約の担当が違う場合、各自の作業完了だけで全体を閉じないようにします。

変更後は、管理画面上の設定と外部から見える参照を両方確認します。資源の解放が完了した後も、古い自動デプロイや定期作業がDNSを戻さないかを見ます。台帳から削除する前に、不要な参照が再生成されないことを確認してください。

証跡は、秘密の認証情報を含めずに残します。何を廃止し、何を残し、どの状態を確認したかが分かれば、後から同じホスト名を別の用途へ使うときも判断しやすくなります。

制作会社のアカウントにある資源を廃止する例

仮想のキャンペーンを外部の制作会社が運用し、DNSだけを自社で管理している場合を考えます。契約終了時に制作会社がホスティングを消しても、自社のDNS担当へ連絡がなければ参照が残ります。双方の担当が自分の作業だけを終えた結果、全体の責任が空白になります。

本サイトは、終了日の前に対象ホストと資源の所有者を突き合わせ、DNSの変更、利用者向けの案内、サービス側の解除、資源の解放を一件の作業票へまとめる方法を勧めます。サービスの管理権限が外部にあるなら、必要な状態の確認を正規の担当者へ依頼し、他人のアカウントへ入ることを前提にしない手順を作ります。

外部から表示が消えただけでは、ドメインの紐付けや再利用の状態は分かりません。提供元の仕様と作業完了の記録を確認します。実際に名前を他のアカウントへ登録してみるという検証を無断で行わず、確認できなかった条件を残して対応先を決めます。

終了後は、DNSの正規の管理元から不要な参照が消えていることと、利用者向けの案内が予定どおりであることを照合します。自動化や古い手順が翌日に同じ参照を作り直さないかを確認し、台帳の状態を閉じます。

スポンサーリンク

所有者が不明なホストの整理を急がない

担当不明の参照を見つけても、使っていなさそうだという理由だけで即座に削除しないようにします。月次の処理や特定の顧客だけが使う入口かもしれません。管理下のアクセス記録や契約、関連する設定から用途を調べ、必要な関係者へ確認します。

調査中も参照先を第三者が再取得できる可能性があるなら、提供元と相談して安全な管理下の案内へ移すなど、影響を限定する方法を検討します。使い続けるか完全に廃止するかの判断と、今ある不明な信頼を減らす対応を分けると進めやすくなります。

新規サービスの導入時から出口を用意する

外部サービスを導入するときに、所有者の確認方式、担当者、終了時のDNS操作、名前の再利用の条件を確認します。入口の設定だけを手順書に残し、解約時は担当者の記憶に頼る状態を避けます。

組織の変更、制作会社の交代、試験環境の削除も見直しの契機です。公開中の本番だけでなく、短期間の検証用ホストが同じDNSへ作られていないかを調べます。利用頻度が低い名前ほど、担当不在になりやすいためです。

サブドメインの安全性は、DNSの設定だけでもクラウド資源の所有だけでも決まりません。名前、参照先、所有者、許可、廃止の手順を対応させ、使っていない参照を残さない運用へ整えることが大切です。

スポンサーリンク

参考資料

以下は2026年10月18日に直接確認した一次資料です。製品やサービスの設定は、実際に利用する版と環境に対応する資料で確認してください。

この記事を書いた人

Ryohei

Webエンジニア / アプリ開発者 / 技術ブログ運営者

福岡のWeb制作会社に勤務するWebエンジニアです。10年以上にわたりWeb制作・開発に携わり、これまでに100以上のWordPressサイトの構築・保守を担当してきました。Webサイト制作に加え、アプリ開発やAIを活用した開発にも取り組み、近年はWebセキュリティにも注力しています。

2015年から技術メディア「Into the Program」を運営し、実務や開発で得た知識をもとに、プログラミングの実装方法やWebサイトの運用・セキュリティ情報を発信しています。

主な分野
WordPress / PHP / JavaScript / アプリ開発 / Webサイトの運用・セキュリティ対策
資格・試験合格
情報セキュリティマネジメント試験
基本情報技術者試験
AWS認定ソリューションアーキテクト アソシエイト
メディア運営
2015年〜

記事の作成・更新について

セキュリティ記事は、ベンダーの公式アドバイザリやCVE・JVNなどの一次情報を参照し、出典と情報確認日を記載します。実環境での検証を行った場合は、その環境と確認範囲を明示します。重要な追加情報や誤りを把握した場合は、内容を確認して追記・訂正します。

スポンサーリンク

関連する記事

おすすめの書籍