コンテンツにスキップ

DNS Vulnerability: Dangling Domain Records

DNSの脆弱性: ダングリングドメインレコード

説明

ダングリングドメインは、DNSレコードがすでにアクティブでないリソース、または組織の制御下にないリソースを指している場合に発生します。このような構成ミスは、ドメインのハイジャック、データ漏えい、および評判の失墜につながる可能性があります。ダングリングドメイン管理における主な懸念事項は以下の分野です。

1. クラウドリソースの参照

プロビジョニングが解除されたクラウドリソースを指すDNSレコードは、重大なリスクをもたらします。一般的な構成ミスには、次のようなものがあります。 * 終了したクラウドサービスを指す孤立したCNAMEレコード * 解放されたIPアドレスを対象とするAレコード 

# 危険なDangling Record
app.example.com.    IN CNAME   terminated-app.cloudservice.com.
api.example.com.    IN A       203.0.113.0   # Released IP

# 適切な廃棄 (Decommissioning)
# 1. リソースを解放する前にDNSレコードを削除する
# 2. または、制御されたプレースホルダーに置き換える
app.example.com.    IN CNAME   service-offline.example.com.

2. サードパーティサービスの統合

廃止されたサードパーティサービスを指すレコードは、セキュリティの脆弱性を生み出します。 * 放棄されたサブドメインの委任 * 有効期限が切れたサービスエンドポイント 

# リスキーな構成
analytics.example.com.   IN CNAME   client-xyz.analytics-service.com.    # Service discontinued
track.example.com.      IN CNAME   example.abandoned-tracker.com.        # Company defunct

# 安全な構成
# サービス依存関係の内部インベントリを常に維持する
analytics.example.com.   IN CNAME   active-client.current-service.com.

3. サブドメインの管理

不適切なサブドメインのクリーンアップは、潜在的なテイクオーバーシナリオにつながります。 * 忘れられた開発/ステージング環境 * レガシーアプリケーションのサブドメイン * 非アクティブなプロジェクト環境 

# 脆弱なサブドメイン
dev.example.com.        IN CNAME   old-project.github.io.        # Repository deleted
stage.example.com.      IN CNAME   staging.heroku.com.          # App removed
beta.example.com.       IN A       198.51.100.1                 # Server decommissioned

# 適切なレコード管理
# 非アクティブなサブドメインの定期的な監査と削除
dev.example.com.        IN A       203.0.113.10                 # Internal development server
staging.example.com.    IN CNAME   current-stage.example.com.   # Active staging environment

4. メールサーバーレコード

放棄されたメール関連のレコードは、電子メールのスプーフィングやフィッシングにつながる可能性があります。 * 古いMXレコード * 非推奨のメールサーバーへの参照 

# 危険なメール構成
example.com.    IN MX    10 legacy-mail.example.com.    # Server decommissioned
mail.example.com.   IN A    203.0.113.50               # Released IP

# 安全な構成
example.com.    IN MX    10 primary-mail.example.com.
example.com.    IN MX    20 backup-mail.example.com.

5. 証明書検証レコード

放棄されたドメイン検証レコードは、セキュリティ上のリスクをもたらします。 * 古いACMEチャレンジレコード * 忘れられたドメイン検証用CNAMEレコード 

# リスキーな検証レコード
_acme-challenge.example.com.    IN TXT    "abandoned-validation-token"
validate.example.com.          IN CNAME   validate.oldcertprovider.com.

# クリーンな構成
# 証明書発行後に検証レコードを削除する
# 自動化された証明書管理を使用する

6. サービスディスカバリレコード

古いサービスディスカバリエントリは、内部インフラストラクチャを公開する可能性があります。 * 廃止されたサービスに対するSRVレコード * レガシーサービスエンドポイントの参照 

# 公開されたサービスレコード
_ldap._tcp.example.com.    IN SRV    0 0 389 old-dc.example.com.
_xmpp._tcp.example.com.    IN SRV    0 0 5222 chat.example.com.

# 適切なクリーンアップ
# リソース破棄時にサービスレコードを削除または更新する
_ldap._tcp.example.com.    IN SRV    0 0 389 current-dc.example.com.

これらのダングリングドメインの構成ミスは、次のような深刻なセキュリティインシデントにつながる可能性があります。 * ドメインのテイクオーバー攻撃 * ハイジャックされたエンドポイントを介したデータ流出 * 正規のドメインを使用したフィッシングキャンペーン * ブランドの評判の失墜 * 内部インフラストラクチャの詳細の公開

組織は、ダングリングドメインの脆弱性を防ぐために、定期的なDNS監査を実施し、サービスインベントリを維持し、適切なデコミッショニング（廃棄）手順に従う必要があります。

推奨事項

ダングリングドメインに関連するリスクを軽減するために、次の推奨事項を検討してください。

  • ドメインインベントリの開始: すべてのドメインとサブドメインの包括的な監査から始めます。 

    # ドメインインベントリの形式例
domain: example.com
subdomains:
  - app.example.com -> AWS CloudFront
  - api.example.com -> Azure App Service
  - mail.example.com -> Google Workspace
owner: DevOps Team

  • プログレッシブな監視レベルの導入: ドメインの重要度に基づいて監視をスケーリングします。 | ドメインタイプ | チェックの頻度 | 理由 | |-----------------------|----------------|------------------------------------| | 本番環境クリティカル | 5分ごと | ビジネスに不可欠なサービス | | 顧客向け | 15分ごと | 顧客体験への影響 | | 内部ツール | 毎時 | 内部運用のサポート | | 開発環境 | 6時間ごと | クリティカルでない環境 |

  • 定期的なドメイン監査:

  • クラウドリソースへのすべての接続を検証します。
  • サードパーティサービスの依存関係を確認します。
  • DNSレコードの正確性を検証します。

  • サブドメインの証明書を監視します。

  • セキュリティのベストプラクティス:

  • DNS管理には専用のクラウド認証情報を使用します。
  • DNSの変更に対して厳格なRBAC（ロールベースアクセス制御）を実施します。
  • すべてのDNS変更に対して監査ログを有効にします。

  • DNS変更の承認ワークフローを維持します。

  • 運用手順:

  • すべてのドメイン所有権の詳細を文書化します。
  • サービスのデコミッショニング（廃棄）チェックリストを作成します。
  • クラウドリソースのマッピングを維持します。

  • ドメインのテイクオーバー防止対策をテストします。

  • 計画的なデコミッショニング戦略:

  • リソースの特定から始めます。
  • すべての依存関係を文書化します。
  • アクティブな接続を監視します。
  • DNSレコードを削除します。
  • 構成の詳細をアーカイブします。

これらの推奨事項は、運用効率を維持しながら、適切なドメイン管理を確実にし、ダングリングドメインの脆弱性を防ぐのに役立ちます。

リンク

標準

  • SOC2_CONTROLS:
    • CC_6_1
    • CC_6_6
    • CC_6_7
    • CC_6_8
    • CC_7_1
    • CC_7_2
    • CC_8_1
  • CCPA:
    • CCPA_1798_150
  • GDPR:
    • ART_25
    • ART_32
  • HIPAA_CONTROLS:
    • SECURITY212
    • SECURITY213