Azure Stack Hub에서 iDNS 사용
iDNS는 외부 DNS 이름을 resolve 수 있는 Azure Stack Hub 네트워킹 기능입니다(예: https://www.bing.com.) 내부 가상 네트워크 이름을 등록할 수도 있음). 이렇게 하면 IP 주소가 아닌 이름으로 동일한 가상 네트워크에 VM(가상 머신)을 resolve 수 있습니다. 이 방법을 사용하면 사용자 지정 DNS 서버 항목을 제공할 필요가 없습니다. DNS에 대한 자세한 내용은 Azure DNS 개요를 참조하세요.
iDNS는 무엇을 합니까?
Azure Stack Hub에서 iDNS를 사용하면 사용자 지정 DNS 서버 항목을 지정하지 않고도 다음 기능을 얻을 수 있습니다.
- 테넌트 워크로드에 대한 공유 DNS 이름 확인 서비스입니다.
- 테넌트 가상 네트워크 내에서 이름 확인 및 DNS 등록을 위한 신뢰할 수 있는 DNS 서비스입니다.
- 테넌트 VM에서 인터넷 이름을 확인하기 위한 재귀 DNS 서비스입니다. 테넌트는 인터넷 이름을 resolve 사용자 지정 DNS 항목을 더 이상 지정할 필요가 없습니다(예: www.bing.com).
사용자 고유의 DNS를 가져오고 사용자 지정 DNS 서버를 사용할 수 있습니다. 그러나 iDNS를 사용하면 사용자 지정 DNS 항목을 만들지 않고도 인터넷 DNS 이름을 resolve 동일한 가상 네트워크의 다른 VM에 연결할 수 있습니다.
iDNS는 무엇을 하지 않나요?
iDNS에서는 가상 네트워크 외부에서 확인할 수 있는 이름에 대한 DNS 레코드를 만들 수 없습니다.
Azure에서는 공용 IP 주소와 연결된 DNS 이름 레이블을 지정할 수 있습니다. 레이블(접두사)을 선택할 수 있지만 Azure는 공용 IP 주소를 만드는 지역을 기반으로 접미사를 선택합니다.
이전 이미지와 같이 Azure는 영역 westus.cloudapp.azure.com 지정된 DNS 이름 레이블에 대한 "A" 레코드를 DNS에 만듭니다. 접두사와 접미사가 결합되어 공용 인터넷의 어디에서나 확인할 수 있는 FQDN( 정규화된 도메인 이름 )을 구성합니다.
Azure Stack Hub는 내부 이름 등록을 위해 iDNS만 지원하므로 다음 작업을 수행할 수 없습니다.
- 기존 호스트된 DNS 영역(예: local.azurestack.external)에서 DNS 레코드를 만듭니다.
- DNS 영역(예: Contoso.com)을 만듭니다.
- 사용자 지정 DNS 영역 아래에 레코드를 만듭니다.
- 도메인 이름 구매를 지원합니다.
iDNS 작동 방식 데모
Virtual Network의 VM에 대한 모든 호스트 이름은 동일한 영역에 DNS 리소스 레코드로 저장되지만 VM이 배포된 SDN 인프라의 VNET ID와 상관 관계가 있는 GUID로 정의된 고유한 구획 아래에 저장됩니다. 테넌트 VM FQDN(정규화된 도메인 이름)은 GUID 형식으로 Virtual Network 대한 컴퓨터 이름과 DNS 접미사 문자열로 구성됩니다.
다음은 이 작동 방식을 보여 주는 간단한 랩입니다. 한 VNet에 3개의 VM과 별도의 VNet에 다른 VM을 만들었습니다.
| VM | vNet | 프라이빗 IP | 공용 IP | DNS 레이블 |
|---|---|---|---|---|
| VM-A1 | VNetA | 10.0.0.5 | 172.31.12.68 | VM-A1-Label.lnv1.cloudapp.azscss.external |
| VM-A2 | VNetA | 10.0.0.6 | 172.31.12.76 | VM-A2-Label.lnv1.cloudapp.azscss.external |
| VM-A3 | VNetA | 10.0.0.7 | 172.31.12.49 | VM-A3-Label.lnv1.cloudapp.azscss.external |
| VM-B1 | VNetB | 10.0.0.4 | 172.31.12.57 | VM-B1-Label.lnv1.cloudapp.azscss.external |
| VNet | GUID | DNS 접미사 문자열 |
|---|---|---|
| VNetA | e71e1db5-0a38-460d-8539-705457a4cf75 | e71e1db5-0a38-460d-8539-705457a4cf75.internal.lnv1.azurestack.local |
| VNetB | e8a6e386-bc7a-43e1-a640-61591b5c76ddd | e8a6e386-bc7a-43e1-a640-61591b5c76dd.internal.lnv1.azurestack.local |
iDNS의 작동 방식을 더 잘 이해하기 위해 몇 가지 이름 확인 테스트를 수행할 수 있습니다.
VM-A1(Linux VM): VM-A2를 조회합니다. VNetA에 대한 DNS 접미사가 추가되고 이름이 개인 IP로 확인되는 것을 볼 수 있습니다.
carlos@VM-A1:~$ nslookup VM-A2
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: VM-A2.e71e1db5-0a38-460d-8539-705457a4cf75.internal.lnv1.azurestack.local
Address: 10.0.0.6
FQDN을 제공하지 않고 VM-A2-Label을 조회하면 예상대로 실패합니다.
carlos@VM-A1:~$ nslookup VM-A2-Label
Server: 127.0.0.53
Address: 127.0.0.53#53
** server can't find VM-A2-Label: SERVFAIL
DNS 레이블에 대한 FQDN을 제공하는 경우 이름은 공용 IP로 확인됩니다.
carlos@VM-A1:~$ nslookup VM-A2-Label.lnv1.cloudapp.azscss.external
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: VM-A2-Label.lnv1.cloudapp.azscss.external
Address: 172.31.12.76
이 레코드가 이 영역에 없기 때문에 VM-B1(다른 VNet에서 온)을 resolve 시도하면 실패합니다.
carlos@caalcobi-vm4:~$ nslookup VM-B1
Server: 127.0.0.53
Address: 127.0.0.53#53
** server can't find VM-B1: SERVFAIL
이 레코드가 다른 영역의 레코드이므로 VM-B1에 FQDN을 사용하는 것은 도움이 되지 않습니다.
carlos@VM-A1:~$ nslookup VM-B1.e8a6e386-bc7a-43e1-a640-61591b5c76dd.internal.lnv1.azurestack.local
Server: 127.0.0.53
Address: 127.0.0.53#53
** server can't find VM-B1.e8a6e386-bc7a-43e1-a640-61591b5c76dd.internal.lnv1.azurestack.local: SERVFAIL
DNS 레이블에 FQDN을 사용하는 경우 다음이 성공적으로 해결됩니다.
carlos@VM-A1:~$ nslookup VM-B1-Label.lnv1.cloudapp.azscss.external
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: VM-B1-Label.lnv1.cloudapp.azscss.external
Address: 172.31.12.57
VM-A3(Windows VM)에서. 신뢰할 수 있는 답변과 신뢰할 수 없는 답변의 차이점을 확인합니다.
내부 레코드:
C:\Users\carlos>nslookup
Default Server: UnKnown
Address: 168.63.129.16
> VM-A2
Server: UnKnown
Address: 168.63.129.16
Name: VM-A2.e71e1db5-0a38-460d-8539-705457ª4cf75.internal.lnv1.azurestack.local
Address: 10.0.0.6
외부 레코드:
> VM-A2-Label.lnv1.cloudapp.azscss.external
Server: UnKnown
Address: 168.63.129.16
Non-authoritative answer:
Name: VM-A2-Label.lnv1.cloudapp.azscss.external
Address: 172.31.12.76
요컨대, 위에서 볼 수 있는 것은 다음과 같습니다.
- 각 VNet에는 VM 이름 및 VNet의 DNS 접미사(GUID)로 구성된 모든 개인 IP 주소에 대한 A 레코드가 포함된 자체 영역이 있습니다.
- <vmname>.<vnetGUID.internal>.<지역.><stackinternalFQDN>
- 이 작업은 자동으로 수행됩니다.
- 공용 IP 주소를 사용하는 경우 해당 주소에 대한 DNS 레이블을 만들 수도 있습니다. 다른 외부 주소와 마찬가지로 해결됩니다.
- iDNS 서버는 내부 DNS 영역에 대한 신뢰할 수 있는 서버이며 테넌트 VM이 외부 리소스에 연결하려고 할 때 공용 이름에 대한 확인자 역할을 합니다. 외부 리소스에 대한 쿼리가 있는 경우 iDNS 서버는 요청을 신뢰할 수 있는 DNS 서버로 전달하여 resolve.
랩 결과에서 볼 수 있듯이 사용되는 IP를 제어할 수 있습니다. VM 이름을 사용하는 경우 개인 IP 주소를 얻게 되며 DNS 레이블을 사용하는 경우 공용 IP 주소를 가져옵니다.