Azure DNS Zone 削除時に忘れてはいけない「委任解除」～サブドメインテイクオーバーを防ぐために～

はじめに

Azure でカスタムドメインの DNS 管理を行っている場合、「Subscription（サブスクリプション）を解約した」「DNS Zone を削除した」というだけでは、実はセキュリティ対応が完了していないケースがあります。

本記事では、Azure Subscription のライフサイクルと DNS 委任の関係、そして委任を削除し忘れた場合に発生しうる重大なリスク（サブドメインテイクオーバー）について詳しく解説します。

1. Azure Subscription を解約すると何が起きるのか

Azure Subscription には主に次のような状態遷移があります。

状態	内容
Active / Enabled	通常利用中。すべての操作が可能。
Disabled（無効）	解約直後に遷移。VM は割り当て解除、ストレージは読み取り専用に。リソースの取得・削除（`GET`/`DELETE`）は引き続き可能だが、新規作成・更新（`PUT`/`PATCH`/`POST`）は不可。
Deleted（削除済み）	配下の全リソース・データが完全に削除された状態。復旧不可。

解約直後の具体的なタイムライン

解約操作 → 課金は即時停止（ポータル反映は最大10分）
解約から 3日後 → 手動でのサブスクリプション削除が可能に
解約から 30〜90日 → Microsoft がデータ復旧に備えて一時保持（この間は課金なし）
その後 → 完全に永続削除（DNS Zone を含むすべてのリソースが失われる）

つまり、「解約した瞬間にすべてが消える」わけではなく、一定期間はリソースが残存し、最終的に完全削除されるという段階を踏みます。

2. DNS の「委任」とは何か

DNS における委任（Delegation）とは、あるドメインの管理権限を別のネームサーバーに引き渡す仕組みです。

contoso.com                          ← 親ゾーン（レジストラ / 社内DNS管理チーム）
  └─ TEST.contoso.com  ← 子ゾーン（Azure DNS に委任）

親ゾーン（contoso.com）側に、以下のような NS レコード を設定することで、TEST.contoso.com 以下の名前解決を Azure DNS に「委任」します。

TEST.contoso.com.  NS  ns1-xx.azure-dns.com.
TEST.contoso.com.  NS  ns2-xx.azure-dns.net.
TEST.contoso.com.  NS  ns3-xx.azure-dns.org.
TEST.contoso.com.  NS  ns4-xx.azure-dns.info.

誰かがこのホスト名を検索すると、親ゾーンの権威サーバーが「その先は Azure DNS に聞いてください」と案内し、最終的に Azure DNS 側のゾーンが実際の回答を返すという流れになります。

3. なぜ「Zone削除」と「委任削除」は別物なのか

見落とされがちなポイントとして、Azure 側で DNS Zone を削除しても、親ゾーン側の委任（NSレコード）は自動的には消えません。

Azure DNS Zone の削除 → Azure 側の「実体」がなくなるだけ
親ゾーン側の NS レコード → レジストラ／親ゾーン管理者が手動で削除しない限り残り続ける

さらに Azure DNS では、同じゾーン名を別の Subscription（＝別のテナント、別の契約者）で再作成することが可能という仕様があります（ゾーン名の一意性は Resource Group 内でのみ保証されるため）。

そのため、次のような危険な「空き地」状態が発生します。

親ゾーン： 委任（NSレコード）は残ったまま
$\downarrow$
Azure DNS 側： ゾーンの実体は削除済み（第三者が誰でも同名で再作成できる状態）

4. 委任を削除しないとどうなるか（想定される悪影響）

この「空き地」状態を放置すると、サブドメインテイクオーバー（Subdomain Takeover） と呼ばれる攻撃を受けるリスクが生じます。

偽サイトへの誘導
第三者が同名の Azure DNS Zone を再作成し、A レコードや CNAME を設定することで、正規ドメインの配下に偽サイト（フィッシングサイト等）を公開できてしまう。
なりすましメールのリスク
TXT レコードや MX レコードを第三者が設定することで、SPF/DKIM の偽装や、正規ドメイン宛メールの横取りが可能になる。
SSL/TLS証明書の不正取得
Let's Encrypt などの認証局はドメイン所有権の確認に DNS（ACME DNS Challenge）を利用するため、委任さえ生きていれば第三者が正規の証明書を取得できてしまう。
ブランド毀損・信頼低下
正規の親ドメイン配下であるため、ユーザーや取引先からは「公式ドメイン」に見えてしまい、悪用された場合の信用毀損リスクが大きい。
気づかれにくい（潜伏リスク）
親ドメイン自体は正常に機能しているため、通常の監視やセキュリティスキャンでは見落とされやすく、長期間放置される傾向がある。
コンプライアンス・情報漏洩リスク
関連システムとの連携用サブドメインだった場合、情報漏洩やアクセス制御上のインシデントに発展する可能性がある。

実害が今すぐ出ていなくても、「時限爆弾」的なリスクとして残り続ける点が最大の問題です。

5. 推奨される対応策

ステップ	対応内容
ステップ 1	Azure DNS Zone を削除する前に、まず親ゾーン（例：`contoso.com`）側の管理チームへ委任レコード（NSレコード）の削除も同時に依頼する。
ステップ 2	既に Zone を削除済みの場合は、親ゾーン側に委任（NSレコード）が残っていないか確認する。
ステップ 3	残っている場合は、該当の NS レコードを削除する。
ステップ 4	削除後、`dig NS TEST.contoso.com` や `nslookup` などで委任が解消されたことを確認する。
ステップ 5	今後も利用予定がある場合は、DNS Zone に Resource Lock（CanNotDelete）を設定し、誤削除を防止する。

まとめ

Azure Subscription の解約 ≠ 即時データ削除（Disabled期間を経て段階的に削除される）
Azure DNS Zone を削除しても、親ゾーン側の委任は自動的には消えない
委任が残ったまま放置すると、第三者による同名ゾーンの再取得＝サブドメインテイクオーバーのリスクがある
「Zoneを削除したら、委任側（親ゾーン）の削除も必ずセットで実施する」 ことが、最も確実なリスク低減策