Azure 仮想ネットワークの DNS 名前解決を構成する

Azure 仮想ネットワークでは、サービスとしてのインフラストラクチャ (IaaS)、サービスとしてのプラットフォーム (PaaS)、ハイブリッド ソリューションに対して複数の名前解決方法がサポートされています。 仮想マシンと仮想ネットワーク内の他のリソース間の通信を有効にするには、適切な DNS 構成が必要です。 覚えやすく一貫性のある名前を使用すると、IP アドレスに依存するのではなく、通信プロセスが簡略化されます。

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

• Azure プライベート DNS ゾーン
• Azure で提供される名前解決
• 独自のドメイン ネーム システム (DNS) サーバーを使用する名前解決 (Azure 提供の DNS サーバーにクエリが転送される可能性がある)
• Azure DNS Private Resolver

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

推奨されるソリューションは Azure プライベート DNS ゾーンです。これを選択すると、DNS ゾーンとレコードを柔軟に管理できます。 詳細については、「プライベート ドメインに Azure DNS を使用する」を参照してください。

Azure で提供される名前解決

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

パブリック DNS の名前解決に加えて、Azure では、同じ仮想ネットワークまたはクラウド サービス内の仮想マシンとロール インスタンスの内部名前解決が提供されます。 クラウド サービス内の仮想マシンとインスタンスは同じ DNS サフィックスを共有するため、ホスト名だけで解決できます。 ただし、クラシック デプロイ モデルの仮想ネットワークでは、異なるクラウド サービスに個別の DNS サフィックスがあり、FQDN はクラウド サービス間で名前を解決する必要があります。

Azure Resource Manager デプロイ モデルを使用してデプロイされた仮想ネットワークでは、DNS サフィックスは仮想ネットワーク内のすべての仮想マシンで一貫性があるため、FQDN は必要ありません。 仮想マシンとネットワーク インターフェイスの両方に DNS 名を割り当てることができます。 Azure 提供の名前解決は、まったく構成作業の必要がないというメリットがある反面、前の表に示した説明のとおり、すべてのデプロイ シナリオに適しているわけではありません。

Features

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

• 構成作業は不要です。
• 可用性が優れているため、独自にお持ちの DNS サーバーのためにクラスターの作成や管理を行う必要はありません。
• このサービスを独自にお持ちの DNS サーバーと組み合わせて使用すると、オンプレミスと Azure の両方のホスト名を解決できます。
• FQDN を必要とせずに、同じクラウド サービス内の仮想マシンとロール インスタンスの間で名前解決を使用できます。
• FQDN を必要とせずに、Resource Manager デプロイ モデルを使用する仮想ネットワーク内の仮想マシン間で名前解決を使用できます。 クラシック デプロイ モデルを使用した仮想ネットワークの場合は、異なるクラウド サービス内の名前を解決する際には FQDN が必要です。
• ホスト名には、自動生成された名前ではなく、デプロイ環境のニーズに応じたわかりやすい名前を使用できます。

Considerations

Azure 提供の名前解決を使用する場合は、以下の事項に留意してください。

• Azure によって作成される DNS サフィックスは変更できません。
• DNS 参照のスコープは仮想ネットワークです。 ある仮想ネットワークに対して作成された DNS 名を、他の仮想ネットワークから解決することはできません。
• 独自に作成したレコードの手動登録は許可されていません。
• WINS と NetBIOS はサポートされません。 Windows エクスプローラーに仮想マシンが表示されません。
• ホスト名は DNS 互換である必要があります。 名前に使用できる文字の種類は、0 から 9、a から z、およびハイフン (-) のみです。 名前の先頭または末尾にはハイフンを使用できません。
• DNS クエリ トラフィックは仮想マシンごとに調整されます。 調整は、ほとんどのアプリケーションに影響しません。 要求のスロットリングが発生する場合は、クライアント側のキャッシュが有効になっていることを確認してください。 詳細については、「DNS クライアントの構成」を参照してください。
• DNS 解決の問題を回避するには、仮想ネットワーク内の仮想マシンごとに異なる名前を使用する必要があります。
• クラシック デプロイ モデルの各仮想ネットワークには、最初の 180 個のクラウド サービス内の仮想マシンのみが登録されます。 この制限は、Azure Resource Manager 内の仮想ネットワークには適用されません。
• Azure DNS IP アドレスは 168.63.129.16 です。 このアドレスは静的な IP アドレスであり、変更されません。

逆引き DNS の考慮事項

仮想マシンの逆引き DNS は、Resource Manager に基づくすべての仮想ネットワークでサポートされます。 Azure 管理の逆引き DNS (別名: ポインター (PTR)) では、個々の VM が起動する際、\[vmname\].internal.cloudapp.net 形式のレコードが 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 に対する前方参照は、VM に割り当てられた IP アドレスへと解決されます。

Azure プライベート DNS ゾーンが仮想ネットワーク リンクを使って仮想ネットワークにリンクされ、かつ、そのリンクについて自動登録が有効になっている場合、逆引き DNS クエリは 2 つのレコードを返します。 1 つは \[vmname\].[privatednszonename] 形式のレコード、もう 1 つは \[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が返されます。

逆引き DNS (PTR) レコードは、フォワード プライベート DNS ゾーン内に格納されません。 逆引き DNS レコードは、逆引き DNS (in-addr.arpa) ゾーン内に格納されます。 仮想ネットワークに関連付けられている既定の逆引き DNS ゾーンを表示することや編集することはできません。

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

PTR レコードの自動登録はサポートされていません。 エントリを作成するには手作業で入力する必要があります。 他のゾーンで有効になっている場合は、仮想ネットワークの自動登録を無効にする必要があります。 プライベート DNS ゾーンを作成して仮想ネットワークにリンクする方法の詳細については、Azure プライベート DNS のクイックスタートを参照してください。 For information on how to create a private DNS zone and link it to a virtual network, see the Azure Private DNS quickstart.

DNS クライアントの構成

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

Client-side caching

DNS クエリには、ネットワーク経由で送信する必要がないものもあります。 クライアント側のキャッシュは、ローカル キャッシュから繰り返される DNS クエリを解決することで、待機時間を短縮し、ネットワークの停止に対する復元性を高めることができます。 DNS レコードには有効期限 (TTL) のしくみが備わっているため、キャッシュ機構は、レコードの有効性に問題を起こすことなく可能な限り長期間にわたってレコードを保持できます。 したがって、クライアント側のキャッシュはほとんどの状況で効果的に機能します。

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

入手して利用できる DNS キャッシュ パッケージには非常に多くの種類があります (dnsmasq など)。 以下に、よく使われているディストリビューションに dnsmasq をインストールする方法を示します。

sudo apt-get install dnsmasq

Client-side retries

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

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

cat /etc/resolv.conf を使用して、Linux VM の現在の設定を確認します。 たとえば、options 行には以下のような記述があります。

options timeout:1 attempts:5

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

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

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

仮想マシンとロール インスタンス

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

仮想ネットワーク内の DNS サーバーは、Azure の再帰的リゾルバーに DNS クエリを転送できます。 このしくみにより、仮想ネットワーク内でホスト名を解決することができます。 たとえば、Azure で実行しているドメイン コントローラー (DC) は、そのドメインに対する DNS クエリに応答し、他のすべてのクエリを Azure に転送できます。 転送クエリを使用すると、仮想マシンはオンプレミスのリソース (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) により、各 VM に内部 DNS サフィックス (.internal.cloudapp.net) が付与されます。 このサフィックスによってホスト名のレコードが internal.cloudapp.net ゾーン内に格納されるため、ホスト名の解決が可能です。 独自の名前解決ソリューションを使用する場合、このサフィックスは他の DNS アーキテクチャ (ドメイン参加シナリオなど) に干渉するため、仮想マシンには提供されません。 Instead, Azure provides a nonfunctioning placeholder (reddog.microsoft.com).

必要な場合は、PowerShell または API を使って内部 DNS サフィックスを知ることができます。

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

実際のニーズに Azure へのクエリ転送が適さない場合は、独自の DNS ソリューションを用意するか、Azure DNS Private Resolver をデプロイしてください。

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

• 適切なホスト名解決を、たとえば動的 DNS (DDNS) などによって提供する。 DDNS を使用する場合、DNS レコードの清掃を無効にする必要がある場合があります。 場合によっては、Azure の長い DHCP リース期間に合わないタイミングで清掃処理が行われ、DNS レコードが削除される可能性があります。
• 適切な再帰的解決を提供し、外部ドメイン名の解決を可能にする。
• 対象のクライアントからのアクセスを可能にし (ポート 53 の TCP および UDP)、インターネットへのアクセスを可能にする。
• インターネットからのアクセスに対してセキュリティを確保し、外部エージェントの脅威を軽減する。

パフォーマンスを最大限に高めるには、Azure 仮想マシンを DNS サーバーとして使用する場合は、IPv6 を無効にする必要があります。

ネットワーク セキュリティ グループ (NSG) は、DNS リゾルバー エンドポイントのファイアウォールとして機能します。 お使いの NSG セキュリティ ルールを変更またはオーバーライドし、DNS リスナー エンドポイント用に、UDP ポート 53 (および、必要に応じて TCP ポート 53) へのアクセスを許可してください。 カスタム DNS サーバーがネットワーク上に設定されると、ポート 53 を経由するトラフィックによってサブネットと NIC の NSG がバイパスされます。

Web apps

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

• お持ちの Web アプリについて、まだ仮想ネットワークの統合を有効にしていない場合は、仮想ネットワークへのアプリの統合に関するページの説明に従って有効にします。
• 仮想ネットワークにリンクされた Web アプリ (App Service を使用して構築) から、同じプライベート ゾーンにリンクされていない別の仮想ネットワーク内の仮想マシンへの名前解決を実行するには、両方の仮想ネットワークでカスタム DNS サーバーまたは Azure DNS プライベート リゾルバー を使用します。

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

• Azure の再帰的リゾルバー (仮想 IP 168.63.129.16) にクエリを転送できる VM 上に、ターゲット仮想ネットワーク内の DNS サーバーをセットアップします。 DNS フォワーダーの例は、Azure クイック スタート テンプレートのギャラリーと GitHub で確認できます。
• VM 上のソース仮想ネットワーク内に DNS フォワーダーを設定します。 この DNS フォワーダーを、ターゲット仮想ネットワーク内の DNS サーバーにクエリを転送するように構成します。
• ソース仮想ネットワークの設定内にソース DNS サーバーを構成します。
• 仮想ネットワークへのアプリ統合に関するページの指示に従って、ソース仮想ネットワークにリンクする App Service Web App に対する仮想ネットワークの統合を有効にします。

To use Azure DNS Private Resolver, see Ruleset links.

DNS サーバーの指定

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

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

お使いの仮想ネットワークでカスタムの DNS サーバーを使用する場合は、少なくとも 1 つの DNS サーバー IP アドレスを指定する必要があります。 そうしないと、その仮想ネットワークでは構成が無視され、代わりに Azure 提供の DNS が使われます。

Related content

Azure Resource Manager デプロイ モデル:

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