naoketa.net

AWS Route53のサブドメイン乗っ取りの仕組みと対策を考える

March 29, 2025

written by naoketa/Naoki Tazawa

はじめに

今年2025年1月ごろ、政府機関のみが利用できる「go.jp」のドメインの省庁の一部ウェブサイトで、サブドメインが乗っ取りできる設定になっているとして、以下のようにNHKはじめ多くのお茶の間のニュースにもなっていました。

この問題の特筆すべき点として、よくあるドメインの杜撰な管理によりドメインが意図的/意図せず有効期限が切れて第三者が取得して悪用するような事例ではなく、共用DNSサーバの仕様やDNS設定不備により、有効期限に関係なく乗っ取りが可能になっていた事例ということにあります。

各社共用サーバの仕様によっては同様に起こりうる事象であり、読者である各位ITエンジニアの扱うWebサイトにおいて同様の事象が発生しうるため、今回はAWS Route53を題材にlame delegationやdangling recordsの仕組みと対策を紹介します。

Lame Delegationとは

「lame delegation（レイム・デリゲーション）」は、本来名前解決が完了するはずのDNSにおいて、権威DNSサーバが正しく動作しない・間違った情報が登録されている・あるいはそもそも設定されていない、という状況により、期待通りのDNS応答が得られない状態を指します。
具体的には、親ゾーンに子ゾーンへの委任（NSレコード）が設定されているにもかかわらず、子ゾーン側で該当する権威DNSサーバが設定されていない/停止している、あるいはそもそも該当ドメインの登録が残っていないようなケースが典型例です。

このような状況が作り出される背景としては、以下のようなパターンがあります。

  • DNSのレコード管理を分散している際に、親ゾーン・子ゾーンの両方の設定が整合していない
  • 移行・廃止作業で子ゾーンだけを削除し、親ゾーンのNSレコードはそのまま放置してしまう
  • AWS Route53を削除したが、古いネームサーバ情報を外部に対して残し続けてしまう

権威DNSサーバが正しく設定されず、宙ぶらりん状態になることで、外部からみれば「サブドメインのゾーンは存在するのに、問合せ先が誤っている」もしくは「何者かが別のホスティングサービスで同名のサブドメインを再度有効化できる」状況が発生します。これがサブドメイン乗っ取りの温床となります。

Dangling Recordsとは

「dangling records（宙ぶらりんレコード）」は、その名の通り、既に有効な宛先ではないにもかかわらず、DNSレコードが削除されずに残ったままの状態を指します。
代表的な例は、先ほどのlame delegationのようにNSレコードが残存しているケースのほか、AレコードやCNAMEレコードなどが削除対象のリソースを参照し続けているケースも含まれます。

例えば、AWS上のS3バケットやCloudFrontディストリビューションを紐付けていたサブドメインを削除した際に、Route53のレコードのみ残してしまうと、誰でも同じバケット名やCloudFrontディストリビューションIDを再利用して同名サブドメインを「正規に」取得できてしまうリスクが生まれます。これがいわゆる「サブドメイン乗っ取り(Subdomain Takeover)」に繋がります。

リスクを理解するための例：naoketa.net

今回は、サンプルドメインとしてnaoketa.netを想定してみます。以下のような設定状況を考えてみましょう。

  1. naoketa.netというドメインがRoute53にホストされている
  2. sub.naoketa.netを別のホストゾーンとして作成し、親ゾーン（naoketa.net）にNSレコードを設定して運用している
  3. ある時、sub.naoketa.netのホストゾーンをAWS上から削除してしまい、親ゾーンのNSレコードを放置する

このとき、外部から見ればsub.naoketa.netへのDNSクエリは、親のNSレコードによって委任先を参照しにいこうとします。しかし実際には、子ゾーンはAWS上で既に削除されており権威DNSが存在しないため、名前解決は行き場を失い「lame delegation」が発生します。
さらに、もし第三者が同名のsub.naoketa.netを別のアカウントや別サービス（場合によっては同じAWSアカウントでも）で再度取得できると、元々の正当なWebサイトだったはずのsub.naoketa.netが悪意のあるサイトに置き換えられ、ユーザの信頼を損ねたり、フィッシングなどの攻撃に利用されたりするリスクがあります。

AWS Route53公式からの呼びかけ

AWS Route53では、公式ドキュメントで以下のようなアナウンスを公開し、慎重なホストゾーンの削除とレコード整理を呼びかけています。

Important
If you delete a hosted zone, you can’t undelete it. You must create a new hosted zone and update the name servers for your domain registration, which can require up to 48 hours to take effect. In addition, if you delete a hosted zone, someone could hijack the domain and route traffic to their own resources using your domain name.

If you delegated responsibility for a subdomain to a hosted zone and you want to delete the child hosted zone, you must also update the parent hosted zone by deleting the NS record that has the same name as the child hosted zone. For example, if you want to delete the hosted zone acme.example.com, you must also delete the NS record acme.example.com in the example.com hosted zone. We recommend that you delete the NS record first, and wait for the duration of the TTL on the NS record before you delete the child hosted zone. This ensures that someone can’t hijack the child hosted zone during the period that DNS resolvers still have the name servers for the child hosted zone cached.

このガイドラインが示す通り、親子関係にあるDNSゾーンを削除するときは、子ゾーンを消す前に親ゾーンに存在するNSレコードを削除し、十分にTTLが切れるのを待ってからホストゾーンを削除する必要があります。これによって、外部のDNSキャッシュで古いNSレコードが生きている間に、別のユーザや悪意ある第三者が同名のサブドメインを取得するリスクを最小化できます。

対策

以上を踏まえると、AWS Route53を使ったサブドメインの管理には、以下のポイントが重要です。

  1. DNSレコードの整合性を確保する

    • 親ゾーンと子ゾーンのNSレコードが合っているか常に確認する
    • 不要になった子ゾーンを削除する際は、親ゾーンの対応するNSレコードを先に削除する

  2. TTLの考慮

    • NSレコードを削除しても、DNSキャッシュが残っている場合は引き続き名前解決が行われる可能性がある
    • AWS公式の推奨通り、TTLを考慮して一定期間を空け、全世界のキャッシュが切れてからホストゾーンを削除する

  3. Dangling Recordsの防止

    • S3やCloudFront、Elastic Load Balancingなどへの割り当てを削除したら、Route53上の対応レコードを早めに削除する
    • もし別のドメインに移行した場合やサービスを廃止した場合も、DNSレコードをこまめに見直す

  4. 監視・運用

    • Route53のレコード一覧やホストゾーン一覧を定期的に監査し、不要なリソースや宙ぶらりんの設定がないかチェックする
    • インフラの変更時には、ドメイン管理やDNSの設定変更手順をドキュメント化し、属人化させない

具体的な技術的対策手順

上記のポイントを踏まえつつ、AWS Route53上でより具体的に手順化すると、参考までですが例えば以下のようになります。

  1. サブドメインのホストゾーンを削除する前にTTLを短くする

    • 事前にRoute53コンソール（またはCLI）で親ゾーンに登録されているサブドメインのNSレコードのTTLを、デフォルトの値（300〜172800秒など）から最短60秒程度などに変更しておきます。
    • TTLを短くしてから実際に削除まで一定期間（例：1〜2日程度）を空け、キャッシュができるだけリフレッシュされるようにします。

  2. 親ゾーンのNSレコードを先に削除する

    • 親ゾーン側（naoketa.netなど）のRoute53コンソールで、サブドメイン（sub.naoketa.netなど）に対応するNSレコードを探し、削除します。
    • この作業を行うことで、新規のDNSクエリがサブドメインを引きに行かなくなり、lame delegationの状態を避けることができます。
    • 削除後も古いキャッシュが世界中に残っているため、TTLぶんの時間が経過するまでは要注意です。

  3. サブドメインのホストゾーン（子ゾーン）を削除する

    • 親ゾーンのNSレコード削除後、一定期間（TTL分以上）経過したら、サブドメインのホストゾーンを削除します。
    • これにより第三者が同名のサブドメインを取得しようとしても、キャッシュが残っていない状態になるため、悪用を最小限に抑えられます。

  4. 不要なAレコードやCNAMEレコードの削除

    • S3バケットやCloudFrontディストリビューションを紐付けていたサブドメインを廃止する場合は、Route53上のAレコード/CNAMEレコードを事前に削除しておきます。
    • 同時に、S3バケットの削除やCloudFrontディストリビューションの無効化（Disable）→削除なども行い、AWS内で実体を持つリソース側の名前が再利用されないように管理します。

  5. CLIやInfrastructure as Code(IaC)での定期監査

    • AWS CLIを利用してaws route53 list-hosted-zonesやlist-resource-record-setsなどのコマンドで、ホストゾーンやレコードが適切に整理されているかをスクリプトで確認できます。
    • TerraformやCloudFormationなどを使ってインフラ構成を管理している場合は、定期的にPlan/Diffを実行して、想定外のレコードが残っていないかをチェックする仕組みを導入します。

  6. ドメイン管理とDNS管理の連携

    • Route53で管理しているドメインが多数ある場合、ドメインの更新・廃止時にDNS設定を漏れなく対応させるためのプロセスを社内で明確化しておきます。
    • 廃止ドメインに関するメール通知やリマインドを行う仕組み（カレンダー登録やAWS Budgetsなどの活用）を整備しておくと、DNS設定漏れのリスクを減らせます。

まとめ

政府機関の事例でも注目を集めたサブドメイン乗っ取りの問題は、ドメイン自体の有効期限とは無関係に生じうるリスクであることが明らかになりました。AWS Route53だけでなく、各社の共用DNSサーバを利用しているエンジニアにとっても決して他人事ではありません。

Route53公式ドキュメントにもあるように、ホストゾーンを削除するときは十分な注意が必要で、不要になったサブドメインに紐づくNSレコードや他のレコードを先に削除・クリアにしたうえで、TTLが失効するまで待ってからホストゾーンを消すのが鉄則です。また、宙ぶらりん(Dangling)になったDNSレコードが存在しないか、日頃の運用で監査を行うことも大切です。

日々進化するクラウドの管理では、多数のドメインやサブドメインを取り扱うことも増えます。今回のlame delegationやdangling recordsの仕組みや対策を押さえておくことで、こういった脆弱性を未然に防ぎ、セキュアな運用を実現していきましょう。

© 2025, Built with Gatsby by Naoki Tazawa