JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト


ドメイン名関連会議報告

2025年

[Interop Tokyo 2025出展報告] 終わったWebサイトのDNS設定、そのままになっていませんか?~サブドメインテイクオーバー・NSテイクオーバーの概要と対策~

本記事では、6月11日から13日までの3日間にわたり幕張メッセで開催された「Interop Tokyo 2025」の出展ブースで実施した、ミニセミナー「終わったWebサイトのDNS設定、そのままになっていませんか?~サブドメインテイクオーバーNSテイクオーバーの概要と対策~」の内容についてご紹介します。

ミニセミナーの資料を公開していますので、併せてご参考にしてください。

DNS設定がそのままになっていると...

2025年1月に、中央省庁が過去に使っていた複数のドメイン名が第三者による不正利用可能な状態になっていた旨が相次いで報告されました。その一部については実際に不正利用が確認され、緊急対応が実施されました。

本件の標的になったドメイン名はいずれも期間限定のWebサイトで使われ、現在は運用を終了している、組織のドメイン名のサブドメインでした(図1)。

(図1)

(図1)標的となったドメイン名の例


▽使い終わったドメイン名を使われる2種類のパターン


使い終わったドメイン名を第三者に使われるパターンは、大きく2種類に分類されます(図2)。

(図2)

(図2)使い終わったドメイン名を使われるパターン


(1) ドメイン名を再登録する
更新されなかったドメイン名は有効期限の満了後に廃止され、再登録が可能になります。こうしたドメイン名を第三者が再登録し、同じ名前でWebサイトを復活させます。

(2) DNS設定の案内先を勝手に使う
Webサイトの運用終了後にそのままになっているDNS設定の案内先を第三者が勝手に使って、同じ名前でWebサイトを復活させます。

本件はいずれも、(2)によるものでした。そのため、今回のミニセミナーではこの攻撃に使われたサブドメインテイクオーバーとNSテイクオーバーの概要と対策について解説しました。

なお、ミニセミナーでは時間の関係で、サブドメインテイクオーバーを中心に解説しました。セミナーで解説した概要と対策については、いずれも共通となっています。

サブドメインテイクオーバーの概要

サブドメインテイクオーバーでは、Webサイトの運用終了後にそのままになっているCNAMEリソースレコードが標的になります。なお、NSテイクオーバーでは委任先として設定されるNSリソースレコードが標的になります。

CNAMEリソースレコードは別名に対する正式名を指定するためのリソースレコードで、そのドメイン名でCDN(Content Delivery Network)サービスを利用する際、CDN事業者のサーバーを指定するために使われます(図3)。

(図3)

(図3)CNAMEリソースレコードの設定例


▽ダングリングレコードが標的に


CDN事業者に委託したドメイン名の運用を終了した場合、ドメイン名の管理者は運用開始時に設定したCNAMEリソースレコードを削除・変更する必要があります(図4)。

(図4)

(図4)Webサイト終了時はDNS設定の削除が必要


もし、運用終了後も設定したCNAMEリソースレコードが残っていた場合、その設定はダングリングレコードと呼ばれる状態になります(図5)。

(図5)

(図5)ダングリングレコード


ダングリング(dangling)は「宙ぶらりんの」という意味で、CNAMEリソースレコードの指定先にWebサーバーが存在しない、親ゾーンの委任情報(NSリソースレコード)の指定先の権威サーバーにゾーンが存在せずlame delegationになっているなど、指定された名前の実体が無効になっているリソースレコードを示す用語として使われることがあります。

▽サブドメインテイクオーバーの攻撃手順


サブドメインテイクオーバーの攻撃手順を、図6に示します。このように、攻撃者は攻撃可能なダングリングレコードを何らかの手段で発見し、サブドメインテイクオーバーを試みます。(図6)

(図6)

(図6)サブドメインテイクオーバーの手順


  1. 攻撃者が攻撃可能なダングリングレコードを見つける
  2. サブドメインの権限を取得するため、参照先のCDN事業者と契約する
  3. 参照先のサーバーにサブドメインのWebサーバーを作成する
  4. Webサーバーに不適切なWebコンテンツを設定する

▽攻撃者がダングリングレコードを見つける方法


セミナーでは、攻撃者がダングリングレコードを見つける方法として、以下の三つを紹介しました。

(1) DNS設定が公開情報であることを利用する
DNSの設定は公開情報で、誰でも確認できます。指定したドメイン名のDNS設定を高速にスキャニング可能なツールがGitHub等で公開されており、誰でも利用できます。
また、稼働中のWebサイトのDNS設定を調べることで、依頼先のCDN事業者やサーバー名を知ることができ、運用終了後にサブドメインテイクオーバーを試みるための「当たりをつける」ことが可能になります(図7)。
(図7)

(図7)DNS設定が公開情報であることを利用する


(2) サーバー証明書のCTログを利用する
サーバー証明書の誤発行・不正発行を検知し、トラブルを最小限に留める仕組みとして、CT(Certificate Transparency)が運用されています。CTログはインターネットで公開されており、どのサーバーのサーバー証明書がいつ・どの認証局から発行されたかを、誰でも確認できます(図8)。
(図8)

(図8)サーバー証明書のCTログを利用する


(3) Passive DNSを利用する
Passive DNSはDNS応答を収集・保存し、ドメイン名の利用状況や、セキュリティ上の脅威の分析に役立てる仕組みです。複数の組織がPassive DNSサービスをインターネットで提供しており、これを利用することで、過去に利用されたドメイン名の情報を知ることができます(図9)。
(図9)

(図9)Passive DNSを利用する


サブドメインテイクオーバーの対策

サブドメインテイクオーバーの対策は、その組織のDNSを運用するDNS運用者におけるものと、レンタルサーバーサービス・CDNサービス・DNSサービス等を提供するサービス事業者におけるものの2種類に分けられます。

▽DNS運用者における対策


DNS運用者における対策として、Webサイト運用終了時にDNS設定を確実に削除・変更することが挙げられます。また、前述したDNSスキャニングツールを用いたダングリングレコードのチェックと削除・変更も、有効な対策となります(図10)。

(図10)

(図10)DNS運用者における対策


▽サービス事業者における対策


サービス事業者における対策として、以下の三つが挙げられます。

(1) サービス提供時のドメイン名管理権限の確認
サービスの提供時に、指定されたドメイン名の管理権限の確認(DCV:Domain Control Validation)を実施し、権限を確認できなかった場合、サービス提供をエラーにします(図11)。
(図11)

(図11)サービス提供時のドメイン名管理権限の確認


(2) サービス解約時のDNS設定削除の確認
サービスの解約時に、利用者のDNS設定(CNAME・NSリソースレコード)の削除を確認し、削除されていなかった場合、サービス解約をエラーにします(図12)。
(図12)

(図12)サービス解約時のDNS設定削除の確認


(3) テイクオーバーが困難なサービスの構築・運用
サービスの提供時にCNAME・NSリソースレコードの参照先として、契約ごとに異なるランダムなラベルを生成・使用し、サービスの解約時に当該サーバーインスタンスを削除し、一度限りの利用とすることで、サブドメインテイクオーバー・NSテイクオーバーを防止します(図13)。
(図13)

(図13)テイクオーバーが困難なサービスの構築・運用


運用担当者・責任者のみなさまへ

最後に、運用担当者・責任者のみなさまへのメッセージとして、以下の2項目を解説しました。

  1. サブドメインテイクオーバー・NSテイクオーバーの対策には、ドメイン名・DNSの適切な管理が必要である。
      この点については、ドメイン名の廃止に関する注意と同様である。

  2. サブドメインテイクオーバー・NSテイクオーバーの対策では、DNS運用者における対策に加え、サービスを提供する事業者に
      おける対策も重要である。