다음을 통해 공유

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

  • 아티클

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

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

어떤 방법으로 이름을 확인할지는 사용하는 리소스가 서로 어떻게 통신해야 하는지에 따라 다릅니다. 다음 표에서는 시나리오 및 해당 이름 확인 솔루션을 보여 줍니다.

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

참고 항목

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

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

Azure에서는 공용 DNS 이름 확인과 함께, 동일한 가상 네트워크 또는 클라우드 서비스 내에 있는 VM 및 역할 인스턴스에 대한 내부 이름 확인을 제공합니다. 클라우드 서비스의 VM 및 인스턴스는 동일한 DNS 접미사를 공유하므로 호스트 이름만으로도 충분합니다. 그러나 클래식 배포 모델을 사용하여 배포된 가상 네트워크에서는 다른 클라우드 서비스에 서로 다른 DNS 접미사가 있습니다. 이 경우 서로 다른 클라우드 서비스 간 이름 확인을 위해 FQDN이 필요합니다.

Azure Resource Manager 배포 모델을 사용하여 배포된 가상 네트워크에서 DNS 접미사는 가상 네트워크 내의 모든 VM에서 일관되므로 FQDN이 필요하지 않습니다. VM 및 네트워크 인터페이스 모두에 DNS 이름을 할당할 수 있습니다. Azure에서 제공하는 이름 확인에는 구성이 필요하지 않지만 이전 표에 설명된 대로 모든 배포 시나리오에 적합한 선택은 아닙니다.

참고 항목

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

기능

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

  • 아무것도 구성할 필요가 없습니다.
  • 고가용성으로 인해 자체 DNS 서버의 클러스터를 만들고 관리할 필요가 없습니다.
  • 자체 DNS 서버와 함께 서비스를 사용하여 온-프레미스 및 Azure 호스트 이름을 모두 확인할 수 있습니다.
  • 동일한 클라우드 서비스 내에서 역할 인스턴스 및 VM 간 이름 확인을 사용할 수 있으며 FQDN은 필요하지 않습니다.
  • FQDN 없이 Resource Manager 배포 모델을 사용하는 가상 네트워크의 VM 간에 이름 확인을 사용할 수 있습니다. 클래식 배포 모델의 가상 네트워크는 다른 클라우드 서비스에서 이름을 확인할 때 FQDN이 필요합니다.
  • 자동 생성된 이름을 사용하는 대신 배포를 가장 잘 설명하는 호스트 이름을 사용할 수 있습니다.

고려 사항

Azure에서 제공하는 이름 확인을 사용하는 경우 다음 사항을 고려합니다.

  • Azure에서 만든 DNS 접미사는 수정할 수 없습니다.
  • DNS 조회 범위는 가상 네트워크로 지정됩니다. 한 가상 네트워크에 대해 생성된 DNS 이름은 다른 가상 네트워크에서 확인할 수 없습니다.
  • 사용자 고유의 레코드를 수동으로 등록할 수 없습니다.
  • WINS 및 NetBIOS가 지원되지 않습니다. VM이 Windows 탐색기에 표시되지 않습니다.
  • 호스트 이름은 DNS와 호환되어야 합니다. 이름은 0~9, 1-z 및 하이픈(-)만 사용해야 합니다. 이름은 하이픈으로 시작하거나 끝낼 수 없습니다.
  • DNS 쿼리 트래픽은 각 VM에 대해 제한됩니다. 이 제한은 대부분의 애플리케이션에 영향을 주지 않습니다. 요청 제한을 관찰하는 경우 클라이언트 쪽 캐싱이 사용하도록 설정되어 있는지 확인합니다. 자세한 내용은 DNS 클라이언트 구성을 참조하세요.
  • DNS 확인 문제를 방지하려면 가상 네트워크의 각 VM에 다른 이름을 사용해야 합니다.
  • 처음 180개의 클라우드 서비스 내에서 VM만 클래식 배포 모델 내의 가상 네트워크에 대해 등록됩니다. 이 제한은 Resource Manager의 가상 네트워크에 적용되지 않습니다.
  • Azure DNS IP 주소는 168.63.129.16입니다. 이 주소는 고정 IP 주소이며 변경되지 않습니다.

역방향 DNS 고려 사항

VM에 대한 역방향 DNS는 Resource Manager를 기반으로 하는 모든 가상 네트워크에서 지원됩니다. PTR(포인터)라고도 하는 Azure 관리 역방향 DNS는 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

internal.cloudapp.net 역방향 DNS 영역은 Azure에서 관리되며 직접 보거나 편집할 수 없습니다. 양식 \[vmname\].internal.cloudapp.net 의 FQDN에 대한 앞으로 조회는 VM에 할당된 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 조회는 다른 가상 네트워크에 피어된 경우에도 특정 가상 네트워크로 범위가 지정됩니다. 피어된 가상 네트워크에 있는 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 레코드의 자동 등록은 지원되지 않습니다. 항목을 만들려면 수동으로 입력합니다. 자동 등록이 다른 영역에 사용하도록 설정된 경우 가상 네트워크에서 자동 등록을 사용하지 않도록 설정해야 합니다. 이 제한은 자동 등록을 사용하는 경우 하나의 프라이빗 영역만 연결할 수 있도록 허용하는 제한 사항 때문입니다. 프라이빗 DNS 영역을 만들고 가상 네트워크에 연결하는 방법에 대한 자세한 내용은 Azure 프라이빗 DNS 빠른 시작을 참조하세요.

참고 항목

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

DNS 클라이언트 구성

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

클라이언트 쪽 캐싱

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

기본 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. 텍스트 편집기를 사용하여 다음을 추가 prepend domain-name-servers 127.0.0.1; 합니다./etc/dhclient-eth0.conf

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

    service network restart

참고 항목

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

클라이언트쪽 재시도

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 특정 단계는 배포에 따라 다릅니다.

RHEL(NetworkManager 사용)

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

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

    systemctl restart NetworkManager.service

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

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

참고 항목

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

VM 및 역할 인스턴스

이름 확인 요구 사항이 Azure에서 제공하는 기능의 범위를 벗어날 수 있습니다. 예를 들어 Windows Server Active Directory 도메인을 사용하여 가상 네트워크 간의 DNS 이름을 확인해야 할 수 있습니다. 이러한 시나리오를 다루기 위해 고유한 DNS 서버를 사용할 수 있습니다.

가상 네트워크 내의 DNS 서버는 Azure의 재귀 확인자로 DNS 쿼리를 전달할 수 있습니다. 이 절차를 사용하여 해당 가상 네트워크 내에서 호스트 이름을 확인할 수 있습니다. 예를 들어 Azure에서 실행 중인 DC(도메인 컨트롤러)는 해당 도메인에 대한 DNS 쿼리에 응답하고 Azure에 다른 모든 쿼리를 전달할 수 있습니다. 쿼리를 전달하면 VM에서 온-프레미스 리소스(DC를 통해) 및 Azure에서 제공하는 호스트 이름(전달자를 통해)을 모두 볼 수 있습니다. Azure의 재귀 확인자에 대한 액세스는 가상 IP 168.63.129.16을 통해 제공됩니다.

Important

가상 네트워크의 사용자 지정 DNS 서버 IP와 함께 이 설정에서 Azure VPN Gateway를 사용하는 경우 삭제되지 않은 서비스를 유지하려면 목록에 Azure DNS IP(168.63.129.16)를 추가해야 합니다.

또한 DNS 전달은 가상 네트워크 간의 DNS 확인을 가능하게 하며 온-프레미스 컴퓨터가 Azure에서 제공하는 호스트 이름을 확인할 수 있도록 합니다. VM의 호스트 이름을 확인하려면 DNS 서버 VM이 동일한 가상 네트워크에 상주하고 호스트 이름 쿼리를 Azure로 전달하도록 구성해야 합니다. DNS 접미사는 가상 네트워크마다 다르기 때문에 올바른 가상 네트워크에 DNS 쿼리를 보내도록 조건부 전달 규칙을 사용하여 이름을 확인할 수 있습니다.

다음 다이어그램과 같이 두 가상 네트워크와 온-프레미스 네트워크는 이 방법을 사용하여 가상 네트워크 간에 DNS 확인을 수행합니다. 예제 DNS 전달자는 Azure 빠른 시작 템플릿 갤러리 및 GitHub에서 사용할 수 있습니다.

참고 항목

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

다른 가상 네트워크(접미사를 사용하여 internal.cloudapp.net FQDN)에서 VM의 이름 확인을 수행해야 하는 역할 인스턴스는 이 섹션에 설명된 방법(두 가상 네트워크 간에 전달되는 사용자 지정 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 cmdlet 및 az network nic show Azure CLI 명령을 통해 접미사를 사용할 수 있습니다.

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

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

  • 예를 들어 DDNS(동적 DNS)를 통해 적절한 호스트 이름 확인을 제공합니다. DDNS를 사용하는 경우 DNS 레코드 청소 기능을 해제해야 할 수도 있습니다. Azure DHCP 임대는 길며 청소 시 DNS 레코드가 조기에 제거될 수 있습니다.
  • 외부 도메인 이름을 확인할 수 있도록 적절한 재귀 확인을 제공해야 합니다.
  • 제공하는 클라이언트에서 액세스 가능해야 하고(포트 53에서 TCP 및 UDP) 인터넷에 액세스할 수 있어야 합니다.
  • 외부 에이전트가 제기하는 위협을 완화하기 위해 인터넷으로부터의 액세스로부터 보안을 유지합니다.

최상의 성능을 위해 Azure VM을 DNS 서버로 사용하는 경우 IPv6을 사용하지 않도록 설정해야 합니다.

NSG(네트워크 보안 그룹)는 DNS 확인자 엔드포인트에 대한 방화벽 역할을 합니다. NSG 보안 규칙을 수정하거나 재정의하여 UDP 포트 53(필요에 따라 TCP 포트 53)에 대한 액세스를 DNS 수신기 엔드포인트로 허용합니다. 네트워크에서 사용자 지정 DNS 서버를 설정한 후 포트 53을 통한 트래픽은 서브넷의 NSG를 무시합니다.

Important

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

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

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

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

웹앱

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

  • 아직 없는 경우 가상 네트워크와 앱 통합에 설명된 대로 웹앱에 대한 가상 네트워크 통합을 사용하도록 설정합니다.
  • App Service를 사용하여 빌드된 가상 네트워크 연결 웹앱에서 동일한 프라이빗 영역에 연결되지 않은 다른 가상 네트워크의 VM으로 이름 확인을 수행해야 하는 경우 두 가상 네트워크에서 사용자 지정 DNS 서버 또는 Azure DNS 프라이빗 확인자를 사용합니다.

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

  • Azure의 재귀 확인자(가상 IP 168.63.129.16)에도 쿼리를 전달할 수 있는 VM의 대상 가상 네트워크에 DNS 서버를 설정합니다. 예제 DNS 전달자는 Azure 빠른 시작 템플릿 갤러리 및 GitHub에서 사용할 수 있습니다.
  • VM에서 원본 가상 네트워크의 DNS 전달자를 설정합니다. 대상 가상 네트워크의 DNS 서버로 쿼리를 전달하도록 이 DNS 전달자를 구성합니다.
  • 원본 가상 네트워크의 설정에 원본 DNS 서버를 구성합니다.
  • 가상 네트워크와 앱 통합의 지침 에 따라 웹앱이 원본 가상 네트워크에 연결되도록 가상 네트워크 통합을 사용하도록 설정합니다.

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

DNS 서버 지정

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

참고 항목

DNS 서버 IP와 같은 네트워크 연결 속성은 VM 내에서 직접 편집해서는 안 됩니다. 가상 네트워크 어댑터를 교체하면 서비스가 복구되는 동안 지워질 수 있습니다. 이 주의 사항은 Windows 및 Linux VM 모두에 적용됩니다.

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

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

참고 항목

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

관련 콘텐츠

Azure Resource Manager 배포 모델: