次の方法で共有

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

  • [アーティクル]

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

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

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

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

Note

Azure 提供の DNS を使用する場合、仮想マシンには適切な DNS サフィックスが自動的に付与されます。 それ以外のオプションを選択する場合は、完全修飾ドメイン名 (FQDN) を使用するか、手作業で VM に適切な DNS サフィックスを付与する必要があります。

シナリオ 解決策 DNS サフィックス
同じ仮想ネットワーク内に配置された VM 間、または同じクラウド サービス内の Azure クラウド サービスのロール インスタンス間での名前解決。 Azure プライベート DNS ゾーンまたは Azure 提供の名前解決 ホスト名または FQDN
異なる仮想ネットワーク内の VM 間または異なるクラウドサービスのロール インスタンス間での名前解決。 Azure プライベート DNS ゾーン、Azure DNS Private Resolver、またはユーザー管理の DNS サーバーで仮想ネットワーク間のクエリ転送を行うことによる Azure での解決 (DNS プロキシ)。 「独自の DNS サーバーを使用する名前解決」を参照してください。 FQDN のみ
Azure App Service (Web アプリ、関数、ボットなど) による、仮想ネットワーク統合を使用した、同じ仮想ネットワーク内のロール インスタンスや VM に対する名前解決。 Azure DNS Private Resolver、または Azure で解決するために仮想ネットワーク間でクエリを転送する、ユーザーが管理する DNS サーバー (DNS プロキシ)。 「独自の DNS サーバーを使用する名前解決」を参照してください。 FQDN のみ
App Service Web Apps による、同じ仮想ネットワーク内の VM に対する名前解決。 Azure DNS Private Resolver、または Azure で解決するために仮想ネットワーク間でクエリを転送する、ユーザーが管理する DNS サーバー (DNS プロキシ)。 「独自の DNS サーバーを使用する名前解決」を参照してください。 FQDN のみ
仮想ネットワーク内の App Service Web Apps から別の仮想ネットワーク内の VM に対する名前解決。 Azure DNS Private Resolver、または Azure で解決するために仮想ネットワーク間でクエリを転送する、ユーザーが管理する DNS サーバー (DNS プロキシ)。 「独自の DNS サーバーを使用する名前解決」を参照してください。 FQDN のみ
Azure 内の VM またはロール インスタンスからのオンプレミスのコンピューターとサービスの名前解決。 Azure DNS Private Resolver またはユーザー管理の DNS サーバー (オンプレミスのドメイン コントローラー、ローカルの読み取り専用ドメイン コントローラー、ゾーン転送で同期される DNS セカンダリなど)。 「独自の DNS サーバーを使用する名前解決」を参照してください。 FQDN のみ
オンプレミスのコンピューターからの Azure のホスト名の解決。 対応する仮想ネットワーク内のユーザーが管理する DNS プロキシ サーバーにクエリを転送します。 プロキシ サーバーは、解決のために Azure にクエリを転送します。 「独自の DNS サーバーを使用する名前解決」を参照してください。 FQDN のみ
内部 IP 用の逆引き DNS。 Azure プライベート DNS ゾーン、Azure 提供の名前解決、Azure DNS Private Resolver、または独自にお持ちの DNS サーバーを使用した名前解決。 適用なし
仮想ネットワークではなく、異なるクラウド サービスに配置された VM またはロール インスタンス間での名前解決。 適用不可。 異なるクラウド サービス内にある VM とロール インスタンス間の接続は、仮想ネットワークの外側ではサポートされません。 適用なし

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

Note

Azure Cloud Services の Web ロールと Worker ロールを使用する場合、ロール インスタンスの内部 IP アドレスには、Azure Service Management REST API を使用してアクセスすることもできます。 詳細については、Service Management REST API リファレンスを参照してください。 アドレスは、ロール名とインスタンス数に基づきます。

特徴

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

  • 構成作業は不要です。
  • 可用性が優れているため、独自にお持ちの DNS サーバーのためにクラスターの作成や管理を行う必要はありません。
  • このサービスを独自にお持ちの DNS サーバーと組み合わせて使用すると、オンプレミスと Azure の両方のホスト名を解決できます。
  • 同じクラウド サービス内の VM とロール インスタンスの間で、FQDN を必要とすることなく名前解決を使用できます。
  • 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 ベースのすべての仮想ネットワークでサポートされています。 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 参照のスコープは特定の仮想ネットワーク 1 つのみであり、他の仮想ネットワークとのピア接続は含まれません。 ピア接続された仮想ネットワーク内にある VM の 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 レコードの自動登録はサポートされていません。 エントリを作成するには手作業で入力する必要があります。 他のゾーンで有効になっている場合は、仮想ネットワークの自動登録を無効にする必要があります。 この制約は、自動登録が有効になっている場合は 1 つのプライベート ゾーンしかリンクできないという制限があることに由来するものです。 プライベート DNS ゾーンを作成して仮想ネットワークにリンクする方法の詳細については、Azure プライベート DNS のクイックスタートを参照してください。

Note

Azure DNS プライベート ゾーンはグローバルであるため、異なる仮想ネットワーク間をまたぐ逆引き DNS 参照を作成することもできます。 これを行うには、逆引き参照用の Azure プライベート DNS ゾーン (in-addr.arpa ゾーン) を作成して仮想ネットワークにリンクする必要があります。 VM の逆引き DNS レコードは手作業で管理する必要があります。

DNS クライアントの構成

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

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

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

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

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

RHEL (NetworkManager を使用)

  1. 以下のコマンドで dnsmasq パッケージをインストールします。

    sudo yum install dnsmasq

  2. 以下のコマンドで dnsmasq サービスを有効にします。

    systemctl enable dnsmasq.service

  3. 以下のコマンドで dnsmasq サービスを起動します。

    systemctl start dnsmasq.service

  4. テキスト エディターを使って、/etc/dhclient-eth0.conf に prepend domain-name-servers 127.0.0.1; を追加します。

  5. 次のコマンドを使用して、ネットワーク サービスを再起動します。

    service network restart

Note

dnsmasq パッケージは、Linux 用に提供されている多種多様な DNS キャッシュの 1 つにすぎません。 使用する前に、実際のニーズに適しているかどうか、また、他のキャッシュが既にインストールされていないか確認してください。

クライアント側の再試行

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 行を追加する場合の具体的な手順はディストリビューションによって異なります。

RHEL (NetworkManager を使用)

  1. テキスト エディターを使って、ファイル /etc/sysconfig/network-scripts/ifcfg-eth0 に RES_OPTIONS="options timeout:1 attempts:5" 行を追加します。

  2. 以下のコマンドで NetworkManager サービスを再起動します。

    systemctl restart NetworkManager.service

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

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

注意

Azure DNS Private Resolver を使用すると、仮想ネットワークで VM ベースの DNS サーバーを使用する必要がなくなります。 次のセクションでは、VM ベースの DNS ソリューションを使用する場合に関する事項を説明します。 Azure DNS Private Resolver には、低コスト、組み込まれた高可用性、スケーラビリティ、柔軟性など多数のメリットがあります。

VM とロール インスタンス

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

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

重要

この構成に含まれる Azure VPN Gateway を仮想ネットワーク上のカスタム DNS サーバー IP と組み合わせて使用する場合、中断なしのサービスを維持するには Azure DNS IP (168.63.129.16) をリストに追加する必要があります。

また、DNS 転送を使うと異なる仮想ネットワーク間での DNS 解決が可能になり、Azure で提供されるホスト名をオンプレミスのマシンで解決することもできます。 VM のホスト名を解決するには、DNS サーバー VM は、同じ仮想ネットワークに存在し、Azure にホスト名のクエリを転送するように構成する必要があります。 DNS サフィックスは仮想ネットワークごとに異なるため、条件付きの転送ルールを使用し、解決のために正しい仮想ネットワークに DNS クエリを送信します。

以下の図は、仮想ネットワーク 2 つとオンプレミス ネットワークがある場合に、この方法で仮想ネットワーク間の DNS 解決が行われる様子を示しています。 DNS フォワーダーの例は、Azure クイック スタート テンプレートのギャラリーと GitHub で確認できます。

Note

ロール インスタンスは、同じ仮想ネットワーク内の VM の名前解決を実行できます。 VM のホスト名と internal.cloudapp.net DNS サフィックスで構成される FQDN が使われています。 この場合、名前解決が成功するのは、ロール インスタンスの VM 名がロール スキーマ (.cscfg ファイル) 内で <Role name="<role-name>" vmName="<vm-name>"> のように定義されている場合のみです。

別の仮想ネットワーク内にある VM (internal.cloudapp.net サフィックスを使用する FQDN) の名前解決を実行する必要があるロール インスタンスでは、このセクションで説明する方法 (2 つの仮想ネットワーク間で転送を行うカスタム DNS サーバー) を使用する必要があります。

仮想ネットワーク間で DNS が機能する様子を示す図

Azure 提供の名前解決を使用する場合、Azure の動的ホスト構成プロトコル (DHCP) により、各 VM に内部 DNS サフィックス (.internal.cloudapp.net) が付与されます。 このサフィックスによってホスト名のレコードが internal.cloudapp.net ゾーン内に格納されるため、ホスト名の解決が可能です。 独自の名前解決ソリューションを使用する場合は、他の DNS アーキテクチャに干渉するため、VM にこのサフィックスは付与されません (ドメイン参加シナリオなど)。 代わりに、Azure によって、機能を持たないプレース ホルダー (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 VM を DNS サーバーとして使用する場合、最適なパフォーマンスを確保するには IPv6 を無効にしてください。

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

重要

Windows DNS サーバーをカスタム DNS サーバーとして使用し、DNS 要求を Azure DNS サーバーに転送させる場合は、Azure 再帰 DNS サーバーでの再帰操作が適切に実行されるように、転送タイムアウト値を必ず 4 秒以上増やしてください。

この問題の詳細については、「フォワーダーと条件付きフォワーダーの解決タイムアウト」 を参照してください。

この推奨事項は、他の DNS サーバー プラットフォーム (転送タイムアウト値が 3 秒以下であるもの) にも該当する可能性があります。

これを行わないと、プライベート DNS ゾーンのレコードがパブリック IP アドレスで解決されることになる可能性があります。

Web Apps

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

  • お持ちの Web アプリについて、まだ仮想ネットワークの統合を有効にしていない場合は、仮想ネットワークへのアプリの統合に関するページの説明に従って有効にします。
  • 仮想ネットワークにリンクされた Web アプリ (App Service を使用して構築したもの) から、同じプライベート ゾーンにリンクされていない別の仮想ネットワーク内の VM に対して名前解決を実行する必要がある場合は、両方の仮想ネットワークでカスタム 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 サーバーを使用する場合は、仮想ネットワークごとに複数の DNS サーバーを指定できます。 また、ネットワーク インターフェイス (Resource Manager の場合) またはクラウド サービス (クラシック デプロイ モデルの場合) ごとに複数の DNS サーバーを指定することもできます。 ネットワーク インターフェイスまたはクラウド サービスに対して指定された DNS サーバーは、仮想ネットワークに対して指定された DNS サーバーよりも優先されます。

Note

ネットワーク接続のプロパティ (例: DNS サーバーの IP など) を VM 内で直接編集しないでください。 直接編集すると、仮想ネットワーク アダプターが交換された場合のサービス回復時に変更内容が失われることがあります。 この注意事項は、Windows VM と Linux VM の両方に該当します。

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

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

Note

既にデプロイされている仮想ネットワークまたは VM の DNS 設定を変更した場合、新しい DNS 設定を有効にするには、仮想ネットワーク内の影響を受けるすべての VM で DHCP リースの更新を実行する必要があります。 Windows OS を実行する VM の場合は、VM 内で直接「ipconfig /renew」と入力します。 この手順は OS によって異なります。 ご使用の種類の OS の関連ドキュメントを参照してください。

関連するコンテンツ

Azure Resource Manager デプロイ モデル: