DNS統合戦略: オンプレミスとAzure間の名前解決をシームレスにする方法

Azure

Last updated at 2025-08-28Posted at 2025-08-28

本記事では、オンプレミスのWindows DNS (Active Directory統合型) を中心に運用してきた企業が、クラウドファーストへの移行に伴い Azure Private DNS を採用し、ハイブリッド全体で統合的・シームレスな名前解決を行うための高度な戦略を解説します。

さらに、オンプレ側AD DSからEntra ID Domain Services (従来のAzure AD DS) への移行を視野に入れた際のDNS連携も取り上げ、細部の設計ポイントと高可用性・移行手順を詳述します。

1. オンプレDNSとAzure Private DNSの統合背景とメリット

1.1 ハイブリッド・クラウドにおけるDNSの重要性
企業がオンプレミス（ADドメイン）とAzureを併用（ハイブリッド）する中で、名前解決はアプリケーション間通信やセキュリティの基盤となります。

従来、オンプレMS DNSが持つ「社内ドメイン名（corp.local など）」や「ドメイン参加のためのSRVレコード」などはオンプレだけで完結していましたが

・Azure上のVMやPaaSリソースからオンプレドメイン名を解決して通信したい

・逆にオンプレからAzure Private Endpointなどの内部FQDNを引いて接続したい

・DNS運用そのものをAzure側に集約し、オンプレDNSを最終的に廃止・縮小して管理負荷を減らしたい

といった要望が高まります。

これら要件を満たすために、Azure Private DNSゾーンを用いたプライベート空間の名前解決をオンプレDNSと連携させ、ひとつの統合されたDNS基盤を構築する必要があります。

1.2 Azure Private DNSゾーンとは
Azure Private DNS は、Azure内のプライベート空間（RFC1918アドレスなど）の名前解決を実現するPaaS型サービスです。

単に「プライベートDNSを自前で構築する」だけでなく、以下の強みがあります。

ゾーンと仮想ネットワーク(VNet)のリンクによるシームレスな可視化: リンクしたVNet内リソースからは自動的にPrivate DNSゾーンを参照できる。

オートレジストレーション（一部制限あり）: VMの起動停止で動的にAレコードを登録/削除できる（プレビュー）。

エンドポイントのプライベートアクセス（パブリックSaaSにもプライベートIPで接続）: Azure Private Linkの仕組みと組み合わせたとき、privatelink.*などのゾーンをホストし、オンプレからも透過的にプライベート接続が利用できる。

管理の単純化: 物理DNSサーバーのパッチ適用やスケール対応が不要（完全マネージド）。

ハイブリッド統合で問題となるのは「オンプレからAzure Private DNSを直接問い合わせできない」点です。

Azure内部でのみ応答する仕組みのため、オンプレDNSサーバーが168.63.129.16に問い合わせても疎通がない。

よってフォワーダーやDNSプロキシ、もしくはAzure DNS Private Resolverが必要になります。

2. ハイブリッドDNSを実現する3つのアプローチ

2.1 DNSプロキシVM方式（従来型）
最も一般的な構成。Azure内にWindowsやBIND等のDNSサーバーVMを置き、オンプレDNSからの問い合わせを条件付きフォワードでそのVMに送る。

そのVMは再帰的に168.63.129.16(Azure内部DNS)に問い合わせてPrivate DNSゾーンを解決。

逆にAzure側からオンプレのcorp.localなどを解決する際は、VMがオンプレDNSへフォワードする形。

メリット: 実装がシンプル。

既存Windows DNSの延長で設定可能。

デメリット: VMの管理負荷、可用性確保（2台以上・可用性ゾーン配慮）など運用コストが発生。高負荷や大量クエリ時にスケールが課題になる。

2.2 Azure DNS Private Resolver方式（最新）
2022年以降に登場したサービスで、DNSプロキシVMを不要にし、マネージドでDNSフォワードを実現。

InboundエンドポイントとOutboundエンドポイントを作成し、オンプレ→Azure、Azure→オンプレの条件付きフォワードをルールセットで定義する。高可用性が標準装備され、ゾーン冗長展開も容易。

メリット: VM管理不要、スケール/HAはAzureが提供。運用効率良し。

デメリット: 新機能のため一部制約やサポート範囲に注意（Azure AD DS連携など）。
かつマネージド費用が発生する。

2.3 Entra ID Domain Services (従来Azure AD DS) DNSを利用
Entra ID Domain Services(Entra ID DS)はクラウド上のADドメイン機能で、DNSも含まれている。

ここでDNSを運用し、オンプレDNSと相互フォワードを設定する手もある【52†L49-L57】。

ただしAD DS DNSは制限が多く、ルートフォワード不可などで設計が複雑になる。従って専用DNSプロキシ or Private Resolver方式のほうが柔軟。

3. カスタムDNSとAzure VNet連携の詳説

3.1 VNet DNS設定
デフォルト(168.63.129.16): Azureに任せる簡易パターン。

ただしPrivate DNSゾーンはVNetリンクが必要で、オンプレ連携はDNSプロキシ/Resolver必須。

カスタムDNS: VNetのDNSをオンプレDNS or Azure DNSプロキシに設定。これによりVMはそのDNSを直接参照。

メリット: Azure提供DNSに頼らないため複雑なフォワーダー連携が不要。

デメリット: Azure固有の内部名が自動解決不可。VM名を短縮形で呼ぶにはサフィックス追加設定が必要。

3.2 NICレベル vs VNetレベル
VNetレベルでDNSを設定すると、そのVNet内の全NICが初期値としてそれを参照。

個別NICでオーバーライド可能だが、運用は一貫性を保つためVNetレベル設定が基本。

3.3 NSGバイパスとDNSトラフィック
DNS(UDP/TCP/53)は一部特例があり、VNet外への通信でもNSGルールをバイパスする場合がある。

セキュリティ要件でDNS問い合わせを制限したい場合、DNSプロキシVM内で制御するか、Azure DNS Private ResolverにACLルールを適用する構成を考慮。

4. 条件付きフォワーダーの詳細設計

4.1 オンプレDNS→Azure DNSフォワード
ゾーン名: privatelink.*, *.internal.cloudapp.net など、Azureで管理するプライベートゾーンを列挙。

フォワード先: Azure DNSプロキシ or Azure DNS Private ResolverのInbound Endpoint IP。

タイムアウト: Windows DNSではデフォルト3秒→5秒以上に引き上げ。

4.2 Azure DNSプロキシ→オンプレDNS
Azure DNSプロキシ(Windows Server/BIND)でオンプレドメイン(corp.local)を条件付きフォワードし、転送先をオンプレDNSに。

Azure VMがcorp.localを引く際はプロキシを経由しオンプレDNSへ問い合わせ。

自ドメイン/ゾーン以外は既定フォワードでAzure Private DNS(168.63.129.16)に問い合わせる設定を行い、プライベートゾーンを解決。

4.3 フォワードのループ防止
オンプレDNSがAzure DNSプロキシへ、プロキシがさらにオンプレDNSに転送するゾーンが一致しているとループに陥る。

条件付きフォワーダーは極力限定的なゾーン名ごとに設定する（例: privatednszone.contoso.local はAzureへ、corp.local はオンプレへ、その他は外部DNSへ）とし、重複がないよう注意する。

5. DNS移行の手順：オンプレ→Azure Private DNS

5.1 エクスポートとインポート
オンプレDNSゾーンエクスポート: dnscmd /ZoneExport でBINDファイル取得 or セカンダリゾーン転送でゾーンファイルを作成。

Azure上でゾーン作成: az network private-dns zone create -g RG -n contoso.local などで空ゾーンを作る。

ファイルインポート: az network private-dns zone import -g RG -n contoso.local -f .\contoso.dns でレコード一括登録。NS/SOAはAzure既定、A/CNAME等はファイルから読み込む。

5.2 移行後の調整
検証: Azure VM or DNSプロキシで nslookup hostname.contoso.local し、期待どおりのAレコードが返るか確認。

TTL設定修正: 移行でTTLがデフォルト化されている場合がある。必要に応じて変更。

自動レコード登録要否: Azure Private DNSでオートレジストレーションを使うか判断。

複数VNetで同ゾーンを共有する場合は制約がある。

サフィックス設定: 短いホスト名でアクセスする場合、OSやDHCPスコープで DNSサフィックス( contoso.local )を付与するよう構成。

5.3 段階切替
並行稼働: 一定期間、オンプレDNSとAzure Private DNSで二重管理。オンプレ側ゾーンは「凍結（編集禁止）」し、新規や変更はAzureにのみ登録して整合性を保つ。

クライアント切替: DHCPや端末NIC設定でDNSサーバーをAzure側に変更（カスタムDNS=DNSプロキシIPなど）。

フォワーダー逆向き設定: OnPrem DNSはAzureゾーンへフォワード、Azure DNSはOnPremのドメインへフォワード。これで双方向に名前解決できる。

オンプレDNS無効化: 問題なければ最終的に停止/除却。ADコントローラーがDNSを兼ねている場合、SRVレコードや_msdcsなどのドメイン管理に影響しないか要確認。

6. 遅延やキャッシュ不整合への対処

6.1 再帰DNSの応答遅延
カスタムDNSフォワーダーがAzure DNSへ問い合わせる際、処理に数秒かかることがあります。

Windows DNSではフォワードタイムアウト3秒が短く、一度タイムアウトしたら外部DNSへフォールバックし誤った応答を得るケースも。

5秒～10秒程度に伸ばし、Azure DNS応答を待つように調整。

6.2 TTLとキャッシュ戦略
移行フェーズ: TTL短め(5~15分)で変更反映を早める。

平常運用: 1~4時間程度に設定し、クエリ数削減とレスポンス向上を両立。

キャッシュクリア: 切替時にClear-DnsServerCacheやクライアントipconfig /flushdnsで古い情報を強制クリア。

6.3 往復フォワードループ防止
同じゾーンがオンプレとAzure両方に存在していると、相互フォワードがループになる可能性あり。明確に権威はどちらかを決め、もう一方では条件付きフォワーダーを最小限の範囲にする。

あるいはゾーン名を変える（corp.local vs a.corp.local）等も検討。

7. Entra ID Domain Services とのDNS連携

7.1 Entra ID DS のDNS特性
Entra ID Domain Services（従来Azure AD DS）はクラウド上にマネージドなドメインコントローラを提供し、同期ユーザーがドメイン参加できる仕組みです。

ここではDNSサービスも提供され、内部ドメイン名（例: mydomain.onmicrosoft.com や mycorp.cloudapp.azure.com）の権威サーバーとなります。

ルートフォワーディング不可等、制約が多い

1つずつ条件付きフォワーダーを設定し、オンプレ/Private DNSゾーンを解決させる必要がある

EntraID DS管理者(EntraID DC Administratorsロール)でドメイン参加マシンにログインし、DNS管理ツールを使用

7.2 ドメイン参加VMとPrivate DNSの関係
ドメイン参加VMはDHCP/ NIC設定でEntra ID DSのDNSを参照するため、Private DNSゾーン解決にはAD DS DNSがフォワードする設定が必要。

msdcsやドメインSRVレコードはEntra ID DS内に存在するが、プライベートエンドポイント等はAzure側のゾーンにあるため、フォワーダーをAzure DNSプロキシへ転送する仕組みが必要となる。

7.3 オンプレ統合
さらにオンプレとのハイブリッドシナリオでは、オンプレDNS→Entra ID DS DNS or Azure DNSフォワーダーへの繋ぎと、Entra ID DS DNS→オンプレDNSという双方向の設定が発生。

設計が複雑化しがちなので、Entra ID DSでDNSを主体運用するか、通常のWindows DNSをAzure上に立てるか、あるいはPrivate Resolverを使うかをよく検討する必要があります。

制約事項をよく踏まえ、オンプレドメインとEntra ID DSの名前空間が競合しないように設計するのが肝要です。

8. 高可用性とDNS運用の最終形

8.1 DNSプロキシ/Resolverの冗長化
可用性ゾーンに2台以上のDNS VMを配置し、VNet DNS設定に2つのIPを指定。

Azure DNS Private Resolverの場合は、インバウンド/アウトバウンドエンドポイントが複数AZに展開され冗長化。

DNSクエリ数が多い場合、スケールアウトしてロードバランサ（UDP/TCP）で振り分ける手法もあるが、DNSプロトコルでのセッション管理が複雑になるため注意。

8.2 運用監視とガバナンス
Azure Monitor: DNSゾーンへのクエリ数、エラー数をメトリクスやログから取得し、異常値をアラート。

ゾーンの変更監査: どのユーザーがいつレコードを変更したか。RBACとアクティビティログを活用。

Productionゾーンへの編集はPull Request/CIパイプラインで行うなどInfra as Codeアプローチも有効。

マルチサブスクリプション: Private DNSゾーンを1つのサブスクリプションでホストし、VNetリンクを他サブスクリプションのVNetにも設定。

ゾーン運用権限を管理グループ/リソースグループレベルで割り当てる。

DR演習: DNS切替シナリオやフォワーダーVM障害時の代替パスなどを定期的にテスト。

8.3 オンプレDNS完全廃止と移行完了
最終的にオンプレDNSを停止しても、ADドメインコントローラーはAzureに移行（またはEntra ID DS）され、全クライアントがAzure DNSを参照する仕組みが整えば「クラウド中心DNS」として運用可能になります。

Public DNSへの外向けゾーン（企業Webサイトなど）もAzure DNS (Public)へ移行する選択肢があり、一連のオンプレDNSインフラを刷新できます。

もちろん、大企業ではフェーズ的に部分移行して数カ月かけて最終停止するケースも多いでしょう。

まとめ

オフィスやデータセンター中心だったWindows DNSを、Azure Private DNSを基盤にしたハイブリッドDNSへ移行・連携することで、オンプレ環境とクラウド環境全体の名前解決を統合できます。

そのための具体的要点は:

条件付きフォワーダーでオンプレDNSからAzure DNSプロキシへ、Azure DNSプロキシからオンプレDNSへ問い合わせが双方向に流れる設計

DNSプロキシ or Azure DNS Private Resolverを使い、オンプレからの問い合わせをAzureの内部DNSに再帰転送できる経路を確保

ゾーンファイルインポートやPowerShell/BINDスクリプトで、既存レコードをAzure Private DNSに移行

TTL短縮やキャッシュコントロールで移行時のダウンを回避

高可用性: VMの場合は可用性ゾーン冗長 or DNS Private ResolverによるマネージドHA

Entra ID Domain Services利用時は制約が多く、条件付きフォワーダーを細かく設定。Azure AD DS DNSだけですべて統合するのは困難

段階的にオンプレDNSを縮小し、Azure側で完結する名前解決へ移行

クラウドファースト化が進むにつれ、オンプレDNSの維持管理負荷を削減しつつ、プライベートリンクやドメイン参加などを容易にする強固でスケーラブルなDNSをAzure上で整備することは大きなメリットをもたらします。

本記事の内容を踏まえ、適切な設計と計画的な移行により、ハイブリッドDNSをスムーズに一元化していくことを目指してください。

参照リンク集

公式ドキュメント（基礎）

Azure Private DNS（ゾーン/レコード/リンク/自動登録）

Private Endpoint / Private Link の DNS

Azure DNS Private Resolver（オンプレとの双方向解決）

VNet/NIC と DNS サーバー設定（補足）

仮想ネットワークの DNS サーバー設定・設計上の考慮点（再掲）

オンプレ Windows DNS（条件付きフォワーダー/タイムアウト）

（PowerShell）Add-DnsServerConditionalForwarderZone
（PowerShell）Set-DnsServerConditionalForwarderZone
フォワーダーの解決タイムアウトの考え方（ForwardingTimeout/RecursionTimeout）
参考：オンプレ→Azure への DNS 転送（Azure Files の例）

移行/IaC・CLI・PowerShell

（CLI）プライベート DNS ゾーンのインポート（BIND形式）
（PowerShell）Az.PrivateDns モジュール（ゾーン/レコード/リンク作成）

運用監視・RBAC

Azure Firewall を DNS プロキシとして使う場合（代替案）

FAQ/補足

Azure プライベート DNS に関する FAQ（制限/設計TIPS）

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up