Private DNS Zone の VNet リンク漏れは、本番障害ではなく設計不備です

山崎行政書士事務所のクラウド法務 × Azure技術支援としての現場評価

1. 結論

私は、Private Endpoint を使った PaaS 閉域設計で一番怖いのは、Private Endpoint を作ったのに、利用元 VNet から名前解決できない状態です。

これは、ネットワークが壊れているのではありません。多くの場合、Private DNS Zone と本番 VNet のリンク漏れです。

現場では、こうなります。

「Private Endpoint はあります」「Private DNS Zone もあります」「A レコードもあります」「dev では動きました」「stg でも動きました」「でも prod だけ FQDN で失敗します」「IP 直打ちなら通ります」「本番リリース後に気づきました」

この時点で、私は DNS を疑います。Private Endpoint の private IP があるかではなく、prod の VNet から FQDN が private IP に解決されているかを見ます。

公式技術資料では、Private Endpoint の IP アドレスを接続文字列の FQDN に解決するため、DNS 設定を正しく構成することが重要だと説明されています。また、Private DNS Zone を VNet にリンクして、対象ドメインを解決する構成が示されています。確認日：2026年5月4日。

2. 私が現場で最初に打つコマンド

私は、構成図を見る前に、まず利用元から名前解決を確認します。

nslookup <対象サービスのFQDN>

または、名前解決先と接続確認を分けて見ます。

nslookup <対象サービスのFQDN>Test-NetConnection <対象サービスのFQDN> -Port 443

見るのは単純です。

FQDN が private IP を返すか。public IP を返していないか。NXDOMAIN になっていないか。dev/stg/prod で結果が違わないか。オンプレ DNS 経由でも同じか。踏み台 VM、App Service、Functions、AKS、運用端末、委託先端末で結果が違わないか。

閉域化は、ネットワーク図では確認できません。名前解決の実測で確認します。

3. Private Endpoint を作っただけでは閉域設計は終わらない

Private Endpoint は、対象リソースに private IP を持つネットワークインターフェイスを作ります。公式技術資料でも、Private Endpoint のライフサイクル中に読み取り専用のネットワークインターフェイスが自動作成され、サブネットから動的 private IP が割り当てられ、その IP はライフサイクル中変更されないと説明されています。確認日：2026年5月4日。

しかし、private IP が存在しても、利用元が FQDN でその private IP を引けなければ、アプリは失敗します。

ここを誤ると、現場ではこうなります。

ネットワーク担当は「Private Endpoint はあります」と言う。アプリ担当は「FQDN で接続できません」と言う。インフラ担当は「IP 直打ちなら通ります」と言う。運用担当は「dev では動いたので DNS ではないと思いました」と言う。監査担当は「閉域化済みと資料にあります」と言う。委託先は「本番 VNet のリンクは範囲外でした」と言う。

これは、構成要素があるのに、利用元からの名前解決が完成していない状態です。

4. 本番だけ壊れる理由

dev/stg/prod で VNet が分かれている会社は多いです。

dev-vnetstg-vnetprod-vnet

Private DNS Zone は共通で作った。dev と stg にはリンクした。prod だけリンクし忘れた。または、prod は別サブスクリプション、別ハブ VNet、別 DNS フォワーダーを使っていた。その結果、本番だけ FQDN が private IP に解決されない。

公式技術資料では、自動登録なしで VNet を Private DNS Zone にリンクした場合、その VNet は解決用 VNet として扱われ、その VNet 内の VM は Private DNS Zone 内のレコードをクエリできると説明されています。つまり、VNet からそのゾーンのレコードを解決させるには、VNet Link が重要です。確認日：2026年5月4日。

だから私は、Private DNS Zone を見るとき、A レコードだけでは見ません。必ず VNet Link を見ます。

Private DNS Zone はあるか。A レコードはあるか。dev VNet はリンクされているか。stg VNet はリンクされているか。prod VNet はリンクされているか。hub VNet はリンクされているか。spoke VNet はリンクされているか。オンプレ DNS 経由の名前解決経路はあるか。リンク状態は Completed か。

公式技術資料でも、VNet Link 作成後はリンク状態を確認し、状態が完了に変わるまで数分かかる場合があると説明されています。確認日：2026年5月4日。

5. 私が見る数字

私は、この手の閉域設計では、きれいな構成図よりも数字を見ます。

Private DNS Zone 数。Private Endpoint 数。A レコード数。VNet Link 数。dev/stg/prod の VNet Link 有無。リンク状態が Completed でない数。環境別 nslookup 実測結果。public IP を返している FQDN 数。NXDOMAIN になっている FQDN 数。手動 A レコード数。不要な古い A レコード数。Private Endpoint 削除後に残った DNS レコード数。Private DNS Zone とサービス種別の不一致数。オンプレ DNS フォワーダー経由の失敗件数。本番リリース前に名前解決テストを実施していない環境数。

この数字が出ない会社は、閉域化を運用できていません。

6. 「IP直打ちは通る」は、むしろ危険なサインです

現場では、よくこう言われます。

「IP 直打ちなら通ります」

私は、それを聞くと安心しません。むしろ、DNS が壊れている証拠として扱います。

Private Endpoint の private IP に直接到達できるなら、ネットワーク経路は生きている可能性があります。それでも FQDN で失敗するなら、アプリが使う通常の接続方式が壊れています。

PaaS の接続では、FQDN が前提です。証明書、接続文字列、SDK、TLS、リダイレクト、サービス側の名前解決が絡むため、IP 直打ちを運用回避策にしてはいけません。

本番障害中に IP 直打ちで暫定対応したくなる気持ちは分かります。しかし、それは恒久対応ではありません。

恒久対応は、FQDN が正しい private IP を返すことです。

7. Private DNS Zone の設計ミスは、事故時に説明責任の問題になる

この問題は、単なる DNS 設定漏れでは終わりません。

監査資料に「閉域化済み」と書いている。セキュリティチェックシートに「Private Endpoint 利用」と書いている。取引先に「public 経路は使っていません」と説明している。契約上、特定データは閉域環境で扱うことになっている。しかし、本番だけ public 解決していた。または、本番だけ接続できず、業務停止した。

これは技術障害であると同時に、説明不一致です。

山崎行政書士事務所のクラウド法務として、私はここを重く見ます。

Private Endpoint を作った事実ではなく、本番 VNet から FQDN が private IP に解決される事実を証跡化する必要があります。

つまり、監査資料には構成図だけでなく、環境別 nslookup 結果を残すべきです。

dev からの nslookup。stg からの nslookup。prod からの nslookup。運用端末からの nslookup。委託先保守端末からの nslookup。オンプレ経由の nslookup。アプリ実行環境からの名前解決結果。

これが本当の閉域化証跡です。

8. よくある設計崩れ

8.1 dev/stg だけリンクされている

開発時に dev と stg は丁寧に作る。本番は別チーム、別サブスクリプション、別 IaC で作る。Private DNS Zone Link が抜ける。

一番多いパターンです。

8.2 hub VNet だけリンクして spoke から解決できると思っている

hub-spoke 構成で、hub には Private DNS Zone Link がある。しかし、spoke 側の名前解決経路が整理されていない。spoke から FQDN を引くと public に行く、または NXDOMAIN になる。

「hub にリンクしているから大丈夫」は、実測しないと信用できません。

8.3 Private DNS Zone はあるが、違うゾーン名を使っている

サービス種別ごとの推奨 zone 名を間違える。似た名前の zone を作る。A レコードを手動で入れる。動いたように見える。別サービスや別環境で壊れる。

公式技術資料でも、Private Endpoint の Private DNS Zone 構成は推奨される名前付けスキームを使う場合に自動生成されること、サービスごとに推奨 zone 名が示されていることが説明されています。確認日：2026年5月4日。

8.4 1つの zone に複数サービスを混ぜる

これも危険です。公式技術資料では、1つの Azure サービスにリンクされた既存の Private DNS Zone を、2つの異なる Azure サービスの Private Endpoint に関連付けてはならない、A レコード削除や解決問題が起き得ると説明されています。確認日：2026年5月4日。

現場では、管理を楽にしようとして zone を雑にまとめた結果、どこかの A レコードが壊れます。

8.5 Private Endpoint 削除後の古い A レコードが残る

古い private IP を返す。通信できない。原因調査に時間がかかる。本番切替時に古いレコードを参照する。

DNS は、作るときよりも消すときが危険です。

9. IaC に入っていない DNS は、いつか漏れます

私は、Private DNS Zone Link を手作業で作る運用を信用しません。

手作業だと、dev は入る。stg も入る。prod だけ抜ける。DR 用 VNet が抜ける。新しい spoke VNet が抜ける。委託先検証 VNet が抜ける。障害時に急造した VNet が抜ける。

だから、IaC に入れます。

Private DNS Zone。A レコード。VNet Link。リンク対象 VNet。環境別変数。リンク状態確認。削除時の依存関係。デプロイ後の nslookup テスト。

閉域化は、ポータルで作るものではなく、再現可能な構成として管理するべきです。

10. RBAC も見ないと危ない

Private DNS Zone の VNet Link 漏れは、単純な作業漏れに見えます。しかし、根本には RBAC 設計不備があることがあります。

ネットワークチームは VNet を管理している。アプリチームは Private Endpoint を作る。DNS チームは Private DNS Zone を管理している。クラウド運用委託先は一部しか権限がない。本番サブスクリプションでは権限が足りない。結果、prod の VNet Link だけ作れていなかった。

こういうことが起きます。

私は、Private DNS 周りでは次の権限を確認します。

Private DNS Zone を作れる人。VNet Link を作れる人。A レコードを変更できる人。本番 VNet へのリンクを承認できる人。Private Endpoint 作成者。DNS 変更の承認者。委託先の作業範囲。変更履歴の確認者。

DNS は地味ですが、本番障害を起こす権限です。誰でも触れるべきではありません。しかし、必要な人が触れない設計でも止まります。

11. 診断ログと運用証跡

Private DNS Zone Link 漏れの問題は、障害後にこう聞かれます。

誰が Private Endpoint を作ったのか。誰が DNS Zone を作ったのか。誰が VNet Link を作らなかったのか。本番リリース前に名前解決テストをしたのか。レビューで誰が確認したのか。なぜ dev/stg の結果だけで本番も動くと判断したのか。変更履歴は残っているのか。

このとき必要なのは、Azure Activity ログ、変更履歴、IaC の Pull Request、作業チケット、承認記録、nslookup 結果です。

山崎行政書士事務所のクラウド法務では、ここを「運用証跡」として整備します。

閉域設計は、できているかどうかだけではありません。誰が確認し、どの結果で本番投入を承認したかが重要です。

12. 私なら本番リリース前に必ずやる確認

本番リリース前に、私は次を必ずやります。

prod VNet から対象 FQDN を nslookup。prod App Service / VM / AKS / Functions など実行元から nslookup。オンプレ経由の利用があるならオンプレから nslookup。委託先保守端末から nslookup。Private DNS Zone の VNet Link 一覧確認。リンク状態が Completed であることを確認。A レコードが private IP を返すことを確認。古い A レコードがないことを確認。public IP を返していないことを確認。接続先 PaaS の public access 状態を確認。障害時の切り戻し手順確認。確認結果をチケットに添付。

ここまでやってから、本番リリースを承認します。

「dev/stg で動いた」は、本番の証跡ではありません。

13. 山崎行政書士事務所としての見解

私は、Private DNS Zone の VNet Link 漏れを、単なる Azure 設定漏れとは見ません。

これは、PaaS 閉域化における説明責任の欠落です。

閉域化済みと説明するなら、次を示す必要があります。

Private Endpoint がある。Private DNS Zone がある。A レコードがある。prod VNet がリンクされている。prod から FQDN が private IP に解決される。public 解決していない。アクセスログが残る。DNS 変更履歴が残る。委託先の作業範囲が明確。本番リリース前の実測結果が残っている。

山崎行政書士事務所としては、次の成果物を整備すべきだと考えます。

Private DNS Zone 一覧。Private Endpoint 一覧。VNet Link 一覧。dev/stg/prod 環境別リンク確認表。FQDN 別 nslookup 実測結果。A レコード棚卸表。DNS 変更承認フロー。RBAC 責任分界表。委託先作業範囲表。閉域化監査ワンペーパー。本番リリース前 DNS チェックリスト。障害時切り戻し手順。

14. 最終評価

私は、Private DNS Zone の VNet Link 漏れを、本番だけ壊れる典型だと見ています。

理由は、dev/stg で正常でも、本番 VNet がリンクされていなければ、本番だけ名前解決が壊れるからです。そして、IP 直打ちで通るため、ネットワーク障害と誤認されやすい。実際には、DNS 設計と運用証跡の問題です。

正しい整理はこれです。

Private Endpoint は private IP を作る。Private DNS Zone は FQDN を private IP に解決する。VNet Link は、その VNet から Zone を引けるようにする。A レコードは接続先を示す。nslookup は閉域化の実測証跡になる。dev/stg/prod は別々に確認する。構成図ではなく、本番 VNet からの実測で確認する。

山崎行政書士事務所のクラウド法務として、私はこのテーマを次の一文で整理します。

PaaS閉域化は、Private Endpoint を作ることではない。本番 VNet から FQDN が private IP に解決されることを、VNet Link、A レコード、RBAC、診断ログ、作業証跡で説明できる状態にすることだ。

これをやらない会社は、dev/stg では動いても、本番だけ壊します。これをやる会社は、閉域化を構成図ではなく、実測と証跡で語れます。