## この記事でわかること

- dangling CNAME（宙ぶらりん CNAME）の意味と、なぜ危険なのか
- 検出する 3 つの方法（CT log / DNS 解決 / SaaS 占有確認）
- 是正の 4 ステップ
- 自社で見落としやすいパターン

## dangling CNAME とは

![dangling CNAME の状態遷移](/blog/dangling-cname-risk/state-transition.svg)

CNAME レコードが指している先（例: `old-app.herokuapp.com`）の **SaaS 側リソースが既に削除・解約されている**のに、CNAME は DNS に残ったままの状態を「dangling CNAME（宙ぶらりん CNAME）」と呼びます。

```
campaign.example.co.jp  CNAME  old-app.herokuapp.com
                                ↑ 解約済（攻撃者が再取得可能）
```

CNAME 自体は DNS の正規エントリなので、**外部からはまだ生きているように見えます**。これが攻撃者の餌食になります。

## なぜ危険なのか

CNAME の宛先 SaaS で同じリソース名を**新規取得できる**設計になっている場合（Heroku / GitHub Pages / S3 等の多くがこれに該当）、攻撃者が再取得すると **御社のサブドメインが攻撃者のサイトを返す**ようになります。

- HTTPS 証明書も攻撃者が SaaS 側で取得 → ブラウザは鍵マークを付ける
- アドレスバーは御社のドメインのまま → エンドユーザーには気付けない
- 結果: 御社のドメインで偽ログイン画面 / 偽請求書 / 偽キャンペーンが配信される

サブドメインテイクオーバー全体の仕組みは [こちら](/blog/subdomain-takeover-toha) で詳しく解説しています。

## 検出する 3 つの方法

![dangling CNAME の検出フロー](/blog/dangling-cname-risk/detection-flow.svg)

### 方法 1: CT log（証明書透明性ログ）から全サブドメインを列挙

`crt.sh` で `%.example.co.jp` 検索すると、過去に発行された全証明書のサブドメイン名が得られます。これが起点。

```bash
curl -s 'https://crt.sh/?q=%25.example.co.jp&output=json' \
  | jq -r '.[].name_value' | sort -u
```

### 方法 2: 各サブドメインの CNAME を確認

```bash
for sub in $(列挙したサブドメイン); do
  dig +short CNAME $sub
done
```

CNAME が返ってくるサブドメインが対象。

### 方法 3: CNAME 宛先の SaaS が解約されているか確認

CNAME が `xxxxx.herokuapp.com` `yyyyy.github.io` 等の SaaS パターンに合致したら、その SaaS にアクセスして「リソースが存在しない」エラーが出るかを確認します。エラーメッセージは SaaS ごとに異なり、HerokuOSS 名解決失敗 / GitHub Pages の "There isn't a GitHub Pages site here" 等が判定キー。

## ドメイン番人の単発チェックなら 30 秒

毎回手作業は大変なので、ドメイン番人の [サブドメイン棚卸し 単発チェック](/subdomain/check) では、CT log + DoH 解決確認 + 11 種の既知 SaaS パターン照合を一括で行います。

## 是正の 4 ステップ

### ステップ 1: dangling と確定した CNAME は **DNS から削除**

最も確実。SaaS 側のリソースを将来再開する予定がない CNAME は DNS から消すのが鉄則です。

### ステップ 2: SaaS アカウントが残っているなら **リソース名を自社で再取得**

将来また使う可能性がある名前は、自社アカウントで占有しておくと攻撃者に取られない。

### ステップ 3: 過去 SaaS の解約処理を SaaS 側で適切に行う

SaaS によっては「アカウント削除時にリソース名を予約する」設定があります。

### ステップ 4: 再発防止のルール化

- サブドメイン作成・削除のフロー（誰が・いつ）
- 退職時のドメイン整理チェックリスト
- 定期棚卸し（半年〜1 年に 1 回）

## 見落としやすいパターン

| パターン | 見落とし理由 |
|---|---|
| ワイルドカード CNAME `*.legacy.example.co.jp` | 個別サブドメインがログに残らないので把握しにくい |
| 子サブドメイン `app.dev.example.co.jp` | CT 検索のクエリ式によっては漏れる |
| 認証不要の DNS 確認サービス（外部） | CNAME のみ確認して SaaS 占有状況まで見ない |

## まずは現状を把握しましょう

ドメイン番人の [サブドメイン棚卸し 単発チェック](/subdomain/check) で 30 秒で確認できます。dangling CNAME と既知 SaaS のテイクオーバー疑いを自動で flag します。

検出された dangling CNAME の整理、SaaS 占有、是正計画の優先順位付けなど棚卸し全般の支援は [サブドメイン棚卸し＋テイクオーバーリスク診断](/contact)（5 万円〜）でご相談ください。

関連記事:
- [サブドメインテイクオーバーとは？仕組みと EC・スタートアップ・制作会社への影響](/blog/subdomain-takeover-toha)
- [CT log でサブドメインを列挙する方法](/blog/ct-log-subdomain-enumeration)
- [GitHub Pages のサブドメインテイクオーバー対策](/blog/github-pages-subdomain-takeover)

総合点検は [無料のドメイン診断](/diagnose) を、SSL 単独は [SSL 単発チェック](/ssl/check) をご利用ください。