Azure 가상 네트워크의 리소스 이름 확인

  • 아티클

주의

이 문서에서는 EOL(수명 종료) 상태에 가까워진 Linux 배포판인 CentOS를 참조하세요. 이에 따라 사용 및 플랜을 고려하세요. 자세한 내용은 CentOS 수명 종료 지침을 참조하세요.

Azure를 사용하여 IaaS, PaaS 및 하이브리드 솔루션을 호스트할 수 있습니다. VM(가상 머신)과 가상 네트워크에 배포된 기타 리소스 간의 통신을 용이하게 하기 위해 서로 통신할 수 있도록 허용해야 할 수도 있습니다. 쉽게 기억되고 변하지 않는 이름을 사용하면 통신 프로세스가 IP 주소를 사용할 필요 없이 간소화됩니다.

가상 네트워크에 배포된 리소스가 도메인 이름으로 내부 IP 주소를 확인하는 방법은 다음의 네 가지가 있습니다.

어떤 방법으로 이름을 확인할지는 사용하는 리소스가 서로 어떻게 통신해야 하는지에 따라 다릅니다. 다음 표에 각 시나리오 별로 해당하는 이름 확인 방법이 나와 있습니다.

참고 항목

Azure DNS 프라이빗 영역은 기본 설정 솔루션이며 DNS 영역 및 레코드를 유연하게 관리할 수 있도록 합니다. 자세한 내용은 프라이빗 도메인에 Azure DNS 사용을 참조하세요.

참고 항목

Azure에서 제공하는 DNS를 사용하는 경우 적절한 DNS 접미사가 가상 머신에 자동으로 적용됩니다. 다른 모든 옵션에 대해 FQDN(정규화된 도메인 이름)을 사용하거나 가상 머신에 적절한 DNS 접미사를 수동으로 적용해야 합니다.

시나리오 솔루션 DNS 접미사
동일한 클라우드 서비스의 Azure Cloud Services 역할 인스턴스 또는 동일한 가상 네트워크에 위치한 VM 간 이름을 확인합니다. Azure DNS 프라이빗 영역 또는 Azure 제공 이름 확인 호스트 이름 또는 FQDN
다른 클라우드 서비스의 역할 인스턴스 또는 다른 가상 네트워크의 VM 간 이름을 확인합니다. Azure(DNS 프록시)에서 이름을 확인할 수 있도록 가상 머신 간에 쿼리를 전달하는 Azure DNS 프라이빗 영역, Azure DNS Private Resolver 또는 고객이 관리하는 DNS 서버 자체 DNS 서버를 이용한 이름 확인. FQDN만
동일한 가상 네트워크에 있는 VM 또는 역할 인스턴스에 대한 가상 네트워크 통합을 사용하여 Azure App Service(웹앱, 함수, 봇)에서 이름을 확인합니다. Azure(DNS 프록시)에서 이름을 확인할 수 있도록 가상 머신 간에 쿼리를 전달하는 Azure DNS Private Resolver 또는 고객이 관리하는 DNS 서버 자체 DNS 서버를 이용한 이름 확인. FQDN만
App Service Web Apps로부터 동일한 가상 네트워크의 VM에 대한 이름을 확인합니다. Azure(DNS 프록시)에서 이름을 확인할 수 있도록 가상 머신 간에 쿼리를 전달하는 Azure DNS Private Resolver 또는 고객이 관리하는 DNS 서버 자체 DNS 서버를 이용한 이름 확인. FQDN만
한 가상 네트워크의 App Service Web Apps로부터 다른 가상 네트워크의 VM까지 이름을 확인합니다. Azure(DNS 프록시)에서 이름을 확인할 수 있도록 가상 머신 간에 쿼리를 전달하는 Azure DNS Private Resolver 또는 고객이 관리하는 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 솔루션이 가상 네트워크에 필요한 경우 고객 관리형 DNS 서버 또는 Azure DNS Private Resolver에서 Azure DNS 프라이빗 영역을 사용할 수 있습니다.

Azure에서는 공용 DNS 이름 확인과 함께, 동일한 가상 네트워크 또는 클라우드 서비스 내에 있는 VM 및 역할 인스턴스에 대한 내부 이름 확인을 제공합니다. 클라우드 서비스의 VM 및 인스턴스는 동일한 DNS 접미사를 공유하므로 호스트 이름만으로 충분합니다. 그러나 클래식 배포 모델을 사용하여 배표된 가상 네트워크에서는 클라우드 서비스마다 다른 DNS 접미사를 사용합니다. 이 경우 서로 다른 클라우드 서비스 간 이름 확인을 위해 FQDN이 필요합니다. Azure Resource Manager 배포 모델을 사용하여 배포된 가상 네트워크에서는 DNS 접미사가 가상 네트워크 내의 모든 가상 머신에서 일관되므로 FQDN이 필요하지 않습니다. DNS 이름은 VM 및 네트워크 인터페이스 모두에 할당할 수 있습니다. Azure에서 제공하는 이름 확인은 구성할 필요가 없지만, 앞의 표에서 자세한 설명한 대로 모든 배포 서비스에 적합한 선택이 아닙니다.

참고 항목

클라우드 서비스 웹 역할 및 작업자 역할을 사용할 때 Azure 서비스 관리 REST API를 사용하면 역할 인스턴스의 내부 IP 주소에 액세스할 수도 있습니다. 자세한 내용은 서비스 관리 REST API 참조를 참조하세요. 주소는 역할 이름 및 인스턴스 번호를 기반으로 합니다.

기능

Azure 제공 이름 확인에는 다음과 같은 기능이 포함됩니다.

  • 사용 편의성 구성이 필요하지 않습니다.

  • 고가용성. 자체 DNS 서버 클러스터를 만들고 관리할 필요가 없습니다.

  • 사용자 고유의 DNS 서버에서 이 서비스를 사용하여 온-프레미스 및 Azure 호스트 이름을 모두 확인할 수 있습니다.

  • 동일한 클라우드 서비스 내에서 역할 인스턴스 및 VM 간 이름 확인을 사용할 수 있으며 FQDN은 필요하지 않습니다.

  • Azure Resource Manager 배포 모델을 사용하는 가상 네트워크에서 VM 간에 이름 확인을 사용할 수 있으며 FQDN은 필요하지 않습니다. 클래식 배포 모델의 가상 네트워크에는 다양한 클라우드 서비스에서 이름을 확인할 때 FQDN이 필요합니다.

  • 자동으로 생성된 이름 대신 배포를 가장 잘 설명하는 호스트 이름을 사용할 수 있습니다.

고려 사항

Azure 제공하는 이름 확인을 사용할 때 고려해야 할 사항은 다음과 같습니다.

  • Azure에서 만든 DNS 접미사는 수정할 수 없습니다.

  • DNS 조회 범위는 가상 네트워크로 지정됩니다. 한 가상 네트워크에 대해 생성된 DNS 이름은 다른 가상 네트워크에서 확인할 수 없습니다.

  • 사용자 고유의 레코드는 수동으로 등록할 수 없습니다.

  • WINS 및 NetBIOS가 지원되지 않습니다. VM이 Windows 탐색기에 표시되지 않습니다.

  • 호스트 이름은 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을 시작할 때 자동으로 추가되고 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

internal.cloudapp.net 역방향 DNS 영역은 Azure에서 관리되며 직접 보거나 편집할 수 없습니다. [vmname].internal.cloudapp.net 형식의 FQDN에 대한 정방향 조회는 가상 머신에 할당된 IP 주소로 확인됩니다.

Azure DNS 프라이빗 영역이 가상 네트워크 링크를 통해 가상 네트워크에 연결되고 해당 링크에서 자동 등록이 사용하도록 설정된 경우 역방향 DNS 쿼리는 두 개의 레코드를 반환합니다. 한 레코드는 [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

이전과 같이 두 개의 PTR 레코드가 반환되면 FQDN 중 하나를 정방향 조회하면 VM의 IP 주소가 반환됩니다.

역방향 DNS 조회는 다른 가상 네트워크에 피어링되는 경우에도 범위가 지정된 가상 네트워크로 지정됩니다. 피어링된 가상 네트워크에 있는 가상 머신의 IP 주소에 대한 역방향 DNS 쿼리는 NXDOMAIN을 반환합니다.

참고 항목

역방향 DNS(PTR) 레코드는 정방향 프라이빗 DNS 영역에 저장되지 않습니다. 역방향 DNS 레코드는 역방향 DNS(in-addr.arpa) 영역에 저장됩니다. vnet과 연결된 기본 역방향 DNS 영역은 보거나 편집할 수 없습니다.

Azure DNS 프라이빗 영역을 사용하여 사용자 고유의 역방향 조회 영역을 만든 다음, 이 영역을 가상 네트워크에 연결하여 가상 네트워크에서 역방향 DNS 기능을 사용하지 않도록 설정할 수 있습니다. 예를 들어 가상 네트워크의 IP 주소 공간이 10.20.0.0/16인 경우 빈 20.10.in-addr.arpa 프라이빗 DNS 영역을 만들어 가상 네트워크에 연결할 수 있습니다. 이 영역은 가상 네트워크에 대한 기본 역방향 조회 영역을 재정의합니다. 이 영역은 비어 있습니다. 이러한 항목을 수동으로 만드는 경우를 제외하고는 역방향 DNS에서 NXDOMAIN을 반환합니다.

PTR 레코드의 자동 등록은 지원되지 않습니다. 항목을 만들려면 수동으로 입력합니다. 자동 등록이 다른 영역에 사용하도록 설정된 경우 가상 네트워크에서 자동 등록을 사용하지 않도록 설정해야 합니다. 이 제한은 자동 등록이 사용하도록 설정된 경우 하나의 프라이빗 영역만 연결되도록 허용하는 제한 사항으로 인해 발생합니다. 프라이빗 DNS 영역을 만들고 이를 가상 네트워크에 연결하는 방법에 대한 자세한 내용은 프라이빗 DNS 빠른 시작 가이드를 참조하세요.

참고 항목

Azure DNS 프라이빗 영역은 전역이므로 여러 가상 네트워크에 걸쳐 있는 역방향 DNS 조회를 만들 수 있습니다. 이렇게 하려면 역방향 조회를 위한 Azure DNS 프라이빗 영역(in-addr.arpa 영역)을 만들고 이를 가상 네트워크에 연결합니다. VM에 대한 역방향 DNS 레코드는 수동으로 관리해야 합니다.

DNS 클라이언트 구성

이 섹션에서는 클라이언트 쪽 캐싱 및 클라이언트 쪽 재시도에 대해 설명합니다.

클라이언트 쪽 캐싱

모든 DNS 쿼리를 네트워크를 통해 전송해야 하는 것은 아닙니다. 클라이언트 쪽 캐싱을 사용하면 대기 시간을 줄이고 로컬 캐시에서 되풀이되는 DNS 쿼리를 확인하여 네트워크 블립에 대한 복원력을 개선하는 데 도움이 됩니다. DNS 레코드는 레코드 새로 고침에 영향을 주지 않으면서 캐시가 가능한 오랫동안 레코드를 저장할 수 있도록 하는 TTL(Time-To-Live) 메커니즘을 포함합니다. 따라서 클라이언트 쪽 캐싱은 대부분의 상황에 적합합니다.

기본 Windows DNS 클라이언트에는 기본 제공되는 DNS 캐시가 있습니다. 일부 Linux 배포판에는 기본적으로 캐싱이 포함되지 않습니다. 로컬 캐시가 아직 없다는 것을 확인한 후에는 각 Linux VM에 DNS 캐시를 추가합니다.

사용할 수 있는 다양한 DNS 캐싱 패키지가 있습니다(예: dnsmasq). 다음은 가장 일반적인 배포판에 dnsmasq를 설치하는 방법입니다.

RHEL/CentOS(NetworkManager 사용):

  1. 다음 명령을 사용하여 dnsmasq 패키지를 설치합니다.

    sudo yum install dnsmasq

  2. 다음 명령을 사용하여 dnsmasq 서비스를 사용하도록 설정합니다.

    systemctl enable dnsmasq.service

  3. 다음 명령을 사용하여 dnsmasq 서비스를 시작합니다.

    systemctl start dnsmasq.service

  4. 텍스트 편집기를 사용하여 prepend domain-name-servers 127.0.0.1;을 /etc/dhclient-eth0.conf에 추가합니다.

  5. 다음 명령을 사용하여 네트워크 서비스를 다시 시작합니다.

    service network restart

참고 항목

dnsmasq 패키지는 여러 DNS 캐시 중에 Linux에 사용할 수 있는 유일한 캐시입니다. 사용하기 전에 특정 요구 사항에 대한 적합성을 확인하고 다른 캐시가 설치되어 있지 않은지 확인합니다.

클라이언트쪽 재시도

DNS는 주로 UDP 프로토콜입니다. UDP 프로토콜은 메시지 배달을 보장하지 않으므로 DNS 프로토콜 자체에서 재시도 논리가 처리됩니다. 각 DNS 클라이언트(운영 체제)는 작성자의 기본 설정에 따라 서로 다른 재시도 논리를 나타낼 수 있습니다.

  • Windows 운영 체제는 1초 후 재시도한 후 2초, 4초 후 다시 재시도하고 또 다시 4초 후 재시도합니다.
  • 기본 Linux 설정에서는 5초 후 재시도합니다. 다시 시도 사양을 1초 간격으로 다섯 번으로 변경하는 것이 좋습니다.

cat /etc/resolv.conf를 통해 Linux VM의 현재 설정을 확인합니다. 예를 들어 options 줄을 살펴봅니다.

options timeout:1 attempts:5

resolv.conf 파일은 자동으로 생성되며 편집할 수 없습니다. options 줄을 추가하는 구체적인 단계는 배포마다 다릅니다.

RHEL/CentOS(NetworkManager 사용):

  1. 텍스트 편집기를 사용하여 RES_OPTIONS="options timeout:1 attempts:5" 줄을 /etc/sysconfig/network-scripts/ifcfg-eth0 파일에 추가합니다.

  2. 다음 명령을 사용하여 NetworkManager 서비스를 다시 시작합니다.

    systemctl restart NetworkManager.service

자체 DNS 서버를 사용하는 이름 확인

이 섹션에서는 VM, 역할 인스턴스 및 웹앱에 대해 설명합니다.

참고 항목

Azure DNS Private Resolver는 가상 네트워크에서 VM 기반 DNS 서버를 사용해야 하는 필요성을 대체합니다. VM 기반 DNS 솔루션을 사용하려는 경우 다음 섹션이 제공되지만 비용 절감, 기본 제공 고가용성, 확장성 및 유연성을 포함하여 Azure DNS Private Resolver 사용에 많은 이점이 있습니다.

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을 통해 제공됩니다.

Important

VNet의 사용자 지정 DNS 서버 IP와 함께 이 설정에서 VPN Gateway를 사용하는 경우 중단 없는 서비스를 유지하려면 Azure DNS IP(168.63.129.16)도 목록에 추가해야 합니다.

또한 DNS 전달로 가상 네트워크 간 DNS 확인이 가능하며 온-프레미스 컴퓨터는 Azure에서 제공하는 호스트 이름을 확인할 수 있습니다. VM의 호스트 이름을 확인하려면 DNS 서버 VM이 동일한 가상 네트워크에 있어야 하며 Azure에 호스트 이름 쿼리를 전달하도록 구성되어야 합니다. DNS 접미사는 가상 네트워크마다 다르기 때문에 올바른 가상 네트워크에 DNS 쿼리를 보내도록 조건부 전달 규칙을 사용하여 이름을 확인할 수 있습니다. 다음 이미지는 이 방법을 사용하여 가상 네트워크 간에 DNS를 확인하는 두 가상 네트워크 및 온-프레미스 네트워크를 보여 줍니다. 예제 DNS 전달자는 Azure 빠른 시작 템플릿 갤러리 및 GitHub에서 사용할 수 있습니다.

참고 항목

역할 인스턴스는 동일한 가상 네트워크 내에서 VM의 이름 확인을 수행할 수 있습니다. 이를 위해 VM의 호스트 이름과 internal.cloudapp.net DNS 접미사로 구성되는 FQDN을 사용하면 됩니다. 그러나 이 경우 역할 인스턴스가 역할 스키마(.cscfg 파일)에서 정의된 이름을 가지는 경우에만 이름 확인에 성공합니다. <Role name="<role-name>" vmName="<vm-name>">

다른 가상 네트워크(internal.cloudapp.net 접미사를 사용하는 FQDN)에서 VM 이름 확인을 수행해야 하는 역할 인스턴스는 이 섹션(두 가상 네트워크 간의 사용자 지정 DNS 서버 전달)에 설명된 방법을 사용하여 이 작업을 수행해야 합니다.

가상 네트워크 간의 DNS 다이어그램

Azure에서 제공하는 이름 확인을 사용하는 경우 Azure DHCP(Dynamic Host Configuration Protocol)에서 내부 DNS 접미사(.internal.cloudapp.net)를 각 VM에 제공합니다. 호스트 이름 레코드가 internal.cloudapp.net 영역에 있으므로 이 접미사를 통해 호스트 이름 확인을 수행할 수 있습니다. 사용자 고유의 이름 확인 솔루션을 사용하는 경우 이 접미사는 다른 DNS 아키텍처(예: 도메인 조인 시나리오)를 방해하므로 VM에 제공되지 않습니다. 대신 Azure에서 작동하지 않는 자리 표시자(reddog.microsoft.com)를 제공합니다.

필요한 경우 PowerShell 또는 API를 사용하여 내부 DNS 접미사를 확인할 수 있습니다.

쿼리를 Azure에 전달하는 것이 요구 사항에 적합하지 않은 경우 사용자 고유의 DNS 솔루션을 제공하거나 Azure DNS Private Resolver를 배포합니다.

사용자 고유 DNS 솔루션을 제공하는 경우 다음을 수행해야 합니다.

  • DDNS 등을 통해 적절한 호스트 이름 확인을 제공합니다. DDNS를 사용하는 경우 DNS 레코드 청소 기능을 해제해야 할 수도 있습니다. Azure DHCP 임대는 기간이 매우 길며 청소를 통해 DNS 레코드가 완전히 제거될 수 있습니다.

  • 외부 도메인 이름을 확인할 수 있도록 적절한 재귀 확인을 제공해야 합니다.

  • 제공하는 클라이언트에서 액세스 가능해야 하고(포트 53에서 TCP 및 UDP) 인터넷에 액세스할 수 있어야 합니다.

  • 외부 에이전트로 인해 나타나는 위험을 완화하기 위해 인터넷의 액세스로부터 보호되어야 합니다.

참고 항목

  • 최상의 성능을 위해 Azure VM을 DNS 서버로 사용하는 경우 IPv6를 사용하지 않도록 설정해야 합니다.
  • NSG는 DNS 확인자 엔드포인트에 대한 방화벽 역할을 합니다. UDP 포트 53(및 필요에 따라 TCP 포트 53)의 DNS 수신기 엔드포인트에 대한 액세스를 허용하도록 NSG 보안 규칙을 수정하거나 재정의해야 합니다. 사용자 지정 DNS 서버가 네트워크에 설정되면 포트 53을 지나는 트래픽이 서브넷의 NSG를 우회합니다.

Important

Azure DNS 서버에 DNS 요청을 전달하는 사용자 지정 DNS 서버로 Windows DNS Server를 사용하는 경우 Azure Recursive DNS Server가 적절한 재귀 작업을 수행할 수 있도록 전달 시간 제한 값을 4초 이상 늘려야 합니다.

이 문제에 대한 자세한 내용은 전달자 및 조건부 전달자 확인 시간 제한을 참조 하세요.

이 권장 사항은 전달 시간 제한 값이 3초 이하인 다른 DNS 서버 플랫폼에도 적용될 수 있습니다.

이렇게 하지 않으면 프라이빗 DNS 영역 레코드가 공용 IP 주소로 확인될 수 있습니다.

웹앱

가상 네트워크 또는 동일한 가상 네트워크의 VM에 연결된 App Service를 사용하여 빌드된 웹앱에서 이름 확인을 수행해야 한다고 가정합니다. Azure(가상 IP 168.63.129.16)로 쿼리를 전달하는 DNS 전달자가 있는 사용자 지정 DNS 서버를 설정하는 것 외에 다음 단계를 수행합니다.

가상 네트워크와 앱 통합에서 설명한 대로 웹앱에 대해 가상 네트워크 통합을 사용하도록 설정합니다(아직 수행하지 않은 경우).

이름 확인을 vnet 연결 웹앱(App Service를 사용하여 빌드됨)에서 동일한 프라이빗 영역에 연결되지 않은 다른 vnet의 VM으로 수행해야 하는 경우 두 vnet 모두에서 사용자 지정 DNS 서버 또는 Azure DNS Private Resolvers를 사용합니다.

사용자 지정 DNS 서버를 사용하려면 다음을 수행합니다.

  • Azure의 재귀 확인자(가상 IP 168.63.129.16)에도 쿼리를 전달할 수 있는 VM에서 대상 가상 네트워크에 DNS 서버를 설정합니다. 예제 DNS 전달자는 Azure 빠른 시작 템플릿 갤러리 및 GitHub에서 사용할 수 있습니다.

  • VM에서 원본 가상 네트워크의 DNS 전달자를 설정합니다. 대상 가상 네트워크의 DNS 서버로 쿼리를 전달하도록 이 DNS 전달자를 구성합니다.

  • 원본 가상 네트워크의 설정에 원본 DNS 서버를 구성합니다.

  • 가상 네트워크와 앱 통합의 지침에 따라 원본 가상 네트워크에 웹앱을 연결하기 위해 가상 네트워크 통합을 사용하도록 설정합니다.

Azure DNS Private Resolver를 사용하려면 규칙 집합 링크를 참조하세요.

DNS 서버 지정

사용자 고유의 DNS 서버를 사용하는 경우 Azure를 통해 가상 네트워크당 여러 DNS 서버를 지정할 수 있습니다. 또한 네트워크 인터페이스(Azure Resource Manager용) 또는 클라우드 서비스(클래식 배포 모델)당 여러 DNS 서버를 지정할 수도 있습니다. 네트워크 인터페이스 또는 클라우드 서비스에 대해 지정된 DNS 서버가 가상 네트워크에 대해 지정된 서버보다 우선적으로 사용됩니다.

참고 항목

DNS 서버 IP와 같은 네트워크 연결 속성은 VM 내에서 직접 편집하지 않는 것이 좋습니다. 가상 네트워크 어댑터가 교체될 때 서비스 복구 동안 지워질 수 있기 때문입니다. 이 내용은 Windows 및 Linux VM 둘 다에 적용됩니다.

Azure Resource Manager 배포 모델을 사용하는 경우 가상 네트워크 및 가상 인터페이스에 대한 DNS 서버를 지정할 수 있습니다. 자세한 내용은 가상 네트워크 관리 및 네트워크 인터페이스 관리를 참조합니다.

참고 항목

가상 네트워크에 사용자 지정 DNS 서버를 포함하려는 경우에는 DNS 서버 IP 주소를 하나 이상 지정해야 합니다. 이렇게 하지 않으면 가상 네트워크에서 구성을 무시하고 Azure에서 제공하는 DNS를 대신 사용합니다.

참고 항목

이미 배포된 가상 네트워크 또는 가상 머신에 대한 DNS 설정을 변경하는 경우 새 DNS 설정을 적용하려면 가상 네트워크에서 영향을 받는 모든 VM에 대해 DHCP 임대 갱신을 수행해야 합니다. Windows OS를 실행하는 VM의 경우 VM에 직접 ipconfig /renew를 입력하여 이 작업을 수행할 수 있습니다. 단계는 OS에 따라 다릅니다. 해당 OS 유형에 대한 관련 설명서를 참조하세요.

다음 단계

Azure Resource Manager 배포 모델: