Azure 仮想ネットワーク内のリソースの名前解決

Azure を使用して、IaaS、PaaS、ハイブリッド ソリューションをホストできます。 仮想マシン (VM) と仮想ネットワークにデプロイされている他のリソースとの通信を容易にするために、これらが相互に通信できるようにする必要がある場合があります。 IP アドレスに依存するのではなく、覚えやすく変化のない名前を使用することで、通信プロセスを簡素化することができます。

仮想ネットワーク内に配置されたリソースがドメイン名を内部 IP アドレスに解決する必要がある場合、次の 4 つの方法のいずれかを使用できます。

• Azure DNS プライベート ゾーン

• Azure で提供される名前解決

• 独自の DNS サーバーを使用する名前解決 (Azure で提供される DNS サーバーにクエリを転送する可能性がある)

• Azure DNS Private Resolver

どちらの名前解決方法を使用するかは、リソースが互いに通信するために必要な方法によって決まります。 次の表では、シナリオと対応する名前解決の方法を示します。

Azure で提供される名前解決

Azure によって提供される名前解決では、基本的な権限を持つ DNS 機能のみが提供されます。 Azure 提供の DNS を使用する場合は、Azure によって DNS ゾーン名とレコードが管理されます。 ユーザーが DNS ゾーン名や DNS レコードのライフ サイクルを制御することはできません。 仮想ネットワークに対応したフル機能の DNS ソリューションが必要な場合は、Azure DNS プライベート ゾーンとお客様が管理する DNS サーバー、または Azure DNS Private Resolver を使用できます。

Azure では、パブリック DNS 名の解決と共に、同じ仮想ネットワークまたはクラウド サービス内に存在する VM とロール インスタンス用に内部の名前解決が提供されます。 クラウド サービス内の VM とインスタンスは、同じ DNS サフィックスを共有するため、ホスト名のみで十分です。 ただし、クラシック デプロイ モデルを使用して展開された仮想ネットワークでは、クラウド サービスが異なると DNS サフィックスも異なります。 このような状況では、異なるクラウド サービス間で名前を解決するために FQDN が必要になります。 Azure Resource Manager デプロイ モデルを使用して展開された仮想ネットワークでは、DNS サフィックスは仮想ネットワーク内のすべての仮想マシン間で一貫性があるため、FQDN は必要ありません。 DNS 名は、VM とネットワーク インターフェイスの両方に割り当てることができます。 Azure 提供の名前解決ではどのような構成も必要ありませんが、前の表で詳しく説明したように、すべてのデプロイ シナリオに適しているわけではありません。

特徴

Azure で提供される名前解決の機能を次に示します。

• 使いやすさ。 構成は必要ありません。

• 高可用性: 独自の DNS サーバーのクラスターを作成および管理する必要はありません。

• このサービスは、オンプレミスと Azure の両方のホスト名を解決するために、独自の DNS サーバーで使用できます。

• 同じクラウド サービス内の VM とロール インスタンスの間で、FQDN を必要とすることなく名前解決を使用できます。

• Azure Resource Manager デプロイ モデルを使用する仮想ネットワーク内の VM 間では、FQDN を必要とすることなく名前解決を使用できます。 クラシック デプロイ モデルの仮想ネットワークの場合は、異なるクラウド サービスの名前を解決するときに FQDN が必要になります。

• 自動生成される名前を使用するのではなく、デプロイの内容がよくわかるホスト名を使用できます。

考慮事項

Azure で提供される名前解決を使用する場合の考慮事項を次に示します。

• Azure によって作成される DNS サフィックスは変更できません。

• DNS 参照のスコープは仮想ネットワークです。 ある仮想ネットワークに対して作成された DNS 名を、他の仮想ネットワークから解決することはできません。

• 独自のレコードを手動で登録することはできません。

• WINS と NetBIOS はサポートされません。 Windows エクスプローラーに VM を表示することはできません。

• ホスト名は DNS 互換である必要があります。 名前に使用できる文字は 0-9、a-z、および "-" のみであり、最初または最後の文字として "-" は使用できません。

• DNS クエリ トラフィックは VM ごとに調整されます。 調整は、ほとんどのアプリケーションに影響しません。 要求の調整が発生した場合は、クライアント側のキャッシュが有効になっていることを確認します。 詳細については、「DNS クライアントの構成」を参照してください。

• DNS 解決の問題を回避するには、仮想ネットワーク内の仮想マシンごとに異なる名前を使用します。

• 最初の 180 のクラウド サービス内の VM だけが、クラシック デプロイ モデルの各仮想ネットワークに対して登録されます。 この制限は、Azure Resource Manager の仮想ネットワークには適用されません。

• Azure DNS IP アドレスは 168.63.129.16 です。 このアドレスは静的な IP アドレスであり、変更されません。

逆引き DNS の考慮事項

VM の逆引き DNS は、Azure Resource Manager ベースのすべての仮想ネットワークでサポートされています。 [vmname].internal.cloudapp.net という形式の Azure が管理する逆引き DNS (PTR) レコードは、VM を起動すると自動的に DNS に追加され、VM を停止 (割り当て解除) すると削除されます。 次の例を参照してください。

C:\>nslookup -type=ptr 10.11.0.4
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
4.0.11.10.in-addr.arpa  name = myeastspokevm1.internal.cloudapp.net

逆引き DNS ゾーン internal.cloudapp.net は Azure によって管理され、直接は表示も編集もできません。 [vmname].internal.cloudapp.net 形式の FQDN に対する前方参照も、仮想マシンに割り当てられた IP アドレスへと解決されます。

Azure DNS プライベート ゾーンが仮想ネットワーク リンクを使用して仮想ネットワークにリンクされ、そのリンクで自動登録が有効になっている場合、逆引き DNS クエリは 2 つのレコードを返します。 片方のレコードは [vmname].[privatednszonename] という形式で、他方は [vmname].internal.cloudapp.net という形式です。 次の例を参照してください。

C:\>nslookup -type=ptr 10.20.2.4
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
4.2.20.10.in-addr.arpa  name = mywestvm1.internal.cloudapp.net
4.2.20.10.in-addr.arpa  name = mywestvm1.azure.contoso.com

上記のように 2 つの PTR レコードが返されると、いずれかの FQDN の前方参照によって VM の IP アドレスが返されます。

逆引き DNS 参照は、他の仮想ネットワークとピアリングされている場合でも、特定の仮想ネットワークにスコープ設定されます。 ピアリングされた仮想ネットワークにある仮想マシンの IP アドレスに対する逆引き DNS クエリは、NXDOMAIN を返します。

Azure DNS プライベート ゾーンを使用して独自の逆引き参照ゾーンを作成し、このゾーンを仮想ネットワークにリンクすることにより、仮想ネットワークで逆引き DNS 機能を無効にできます。 たとえば、仮想ネットワークの IP アドレス空間が 10.20.0.0/16 の場合、空のプライベート DNS ゾーン 20.10.in-addr.arpa を作成し、これを仮想ネットワークにリンクすることができます。 このゾーンは、仮想ネットワークの既定の逆引き参照ゾーンをオーバーライドします。 このゾーンは空です。 これらのエントリを手動で作成しない限り、逆引き DNS は NXDOMAIN を返します。

PTR レコードの自動登録はサポートされていません。 エントリを作成する場合は、手動で入力します。 他のゾーンで有効になっている場合は、仮想ネットワークの自動登録を無効にする必要があります。 この制限は、自動登録が有効になっている場合に 1 つのプライベート ゾーンのみをリンクできるようにするという制限に起因します。 プライベート DNS ゾーンを作成して仮想ネットワークにリンクする方法の詳細については、プライベート DNS のクイックスタート ガイドを参照してください。

DNS クライアントの構成

このセクションでは、クライアント側のキャッシュとクライアント側の再試行について説明します。

クライアント側のキャッシュ

DNS クエリには、ネットワーク経由で送信する必要がないものもあります。 クライアント側のキャッシュは、ローカル キャッシュから繰り返される DNS クエリを解決することで、待ち時間を短縮し、ネットワークの停止に対する復元性を高めるのに役立ちます。 DNS レコードには、有効期限 (TTL) メカニズムが含まれています。有効期限により、キャッシュは、レコードの鮮度に影響を与えずに、可能な限り長い時間レコードを格納できます。 このため、クライアント側のキャッシュはほとんどの状況に適しています。

既定の Windows DNS クライアントには、組み込みの DNS キャッシュがあります。 Linux ディストリビューションの一部では、既定でキャッシュは含まれていません。 ローカル キャッシュがまだ存在していない場合は、各 Linux VM に DNS キャッシュを追加します。

多数のさまざまな DNS キャッシュ パッケージ (dnsmasq など) を使用できます。 最も一般的なディストリビューションに dnsmasq をインストールする方法を次に示します。

クライアント側の再試行

DNS では、主に UDP プロトコルが使用されます。 UDP プロトコルでは、メッセージの配信が保証されないため、再試行ロジックは、DNS プロトコル自体で処理されます。 各 DNS クライアント (オペレーティング システム) では、作成者の選択に応じて、再試行ロジックが異なる場合があります。

• Windows オペレーティング システムでは、1 秒後に再試行されます。その後、2 秒後、4 秒後に再試行され、さらにもう一度その 4 秒後に再試行されます。
• 既定の Linux の設定では、5 秒後に再試行されます。 再試行の仕様を 1 秒間隔の 5 回に変更することをお勧めします。

cat /etc/resolv.conf を使用して、Linux VM の現在の設定を確認します。 options 行を調べます。以下に例を示します。

options timeout:1 attempts:5

resolv.conf ファイルは自動生成され、編集すべきではありません。 options 行を追加する具体的な手順は、ディストリビューションによって異なります。

独自の DNS サーバーを使用する名前解決

このセクションでは、VM、ロール インスタンス、および Web アプリについて説明します。

VM とロール インスタンス

名前解決のニーズが、Azure で提供される機能の範囲を超えている場合があります。 たとえば、Microsoft Windows Server Active Directory ドメインを使用して、仮想ネットワーク間で DNS 名を解決することが必要である場合があります。 これらのシナリオを可能にするために、Azure では独自の DNS サーバーを使用できます。

仮想ネットワーク内の DNS サーバーは、Azure の再帰的リゾルバーに DNS クエリを転送できます。 この手順により、その仮想ネットワーク内のホスト名を解決することができます。 たとえば、Azure で実行しているドメイン コントローラー (DC) は、そのドメインに対する DNS クエリに応答し、他のすべてのクエリを Azure に転送できます。 クエリを転送することで、VM はオンプレミスのリソース (DC 経由) と Azure で提供されるホスト名 (フォワーダー経由) の両方を参照できます。 Azure の再帰的リゾルバーへのアクセスは、仮想 IP 168.63.129.16 を通じて提供されます。

また、DNS の転送により、仮想ネットワーク間の DNS 解決も可能になり、オンプレミスのマシンが Azure で提供されるホスト名を解決できるようになります。 VM のホスト名を解決するために、DNS サーバー VM は、同じ仮想ネットワークに存在し、Azure にホスト名のクエリを転送するように構成されている必要があります。 DNS サフィックスは仮想ネットワークごとに異なるため、条件付きの転送ルールを使用し、解決のために正しい仮想ネットワークに DNS クエリを送信します。 次の図は、2 つの仮想ネットワークと、この方法を使用して仮想ネットワーク間の DNS 解決を行うオンプレミスのネットワークを示しています。 DNS フォワーダーの例は、Azure クイック スタート テンプレートのギャラリーと GitHub で確認できます。

Azure で提供される名前解決を使用している場合、Azure の動的ホスト構成プロトコル (DHCP) によって内部 DNS サフィックス (.internal.cloudapp.net) が各 VM に提供されます。 ホスト名のレコードは internal.cloudapp.net ゾーン内に存在するため、このサフィックスによってホスト名を解決できます。 独自の名前解決ソリューションを使用している場合、このサフィックスは他の DNS アーキテクチャ (ドメイン参加シナリオなど) に干渉するため、VM には提供されません。 代わりに、Azure によって、機能を持たないプレース ホルダー (reddog.microsoft.com) が提供されます。

必要に応じて、PowerShell または API を使用して、内部 DNS サフィックスを調べることができます。

• Azure Resource Manager デプロイ モデルの仮想ネットワークの場合、ネットワーク インターフェイス REST API、Get-AzNetworkInterface PowerShell コマンドレット、および az network nic show Azure CLI コマンドを通じてサフィックスを取得することができます。

Azure へのクエリの転送がニーズに合わない場合は、独自の DNS ソリューションを提供するか、Azure DNS Private Resolver をデプロイします。

独自の DNS ソリューションを提供する場合は、次のようなソリューションにする必要があります。

• たとえば、DDNS 経由で、適切なホスト名解決を提供する。 DDNS を使用するときは DNS レコードの清掃を無効にすることが必要になる場合があります。 Azure の DHCP リースが長く、清掃によって、完了前に DNS レコードが削除されることがあります。

• 適切な再帰的解決を提供し、外部ドメイン名の解決を可能にする。

• 対象のクライアントからのアクセスを可能にし (ポート 53 の TCP および UDP)、インターネットへのアクセスを可能にする。

• 外部エージェントによる脅威を軽減するために、インターネットからのアクセスをセキュリティ保護する。

Web Apps

仮想ネットワークにリンクされた App Service を使用して構築された Web アプリから同じ仮想ネットワーク内の VM への名前解決を実行する必要があるとします。 Azure (仮想 IP 168.63.129.16) にクエリを転送する DNS フォワーダーがあるカスタム DNS サーバーを設定することに加え、次の手順を実行します。

既に実行していなければ、仮想ネットワークへのアプリの統合に関するページの説明に従って、Web アプリに対する仮想ネットワークの統合を有効にします。

vnet にリンクされた Web アプリ (App Service を使用して構築) から、同じプライベート ゾーンにリンクされていない別の vnet 内の VM への名前解決を実行する必要がある場合は、両方の vnet でカスタム DNS サーバーまたは Azure DNS Private Resolver を使用します。

カスタム DNS サーバーを使用するには、次の手順に従います。

• クエリを Azure の再帰的リゾルバー (仮想 IP 168.63.129.16) に転送することもできる VM 上のターゲット仮想ネットワーク内に DNS サーバーを設定します。 DNS フォワーダーの例は、Azure クイック スタート テンプレートのギャラリーと GitHub で確認できます。

• VM 上のソース仮想ネットワーク内に DNS フォワーダーを設定します。 この DNS フォワーダーを、ターゲット仮想ネットワーク内の DNS サーバーにクエリを転送するように構成します。

• ソース仮想ネットワークの設定内にソース DNS サーバーを構成します。

• 仮想ネットワークへのアプリの統合に関するページの指示に従って、ソース仮想ネットワークにリンクする App Service Web App に対する仮想ネットワークの統合を有効にします。

Azure DNS Private Resolver を使用するには、「ルールセット リンク」を参照してください。

DNS サーバーの指定

独自の DNS サーバーを使用する場合、Azure では、仮想ネットワークごとに複数の DNS サーバーを指定できます。 また、ネットワーク インターフェイス (Azure Resource Manager の場合) またはクラウド サービス (クラシック デプロイ モデルの場合) ごとに複数の DNS サーバーを指定することもできます。 ネットワーク インターフェイスまたはクラウド サービスに対して指定された DNS サーバーは、仮想ネットワークに対して指定された DNS サーバーよりも優先されます。

Azure Resource Manager デプロイ モデルを使用している場合は、仮想ネットワークとネットワーク インターフェイス用の DNS サーバーを指定できます。 詳細については、仮想ネットワークの管理に関するページとネットワーク インターフェイスの管理に関するページを参照してください。

次のステップ

Azure Resource Manager デプロイ モデル:

• 仮想ネットワークを管理する

• ネットワーク インターフェイスを管理する