Azure 仮想ネットワーク内のリソースの名前解決Name resolution for resources in Azure virtual networks

Azure を使用して IaaS、PaaS、ハイブリッド ソリューションをホストする方法によっては、仮想マシン (VM) と仮想ネットワーク内に配置されたその他のリソースが相互に通信できるようにする必要があります。Depending on how you use Azure to host IaaS, PaaS, and hybrid solutions, you might need to allow the virtual machines (VMs), and other resources deployed in a virtual network to communicate with each other. IP アドレスを使用して通信を行うこともできますが、簡単に記憶できて変更されない名前を使用する方が、はるかに簡単です。Although you can enable communication by using IP addresses, it is much simpler to use names that can be easily remembered, and do not change.

仮想ネットワーク内に配置されたリソースがドメイン名を内部 IP アドレスに解決する必要がある場合、次の 2 つの方法のいずれかを使用できます。When resources deployed in virtual networks need to resolve domain names to internal IP addresses, they can use one of two methods:

どちらの名前解決方法を使用するかは、リソースが互いに通信するために必要な方法によって決まります。The type of name resolution you use depends on how your resources need to communicate with each other. 次の表では、シナリオと対応する名前解決の方法を示します。The following table illustrates scenarios and corresponding name resolution solutions:

注意

シナリオに応じて、現在パブリック プレビュー段階の Azure DNS Private Zones 機能を使用することをお勧めします。Depending on your scenario, you may want to use the Azure DNS Private Zones feature, which is currently in Public Preview. 詳しくは、「プライベート ドメインに Azure DNS を使用する」をご覧ください。For more information, see Using Azure DNS for private domains.

シナリオScenario ソリューションSolution サフィックスSuffix
同じ仮想ネットワーク内に配置された VM 間、または同じクラウド サービス内の Azure クラウド サービスのロール インスタンス間での名前解決。Name resolution between VMs located in the same virtual network, or Azure Cloud Services role instances in the same cloud service. Azure DNS Private Zones または Azure で提供される名前解決Azure DNS Private Zones or Azure-provided name resolution ホスト名または FQDNHostname or FQDN
異なる仮想ネットワーク内の VM 間または異なるクラウドサービスのロール インスタンス間での名前解決。Name resolution between VMs in different virtual networks or role instances in different cloud services. Azure DNS Private Zones、または Azure で解決するために仮想ネットワーク間でクエリを転送する、ユーザーが管理する DNS サーバー (DNS プロキシ)。Azure DNS Private Zones or, Customer-managed DNS servers forwarding queries between virtual networks for resolution by Azure (DNS proxy). 独自の DNS サーバーを使用する名前解決」を参照してください。See Name resolution using your own DNS server. FQDN のみFQDN only
仮想ネットワーク統合を使用した Azure App Service (Web App、Function、Bot など) から同じ仮想ネットワーク上のロール インスタンスまたは VM への名前解決。Name resolution from an Azure App Service (Web App, Function, or Bot) using virtual network integration to role instances or VMs in the same virtual network. Azure で解決するために仮想ネットワーク間でクエリを転送する、ユーザーが管理する DNS サーバー (DNS プロキシ)。Customer-managed DNS servers forwarding queries between virtual networks for resolution by Azure (DNS proxy). 独自の DNS サーバーを使用する名前解決」を参照してください。See Name resolution using your own DNS server. FQDN のみFQDN only
App Service Web Apps から同じ仮想ネットワーク内の VM への名前解決。Name resolution from App Service Web Apps to VMs in the same virtual network. Azure で解決するために仮想ネットワーク間でクエリを転送する、ユーザーが管理する DNS サーバー (DNS プロキシ)。Customer-managed DNS servers forwarding queries between virtual networks for resolution by Azure (DNS proxy). 独自の DNS サーバーを使用する名前解決」を参照してください。See Name resolution using your own DNS server. FQDN のみFQDN only
ある仮想ネットワーク内の App Service Web Apps から異なる仮想ネットワーク内の VM への名前解決。Name resolution from App Service Web Apps in one virtual network to VMs in a different virtual network. Azure で解決するために仮想ネットワーク間でクエリを転送する、ユーザーが管理する DNS サーバー (DNS プロキシ)。Customer-managed DNS servers forwarding queries between virtual networks for resolution by Azure (DNS proxy). 「独自の DNS サーバーを使用する名前解決」を参照してください。See Name resolution using your own DNS server. FQDN のみFQDN only
Azure 内の VM またはロール インスタンスからのオンプレミスのコンピューターとサービスの名前解決。Resolution of on-premises computer and service names from VMs or role instances in Azure. ユーザーが管理する DNS サーバー (オンプレミスのドメイン コントローラー、ローカルの読み取り専用ドメイン コントローラー、ゾーン転送を使用して同期する DNS セカンダリなど)。Customer-managed DNS servers (on-premises domain controller, local read-only domain controller, or a DNS secondary synced using zone transfers, for example). 独自の DNS サーバーを使用する名前解決」を参照してください。See Name resolution using your own DNS server. FQDN のみFQDN only
オンプレミスのコンピューターからの Azure のホスト名の解決。Resolution of Azure hostnames from on-premises computers. 対応する仮想ネットワーク内のユーザーが管理する DNS プロキシ サーバーにクエリを転送し、プロキシ サーバーが解決するために Azure にクエリを転送します。Forward queries to a customer-managed DNS proxy server in the corresponding virtual network, the proxy server forwards queries to Azure for resolution. 独自の DNS サーバーを使用する名前解決」を参照してください。See Name resolution using your own DNS server. FQDN のみFQDN only
内部 IP 用の逆引き DNS。Reverse DNS for internal IPs. 独自の DNS サーバーを使用する名前解決Name resolution using your own DNS server. 適用不可Not applicable
仮想ネットワークではなく、異なるクラウド サービスに配置された VM またはロール インスタンス間での名前解決。Name resolution between VMs or role instances located in different cloud services, not in a virtual network. 適用不可。Not applicable. 異なるクラウド サービス内にある VM とロール インスタンス間の接続は、仮想ネットワークの外側ではサポートされません。Connectivity between VMs and role instances in different cloud services is not supported outside a virtual network. 適用不可Not applicable

Azure で提供される名前解決Azure-provided name resolution

Azure では、パブリック DNS 名の解決と共に、同じ仮想ネットワークまたはクラウド サービス内に存在する VM とロール インスタンス用に内部の名前解決が提供されます。Along with resolution of public DNS names, Azure provides internal name resolution for VMs and role instances that reside within the same virtual network or cloud service. クラウド サービス内の VM とインスタンスは、同じ DNS サフィックスを共有するため、ホスト名のみで十分です。VMs and instances in a cloud service share the same DNS suffix, so the host name alone is sufficient. ただし、クラシック デプロイ モデルを使用して展開された仮想ネットワークでは、クラウド サービスが異なると DNS サフィックスも異なります。But in virtual networks deployed using the classic deployment model, different cloud services have different DNS suffixes. このような状況では、異なるクラウド サービス間で名前を解決するために FQDN が必要になります。In this situation, you need the FQDN to resolve names between different cloud services. Azure Resource Manager デプロイ モデルを使用して展開された仮想ネットワークでは、DNS サフィックスは仮想ネットワーク間で一貫性があるため、FQDN は必要ありません。In virtual networks deployed using the Azure Resource Manager deployment model, the DNS suffix is consistent across the virtual network, so the FQDN is not needed. DNS 名は、VM とネットワーク インターフェイスの両方に割り当てることができます。DNS names can be assigned to both VMs and network interfaces. Azure 提供の名前解決ではどのような構成も必要ありませんが、前の表で詳しく説明したように、すべてのデプロイ シナリオに適しているわけではありません。Although Azure-provided name resolution does not require any configuration, it is not the appropriate choice for all deployment scenarios, as detailed in the previous table.

注意

クラウド サービスの Web ロールと Worker ロールを使用した場合、Azure Service Management REST API を使用して、ロール インスタンスの内部 IP アドレスにアクセスすることもできます。When using cloud services web and worker roles, you can also access the internal IP addresses of role instances using the Azure Service Management REST API. 詳細については、「サービス管理 REST API リファレンス」を参照してください。For more information, see the Service Management REST API Reference. アドレスは、ロール名とインスタンス数に基づきます。The address is based on the role name and instance number.

機能Features

Azure で提供される名前解決の機能を次に示します。Azure-provided name resolution includes the following features:

  • 使いやすさ。Ease of use. 構成は必要ありません。No configuration is required.
  • 高可用性:High availability. 独自の DNS サーバーのクラスターを作成および管理する必要はありません。You don't need to create and manage clusters of your own DNS servers.
  • このサービスは、オンプレミスと Azure の両方のホスト名を解決するために、独自の DNS サーバーと組み合わせて使用できます。You can use the service in conjunction with your own DNS servers, to resolve both on-premises and Azure host names.
  • 同じクラウド サービス内の VM とロール インスタンスの間で、FQDN を必要とすることなく名前解決を使用できます。You can use name resolution between VMs and role instances within the same cloud service, without the need for an FQDN.
  • Azure Resource Manager デプロイ モデルを使用する仮想ネットワーク内の VM 間では、FQDN を必要とすることなく名前解決を使用できます。You can use name resolution between VMs in virtual networks that use the Azure Resource Manager deployment model, without need for an FQDN. クラシック デプロイ モデルの仮想ネットワークの場合は、異なるクラウド サービスの名前を解決するときに FQDN が必要になります。Virtual networks in the classic deployment model require an FQDN when you are resolving names in different cloud services.
  • 自動生成される名前を使用するのではなく、デプロイの内容がよくわかるホスト名を使用できます。You can use host names that best describe your deployments, rather than working with auto-generated names.

考慮事項Considerations

Azure で提供される名前解決を使用する場合の考慮事項を次に示します。Points to consider when you are using Azure-provided name resolution:

  • Azure によって作成される DNS サフィックスは変更できません。The Azure-created DNS suffix cannot be modified.
  • 独自のレコードを手動で登録することはできません。You cannot manually register your own records.
  • WINS と NetBIOS はサポートされませんWINS and NetBIOS are not supported. Windows エクスプローラーに VM を表示することはできません。You cannot see your VMs in Windows Explorer.
  • ホスト名は DNS 互換である必要があります。Host names must be DNS-compatible. 名前に使用できる文字は 0-9、a-z、および "-" のみであり、最初または最後の文字として "-" は使用できません。Names must use only 0-9, a-z, and '-', and cannot start or end with a '-'.
  • DNS クエリ トラフィックは VM ごとに調整されます。DNS query traffic is throttled for each VM. 調整は、ほとんどのアプリケーションに影響がありません。Throttling shouldn't impact most applications. 要求の調整が発生した場合は、クライアント側のキャッシュが有効になっていることを確認します。If request throttling is observed, ensure that client-side caching is enabled. 詳細については、「DNS クライアントの構成」を参照してください。For more information, see DNS client configuration.
  • 最初の 180 のクラウド サービス内の VM だけが、クラシック デプロイ モデルの各仮想ネットワークに対して登録されます。Only VMs in the first 180 cloud services are registered for each virtual network in a classic deployment model. この制限は、Azure Resource Manager の仮想ネットワークには適用されません。This limit does not apply to virtual networks in Azure Resource Manager.
  • Azure DNS IP アドレスは 168.63.129.16 です。The Azure DNS IP address is 168.63.129.16. これは静的な IP アドレスであり、変更されません。This is a static IP address and will not change.

DNS クライアントの構成DNS client configuration

このセクションでは、クライアント側のキャッシュとクライアント側の再試行について説明します。This section covers client-side caching and client-side retries.

クライアント側のキャッシュClient-side caching

DNS クエリには、ネットワーク経由で送信する必要がないものもあります。Not every DNS query needs to be sent across the network. クライアント側のキャッシュは、ローカル キャッシュから繰り返される DNS クエリを解決することで、待ち時間を短縮し、ネットワークの停止に対する復元性を高めるのに役立ちます。Client-side caching helps reduce latency and improve resilience to network blips, by resolving recurring DNS queries from a local cache. DNS レコードには、有効期限 (TTL) メカニズムが含まれています。有効期限により、キャッシュは、レコードの鮮度に影響を与えずに、可能な限り長い時間レコードを格納できます。DNS records contain a time-to-live (TTL) mechanism, which allows the cache to store the record for as long as possible without impacting record freshness. このため、クライアント側のキャッシュはほとんどの状況に適しています。Thus, client-side caching is suitable for most situations.

既定の Windows DNS クライアントには、組み込みの DNS キャッシュがあります。The default Windows DNS client has a DNS cache built-in. Linux ディストリビューションの一部では、既定でキャッシュは含まれていません。Some Linux distributions do not include caching by default. ローカル キャッシュがまだ存在していない場合は、各 Linux VM に DNS キャッシュを追加します。If you find that there isn't a local cache already, add a DNS cache to each Linux VM.

多数のさまざまな DNS キャッシュ パッケージ (dnsmasq など) を使用できます。There are a number of different DNS caching packages available (such as dnsmasq). 最も一般的なディストリビューションに dnsmasq をインストールする方法を次に示します。Here's how to install dnsmasq on the most common distributions:

  • Ubuntu (resolvconf を使用) :Ubuntu (uses resolvconf):
    • sudo apt-get install dnsmasq を使用して dnsmasq パッケージをインストールします。Install the dnsmasq package with sudo apt-get install dnsmasq.
  • SUSE (netconf を使用) :SUSE (uses netconf):
    • sudo zypper install dnsmasq を使用して dnsmasq パッケージをインストールします。Install the dnsmasq package with sudo zypper install dnsmasq.
    • systemctl enable dnsmasq.service を使用して、dnsmasq サービスを有効にします。Enable the dnsmasq service with systemctl enable dnsmasq.service.
    • systemctl start dnsmasq.service を使用して、dnsmasq サービスを開始します。Start the dnsmasq service with systemctl start dnsmasq.service.
    • /etc/sysconfig/network/config を編集して、NETCONFIG_DNS_FORWARDER=""dnsmasq に変更します。Edit /etc/sysconfig/network/config, and change NETCONFIG_DNS_FORWARDER="" to dnsmasq.
    • netconfig update を使用して resolv.conf を更新し、キャッシュをローカル DNS リゾルバーとして設定します。Update resolv.conf with netconfig update, to set the cache as the local DNS resolver.
  • CentOS (NetworkManager を使用) :CentOS (uses NetworkManager):
    • sudo yum install dnsmasq を使用して dnsmasq パッケージをインストールします。Install the dnsmasq package with sudo yum install dnsmasq.
    • systemctl enable dnsmasq.service を使用して、dnsmasq サービスを有効にします。Enable the dnsmasq service with systemctl enable dnsmasq.service.
    • systemctl start dnsmasq.service を使用して、dnsmasq サービスを開始します。Start the dnsmasq service with systemctl start dnsmasq.service.
    • prepend domain-name-servers 127.0.0.1;/etc/dhclient-eth0.conf に追加します。Add prepend domain-name-servers 127.0.0.1; to /etc/dhclient-eth0.conf.
    • service network restart を使用してネットワーク サービスを再起動し、キャッシュをローカル DNS リゾルバーとして設定します。Restart the network service with service network restart, to set the cache as the local DNS resolver.

注意

dnsmasq パッケージは、Linux で使用可能な多くの DNS キャッシュの 1 つにすぎません。The dnsmasq package is only one of many DNS caches available for Linux. 使用する前に、目的とするニーズに適合するかどうかと、その他のキャッシュがインストールされていないことを確認してください。Before using it, check its suitability for your particular needs, and check that no other cache is installed.

クライアント側の再試行Client-side retries

DNS では、主に UDP プロトコルが使用されます。DNS is primarily a UDP protocol. UDP プロトコルでは、メッセージの配信が保証されないため、再試行ロジックは、DNS プロトコル自体で処理されます。Because the UDP protocol doesn't guarantee message delivery, retry logic is handled in the DNS protocol itself. 各 DNS クライアント (オペレーティング システム) では、作成者の選択に応じて、再試行ロジックが異なる場合があります。Each DNS client (operating system) can exhibit different retry logic, depending on the creator's preference:

  • Windows オペレーティング システムでは、1 秒後に再試行されます。その後、2 秒後、4 秒後に再試行され、さらにもう一度その 4 秒後に再試行されます。Windows operating systems retry after one second, and then again after another two seconds, four seconds, and another four seconds.
  • 既定の Linux の設定では、5 秒後に再試行されます。The default Linux setup retries after five seconds. 再試行の仕様を 1 秒間隔の 5 回に変更することをお勧めします。We recommend changing the retry specifications to five times, at one-second intervals.

cat /etc/resolv.conf を使用して、Linux VM の現在の設定を確認します。Check the current settings on a Linux VM with cat /etc/resolv.conf. options 行を調べます。以下に例を示します。Look at the options line, for example:

options timeout:1 attempts:5

resolv.conf ファイルは通常は自動生成され、編集すべきではありません。The resolv.conf file is usually auto-generated, and should not be edited. options 行を追加する具体的な手順は、ディストリビューションによって異なります。The specific steps for adding the options line vary by distribution:

  • Ubuntu (resolvconf を使用):Ubuntu (uses resolvconf):
    1. options 行を /etc/resolvconf/resolv.conf.d/tail に追加します。Add the options line to /etc/resolvconf/resolv.conf.d/tail.
    2. resolvconf -u を実行して更新します。Run resolvconf -u to update.
  • SUSE (netconf を使用):SUSE (uses netconf):
    1. timeout:1 attempts:5/etc/sysconfig/network/configNETCONFIG_DNS_RESOLVER_OPTIONS="" パラメーターに追加します。Add timeout:1 attempts:5 to the NETCONFIG_DNS_RESOLVER_OPTIONS="" parameter in /etc/sysconfig/network/config.
    2. netconfig update を実行して更新します。Run netconfig update to update.
  • CentOS (NetworkManager を使用):CentOS (uses NetworkManager):
    1. echo "options timeout:1 attempts:5"/etc/NetworkManager/dispatcher.d/11-dhclient に追加します。Add echo "options timeout:1 attempts:5" to /etc/NetworkManager/dispatcher.d/11-dhclient.
    2. service network restart を使用して更新します。Update with service network restart.

独自の DNS サーバーを使用する名前解決Name resolution that uses your own DNS server

このセクションでは、VM、ロール インスタンス、および Web アプリについて説明します。This section covers VMs, role instances, and web apps.

VM とロール インスタンスVMs and role instances

名前解決のニーズが、Azure で提供される機能の範囲を超えている場合があります。Your name resolution needs might go beyond the features provided by Azure. たとえば、Microsoft Windows Server Active Directory ドメインを使用して、仮想ネットワーク間で DNS 名を解決することが必要である場合があります。For example, you might need to use Microsoft Windows Server Active Directory domains, resolve DNS names between virtual networks. これらのシナリオを可能にするために、Azure では独自の DNS サーバーを使用する機能を提供します。To cover these scenarios, Azure provides the ability for you to use your own DNS servers.

仮想ネットワーク内の DNS サーバーは、Azure の再帰的リゾルバーに DNS クエリを転送できます。DNS servers within a virtual network can forward DNS queries to the recursive resolvers in Azure. これにより、その仮想ネットワーク内のホスト名を解決することができます。This enables you to resolve host names within that virtual network. たとえば、Azure で実行しているドメイン コントローラー (DC) は、そのドメインに対する DNS クエリに応答し、他のすべてのクエリを Azure に転送できます。For example, a domain controller (DC) running in Azure can respond to DNS queries for its domains, and forward all other queries to Azure. クエリを転送することで、VM はオンプレミスのリソース (DC 経由) と Azure で提供されるホスト名 (フォワーダー経由) の両方を参照できます。Forwarding queries allows VMs to see both your on-premises resources (via the DC) and Azure-provided host names (via the forwarder). Azure の再帰的リゾルバーへのアクセスは、仮想 IP 168.63.129.16 を通じて提供されます。Access to the recursive resolvers in Azure is provided via the virtual IP 168.63.129.16.

また、DNS の転送により、仮想ネットワーク間の DNS 解決も可能になり、オンプレミスのマシンが Azure で提供されるホスト名を解決できるようになります。DNS forwarding also enables DNS resolution between virtual networks, and allows your on-premises machines to resolve Azure-provided host names. VM のホスト名を解決するために、DNS サーバー VM は、同じ仮想ネットワークに存在し、Azure にホスト名のクエリを転送するように構成されている必要があります。In order to resolve a VM's host name, the DNS server VM must reside in the same virtual network, and be configured to forward host name queries to Azure. DNS サフィックスは仮想ネットワークごとに異なるため、条件付きの転送ルールを使用し、解決のために正しい仮想ネットワークに DNS クエリを送信します。Because the DNS suffix is different in each virtual network, you can use conditional forwarding rules to send DNS queries to the correct virtual network for resolution. 次の図は、2 つの仮想ネットワークと、この方法を使用して仮想ネットワーク間の DNS 解決を行うオンプレミスのネットワークを示しています。The following image shows two virtual networks and an on-premises network doing DNS resolution between virtual networks, by using this method. DNS フォワーダーの例は、Azure クイック スタート テンプレートのギャラリーGitHub で確認できます。An example DNS forwarder is available in the Azure Quickstart Templates gallery and GitHub.

注意

ロール インスタンスは、同じ仮想ネットワーク内の VM の名前解決を実行できます。A role instance can perform name resolution of VMs within the same virtual network. これは、VM のホスト名と internal.cloudapp.net DNS サフィックスで構成される FQDN を使用することで可能になります。It does so by using the FQDN, which consists of the VM's host name and internal.cloudapp.net DNS suffix. ただし、この場合、名前解決は、ロール インスタンスがロール スキーマ (.cscfg ファイル) に定義されている VM 名を持っている場合にのみ成功します。However, in this case, name resolution is only successful if the role instance has the VM name defined in the Role Schema (.cscfg file). <Role name="<role-name>" vmName="<vm-name>">

別の仮想ネットワーク内の VM の名前解決 (internal.cloudapp.net サフィックスを使用する FQDN) を実行する必要があるロール インスタンスは、このセクションで説明する方法 (2 つの仮想ネットワーク間で転送を行うカスタム DNS サーバー) を使用してこの操作を行う必要があります。Role instances that need to perform name resolution of VMs in another virtual network (FQDN by using the internal.cloudapp.net suffix) have to do so by using the method described in this section (custom DNS servers forwarding between the two virtual networks).

仮想ネットワーク間の DNS の図

Azure で提供される名前解決を使用している場合、Azure の動的ホスト構成プロトコル (DHCP) によって内部 DNS サフィックス ( .internal.cloudapp.net) が各 VM に提供されます。When you are using Azure-provided name resolution, Azure Dynamic Host Configuration Protocol (DHCP) provides an internal DNS suffix (.internal.cloudapp.net) to each VM. ホスト名のレコードは internal.cloudapp.net ゾーン内に存在するため、このサフィックスによってホスト名を解決できます。This suffix enables host name resolution because the host name records are in the internal.cloudapp.net zone. 独自の名前解決ソリューションを使用している場合、このサフィックスは他の DNS アーキテクチャ (ドメイン参加シナリオなど) に干渉するため、VM には提供されません。When you are using your own name resolution solution, this suffix is not supplied to VMs because it interferes with other DNS architectures (like domain-joined scenarios). 代わりに、Azure によって、機能を持たないプレース ホルダー (reddog.microsoft.com) が提供されます。Instead, Azure provides a non-functioning placeholder (reddog.microsoft.com).

必要に応じて、PowerShell または API を使用して、内部 DNS サフィックスを調べることができます。If necessary, you can determine the internal DNS suffix by using PowerShell or the API:

Azure へのクエリの転送がニーズに合わない場合は、独自の DNS ソリューションを提供する必要があります。If forwarding queries to Azure doesn't suit your needs, you should provide your own DNS solution. DNS 解決では次を行う必要があります。Your DNS solution needs to:

  • たとえば、DDNS 経由で、適切なホスト名解決を提供する。Provide appropriate host name resolution, via DDNS, for example. DDNS を使用するときは DNS レコードの清掃を無効にすることが必要になる場合があります。If you are using DDNS, you might need to disable DNS record scavenging. Azure の DHCP リースが長く、清掃によって、完了前に DNS レコードが削除されることがあります。Azure DHCP leases are long, and scavenging might remove DNS records prematurely.
  • 適切な再帰的解決を提供し、外部ドメイン名の解決を可能にする。Provide appropriate recursive resolution to allow resolution of external domain names.
  • 対象のクライアントからのアクセスを可能にし (ポート 53 の TCP および UDP)、インターネットへのアクセスを可能にする。Be accessible (TCP and UDP on port 53) from the clients it serves, and be able to access the internet.
  • 外部エージェントによる脅威を軽減するために、インターネットからのアクセスをセキュリティ保護する。Be secured against access from the internet, to mitigate threats posed by external agents.

注意

最高のパフォーマンスを得るには、Azure VM を DNS サーバーとして使用するときに IPv6 を無効にする必要があります。For best performance, when you are using Azure VMs as DNS servers, IPv6 should be disabled. パブリック IP アドレスを各 DNS サーバーの VM に割り当てる必要があります。A public IP address should be assigned to each DNS server VM. Windows Server を DNS サーバーとして使用したときの追加のパフォーマンスの分析と最適化については、再帰的な Windows DNS Server 2012 R2 の名前解決のパフォーマンスに関する記事を参照してください。For additional performance analysis and optimizations when you are using Windows Server as your DNS server, see Name resolution performance of a recursive Windows DNS Server 2012 R2.

Web AppsWeb apps

仮想ネットワークにリンクされた App Service を使用して構築された Web アプリから同じ仮想ネットワーク内の VM への名前解決を実行する必要があるとします。Suppose you need to perform name resolution from your web app built by using App Service, linked to a virtual network, to VMs in the same virtual network. Azure (仮想 IP 168.63.129.16) にクエリを転送する DNS フォワーダーがあるカスタム DNS サーバーを設定することに加え、次の手順を実行します。In addition to setting up a custom DNS server that has a DNS forwarder that forwards queries to Azure (virtual IP 168.63.129.16), perform the following steps:

  1. 既に実行していなければ、仮想ネットワークへのアプリの統合に関するページの説明に従って、Web アプリに対する仮想ネットワークの統合を有効にします。Enable virtual network integration for your web app, if not done already, as described in Integrate your app with a virtual network.

  2. Azure Portal で、Web アプリをホストしている App Service プランで、 [ネットワーキング][Virtual Network 統合] の下の [ネットワークの同期] を選択します。In the Azure portal, for the App Service plan hosting the web app, select Sync Network under Networking, Virtual Network Integration.

    仮想ネットワークの名前解決のスクリーンショット

仮想ネットワークにリンクされている App Service を使用してビルドされた Web アプリから別の仮想ネットワーク内の VM への名前解決を行う必要がある場合は、次のように、両方の仮想ネットワークでカスタム DNS サーバーを使用する必要があります。If you need to perform name resolution from your web app built by using App Service, linked to a virtual network, to VMs in a different virtual network, you have to use custom DNS servers on both virtual networks, as follows:

  • クエリを Azure の再帰的リゾルバー (仮想 IP 168.63.129.16) に転送することもできる VM 上のターゲット仮想ネットワーク内に DNS サーバーを設定します。Set up a DNS server in your target virtual network, on a VM that can also forward queries to the recursive resolver in Azure (virtual IP 168.63.129.16). DNS フォワーダーの例は、Azure クイック スタート テンプレートのギャラリーGitHub で確認できます。An example DNS forwarder is available in the Azure Quickstart Templates gallery and GitHub.
  • VM 上のソース仮想ネットワーク内に DNS フォワーダーを設定します。Set up a DNS forwarder in the source virtual network on a VM. この DNS フォワーダーを、ターゲット仮想ネットワーク内の DNS サーバーにクエリを転送するように構成します。Configure this DNS forwarder to forward queries to the DNS server in your target virtual network.
  • ソース仮想ネットワークの設定内にソース DNS サーバーを構成します。Configure your source DNS server in your source virtual network’s settings.
  • 仮想ネットワークへのアプリの統合に関するページの指示に従って、ソース仮想ネットワークにリンクする App Service Web App に対する仮想ネットワークの統合を有効にします。Enable virtual network integration for your web app to link to the source virtual network, following the instructions in Integrate your app with a virtual network.
  • Azure Portal で、Web アプリをホストしている App Service プランで、 [ネットワーキング][Virtual Network 統合] の下の [ネットワークの同期] を選択します。In the Azure portal, for the App Service plan hosting the web app, select Sync Network under Networking, Virtual Network Integration.

DNS サーバーの指定Specify DNS servers

独自の DNS サーバーを使用する場合、Azure では、仮想ネットワークごとに複数の DNS サーバーを指定できます。When you are using your own DNS servers, Azure provides the ability to specify multiple DNS servers per virtual network. また、ネットワーク インターフェイス (Azure Resource Manager の場合) またはクラウド サービス (クラシック デプロイ モデルの場合) ごとに複数の DNS サーバーを指定することもできます。You can also specify multiple DNS servers per network interface (for Azure Resource Manager), or per cloud service (for the classic deployment model). ネットワーク インターフェイスまたはクラウド サービスに対して指定された DNS サーバーは、仮想ネットワークに対して指定された DNS サーバーよりも優先されます。DNS servers specified for a network interface or cloud service get precedence over DNS servers specified for the virtual network.

注意

DNS サーバーの IP などのネットワーク接続プロパティは、Windows VM 内で直接編集しないでください。Network connection properties, such as DNS server IPs, should not be edited directly within Windows VMs. これは、仮想ネットワーク アダプターを交換したときのサービス回復時にネットワーク接続プロパティが消去される可能性があるためです。This is because they might get erased during service heal when the virtual network adaptor gets replaced.

Azure Resource Manager デプロイ モデルを使用している場合は、仮想ネットワークとネットワーク インターフェイス用の DNS サーバーを指定できます。When you are using the Azure Resource Manager deployment model, you can specify DNS servers for a virtual network and a network interface. 詳細については、仮想ネットワークの管理に関するページとネットワーク インターフェイスの管理に関するページを参照してください。For details, see Manage a virtual network and Manage a network interface.

注意

仮想ネットワークのカスタムの DNS サーバーを選択する場合は、DNS サーバーの少なくとも 1 つの IP アドレスを指定する必要があります。そうしないと、仮想ネットワークは構成を無視し、代わりに Azure で提供される DNS を使用します。If you opt for custom DNS server for your virtual network, you must specify at least one DNS server IP address; otherwise, virtual network will ignore the configuration and use Azure-provided DNS instead.

クラシック デプロイ モデルを使用している場合は、Azure Portal またはネットワーク構成ファイルを使用して仮想ネットワークの DNS サーバーを指定できます。When you are using the classic deployment model, you can specify DNS servers for the virtual network in the Azure portal or the Network Configuration file. クラウド サービスでは、DNS サーバーは、サービス構成ファイルまたは PowerShell (New-AzureVM) を使用して指定できます。For cloud services, you can specify DNS servers via the Service Configuration file or by using PowerShell, with New-AzureVM.

注意

既にデプロイされている仮想ネットワークまたは仮想マシンの DNS 設定を変更した場合、変更を有効にするには、関係する各 VM を再起動する必要があります。If you change the DNS settings for a virtual network or virtual machine that is already deployed, you need to restart each affected VM for the changes to take effect.

次の手順Next steps

Azure Resource Manager デプロイ モデル:Azure Resource Manager deployment model:

クラシック デプロイ モデル:Classic deployment model: