Azure DNS Private ResolverでハイブリッドDNSを整理する

山崎行政書士事務所
7月8日
読了時間: 21分

オンプレDNS、Azure DNS、条件付きフォワードの複雑化を防ぐDNS責任分界と運用手順

確認日：2026年7月8日対象読者：情シス担当者、Azure運用担当者、ネットワーク担当者、クラウド移行担当者、監査対応担当者、経営層対象領域：Azure DNS Private Resolver、Azure Private DNS Zone、オンプレミスDNS、条件付きフォワーダー、Private Endpoint、DNS運用規程

結論

ハイブリッド環境のDNSは、Azure DNS Private Resolverを中心に、オンプレDNS・Azure Private DNS Zone・条件付きフォワード・Private Endpoint DNSを整理するべきです。

理由は、オンプレミスDNS、Azure上のカスタムDNS VM、Azure提供DNS、Private DNS Zone、Private Endpoint、条件付きフォワーダーが混在すると、名前解決の経路が見えなくなり、障害時に「どこで止まっているのか」を説明できなくなるためです。

数字で見ると、最低限整理すべき項目は12個です。

No.	管理項目	内容
1	DNS名前空間	corp.example.local、privatelink.*、業務サブドメイン
2	権威DNS	そのゾーンを誰が管理しているか
3	条件付きフォワーダー	どのドメインをどこへ転送するか
4	Azure DNS Private Resolver	配置VNet、リージョン、受信・送信エンドポイント
5	Inbound Endpoint	オンプレDNSからAzureへ向かう転送先IP
6	Outbound Endpoint	AzureからオンプレDNS等へ転送する出口
7	DNS Forwarding Ruleset	転送ルール、リンク先VNet、優先設計
8	Private DNS Zone	Private Endpoint用ゾーン、業務用プライベートゾーン
9	VNet Link	どのVNetがどのDNSゾーン・ルールセットを使うか
10	変更管理	DNS変更申請、承認、切戻し、検証
11	ログ・監視	QPS、DNSQueryLogs、Activity Log、異常検知
12	責任分界	オンプレ担当、Azure担当、アプリ担当、監査担当

1. なぜハイブリッドDNSは複雑化するのか

クラウド移行が進む企業では、DNSが次のように分散しがちです。

オンプレミス
  ├─ Active Directory DNS
  ├─ 既存業務システムDNS
  ├─ 条件付きフォワーダー
  └─ 拠点・工場・閉域網DNS

Azure
  ├─ Azure提供DNS
  ├─ Azure Private DNS Zone
  ├─ Private Endpoint用DNS
  ├─ Azure DNS Private Resolver
  ├─ 旧来のDNS Forwarder VM
  └─ 各VNetのカスタムDNS設定

この状態でPrivate EndpointやマルチVNet、ExpressRoute、VPN、複数サブスクリプションが増えると、DNSはすぐにブラックボックス化します。

Microsoft公式では、Azure Virtual Networkの名前解決方法として、Azure Private DNS Zone、Azure提供の名前解決、独自DNSサーバー、Azure DNS Private Resolverが示されています。さらに、Azure提供DNSは基本的な権威DNS機能に限られ、DNSゾーン名やDNSレコードのライフサイクルを利用者が制御できないため、より柔軟な構成ではAzure Private DNS ZoneとDNS Private Resolver等の組み合わせが必要になります。

2. Azure DNS Private Resolverとは

Azure DNS Private Resolverは、VMベースのDNSフォワーダーを構築・保守しなくても、Azure Virtual Networkとオンプレミス環境の間でプライベートDNS解決を行うためのマネージドサービスです。

Microsoft公式では、Azure DNS Private ResolverはVNet内に作成し、DNSクエリの宛先となる受信エンドポイントを作成し、送信エンドポイントはDNS転送ルールセットに基づいてクエリを処理すると説明されています。また、Private Resolverを使うためにVMのDNSクライアント設定を変更する必要はないとされています。

図1：Azure DNS Private Resolverの基本構成

オンプレミスDNS
  │
  │ 条件付きフォワード
  │ 例：privatelink.database.windows.net → 10.10.0.4
  ▼
┌──────────────────────────┐
│ Azure DNS Private Resolver │
│                          │
│  Inbound Endpoint         │
│  10.10.0.4                │
│                          │
│  Outbound Endpoint        │
│  DNS Forwarding Ruleset   │
└───────────┬──────────────┘
            │
            ├─ Azure Private DNS Zone
            │   privatelink.database.windows.net
            │
            └─ オンプレDNS
                corp.example.local

3. 確認できた公式情報

項目	確認できた事実
Private Resolverの基本	VNet内に作成し、受信エンドポイントと送信エンドポイント、DNS転送ルールセットで構成する
VM DNS設定	Private Resolver利用のためにVMのDNSクライアント設定を変更する必要はない
ハイブリッドDNS	Azureリソースがオンプレドメインを解決し、オンプレDNSがAzure Private DNS Zoneを解決する構成が可能
オンプレ接続	ハイブリッドDNS構成ではVPNまたはExpressRoute接続が前提
可用性	Azure DNS Private Resolverはマネージドサービスで、組み込みの高可用性を持つ
ルールセット	DNS Forwarding Rulesetは特定名前空間のクエリを指定DNSサーバーへ転送する
制限	1サブスクリプションあたりPrivate Resolverは15、1VNetあたり1、受信・送信エンドポイントは各5、ルールセットあたり転送ルール1000、VNetリンク500、エンドポイントあたり10,000 QPS

Microsoft公式のハイブリッドDNS手順では、Azure DNS Private ResolverとDNS Forwarding Rulesetを使って、Azureからオンプレドメインを解決し、オンプレDNSからAzure Private DNS Zoneを解決する流れが説明されています。オンプレミスDNS条件付きフォワーダーは、Private ResolverのInbound Endpoint IPへ向ける構成例が示されています。

また、Azure DNS Private Resolverの制限として、サブスクリプションあたり15個、VNetあたり1個、Resolverあたり受信エンドポイント5個・送信エンドポイント5個、転送ルールセットあたり1000ルール、500 VNetリンク、エンドポイントあたり10,000 QPSがMicrosoft公式に記載されています。

4. 整理前によくある構成

図2：複雑化したDNS構成

オンプレAD DNS
  ├─ corp.example.local
  ├─ 条件付きフォワード：database.windows.net → DNS VM A
  ├─ 条件付きフォワード：blob.core.windows.net → DNS VM B
  └─ 条件付きフォワード：azure.internal → 旧DNS VM

Azure Hub VNet
  ├─ DNS Forwarder VM A
  ├─ DNS Forwarder VM B
  ├─ Azure Firewall DNS Proxy
  └─ Private DNS Zone

Azure Spoke VNet
  ├─ VNetごとにDNS設定が異なる
  ├─ Private DNS Zone Linkが不足
  ├─ 条件付きフォワード未反映
  └─ Private Endpointはあるが名前解決できない

この構成の問題は、DNS障害時に「DNSレコードがない」のか、「フォワード先が違う」のか、「VNet Linkがない」のか、「Private EndpointのDNS Zone Groupが壊れている」のかをすぐに切り分けられないことです。

5. 目指すべき構成

図3：Azure DNS Private Resolverを中心にした整理後の構成

                  ┌────────────────────┐
                  │ オンプレミスDNS      │
                  │ AD DNS / BIND等     │
                  └─────────┬──────────┘
                            │
          条件付きフォワード│
          Azure向けドメイン │
                            ▼
        ┌────────────────────────────┐
        │ Azure Hub VNet              │
        │                            │
        │ Azure DNS Private Resolver  │
        │  ├─ Inbound Endpoint        │
        │  ├─ Outbound Endpoint       │
        │  └─ DNS Forwarding Ruleset  │
        │                            │
        │ Azure Private DNS Zones     │
        └─────────┬──────────┬───────┘
                  │          │
         Ruleset Link    Private DNS Link
                  │          │
        ┌─────────▼──────────▼───────┐
        │ Azure Spoke VNets           │
        │ App / AKS / VM / PaaS       │
        └────────────────────────────┘

Microsoft公式では、DNS Forwarding RulesetをVNetにリンクすると、そのVNet内のリソースは設定された転送ルールを使用できます。ハブアンドスポーク構成では、ルールセットをスポークVNetにリンクし、ハブVNetのPrivate Resolver Inbound Endpointへ転送する例も示されています。

6. DNS経路を3つに分けて考える

ハイブリッドDNSは、1つの仕組みで考えると混乱します。実務では、次の3経路に分けると整理しやすくなります。

表1：DNS経路の整理

経路	例	主な仕組み	責任者
オンプレ → Azure	オンプレPCからPrivate Endpointへ接続	オンプレDNS条件付きフォワーダー → Inbound Endpoint	オンプレDNS担当＋Azureネットワーク担当
Azure → オンプレ	Azure VMからADドメイン名を解決	DNS Forwarding Ruleset → Outbound Endpoint → オンプレDNS	Azureネットワーク担当＋オンプレDNS担当
Azure内	Spoke VNetからPrivate DNS Zoneを解決	Private DNS Zone LinkまたはRuleset Link	Azureネットワーク担当＋アプリ担当

7. オンプレ → Azureの名前解決

オンプレミス側からAzure Private DNS ZoneやPrivate Endpointへアクセスする場合、オンプレDNSに条件付きフォワーダーを設定し、Azure DNS Private ResolverのInbound Endpoint IPへ転送します。

図4：オンプレからAzure Private DNS Zoneを解決する流れ

オンプレ端末
  │
  │ nslookup app.privatelink.example
  ▼
オンプレDNS
  │
  │ 条件付きフォワード
  │ Azure向けゾーン → 10.10.0.4
  ▼
Azure DNS Private Resolver
  │
  │ Inbound Endpoint
  ▼
Azure Private DNS Zone
  │
  ▼
Private Endpoint IPを応答

Microsoft公式のハイブリッドDNS手順では、オンプレミスDNSの条件付きフォワーダーをAzure DNS Private ResolverのInbound Endpoint IPへ向ける例が示されています。

8. Azure → オンプレの名前解決

Azure側からオンプレミスのADドメイン、業務システム名、内部API名を解決する場合は、DNS Forwarding Rulesetでオンプレドメインを指定し、送信先をオンプレDNSサーバーにします。

図5：AzureからオンプレDNSを解決する流れ

Azure VM / AKS / App
  │
  │ query: fileserver.corp.example.local
  ▼
Azure提供DNS
  │
  ▼
Azure DNS Private Resolver
  │
  │ DNS Forwarding Ruleset
  │ corp.example.local → 10.100.0.2
  ▼
オンプレDNS
  │
  ▼
オンプレIPを応答

Microsoft公式のハイブリッドDNS例では、Azure VMからオンプレドメインを問い合わせる経路として、Azure DNS、Private Resolverのエンドポイント、Ruleset、オンプレDNSへ進む流れが説明されています。

9. Private EndpointのDNSで注意すべきこと

Private Endpointでは、DNS構成が非常に重要です。Microsoft公式では、Private EndpointのIPアドレスを接続文字列のFQDNへ解決するためにDNS設定を正しく構成することが重要であり、既存AzureサービスのパブリックエンドポイントDNS構成をPrivate Endpoint用に上書きする必要があると説明されています。

表2：Private Endpoint DNSの注意点

注意点	内容
FQDNは変えない	アプリの接続先URLを変えず、DNSでPrivate IPへ誘導する
推奨ゾーン名を使う	サービスごとの推奨Private DNS Zone名を使う
ActiveなPublic Zoneを安易に上書きしない	Public DNSへの転送がないと解決不能になる可能性
複数サービスを同一Private DNS Zoneへ混在させない	既存Aレコード削除等による解決問題が起き得る
DNSとアクセス制御は別	DNS解決できても、サービス側FirewallやPublic Network Access設定で拒否される場合がある
DNS Zone Groupを活用する	Private Endpoint更新時のDNSレコード管理を自動化しやすい

Private Endpoint DNS統合の公式情報では、オンプレミスからPrivate Endpointへアクセスする場合、条件付きフォワードは推奨されるPublic DNS Zone forwarderへ向けるべきで、例としてdatabase.windows.netを使い、privatelink.database.windows.netではないと説明されています。

10. 権威DNSとフォワーダーを混同しない

DNS運用で最も重要なのは、どのDNSが権威を持ち、どのDNSが単に転送しているだけかを分けることです。

表3：権威DNSとフォワーダーの違い

種類	役割	例
権威DNS	DNSレコードの正本を持つ	AD DNS、Azure Private DNS Zone、Azure DNS Public Zone
リゾルバー	問い合わせを受けて解決する	Azure DNS Private Resolver、クライアントDNS
フォワーダー	自分で答えず他DNSへ転送する	オンプレDNS条件付きフォワーダー、DNS Forwarding Ruleset
キャッシュDNS	一時的に応答を保持する	Windows DNS、BIND、DNS Proxy

11. DNS名前空間台帳を作る

DNSを整理する第一歩は、技術設定ではなく台帳です。

表4：DNS名前空間台帳

名前空間	種別	権威DNS	フォワード先	利用者	所有者	変更窓口
corp.example.local	オンプレAD	AD DNS	オンプレDNS	全社端末、Azure VM	情シス基盤	AD担当
privatelink.database.windows.net	Private Endpoint	Azure Private DNS Zone	Azure Private Resolver	Azure/オンプレ業務アプリ	Azure基盤	クラウド担当
privatelink.blob.core.windows.net	Private Endpoint	Azure Private DNS Zone	Azure Private Resolver	バックアップ、ログ保管	Azure基盤	クラウド担当
apps.internal.example.com	業務内部	Azure Private DNS Zone	Inbound Endpoint	Azureアプリ	アプリ部門	アプリ担当
legacy.example.local	旧基盤	旧DNS	オンプレDNS	移行中システム	旧基盤担当	移行PM

12. DNS責任分界を明確にする

DNSは、ネットワーク担当だけでは完結しません。オンプレDNS、Azureネットワーク、アプリ、セキュリティ、監査が関係します。

表5：DNS責任分界表

領域	主担当	承認者	証跡
オンプレAD DNS	AD/DNS担当	情シス責任者	AD変更履歴、DNS設定バックアップ
Azure DNS Private Resolver	Azureネットワーク担当	クラウド責任者	IaC、Activity Log、構成図
Inbound Endpoint IP管理	Azureネットワーク担当	クラウド責任者	IP台帳、オンプレ条件付きフォワード設定
Outbound Endpoint	Azureネットワーク担当	クラウド責任者	Subnet台帳、Ruleset関連付け
DNS Forwarding Ruleset	Azureネットワーク担当	変更管理責任者	PR、変更申請、承認ログ
Private DNS Zone	Azure基盤担当	クラウド責任者	Zone台帳、レコード一覧
Private Endpoint DNS Zone Group	アプリ担当＋Azure担当	システムオーナー	PE作成記録、DNSレコード
条件付きフォワーダー	オンプレDNS担当	情シス責任者	Windows DNS/BIND設定
DNS監視	SOC/運用担当	情報セキュリティ責任者	Log Analytics、アラート記録
DNS例外	セキュリティ担当	CISO/情シス責任者	例外台帳、期限、代替策

13. RACI表

表6：ハイブリッドDNS運用RACI

作業	オンプレDNS	Azureネットワーク	アプリ担当	セキュリティ	監査/規程	経営層
DNS設計方針	C	R	C	C	C	A
Resolver作成	I	R	I	C	I	I
Inbound IP通知	C	R	I	I	I	I
オンプレ条件付きフォワード	R	C	I	C	I	I
Ruleset作成	C	R	C	C	I	I
Private DNS Zone作成	I	R	C	C	I	I
Private Endpoint追加	I	C	R	C	I	I
DNS障害対応	R	R	C	C	I	I
DNSログ監視	I	C	I	R	C	I
例外承認	C	C	C	A	R	I
重大障害報告	I	C	C	R	C	A

R：実行責任、A：説明責任、C：相談先、I：共有先

14. 中央集約型と分散型の比較

表7：設計パターン比較

パターン	内容	向いている環境	注意点
中央集約型	Hub VNetにPrivate ResolverとPrivate DNS Zoneを集約	大企業、複数Spoke、監査重視	Hub依存、ルール設計が重要
分散型	各VNetまたは各リージョンにResolver/Zoneを配置	独立性が高いシステム	設定重複、管理負荷増
DNS VM継続型	既存DNS Forwarder VMを使い続ける	移行途中、特殊要件あり	パッチ、冗長化、監視が必要
ハイブリッド併用型	Private Resolver＋既存DNSを段階移行	現実的な移行期	責任分界が曖昧になりやすい

実務上は、まず中央集約型を標準にし、特殊な要件がある場合だけ分散型・個別構成を例外として扱う方が、監査・運用・障害対応で説明しやすくなります。

15. Azure DNS Private Resolverの制限を設計に反映する

表8：主要制限と設計上の意味

制限	数値	設計上の意味
サブスクリプションあたりResolver数	15	大規模環境ではサブスクリプション設計が重要
VNetあたりResolver数	1	Hub VNetの設計を誤ると後から分割しにくい
ResolverあたりInbound Endpoint	5	複数IP・複数用途を設計段階で整理
ResolverあたりOutbound Endpoint	5	転送先設計とリージョン設計が重要
Rulesetあたり転送ルール	1000	名前空間を整理しないと上限に近づく
RulesetあたりVNet Link	500	大規模Hub-Spokeではリンク台帳が必須
VNetにリンクできるRuleset	1	複数チームが勝手にRulesetを作る設計は危険
転送ルールあたりターゲットDNS	6	オンプレDNS冗長化の上限確認が必要
EndpointあたりQPS	10,000	大量問い合わせ環境ではQPS監視が必要

これらの制限はMicrosoft公式のAzureサービス制限に記載されています。

16. 運用手順1：新しいPrivate Endpointを追加する場合

図6：Private Endpoint追加時のDNS手順

Private Endpoint作成申請
        │
        ▼
対象サービスの推奨Private DNS Zone確認
        │
        ▼
既存Private DNS Zoneの有無確認
        │
        ├─ 既存あり → 同じZoneを利用
        └─ 既存なし → 新規Zone作成
        │
        ▼
Private DNS Zone Group作成
        │
        ▼
Hub/SpokeのVNet LinkまたはRuleset Link確認
        │
        ▼
オンプレアクセス要否確認
        │
        ├─ 必要 → 条件付きフォワーダー確認
        └─ 不要 → Azure内検証のみ
        │
        ▼
名前解決テスト
        │
        ▼
台帳更新・証跡保存

表9：Private Endpoint追加チェックリスト

No.	チェック項目	OK/NG
1	対象サービスの推奨Private DNS Zone名を確認した
2	同名Private DNS Zoneの既存有無を確認した
3	重複Zoneを作成していない
4	Private DNS Zone Groupを設定した
5	DNSレコードが作成された
6	対象VNetからPrivate IPへ解決できる
7	オンプレから解決できる必要があるか確認した
8	条件付きフォワーダーの転送先を確認した
9	Public Endpointへの誤解決がない
10	アプリ接続テストを実施した
11	DNS台帳を更新した
12	変更申請と承認記録を保存した

Private Endpoint DNS統合の公式情報では、Private EndpointのDNS Zone Groupにより、Private DNS ZoneとPrivate Endpointの関連付けを管理し、Private Endpoint更新時にDNSレコードを自動更新しやすくなることが説明されています。

17. 運用手順2：オンプレドメインをAzureから解決する場合

表10：オンプレドメイン解決の手順

手順	作業	担当	証跡
1	解決対象ドメインを確認	アプリ担当	申請書
2	権威DNSを確認	オンプレDNS担当	DNS台帳
3	転送先DNS IPを確認	オンプレDNS担当	IP台帳
4	DNS Forwarding Rulesetにルール追加	Azureネットワーク担当	PR/IaC
5	Ruleset Link対象VNetを確認	Azureネットワーク担当	VNet台帳
6	Azure側から名前解決テスト	運用担当	テスト結果
7	アプリ接続確認	アプリ担当	リリース記録
8	台帳更新	運用担当	DNS台帳

例

対象ドメイン：
corp.example.local

転送先：
10.100.0.2
10.100.0.3

用途：
Azure VM / AKS / App ServiceからオンプレAD・ファイルサーバー名を解決

18. 運用手順3：新しいSpoke VNetを追加する場合

表11：Spoke VNet追加時のDNS確認

項目	確認内容
VNetのDNS設定	Azure提供DNSのままか、カスタムDNSか
Ruleset Link	対象DNS Forwarding Rulesetにリンクしたか
Private DNS Zone Link	必要なPrivate DNS Zoneへリンクしたか
Hub接続	VNet Peering、UDR、Firewall経路に問題ないか
オンプレ接続	ExpressRoute/VPN経路でInbound Endpointへ到達できるか
名前解決	Azure→オンプレ、Azure→Private Endpoint、オンプレ→Azureを確認
監視	DNS関連メトリック・ログ対象に含めたか
台帳	VNet、Ruleset、Zone Linkを更新したか

Microsoft公式のハイブリッドDNS手順では、Private ResolverがあるVNetのDNS設定をInbound Endpoint IPへ変更せず、既定DNS設定のままにする注意が示されています。

19. テスト観点

DNSは、設定しただけでは不十分です。必ず複数地点からテストします。

表12：DNSテストケース

テスト元	テスト対象	期待結果
Azure Hub VM	オンプレFQDN	オンプレIPへ解決
Azure Spoke VM	オンプレFQDN	オンプレIPへ解決
Azure App/AKS	Private Endpoint FQDN	Private IPへ解決
オンプレ端末	Azure Private DNS Zoneレコード	Azure Private IPへ解決
オンプレ端末	Private Endpoint FQDN	Private IPへ解決
Azure VM	Public FQDN	Public IPまたは設計どおりの応答
Azure VM	存在しないレコード	NXDOMAINまたは期待エラー
DR拠点	Azure Private DNS Zone	セカンダリ経路で解決

コマンド例

nslookup mydb.database.windows.net

nslookup test.corp.example.local

Resolve-DnsName myapp.internal.example.com

dig mydb.database.windows.net

dig test.corp.example.local

dig myapp.internal.example.com

20. DNS監視とログ

Azure DNSの監視では、DNS ResolverのQPS、Inbound Endpoint数、Outbound Endpoint数などのメトリックを確認できます。Microsoft公式のAzure DNS監視リファレンスでは、Microsoft.Network/dnsResolversのメトリックとしてInbound Endpoint Count、Outbound Endpoint Count、Queries Per Secondが示されています。

また、DNS Security Policyを利用する場合、VNetレベルでDNSクエリのフィルタリングとログ記録が可能で、DNSログをStorage Account、Log Analytics Workspace、Event Hubsへ送信でき、Allow、Alert、Blockのアクションを選択できます。

表13：監視すべき指標

監視項目	目的
Resolver QPS	負荷増加、DDoS的な問い合わせ、設定ミス検知
Inbound Endpoint Count	構成変更確認
Outbound Endpoint Count	構成変更確認
Ruleset Rule Count	ルール肥大化確認
VNet Link Count	Spoke追加漏れ確認
DNSQueryLogs	問い合わせ元、問い合わせ名、応答、Policy Action確認
Activity Log	Resolver、Ruleset、Zone Link変更の監査
NXDOMAIN増加	誤設定、不要問い合わせ、アプリ不具合検知
特定ドメイン急増	マルウェア、DNSトンネリング、設定不備の兆候

DNSQueryLogsの公式リファレンスでは、SourceIpAddress、QueryName、QueryType、ResponseCode、ResolutionPath、DnsForwardingRulesetDomain、ResolverPolicyRuleActionなどの列が確認できます。

KQL例：問い合わせ上位ドメイン

DNSQueryLogs
| where TimeGenerated > ago(24h)
| summarize Queries = count() by QueryName
| top 50 by Queries desc

KQL例：NXDOMAINや異常応答の確認

DNSQueryLogs
| where TimeGenerated > ago(24h)
| where ResponseCode != 0
| summarize Count = count() by ResponseCode, QueryName, SourceIpAddress
| order by Count desc

KQL例：特定VNetからの問い合わせ確認

DNSQueryLogs
| where TimeGenerated > ago(24h)
| where VirtualNetworkId contains "<vnet-name-or-id>"
| project TimeGenerated, SourceIpAddress, QueryName, QueryType,
          ResponseCode, ResolutionPath, ResolverPolicyRuleAction
| order by TimeGenerated desc

21. DNS障害時の切り分け手順

図7：DNS障害切り分けフロー

名前解決できない
      │
      ▼
どこから問い合わせたか確認
      │
      ├─ オンプレ端末
      │     ├─ オンプレDNS条件付きフォワード確認
      │     ├─ Inbound Endpoint到達性確認
      │     └─ Private DNS Zone Link確認
      │
      ├─ Azure VM / AKS
      │     ├─ VNet DNS設定確認
      │     ├─ Ruleset Link確認
      │     ├─ Forwarding Rule確認
      │     └─ オンプレDNS到達性確認
      │
      └─ App Service / PaaS
            ├─ VNet統合確認
            ├─ DNS設定確認
            ├─ Private Endpoint DNS確認
            └─ アプリ構成確認

表14：障害パターンと原因

症状	可能性のある原因	確認箇所
オンプレからPrivate Endpointに接続できない	条件付きフォワード不足	オンプレDNS
Azureからオンプレ名が解決できない	Ruleset未設定	DNS Forwarding Ruleset
Spokeだけ解決できない	Ruleset LinkまたはZone Link不足	VNet Link
Public IPへ解決される	Private DNS Zone未リンク	Private DNS Zone
NXDOMAINになる	ゾーン重複、レコード不足	Private DNS Zone
一部アプリだけ失敗	DNSキャッシュ、アプリ独自DNS	アプリ設定
たまに失敗する	DNSサーバー冗長性不足	条件付きフォワード先
大量遅延	QPS超過、転送先遅延	Resolverメトリック

22. DNS変更管理台帳

DNS変更は、アプリ停止につながります。必ず変更管理台帳に残します。

表15：DNS変更管理台帳

項目	記入例
変更番号	DNS-CHG-2026-001
変更種別	新規Forwarding Rule追加
対象名前空間	corp.example.local
変更理由	AzureアプリからオンプレAD参照が必要
変更前	ルールなし
変更後	corp.example.local → 10.100.0.2, 10.100.0.3
影響範囲	Azure Hub/Spoke VNet内の全ワークロード
検証方法	Hub VM、Spoke VM、AKS Podからnslookup
切戻し方法	ルール無効化または削除
実施者	Azureネットワーク担当
承認者	情シス責任者
実施日時	2026-07-15 22:00
完了確認	2026-07-15 22:30
証跡	PR、Activity Log、テスト結果

23. DNS例外管理

DNS例外は放置すると危険です。一時対応で追加したフォワードや手動Aレコードが、そのまま残り続けることがあります。

表16：DNS例外管理台帳

項目	記入例
例外番号	DNS-EX-2026-003
対象	手動Aレコード
ゾーン	privatelink.blob.core.windows.net
理由	緊急障害対応のため一時的に手動登録
代替策	正式なPrivate DNS Zone Group設定へ移行
期限	2026-08-31
承認者	情シス責任者
再評価日	2026-08-15
削除条件	Private Endpoint再作成後
証跡	チケット、変更申請、検証ログ

24. DNS運用規程に入れるべき項目

表17：DNS運用規程の構成

規程項目	記載内容
目的	ハイブリッド環境の名前解決を安定化し、障害・監査対応を可能にする
適用範囲	オンプレDNS、Azure DNS、Private Resolver、Private DNS Zone、Private Endpoint
DNS名前空間管理	ゾーン所有者、権威DNS、フォワード先
変更管理	DNSレコード、Forwarding Rule、VNet Link、条件付きフォワード
責任分界	オンプレ担当、Azure担当、アプリ担当、監査担当
Private Endpoint DNS	推奨ゾーン名、DNS Zone Group、重複防止
条件付きフォワード	設定基準、宛先、冗長化、テスト
監視	QPS、DNSQueryLogs、Activity Log、異常検知
障害対応	切り分け手順、連絡経路、重大度
例外管理	手動レコード、暫定フォワード、期限、承認
証跡保存	変更申請、承認、テスト結果、ログ
定期レビュー	月次棚卸し、四半期レビュー、年次見直し

規程文サンプル

第○条（ハイブリッドDNS運用）

1. 当社のAzureおよびオンプレミス環境におけるDNS名前解決は、
   DNS名前空間台帳、条件付きフォワーダー台帳、Private DNS Zone台帳に基づき管理する。

2. Azure DNS Private Resolverの受信エンドポイント、送信エンドポイント、
   DNS転送ルールセット、VNetリンクを変更する場合は、事前に変更申請を行い、
   影響範囲、検証方法、切戻し方法を明記しなければならない。

3. オンプレミスDNSからAzure Private DNS ZoneまたはPrivate Endpointへ
   条件付きフォワードを行う場合は、転送先、対象ドメイン、冗長化、
   承認者、検証結果を記録する。

4. Private Endpointを追加する場合は、Microsoftが推奨するPrivate DNS Zone名を確認し、
   既存Zoneの重複作成を避け、DNS Zone Groupまたは所定のDNS運用手順に従って登録する。

5. DNS障害が発生した場合は、問い合わせ元、対象FQDN、応答コード、
   Forwarding Rule、VNet Link、Private DNS Zone、オンプレDNSの順に切り分けを実施する。

6. 一時的な手動DNSレコード、暫定フォワーダー、DNS例外は、
   理由、期限、承認者、代替策、再評価日を記録し、期限到来時に見直す。

25. セキュリティ観点：DNSはセキュリティ基盤である

DNSは単なる名前解決ではありません。NIST SP 800-81 Rev.3は、DNSを企業ネットワークアーキテクチャの不可欠な要素と位置付け、DNSインフラへの攻撃は企業ネットワーク運用全体に影響し得ると説明しています。また、DNSをゼロトラストや多層防御の一部として安全に展開するためのガイドラインを示しています。

表18：DNSセキュリティで見るべき観点

観点	内容
改ざん	不正なAレコード、CNAME変更
誤設定	条件付きフォワード先ミス、Zone Link漏れ
可用性	DNS障害による全社停止
監査	誰がDNSを変更したか
検知	不審ドメイン問い合わせ、DNSトンネリング疑い
保全	DNS変更履歴、Activity Log、DNSQueryLogs
責任分界	オンプレ・Azure・アプリの境界

26. 経営層向け説明

図8：経営層に説明するDNSガバナンス

DNSが整理されていない
  ↓
Private Endpointに接続できない
  ↓
業務アプリ停止
  ↓
原因調査に時間がかかる
  ↓
監査・事故対応で説明できない


DNSを整理する
  ↓
誰が何を管理するか明確
  ↓
名前解決経路が見える
  ↓
障害時に切り分けできる
  ↓
監査・経営説明が可能

表19：経営層へ説明すべきポイント

論点	説明
DNSは基盤リスク	DNS障害は認証、DB接続、Private Endpoint、アプリ通信へ波及する
Private Resolverの価値	DNS Forwarder VMを減らし、マネージドに寄せられる
それでも運用責任は残る	名前空間、条件付きフォワード、レコード、例外は企業側管理
監査対応	DNS変更履歴、承認、台帳、ログを提示できる必要がある
コスト	VM運用コストだけでなく、障害調査・属人化コストも削減対象
標準化	ルール化しないとVNet・Private Endpoint増加時に破綻する

27. 山崎行政書士事務所としての支援領域

Azure DNS Private Resolverの導入は、単なるAzure構築ではありません。オンプレDNS、Azure Private DNS Zone、Private Endpoint、条件付きフォワーダー、監査証跡、変更管理、例外管理まで含む、クラウドガバナンスの重要領域です。

表20：支援できる内容

領域	支援内容
Azure技術支援	Azure DNS Private Resolver、Inbound/Outbound Endpoint、Ruleset設計
ハイブリッドDNS	オンプレDNS、条件付きフォワーダー、ExpressRoute/VPN前提整理
Private Endpoint DNS	Private DNS Zone、DNS Zone Group、VNet Link整理
運用設計	DNS変更管理、障害切り分け、テスト手順、台帳整備
監査対応	DNS責任分界、Activity Log、DNSQueryLogs、証跡保存
セキュリティ	DNS Security Policy、異常問い合わせ監視、ゼロトラスト観点
規程整備	DNS運用規程、クラウド利用規程、例外管理規程
経営説明	DNSリスク、可用性、責任分界、監査説明資料
契約・委託管理	DNS運用委託、責任分界、SLA、報告様式整理

行政書士業務の範囲を踏まえ、個別紛争対応や訴訟代理など弁護士領域に属する事項は切り分けたうえで、企業がクラウドを安全に利用するための規程整備、契約関連資料、監査説明資料、運用ルール整備を支援します。

まとめ

Azure DNS Private Resolverは、ハイブリッドDNSを整理するための重要な基盤です。

しかし、導入するだけでは十分ではありません。重要なのは、次の状態を作ることです。

必要な状態	内容
名前空間が整理されている	どのドメインを誰が管理するか明確
DNS経路が見える	オンプレ→Azure、Azure→オンプレ、Azure内を図示
条件付きフォワードが台帳化されている	転送元、転送先、理由、承認者を記録
Private DNS Zoneが重複していない	Private Endpointの名前解決事故を防止
変更管理がある	DNS変更の影響範囲・切戻し・承認を記録
監視がある	QPS、DNSQueryLogs、Activity Logを確認
責任分界がある	オンプレ、Azure、アプリ、セキュリティ、監査を分離

DNSは、地味ですが、クラウド運用の根幹です。

Azure DNS Private Resolver、Private Endpoint DNS、オンプレDNS条件付きフォワード、DNS責任分界、運用手順・監査資料の整備は、山崎行政書士事務所へご相談ください。

出典・確認日

確認日：2026年7月8日

出典	確認した主な内容	最終更新・公開日
Microsoft Learn：Azure DNS Private Resolver概要	受信エンドポイント、送信エンドポイント、DNS転送ルールセット、VM DNS設定変更不要	2026年6月22日
Microsoft Learn：Azure DNS Private Resolver endpoints and rulesets	Ruleset、VNet Link、1000ルール、500 VNetリンク、Hub-Spoke例	2025年3月21日
Microsoft Learn：Azureサービス制限	DNS Private Resolverの上限、QPS、VNetあたりResolver数	2026年3月6日
Microsoft Learn：Resolve Azure and on-premises domains	ハイブリッドDNS、VPN/ExpressRoute、オンプレDNS条件付きフォワード	2024年4月5日
Microsoft Learn：Azure Private Endpoint DNS Integration Scenarios	Private Endpoint DNSシナリオ、条件付きフォワード、単一Private DNS Zone注意	2025年9月30日
Microsoft Learn：Azure Private Endpoint private DNS zone values	Private Endpoint DNS、Private DNS Zone、推奨ゾーン名、DNSとアクセス制御の独立性	2026年5月5日
Microsoft Learn：Azure DNS monitoring data reference	DNS Resolver QPS、DNSQueryLogs、監視メトリック	2025年1月30日
Microsoft Learn：DNS Security Policy	VNetレベルのDNSフィルタリング、ログ、Allow/Alert/Block	2025年11月18日
Microsoft Learn：DNSQueryLogs	DNSQueryLogs列、SourceIpAddress、QueryName、ResponseCode等	2026年3月11日
NIST SP 800-81 Rev.3	DNSの安全な展開、DNSをゼロトラスト・多層防御の一部として扱う考え方	2026年3月