VPN을 통한 Azure 프라이빗 DNS: 리졸버 엔드포인트인가 포워더인가
두 설계 모두 터널을 통해 프라이빗 영역에 응답합니다. 관리형 인바운드 엔드포인트와 포워더 VM을 비교한 뒤, 두 경우 모두에 있어야 하는 경로를 확인하세요.
온프레미스 서버가 프라이빗 주소로 Azure VM에 도달하지만 여전히 프라이빗 호스트 이름을 확인하지 못해 사람들이 끊어진 터널을 찾게 된다. 터널은 정상이다. 빠진 것은 DNS 경계다. 온프레미스 쪽에는 특정 Azure 프라이빗 영역이 VNet 내부의 리졸버가 응답해야 한다는 사실을 아는 것이 없다. 이 격차를 메우는 설계는 두 가지이며, 차이는 결국 무엇을 운영하느냐에 있지 쿼리가 되느냐에 있지 않다.
터널은 쿼리를 전달할 뿐 영역 지식을 전달하지 않는다
사이트 간 연결은 패킷에 두 네트워크 사이의 경로를 준다. 어떤 네임스페이스가 Azure에 속하는지, 어느 주소가 응답해야 하는지를 온프레미스 DNS 서버에 알려 주지는 않으므로 쿼리는 인터넷으로 나가 빈 응답으로 돌아오거나 로컬 리졸버를 떠나지 않는다.
해결책은 쉽게 나뉘는 두 부분으로 이루어진다. 한 부분은 터널을 통해 들어오는 쿼리를 받아들이는 VNet 내부의 리졸버다. 다른 부분은 정확히 하나의 네임스페이스를 그 리졸버로 보내는 온프레미스 쪽 조건부 포워더다. 어느 한쪽만으로는 동작하지 않는다.
이 설명의 나머지 부분에서는 영역이 cloud.corp.example이라고 가정하고 모든 주소는 예시로 본다.
옵션 A: 관리형 인바운드 엔드포인트
Azure DNS Private Resolver는 VNet 외부에서 오는 DNS 쿼리를 받아들이는 인바운드 엔드포인트를 제공한다. 전용 위임 서브넷에 배포하고 프라이빗 영역을 해당 VNet에 연결한 뒤 서비스가 할당하는 인바운드 주소를 기록한다.
그 다음 온프레미스 DNS 서버에서 정확한 네임스페이스에 대해 그 주소를 향하는 조건부 포워더를 만든다.
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsoft의 하이브리드 DNS 절차는 영역 연결과 포워더 단계를 모두 문서화한다. 관리형 경로에서는 패치할 DNS 소프트웨어가 남지 않고 엔드포인트 주소는 리소스 수명 동안 안정적으로 유지된다.
대가는 이제 리졸버 리소스와 그 서브넷 위임, 비용을 떠안는 것이다. 쿼리 양이 아주 적어도 실제로 발생한다.
옵션 B: VNet 내부의 포워더 VM
오래된 설계는 VNet의 일반 VM에서 DNS 소프트웨어를 실행한다. Windows DNS, BIND, dnsmasq 등이며 프라이빗 영역을 로컬에 호스팅하거나 168.63.129.16의 Azure 리졸버로 전달한다. 온프레미스 조건부 포워더는 그 VM의 프라이빗 주소를 가리킨다.
이 옵션은 이미 DNS 서버를 운영하는 팀에게 익숙하고 로깅이나 스플릿 호라이즌 응답 같은 추가 로직을 실을 수 있다. 반면 DNS 서버의 모든 운영 의무를 물려받는다. 패치, 가용성을 위한 두 번째 인스턴스, 모니터링, VM이 교체되어 주소가 바뀔 때의 재구축 경로다.
일반 VNet 호스트는 서비스가 설치되고 해당 클라이언트에 응답할 권한이 생기기 전까지 DNS 프록시가 아니며, VM을 복제할 때 사람들이 건너뛰는 단계가 바로 이것이다.
어느 쪽이 운영에 맞는가
비교의 초점은 어느 설계가 더 빠른지가 아니다. DNS 소프트웨어를 운영할 것인지, 쿼리 양이 엔드포인트와 쿼리 단위로 과금되는 관리형 리소스를 정당화하는지다.
| Question | Managed inbound endpoint | Forwarder VM |
|---|---|---|
| Software to patch | None | The DNS service on every instance |
| Address stability | Fixed for the resource lifetime | Tied to the VM or its reserved address |
| Availability work | Handled by the service | Second instance, health checks, failover |
| Extra logic | Limited to resolver features | Whatever the DNS software supports |
어느 행이 결정하든 온프레미스 포워더 규칙은 같아 보인다. 두 설계 모두에 반드시 있어야 하는 부분이며, Azure 내부에서는 확인이 되지만 사무실에서는 안 된다는 보고에서 가장 자주 빠지는 부분이다.
경로를 순서대로 확인한다
영역이 리졸버를 가진 VNet에 연결되어 있는지, 온프레미스 포워더가 상위 도메인이 아니라 네임스페이스를 지정하는지 확인한다. corp.example용 포워더는 리졸버가 직접 위임하지 않는 한 cloud.corp.example과 일치하지 않으며, 이 불일치는 레코드가 없는 것처럼 보이는 깔끔한 부정 응답을 만든다.
다음으로 쿼리가 엔드포인트에 도달하는지 확인한다. 온프레미스 소스에는 리졸버 주소로 가는 경로와 돌아오는 경로가 필요하고, 정책이 허용하는 곳에서는 UDP와 TCP 모두 포트 53이 열려 있어야 한다. NSG는 빠진 영역 레코드를 제공할 수 없고, 올바른 영역도 도달하지 않는 쿼리에 응답할 수 없다.
진단할 때 요청한 FQDN을 선택한 리졸버 옆에 두고 타임아웃과 부정 응답을 구분한다. 타임아웃은 경로나 정책 문제다. 부정 응답은 쿼리가 도달했지만 네임스페이스가 맞지 않았다는 뜻이다. 작업 순서는 영역 연결, 조건부 포워더 추가, 포트 53 양방향 개방, 온프레미스에서 이름 하나 테스트, 그 다음에야 애플리케이션 자체의 권한 확인이다.