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

生徒

「Azureの仮想ネットワーク（VNet）内で、サーバー同士が名前で通信できるようにしたいのですが、どうすればいいですか？」

先生

「Azure（アジュール）には、IPアドレスではなくホスト名で通信するための『名前解決（なまえかいけつ）』の仕組みがいくつか用意されていますよ。」

生徒

「Azure DNS（アジュールディーエヌエス）とプライベートDNSゾーンという言葉を聞いたのですが、違いがよくわからなくて……。」

先生

「それは重要なポイントですね！インターネット公開用か、社内ネットワーク専用かという違いがあります。初心者の方向けに詳しく解説しましょう。」

1. Azureにおける名前解決の基本

Azureの仮想（かそう）ネットワークであるVNet（ブイネット）を利用する際、コンピューター同士が通信するためには「IP（アイピー）アドレス」が必要です。しかし、数字の羅列であるIPアドレスを覚えるのは大変です。そこで、人間が理解しやすい「名前」をIPアドレスに変換する仕組みを名前解決と呼びます。

Azureでは、標準で提供される「Azure提供の名前解決」のほかに、自分でドメイン名を管理できる「Azure DNS」や「Azure プライベートDNSゾーン」が選択できます。これらを適切に使い分けることが、クラウド基盤（きばん）を構築する第一歩となります。特にシステム構築（こうちく）の現場では、サーバーの役割に応じて名前を付けることで、管理の効率が劇的に向上します。

2. Azure DNSとは？公共の住所録の役割

Azure DNSは、インターネット上で公開されるドメイン名を管理するためのサービスです。例えば、「example.com」といったドメインを購入し、それを自分のWebサーバーに関連付けたい場合に使用します。これは「パブリックDNS」とも呼ばれ、世界中の誰からでもアクセス可能な名前解決を提供します。

Azure DNSの特徴は、Microsoftのグローバルなネットワークインフラを利用しているため、非常に高速で信頼性が高いことです。高い可用性（かようせい）が保証されており、外部向けのサービスを運用する際には欠かせないツールです。ただし、VNet内部だけで使いたい名前をここに登録してしまうと、全世界にその名前が公開されてしまうため注意が必要です。

3. Azure プライベートDNSゾーンの仕組み

一方、Azure プライベートDNSゾーンは、特定のVNet内や、複数のVNet間だけで有効な名前解決を提供するサービスです。社内システムやデータベースサーバーなど、インターネットには公開したくないけれど、名前で管理したい場合に最適です。

これを利用すると、独自のドメイン名（例：internal.corp）をVNetにリンクさせることができます。仮想マシン（VM）を新しく作成した際に、自動的にその名前を登録してくれる「自動登録機能（じどうとうろくきのう）」もあり、手動でIPアドレスを登録する手間が省けます。セキュリティの観点からも、内部ネットワークの情報を隠しつつ利便性を高めることができるため、エンタープライズ用途で多用されます。

4. Azure DNSとプライベートDNSゾーンの決定的な違い

この2つの大きな違いは、「誰がその名前を解決できるか」という公開範囲（こうかいはんい）にあります。以下の表で比較してみましょう。

項目	Azure DNS（パブリック）	Azure プライベートDNSゾーン
アクセス範囲	インターネット全体	指定したVNet内部のみ
主な用途	Webサイトの公開	社内サーバー、DB連携
セキュリティ	全世界から参照可能	内部限定で安全
自動登録	なし（手動設定）	あり（VM作成時に連動）

5. プライベートDNSゾーンで自動登録を試す

実際に、プライベートDNSゾーンを作成し、VNetとリンクさせる際の設定イメージを確認しましょう。Azure CLI（コマンドラインインターフェース）を使って、ゾーンを作成するコマンドの例です。


az network private-dns zone create --resource-group MyResourceGroup --name myservice.local
{
  "etag": "00000000-0000-0000-0000-000000000000",
  "id": "/subscriptions/.../privateDnsZones/myservice.local",
  "name": "myservice.local",
  "type": "Microsoft.Network/privateDnsZones"
}

このコマンドを実行することで、「myservice.local」という内部専用のドメインが作成されました。次に、このドメインとVNetを紐付ける（リンクする）ことで、そのネットワーク内のマシンたちがこの名前を使えるようになります。

6. VNet内部での名前解決を確認する

設定が完了したら、実際にLinuxサーバーにログインして、正しく名前解決ができるかを確認してみましょう。nslookup（エヌエスルックアップ）というコマンドを使って、サーバー名からIPアドレスが引けるかテストします。


nslookup webserver01.myservice.local
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   webserver01.myservice.local
Address: 10.0.0.4

上記の結果のように、名前に対してプライベートIPアドレス（10.0.0.4）が返ってくれば、名前解決は成功です。これで、アプリケーションの設定ファイルにIPアドレスを直接書く必要がなくなり、管理が非常に楽になります。

7. PowerShellを使用したDNSレコードの管理

Windows環境をメインに使っている方は、PowerShell（パワーシェル）を使ってDNSレコードを操作することも多いでしょう。特定のドメインに新しいレコードを追加する簡単なスクリプトの例を紹介します。


$record = New-AzPrivateDnsRecordConfig -AaaaRecord "2001:db8::1"
New-AzPrivateDnsRecordSet -Name "test-record" -RecordType AAAA -ResourceGroupName "MyRG" -ZoneName "internal.com" -Ttl 3600 -PrivateDnsRecord $record

クラウド管理では、ポータル画面（マウス操作）だけでなく、このようにスクリプトを使って自動化（じどうか）することで、設定ミスを減らし、作業時間を短縮することができます。初心者の方も、少しずつコマンド操作に慣れていくのがおすすめです。

8. データベース接続への応用例

名前解決が役立つ最も一般的なケースは、Webサーバーからデータベース（DB）サーバーへ接続する場合です。IPアドレスが変わっても名前（ホスト名）が変わらなければ、アプリ側の修正は不要です。以下は、SQLデータベースの接続情報を管理するイメージです。


id | server_name         | role       | private_ip
---+---------------------+------------+-----------
1  | web-01.local        | frontend   | 10.0.0.10
2  | web-02.local        | frontend   | 10.0.0.11
3  | db-primary.local    | database   | 10.0.1.50
4  | db-secondary.local  | database   | 10.0.1.51

この状態で、SQLを使って接続先を確認するようなプログラムを書く場合、以下のようにシンプルに記述できます。


-- DBの接続先サーバー名を特定するクエリ例
SELECT server_name 
FROM server_list 
WHERE role = 'database' AND server_name LIKE '%primary%';

このように、名前解決の仕組みを整えることは、システム全体の可読性（かどくせい）を高めることにつながります。

9. 名前解決がうまくいかない時のチェックポイント

もし名前解決ができない場合は、以下の点を確認してみましょう。まず、VNetの「DNSサーバー」の設定が「Azure提供」になっているか、あるいは適切なカスタムIPが指定されているかを確認します。次に、プライベートDNSゾーンが正しく対象のVNetに「仮想ネットワークリンク」として登録されているかを見ます。

また、ネットワークセキュリティグループ（NSG）でDNS通信（ポート53番）が拒否（きょひ）されていないかも重要です。初心者が陥りやすい罠として、リンク設定を忘れて「ゾーンだけ作った」状態になっていることがあります。必ず「ゾーン作成」と「VNetリンク」はセットで考えるようにしましょう。これを意識するだけで、トラブル解決のスピードが格段に上がります。

まとめ

Azureにおける名前解決（なまえかいけつ）の仕組みは、クラウドインフラを構築する上で避けては通れない非常に重要な要素です。今回の記事では、外部公開用のAzure DNSと、内部ネットワーク専用のAzure プライベートDNSゾーンの役割と使い分けについて詳しく解説しました。仮想ネットワーク（VNet）内での通信をIPアドレスではなく、ホスト名で行うことにより、システムの柔軟性と管理効率が飛躍的に向上します。

Azure DNSとプライベートDNSゾーンの最適な選択

システム設計（せっけい）において、どちらのサービスを利用すべきかは「誰がその名前にアクセスする必要があるか」という視点で判断します。インターネット上の不特定多数のユーザーにWebサービスを提供する場合は、グローバルな信頼性と高速な応答性能を持つAzure DNSを選択します。一方で、データベースサーバーやアプリケーションサーバー間の通信など、組織内（VNet内）だけで完結する通信には、セキュリティを担保しつつ自動登録機能（じどうとうろくきのう）の恩恵を受けられるプライベートDNSゾーンが最適です。

特に、開発現場（かいはつげんば）では、環境ごとにIPアドレスが変動することが多いため、名前解決を利用することで設定ファイル（構成情報）を書き換える手間を削減できます。これは、自動化（じどうか）や継続的デリバリー（CI/CD）を推進する上でも大きなメリットとなります。

C#による名前解決の動作確認プログラム

開発者がプログラムからホスト名を使用してIPアドレスを取得する際の、C#（シーシャープ）による実装例を確認してみましょう。System.Net名前空間のDnsクラスを使用することで、簡単に名前解決の結果を取得できます。


using System;
using System.Net;

class DnsResolver
{
    static void Main()
    {
        string hostName = "db-primary.local";
        try
        {
            // ホスト名からIPアドレスのリストを取得します
            IPAddress[] adresses = Dns.GetHostAddresses(hostName);

            foreach (var ip in adresses)
            {
                Console.WriteLine($"ホスト名: {hostName} のIPアドレスは {ip} です。");
            }
        }
        catch (Exception ex)
        {
            Console.WriteLine("名前解決に失敗しました: " + ex.Message);
        }
    }
}

上記のコードを実行した際の、典型的な出力結果は以下の通りです。プライベートDNSゾーンが正しく設定されていれば、内部IPアドレスが返されます。


ホスト名: db-primary.local のIPアドレスは 10.0.1.50 です。

SQL Server接続における名前解決の活用

実際の業務（ぎょうむ）アプリケーションでは、データベース接続文字列にホスト名を使用することが推奨されます。以下に、データベースサーバーの情報を管理するテーブルの例と、それを参照するSQLクエリを示します。

まずは、現在のネットワーク内のサーバー一覧（サーバー管理テーブル）の状態を確認します。


id | server_name           | ip_address | environment | status
---+-----------------------+------------+-------------+---------
1  | web-server-01.local   | 10.0.0.10  | production  | online
2  | web-server-02.local   | 10.0.0.11  | production  | online
3  | db-primary.local      | 10.0.1.50  | production  | active
4  | db-secondary.local    | 10.0.1.51  | production  | standby
5  | dev-sql-01.local      | 10.0.2.100 | development | testing

次に、本番環境（production）のデータベースサーバー名のみを抽出するSQLを実行してみましょう。


SELECT id, server_name, status
FROM network_servers
WHERE environment = 'production' 
AND server_name LIKE 'db%';

実行結果は以下のようになります。この名前（server_name）を使用してアプリケーションは接続を試みます。


id | server_name        | status
---+--------------------+--------
3  | db-primary.local   | active
4  | db-secondary.local | standby

COBOL環境での名前解決の概念

レガシーシステムからAzureへの移行（リホスト）を行う際、COBOL（コボル）プログラムから外部リソースを呼び出す場合も、名前解決の概念は共通です。プログラム内で直接IPをハードコードせず、外部の構成定義やDNSを介して接続先を特定することが保守性を高める鍵となります。


IDENTIFICATION DIVISION.
PROGRAM-ID. CHECK-SERVER.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 SERVER-NAME     PIC X(30) VALUE "DB-PRIMARY.LOCAL".
01 IP-ADDRESS      PIC X(15).

PROCEDURE DIVISION.
    DISPLAY "接続先サーバー名を確認中: " SERVER-NAME.
    * 実際には外部APIやシステムコールを通じて名前解決を行います
    STOP RUN.

Linuxコマンドによるネットワークトラブルシューティング

Azure VNet内で名前解決が正常に動作しているかをコマンドラインから確認する方法は、エンジニアにとって必須のスキルです。digコマンドやhostコマンドを使用して、DNSの応答を確認します。


host db-primary.local
db-primary.local has address 10.0.1.50

もし、設定が反映されていない場合は、以下のコマンドでVNetのリンク状態やゾーンの情報を再確認する必要があります。


az network private-dns link vnet list --resource-group MyResourceGroup --zone-name myservice.local
[
  {
    "id": "/subscriptions/.../virtualNetworkLinks/myVNetLink",
    "name": "myVNetLink",
    "provisioningState": "Succeeded",
    "registrationEnabled": true
  }
]

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

生徒

「先生、まとめありがとうございました！Azure DNSとプライベートDNSゾーンの使い分けがはっきり分かりました。外部向けか内部向けか、という点が最大のポイントですね。」

先生

「その通りです。特にプライベートDNSゾーンの『自動登録機能』は、仮想マシンを増設する際に非常に便利ですよ。設定の手間が減るだけでなく、入力ミスによる通信エラーも防げますからね。」

生徒

「プログラムからも、ホスト名を使うことで接続先を柔軟に変更できることが分かりました。C#のサンプルコードを見て、IPアドレスを直接書かないことの大切さが実感できました。」

先生

「素晴らしい気づきですね！クラウドネイティブな開発では、インフラの構成変更に強いプログラムを書くことが求められます。名前解決はその基礎となる部分です。トラブルが起きたときは、LinuxのhostコマンドやAzure CLIを使って、一歩ずつ確認していく習慣をつけましょう。」

生徒

「はい！仮想ネットワークリンクの設定を忘れないように注意して、これからのシステム構築に活かしていきたいと思います。ありがとうございました！」

先生