Azure DNSとオンプレミスDNSの統合ガイド！条件付きフォワーダーで名前解決を実現

Azure DNSとオンプレミスDNSの統合｜条件付きフォワーダーによる相互解決

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

生徒

「会社のネットワークをAzure（アジュール）に接続したのですが、クラウド上のサーバーの名前が自分のパソコンから解決できなくて困っています。」

先生

「それはハイブリッドクラウド環境でよくある課題ですね。Azure DNS（アジュールディーエヌエス）とオンプレミスにある既存のDNSサーバーを連携させる必要があります。」

生徒

「連携させるにはどうすればいいんですか？条件付きフォワーダーという言葉を聞いたのですが...。」

先生

「正解です！Azureプライベートリゾルバーと条件付きフォワーダーを組み合わせることで、お互いのドメイン名をスムーズに引き当てることができるようになります。その仕組みを詳しく解説しましょう！」

1. Azure DNSとオンプレミスDNS統合の基礎知識

Azure（アジュール）などのクラウドサービスを利用し始めると、社内（オンプレミス）のネットワークとクラウドのネットワークを繋ぐ「ハイブリッドクラウド」構成をとることが一般的です。しかし、ただネットワークを繋いだだけでは、社内のパソコンからクラウド上のサーバーの名前（FQDN：エフキューディーエヌ）でアクセスすることができません。これを解決するのがDNS統合（ディーエヌエスとうごう）です。

通常、社内にはActive Directory（アクティブディレクトリ）に紐付いたDNSサーバーがあり、Azure内にはAzure DNSが存在します。これらは管理されている場所が異なるため、そのままではお互いの情報を知り得ません。そこで、「このドメイン名宛ての問い合わせは、あちらのサーバーに聞いてね」という転送設定が必要になります。これが条件付きフォワーダー（じょうけんつきフォワーダー）の役割です。

2. 条件付きフォワーダーとは？仕組みとメリット

条件付きフォワーダーとは、特定のドメイン名（例えば sample.com など）に対するDNSクエリを受け取った際に、あらかじめ指定しておいた特定のDNSサーバーへその問い合わせを転送する機能のことです。通常のフォワーダーは「知らない名前はすべて外（インターネットなど）に聞く」という動作をしますが、条件付きフォワーダーは「特定のドメイン名だけ」を狙って転送します。

この仕組みを利用することで、インターネットに情報を公開することなく、安全に社内とAzure間の名前解決が可能になります。VPN（ブイピーエヌ）やExpressRoute（エクスプレスルート）といった専用線を経由して通信を行うため、セキュリティレベルを高く保ったまま運用できるのが大きなメリットです。

3. Azureプライベートリゾルバーの導入

以前のAzureでは、独自の仮想マシンを立ててDNSプロキシを作る必要がありましたが、現在はAzure DNS Private Resolver（アジュールディーエヌエスプライベートリゾルバー）というフルマネージドサービスが提供されています。これを使うことで、サーバーの運用管理の手間を省きつつ、オンプレミスとの連携が容易になります。

プライベートリゾルバーには、外部からの問い合わせを受け付ける「受信エンドポイント」と、外部へ問い合わせを投げる「送信エンドポイント」の2種類があります。オンプレミスからAzureの名前を引きたい場合は、受信エンドポイントのIPアドレスをオンプレミス側の条件付きフォワーダーに設定します。


# Azure CLIを使用してプライベートリゾルバーの情報を確認する例
az network dns-resolver show --name MyResolver --resource-group MyRG
{
  "id": "/subscriptions/.../dnsResolvers/MyResolver",
  "location": "japaneast",
  "provisioningState": "Succeeded",
  "resourceGroup": "MyRG"
}

4. オンプレミス側での条件付きフォワーダー設定手順

Windows Server（ウィンドウズサーバー）のDNSマネージャーを使用して設定する場合の手順を解説します。まず、管理ツールからDNSを開き、対象のサーバーを選択して「条件付きフォワーダー」を右クリックして新規作成します。ここで、Azure側で利用しているプライベートドメイン名（例：azure.local）と、先ほど確認したAzure受信エンドポイントのIPアドレスを入力します。

この設定により、社内のユーザーが「server01.azure.local」にアクセスしようとした際、社内DNSは「これはAzureのことだ！」と判断し、Azureのプライベートリゾルバーに答えを聞きに行ってくれるようになります。設定が反映されているかは、コマンドプロンプトやPowerShell（パワーシェル）で確認できます。


// C#で名前解決ができるか確認する簡単なテストプログラム
using System;
using System.Net;

class DnsTest
{
    static void Main()
    {
        try
        {
            string hostName = "server01.azure.local";
            IPHostEntry entry = Dns.GetHostEntry(hostName);
            Console.WriteLine($"{hostName} のIPアドレスは: {entry.AddressList[0]}");
        }
        catch (Exception ex)
        {
            Console.WriteLine("名前解決に失敗しました: " + ex.Message);
        }
    }
}


server01.azure.local のIPアドレスは: 10.0.0.5

5. Azureからオンプレミスへの逆方向の解決

相互解決（そうごかいけつ）を実現するためには、Azure側からオンプレミスの名前を引く設定も必要です。これには「転送ルールセット」を使用します。Azureプライベートリゾルバーの送信エンドポイントに対して、オンプレミスのドメイン名（例：corp.internal）と、オンプレミスDNSサーバーのIPアドレスを紐付けたルールを作成します。

このルールを対象のVirtual Network（仮想ネットワーク：VNet）にリンクさせることで、Azure上の仮想マシン（VM）からも社内のファイルサーバーや社内ポータルサイトを名前で探せるようになります。データベースの接続文字列などにIPアドレスを直書きしなくて済むため、構成の柔軟性が向上します。


-- データベース接続時にFQDNを使用するイメージ（SQL Server）
-- 名前解決ができていれば、IPアドレスではなくホスト名で接続可能
SELECT 
    @@SERVERNAME AS 'Server Name',
    CONNECTIONPROPERTY('net_transport') AS 'Protocol';


Server Name         | Protocol
--------------------+----------
DB-SERVER.corp.internal | TCP

6. 構築時の注意点とトラブルシューティング

設定したのに名前が解決できない場合、いくつかのポイントをチェックする必要があります。まず第一に、Azureの「受信エンドポイント」が配置されているサブネット（Subnet）に対して、ネットワークセキュリティグループ（NSG）でUDP/TCPの53番ポートが許可されているか確認しましょう。DNS通信は基本的に53番ポートを使用します。

次に、オンプレミスとAzureを繋ぐVPNやExpressRouteのルーティングが正しく通っているかを確認します。pingコマンド（ピンコマンド）などでIPアドレスへの疎通が取れない場合は、DNSの設定以前にネットワーク経路に問題があります。また、DNSのキャッシュ（一時的な記憶）が残っている場合もあるので、確認の際はキャッシュクリアを試すのも有効です。


# WindowsでDNSキャッシュをクリアするコマンド
ipconfig /flushdns
Successfully flushed the DNS Resolver Cache.

7. セキュリティと可用性の考慮事項

DNS統合においてセキュリティは非常に重要です。条件付きフォワーダーで転送する先は、信頼できる社内サーバーまたはAzureのエンドポイントのみに限定してください。また、可用性（システムが動き続けること）を高めるために、Azureプライベートリゾルバーは複数の可用性ゾーン（Availability Zones）に分散して配置することが推奨されます。

大規模な環境では、DNSクエリのログを監視（モニタリング）することも大切です。Azure Monitor（アジュールモニター）を利用することで、どのサーバーからどの名前に対して問い合わせがあったかを可視化でき、不審な通信の早期発見に繋がります。統合管理されたDNS環境は、インフラエンジニアにとって運用の負担を減らす強力な武器になります。


id | resource_name      | status      | location
---+--------------------+-------------+------------
1  | Resolver-Primary   | Running     | japaneast-1
2  | Resolver-Secondary | Running     | japaneast-2
3  | Inbound-Endpoint   | Provisioned | japaneast-1
4  | Outbound-Endpoint  | Provisioned | japaneast-1

8. まとめとしての運用チェックリスト

最後に、Azure DNSとオンプレミスDNSの統合を成功させるための確認ポイントを整理しましょう。このプロジェクトを進める際は、ネットワーク担当者とサーバー担当者の連携が不可欠です。それぞれの役割が明確になっているか、検証環境でテストを行ったか、切り戻しプラン（設定を元に戻す手順）は用意されているかを確認してください。

IT業界では、このDNSの仕組みを「インターネットの住所録（じゅうしょろく）」と例えることがよくあります。住所録が正しく整理されていないと、どんなに豪華な家（サーバー）を建てても誰もたどり着けません。Azure DNS Private Resolverを賢く活用して、快適なハイブリッドクラウド環境を構築しましょう。一歩ずつ設定を進めれば、初心者の方でも必ず実現できるはずです。

まとめ

ここまで、Azure DNS（アジュールディーエヌエス）とオンプレミス環境のDNSを統合し、ハイブリッドクラウド環境におけるシームレスな名前解決を実現する方法について詳しく解説してきました。この記事を通じて、Azureプライベートリゾルバー（Azure DNS Private Resolver）の重要性や、条件付きフォワーダー（じょうけんつきフォワーダー）が果たす役割について、具体的なイメージが湧いたのではないでしょうか。クラウドとオンプレミスの架け橋となるこの技術は、現代のITインフラ構築において避けては通れない必須の知識と言えます。

ハイブリッドクラウド環境での名前解決の要点

ハイブリッドクラウド環境を構築する際、VPN（ブイピーエヌ）やExpressRoute（エクスプレスルート）によってネットワークの疎通が確保されていても、IPアドレスの直打ちで運用を続けるのは現実的ではありません。サーバーの増設やリプレースのたびに設定変更が必要になり、ヒューマンエラーの原因にもなるからです。そこで、Azure DNSとオンプレミスDNSを「条件付きフォワーダー」で結びつけることにより、ドメイン名（FQDN：エフキューディーエヌ）による安全で柔軟なアクセスが可能になります。

特に、Azureが提供するフルマネージドサービスである「Azureプライベートリゾルバー」の登場は、インフラエンジニアにとって大きな転換点となりました。以前のように、自前でLinux（リナックス）やWindows Server（ウィンドウズサーバー）上にDNSフォワーダー用の仮想マシン（VM）を構築・管理する必要がなくなったため、運用の手間が劇的に削減され、可用性も向上しています。

実装における具体的なステップとプログラムによる検証

実装のプロセスでは、まずAzure側で「受信エンドポイント」と「送信エンドポイント」を正しく構成することが第一歩です。受信エンドポイントはオンプレミスからAzureへの問い合わせを受け取り、送信エンドポイントはAzureからオンプレミスへの問い合わせを転送します。この双方向の設定が完了して初めて、真の統合が実現します。

また、設定が正しいかどうかを判断するためには、実際のアプリケーションコードやデータベース接続のレベルでテストを行うことが推奨されます。例えば、C#（シーシャープ）を用いた名前解決の確認プログラムや、SQL（エスキューエル）を用いたデータベース接続の検証などは、インフラが正しく機能しているかを証明する有力な手段となります。


using System;
using System.Net;
using System.Net.Sockets;

namespace AzureDnsValidator
{
    class Program
    {
        static void Main(string[] args)
        {
            // 接続テストを行いたいオンプレミス側のファイルサーバーFQDN
            string onPremHost = "fileserver.corp.internal";
            
            Console.WriteLine("--- 名前解決テスト開始 ---");
            try
            {
                // DNSルックアップの実行
                IPHostEntry hostEntry = Dns.GetHostEntry(onPremHost);
                
                Console.WriteLine($"ホスト名: {hostEntry.HostName}");
                foreach (var address in hostEntry.AddressList)
                {
                    if (address.AddressFamily == AddressFamily.InterNetwork)
                    {
                        Console.WriteLine($"解決されたIPv4アドレス: {address}");
                    }
                }
                Console.WriteLine("名前解決は正常に完了しました。");
            }
            catch (SocketException ex)
            {
                Console.WriteLine($"エラー: 名前解決に失敗しました。設定を確認してください。");
                Console.WriteLine($"エラーコード: {ex.SocketErrorCode}");
                Console.WriteLine($"メッセージ: {ex.Message}");
            }
            Console.WriteLine("--- テスト終了 ---");
        }
    }
}


--- 名前解決テスト開始 ---
ホスト名: fileserver.corp.internal
解決されたIPv4アドレス: 192.168.100.50
名前解決は正常に完了しました。
--- テスト終了 ---

データベース統合における名前解決の活用

データベース（SQL Serverなど）の運用においても、FQDNによる接続は非常に重要です。以下の例では、Azure上のアプリケーションからオンプレミスにあるデータベースサーバーへ接続し、データを取得する際のイメージを示します。事前に名前解決ができていれば、接続文字列にIPアドレスをハードコーディングすることなく、スマートに管理できます。


id | emp_name   | department | location
---+------------+------------+-----------
1  | 佐藤健一   | 営業部     | 東京本社
2  | 鈴木美咲   | 開発部     | 大阪支店
3  | 高橋浩二   | 総務部     | 名古屋支店
4  | 田中愛子   | 広報部     | 東京本社
5  | 伊藤博     | ITインフラ | クラウド


-- オンプレミスのデータベースサーバーから情報を取得するクエリ例
-- DB-SERVER.corp.internal というFQDNでアクセスしている前提
SELECT 
    id, 
    emp_name, 
    department, 
    location 
FROM 
    OnPremDB.dbo.EmployeeMaster
WHERE 
    location = '東京本社';


id | emp_name   | department | location
---+------------+------------+-----------
1  | 佐藤健一   | 営業部     | 東京本社
4  | 田中愛子   | 広報部     | 東京本社

トラブルシューティングと今後の展望

万が一、名前解決がうまくいかない場合は、基本に立ち返ることが大切です。Linux（リナックス）環境であれば、dig（ディグ）コマンドやnslookup（エヌエスルックアップ）コマンドを駆使して、どの段階で問い合わせが止まっているかを特定しましょう。また、Azureの送信ルールセットが正しいVNet（仮想ネットワーク）にリンクされているか、ルーティングテーブルに不足がないかといった点も重要なチェック項目です。


dig server01.azure.local
; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> server01.azure.local
;; ANSWER SECTION:
server01.azure.local. 3600 IN A 10.0.0.5

ITの世界は日々進化しており、ネットワーク構成の自動化やコードによる管理（IaC：インフラストラクチャアズコード）も一般的になっています。今回学んだDNS統合の仕組みを理解しておくことで、将来的にTerraform（テラフォーム）やBicep（バイセップ）を使って、これらの設定を自動展開する際にも、論理的な裏付けを持って作業に当たることができるようになります。

本記事が、皆様のハイブリッドクラウド構築の一助となれば幸いです。Azure DNS Private Resolverを使いこなし、堅牢で使いやすいネットワークインフラを目指しましょう。

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

生徒

「先生、ありがとうございました！Azureプライベートリゾルバーと条件付きフォワーダーの設定、無事に完了しました。今までIPアドレスで通信していたのが嘘みたいに、ドメイン名でサクサク繋がるようになって感動しています！」

先生

「それは素晴らしいですね！名前で解決できるようになったことで、サーバーの移行やIPアドレスの変更があっても、アプリケーション側の設定を変えずに済むようになりますよ。まさに運用の効率化ですね。」

生徒

「はい！ただ、最初は53番ポートの許可を忘れていて少しハマりました。先生が言っていた通り、ネットワークセキュリティグループ（NSG）の設定は本当に大事ですね。」

先生

「トラブルを経験することで、DNSの通信フローがより深く理解できたはずです。ちなみに、可用性を高めるためにエンドポイントを複数のゾーンに配置する設定も確認しましたか？」

生徒

「もちろんです！ japaneast-1（東日本1）とjapaneast-2（東日本2）の両方に配置して、冗長性を持たせました。これで片方のゾーンに障害が起きても安心です。」

先生

「完璧ですね。次はAzure Monitorを使って、クエリのログを監視する方法も学んでみるといいでしょう。不審なドメインへのアクセスがないかチェックできれば、セキュリティ担当者としても一人前ですよ。」

生徒

「ログの監視ですね！それも面白そうです。どんどんAzureの機能を使いこなせるように頑張ります！」