先生と生徒の会話形式で理解しよう

生徒

「Azure（アジュール）で複数の仮想ネットワーク（VNet）を使っているのですが、お互いのサーバーの名前解決（DNS）がうまくいかなくて困っています。」

先生

「それはクラウド構築でよくある悩みですね。以前は自前でDNSサーバーを立てる必要がありましたが、今はAzure DNS Private Resolver（アジュール・ディーエヌエス・プライベート・リゾルバー）という便利なサービスがあるんですよ。」

生徒

「リゾルバー...？難しそうな名前ですね。初心者でも設定できる構成パターンはありますか？」

先生

「もちろんです！今回は、複数のVNetやオンプレミス環境をつなぐ名前解決の仕組みを、図解を交えて分かりやすく解説しますね。」

1. Azure DNS Private Resolverとは？

Azure DNS Private Resolver（アジュール・ディーエヌエス・プライベート・リゾルバー）とは、Azure上の仮想ネットワーク（Virtual Network、略してVNet：ブイネット）内でのドメイン名とIPアドレスの紐付けを管理する、マネージド型のサービスです。簡単に言うと、インターネット上の住所録のような役割を、自分たちだけの閉じたネットワークの中で提供してくれる仕組みです。

これまでは、Azure内と会社にある物理サーバー（オンプレミス）の間で名前解決をしたい場合、自分たちでWindows ServerやLinuxを使ってDNSサーバーを構築・管理しなければなりませんでした。しかし、このリゾルバーを使えば、インフラの運用負荷を大幅に減らすことができます。高い可用性（サービスが止まりにくいこと）を維持しながら、安全に通信相手を特定できるのが最大の特徴です。

2. なぜ複数のVNetで名前解決が必要なのか

クラウド環境を運用していくと、セキュリティや部署ごとの管理の都合上、ネットワークを分割することがよくあります。例えば、本番環境用VNet、開発環境用VNet、共有サービス用VNetといった具合です。しかし、ネットワークを分けると、標準の状態では「隣のVNetにいるサーバーの名前」が分からなくなってしまいます。

例えば、web-server.internalという名前でアクセスしようとしても、ネットワークが分かれているとIPアドレスが解決できず、エラーになります。これを解決するために、複数のVNetをまたいで情報を共有する仕組みが必要になります。Azure DNS Private Resolverは、こうした「ハブ・アンド・スポーク」構成と呼ばれる大規模なネットワーク設計において、中心的な役割（ハブ）として機能します。

3. 構成の基本！インバウンドとアウトバウンド

このサービスを理解する上で重要なのが、「インバウンド・エンドポイント」と「アウトバウンド・エンドポイント」という二つの窓口です。

インバウンド・エンドポイントは、外部（オンプレミスや他のVNet）からの問い合わせを受け取るための窓口です。ここに問い合わせを送ることで、Azure内のPrivate DNS Zone（プライベート・ディーエヌエス・ゾーン）に登録された情報を教えてもらえます。一方、アウトバウンド・エンドポイントは、Azure内から外部のDNSサーバーへ問い合わせを転送するための出口です。この二つの窓口を組み合わせることで、双方向の通信がスムーズになります。

ここでは、設定情報のサンプルをJSON形式で見てみましょう。どのようなパラメータが必要になるかのイメージを掴んでください。


{
    "location": "japaneast",
    "properties": {
        "inboundEndpoints": [
            {
                "name": "myInboundEndpoint",
                "ipConfigurations": [
                    {
                        "privateIpAddress": "10.0.0.4",
                        "subnetId": "/subscriptions/.../subnets/snet-inbound"
                    }
                ]
            }
        ]
    }
}

4. 複数VNet間をまたぐ名前解決のパターン

最も一般的な構成パターンは、中央のハブ（Hub）となるVNetにPrivate Resolverを配置し、周囲のスポーク（Spoke）となるVNetからそれを利用する形です。スポークVNet側で「DNSフォワーディング・ルールセット」を設定することで、特定のドメイン名に対する問い合わせをハブにあるリゾルバーへ自動的に転送するようにします。

この構成のメリットは、管理が一箇所に集約される点です。新しいVNetが増えたとしても、中央のルールセットに設定を追加するだけで、全ての環境で一貫した名前解決が可能になります。これは、大規模な企業システムを構築する際に非常に強力な武器となります。

5. オンプレミスとの連携を実現する方法

Azureと社内ネットワークをVPNやExpressRoute（エクスプレスルート）で接続している場合、オンプレミスのパソコンからAzure上のサーバーを名前で呼びたいことがあります。この場合、オンプレミス側のDNSサーバーの転送設定（フォワーダー）として、Azure DNS Private Resolverのインバウンド・エンドポイントのIPアドレスを指定します。

逆に、Azureから社内のドメイン名（例：corp.local）を解決したい場合は、アウトバウンド・エンドポイントと「転送ルール」を使用します。これにより、クラウドと物理環境がシームレスにつながるハイブリッド・クラウド環境が完成します。

以下は、Linuxサーバーから名前解決のテストを行う際のコマンド例です。


nslookup web-server.azure.internal 10.0.0.4
Server:		10.0.0.4
Address:	10.0.0.4#53

Non-authoritative answer:
Name:	web-server.azure.internal
Address: 10.0.1.5

6. 具体的な設定値の管理例

実際に運用する際は、どのドメインをどのサーバーに飛ばすかというリストを管理することになります。データベースのテーブルに見立てて、管理情報のイメージを確認してみましょう。


id | domain_name            | target_dns_ip | description
---+------------------------+---------------+---------------------
1  | contoso.com            | 10.0.0.4      | Azure Inbound
2  | factory.local          | 192.168.1.10  | On-premise DNS
3  | research.internal      | 10.1.0.4      | Dev VNet Resolver
4  | privatelink.database   | 10.0.0.4      | Private Link DNS

このような対応表（フォワーディング・ルール）をリゾルバーに登録していくことで、複雑なネットワーク内でも迷子にならずに通信ができるようになります。SQLを使ってこれらの設定変更履歴を管理するようなシステムを作る場合、以下のようなクエリが考えられます。


SELECT id, domain_name, target_dns_ip
FROM dns_rules
WHERE description LIKE '%Azure%'
ORDER BY id ASC;


id | domain_name            | target_dns_ip
---+------------------------+---------------
1  | contoso.com            | 10.0.0.4
4  | privatelink.database   | 10.0.0.4

7. 導入時に注意すべきポイントと制限事項

非常に便利なサービスですが、いくつか注意点があります。まず、リゾルバー専用のサブネット（小分けにされたネットワーク範囲）を用意する必要があります。このサブネットには他のリソース（仮想マシンなど）を置くことはできません。また、サブネットのサイズは最小でも /28（アドレスが16個分）必要ですが、将来的な拡張を考えると /24 程度を確保しておくのが安心です。

また、料金面についても確認しておきましょう。エンドポイントの維持費と、処理されたクエリ（問い合わせ）の数に応じて課金される仕組みになっています。小規模な環境であれば安価ですが、大規模なトラフィックが発生する場合は、事前にコスト試算を行うことが推奨されます。特にインバウンド・エンドポイントを複数のVNetで共有することで、コストを最適化することが可能です。

8. 疎通確認とトラブルシューティングの手順

設定が終わったら、正しく名前解決ができるか確認しましょう。Windowsであれば PowerShell（パワーシェル）を使って、Resolve-DnsName コマンドを実行するのが一般的です。もし名前が解決できない場合は、ネットワーク・セキュリティ・グループ（NSG）の設定で、DNS通信（ポート番号53番）が許可されているかを確認してください。


# 指定したリゾルバーのIPを使って名前解決を試す
Resolve-DnsName -Name "my-app.privatelink.blob.core.windows.net" -Server "10.0.0.4"

実行結果のイメージは以下のようになります。


Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
my-app.privatelink.blob.core.windows.net       A      60    Answer     10.0.1.10

このように、期待したプライベートIPアドレスが返ってくれば、複数VNet間やオンプレミスとの連携設定は成功です。エラーが出る場合は、仮想ネットワーク・リンクの設定が漏れていないか、あるいは転送ルールの優先順位が間違っていないかを見直してみましょう。

9. プライベートリンクとの相性が抜群な理由

Azureには、PaaS（パース：プラットフォーム・アズ・ア・サービス）と呼ばれるデータベースなどの機能を、インターネットに出さずにプライベートなネットワーク内で利用できる「Azure Private Link（アジュール・プライベート・リンク）」という機能があります。この機能を使う際、自動的に複雑なドメイン名が割り振られますが、これを正しく解決するためにも Private Resolver は非常に役立ちます。

特に複数のサブスクリプションにまたがって Private Link を利用する場合、標準のDNS設定だけでは限界が来ることがあります。一元管理されたリゾルバーを通すことで、どの部署のどのVNetからでも、安全かつ確実にデータベースなどのサービスにアクセスできるようになります。これが、現代のAzure設計において、Private Resolverが「必須級」のサービスと言われる理由の一つです。

まとめ

この記事では、Azureにおけるネットワーク構築の要となるAzure DNS Private Resolver（アジュール・ディーエヌエス・プライベート・リゾルバー）の基礎知識から、具体的な構成パターン、運用時の注意点までを詳しく解説してきました。クラウドネイティブな環境において、複数の仮想ネットワーク（VNet）やオンプレミス環境が混在するハイブリッド構成は、もはや標準的な設計となっています。その中で、いかにして「名前解決」という通信の根幹部分を安定させ、管理を簡素化するかが、システム全体の信頼性に直結します。

名前解決の重要性とリゾルバーの役割

従来のシステム構築では、名前解決のために自前で仮想マシン（VM）を立ち上げ、DNSサーバーとしての役割を持たせていました。しかし、この手法ではサーバーの保守、パッチ適用、高可用性の確保といった運用負荷が大きな課題となっていました。Azure DNS Private Resolverは、これらをマイクロソフトが管理するマネージドサービスとして提供することで、管理者がインフラの面倒を見ることなく、安全な名前解決環境を手に入れられるようにした画期的なソリューションです。

主要なコンポーネントの再確認

構成を考える上で、以下の要素を正しく理解しておくことが重要です。

インバウンド・エンドポイント： 外部からAzure内の情報を参照するための入り口。
アウトバウンド・エンドポイント： Azure内から外部（オンプレミス等）へ問い合わせを投げるための出口。
DNSフォワーディング・ルールセット： どのドメインをどのサーバーに転送するかを決める「交通整理」の役割。

実践的な管理シナリオ

例えば、社内のシステム構成情報をデータベースで管理し、動的にDNSの転送ルールを把握したい場合を想定してみましょう。以下のような管理テーブルをイメージすると、どの環境へ通信が流れるのかが明確になります。


id | system_name  | target_domain          | forwarding_ip | location
---+--------------+------------------------+---------------+-----------
1  | Core-Hub     | internal.example.com   | 10.0.0.4      | Japan East
2  | On-Prem-GW   | corp.local             | 192.168.1.1   | Tokyo HQ
3  | Storage-PL   | privatelink.blob.core  | 10.0.0.4      | Japan East
4  | Dev-Spoke    | dev.internal           | 10.1.0.5      | Japan West
5  | Auth-Service | auth.global            | 172.16.0.10   | US East

上記のデータから、特定のリージョン（例：Japan East）に関連する転送設定のみを抽出して確認するSQLクエリの例は以下の通りです。


SELECT system_name, target_domain, forwarding_ip
FROM network_configs
WHERE location = 'Japan East'
AND target_domain LIKE '%internal%'
ORDER BY id DESC;


system_name | target_domain        | forwarding_ip
------------+----------------------+---------------
Core-Hub    | internal.example.com | 10.0.0.4

C#による自動化のヒント

運用の現場では、Azure SDKを利用してプログラムからこれらの設定を確認したり、異常がないかチェックしたりすることもあります。C#でエンドポイントの状態をシミュレートする簡単なロジックを見てみましょう。


public class DnsResolverManager
{
    public void CheckEndpointStatus(string endpointName, string ipAddress)
    {
        if (string.IsNullOrEmpty(ipAddress))
        {
            Console.WriteLine(endpointName + " のIPアドレスが未設定です。");
        }
        else
        {
            Console.WriteLine(string.Format("エンドポイント: {0} (IP: {1}) は正常に構成されています。", endpointName, ipAddress));
        }
    }
}

このプログラムを実行すると、管理コンソール等で以下のようなログが出力されるイメージになります。


エンドポイント: myInboundEndpoint (IP: 10.0.0.4) は正常に構成されています。

導入を成功させるための秘訣

最後に、導入時に陥りやすい「サブネットの設計ミス」には十分に注意してください。専用サブネットが必要であるため、既存のネットワーク設計に組み込む際は、あらかじめ余裕を持ったIPアドレス空間を切り出しておくことが推奨されます。また、NSG（ネットワークセキュリティグループ）でポート53（UDP/TCP）を適切に許可することも忘れないでください。

Azure DNS Private Resolverをマスターすることで、複雑なハイブリッドクラウドの世界でも、迷うことなくスムーズな通信経路を構築できるようになります。この記事が、皆さんのクラウドインフラ構築の一助となれば幸いです。

先生と生徒の振り返り会話

生徒

「先生、ありがとうございました！Azure DNS Private Resolverのおかげで、あんなに苦労していたVNet間の名前解決がスッキリ整理できそうです。特にハブ・アンド・スポーク構成での一括管理は、運用がすごく楽になりそうですね。」

先生

「その通りです。自分でDNSサーバーのパッチを当てたり、冗長化を考えたりしなくていいのは、マネージドサービスならではの強みですね。インバウンドとアウトバウンドの違いは整理できましたか？」

生徒

「はい！外から見つけてもらうためのインバウンドと、外に聞きに行くためのアウトバウンドですね。オンプレミスとの連携も、この窓口を意識すればスムーズに設定できそうです。」

先生

「素晴らしい理解度です！あとは、実際に手を動かしてnslookupやResolve-DnsNameで疎通確認をしてみてください。万が一繋がらないときは、まずNSGのポート53番が開いているかをチェックするのを忘れずに。」

生徒

「分かりました！専用サブネットの確保も最初に行います。これで、Azure Private Linkを使ったセキュアなシステム作りにも自信が持てました！」