Today Keys : private, dns, resolver, domain, hybrid, on-premises, 도메인, conditional, forwarder, forwarding, rule
이번 포스팅 지난 5월 17일에 Public Preview로 공개된, Azure DNS Private Resolver에 대한 테스트를 해보는 내용입니다. 기존의 Hybrid Cloud 환경에서 On-Premises와 DNS Query를 원활하게 하기 위해서는 Azure VNet 내에 IaaS로 기반의 DNS 솔루션을 별도로 만들어서 사용해야 했지만, 이제 Managed 형태의 서비스로 On-Premises ↔ Azure 간의 DNS 조회를 할 수 있게 됩니다.
오늘 포스팅에서 다뤄진 아키텍처입니다.
On-Premises에 DNS서버와 테스트를 위한 가상머신 1대가 배포되어 있습니다.
가상머신의 DNS 서버(10.1.0.37)을 DNS로 잡고 있으며, Azure와 Private하게 연결되어 있습니다.
실제 구성은 VPN으로 연결되어 있으나, VPN 혹은 Express Route든 동일하게 동작합니다.
Azure에는 3개의 서브넷이 존재합니다.
테스트를 위한 가상머신과 Storage Account와 연결된 Private Endpoint가 있는 서브넷과
Private DNS Resolvers의 구성 요소인 Inbound endpoints와 Outbound endpotins가
각각의 서브넷을 가지고 있습니다.
그럼 지금부터 DNS Private Resolver를 생성해 보겠습니다.
DNS Private Resolver는 VNet 별로 구성이 되며,
VNet 외부에서 VNet의 Private DNS로 Query를 받아주기 위한 Inbound Endpoints와
VNet 내부에서 VNet 외부의 DNS로 Query를 하기 위한 Outbound Endpoints가 있습니다 .
그리고, Outbound Query 시에 어떤 도메인에 대해서 어떤 외부 DNS로 호출을 할지 설정하는 Ruleset이 있습니다.
그럼 이제부터 하나씩 구성해 보도록 하겠습니다.
DNS Private Resolver를 만드는 첫 번째 메뉴에서는
다른 서비스를 만드는 것과 동일하게 Subscription과 Resource Group을 지정하고,
이름과 함께 Region을 설정합니다.
Private Resolver는 리전 서비스이기 때문에 Private Resolver와 Private Resolver이 연결될 VNet의 리전이 같아야 합니다.
현재 Private Resolver는 Public Preview 상태로,
아직 한국 리전이 지원하지 않기 때문에 현재 지원되는 리전 중에서 East US2로 선택합니다.
그리고, East US2 리전에 미리 만들어 둔, 'ZIGI-DNS-VNET'이라는 VNet을 선택합니다.
다음은 Inbound Endpoints를 만듭니다.
Inbound Endpoints는 앞서 얘기한 것처럼 VNet 외부에서 VNet의 Private DNS로 Query를 받아주기 위한 용도입니다.
Inbound Endpoints는 별도의 독립적인 서브넷을 사용하기 때문에 Inbound Endpoints용 서브넷을 미리 만들어 둡니다.
참고로 최소 28bit ~ 24bit의 서브넷을 사용합니다.
미리 10.2.0.0/28로 만들어 둔, zigi-in-sub을 이용해서 zigi-in-ep라는 Inbound Endpoint를 만듭니다.
다음은 Outbound Endpoints를 만듭니다.
Outbound Endpoints는 앞서 만든 Inbound Endpoint처럼 독립적인 서브넷을 사용합니다.
Inbound Endpoints와도 함께 사용할 수 없기 때문에 zigi-out-sub라는 별도 서브넷을 만들어서,
zigi-out-ep라는 Outbound Endpoint를 만듭니다.
다음은 Ruleset 입니다.
Ruleset은 VNet에서 외부의 DNS로 Query하기 위한 Rule을 모아 놓은 것입니다.
Private Resolver를 만들 때 함께 만들 수 있지만,
실제로는 Private Resolver의 서비스가 아니라,
DNS Forwarding Ruleset이라는 별도의 서비스로 VNet의 Outbound Endpoint와 연결됩니다.
여기에서는 zigi-rule이라는 이름의 rule-set을 만들고,
방금 전에 만든 zigi-out-ep라는 Outbound-Endpoints에 연결합니다.
그리고, Rule을 추가하는 데 제가 추가한 Rule은
zigi.space. 라는 도메인을 VNet에서 조회 시에, 10.1.0.37이라는 외부 DNS로 Query를 보내는 Rule입니다.
여기서 Domain name으로 입력되는 도메인은
보통의 경우 생략되는 제일 마지막의 '.' (Root)가 반드시 포함되야 정상 입력이 됩니다.
이제 마지막으로 Private Resovler 생성을 위해서 설정한 값을 확인하고
'Create' 를 클릭해서 Private Resolver를 생성합니다.
Private Resolver가 생성되고 나면,
이제 Inbound endpoints부터 확인해 보겠습니다.
Inbound endpoints 확인을 위해서, 생성된 Inbound endpoints IP 주소를 확인합니다.
Inbound endpoints이 IP 주소가 10.2.0.4 인 것을 볼 수 있습니다.
이제 VNet 외부에서 Inbound endpoints로 VNet의 Private DNS 조회가 가능해집니다.
테스트를 위해서, Storage Account의 Blob Container를 생성 후, Privatelink를 만들었습니다.
Privatelink는 10.0.0.5 IP 주소를 갖고 있습니다.
이제 VNet과 ER(혹은 VPN으로) 연결된 On-Premises의 서버에서 도메인을 조회합니다.
On-Premises에서 사용하는 DNS로 zigistorage.blob.core.windows.net을 조회하면,
blob의 Public IP 주소가 응답하는 것을 볼 수 있습니다.
그럼 이제 On-Premises에서 Inbound Endpoints를 사용할 수 있도록,
DNS 서버에서 Conditional Forwarder 설정을 합니다.
테스트를 위해서 저는 Windows DNS를 사용했습니다.
blob.core.windwos.net이라는 도메인에 대한 Query 시에,
앞서 만든 Inbound endpoints인 10.2.0.4로 조회하도록 Conditional Forwarder 설정을 합니다.
그리고, 다시 zigistorage.blob.core.windows.net을 조회하면,
blob의 IP 주소가 VNet에서 만든 Privatelink IP 주소인 10.0.0.5로 응답하는 것을 볼 수 있습니다.
다음은 Outbound endpoints 테스트입니다.
테스트를 위해서 On-Premises DNS에 zigi.space라는 도메인을 등록하고,
zigi.space의 A 레코드를 10.10.10.10 이라는 IP 주소로 응답하도록 만들었습니다.
On-Premises 서버에서 zigi.space를 조회하면 정상적으로 10.10.10.10 IP주소가 응답됩니다.
현재 설정된 Outbound endpoints에 적용되는
DNS forwarding ruleset을 다시 확인해보면,
zigi.space. 도메인은 On-Premises의 DNS 서버의 IP 주소인 10.1.0.37로 Query하도록 된 것을 볼 수 있습니다.
Outbound endpoints가 설정된 VNet 내의 서버에서도 동일하게 zigi.space를 조회하면
정상적으로 10.10.10.10 IP 주소가 응답하는 것을 확인 할 수 있습니다.
만약 Outbund endpoints를 삭제하고, zigi.space를 다시 조회해 보면
아래와 같이 정상적으로 응답을 받지 못하게 됩니다.
