Microsoft AZ-700: Azure DNS 및 이름 확인 — 학습 가이드

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

다음의 일부입니다: Microsoft Azure Network Engineer AZ-700 — 학습 가이드. 검증된 답안으로 연습하기: Microsoft 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

Azure DNS: 공용 영역, 사설 영역 및 장단점

Azure는 공용 DNS 호스팅과 가상 네트워크 평면과 긴밀하게 통합된 사설 DNS 확인 기능을 모두 제공하며, 둘 중 하나를 선택하는 것은 범위, 제어, 비용 및 운영 오버헤드의 문제입니다. 공용 Azure DNS 영역(Azure DNS에서 호스팅)은 인터넷 연결 이름에 적합하며 전역 애니캐스트 엔드포인트, 예측 가능한 API 기반 관리, 쿼리당 확장성의 이점을 누릴 수 있습니다. Private DNS 영역을 사용하면 연결된 VNet 내부의 사설 IP 주소로만 확인되는 영역 이름을 생성할 수 있습니다. 이를 통해 Azure 내 이름 확인을 위해 DNS VM을 실행하고 유지 관리할 필요가 없으며, 특정 PaaS 사설 엔드포인트와 통합될 때 자동 레코드 관리를 지원합니다. 주요 장단점은 제어입니다. 사용자 지정 DNS 서버(Windows DNS, BIND)는 조건부 전달, 고급 정책, AD 통합 SRV/CNAME 동작과 같은 절대적인 유연성을 제공하지만 VM/관리 오버헤드 및 복원력 책임이라는 비용이 따릅니다. 성능 선택은 대기 시간과 비용의 문제로 귀결됩니다. 관리형 Azure DNS 서비스는 유지 관리를 줄이고 공용 쿼리에 대한 전역 확인 속도를 제공하는 반면, 허브에 상주하는 DNS 전달자 또는 확인자 어플라이언스는 하이브리드 성능을 개선하고 정책을 적용할 수 있지만 컴퓨팅 및 가용성 비용이 추가됩니다. 일반적인 함정으로는 이름 확인이 필요한 모든 VNet에 Private DNS 영역을 연결하는 것을 잊거나, 온프레미스에서 Azure로 이름을 이전할 때 위임을 마이그레이션하지 못하거나, 명시적인 DNS 레코드나 전달 설정 없이 공용-사설 간 분할-수평(split-horizon) 동작이 자동으로 이루어질 것으로 기대하는 것 등이 있습니다.

Azure DNS (공용): 전역 애니캐스트, 관리형 API, 영역/쿼리당 과금.
Private DNS 영역: VNet 범위 확인, 지원되는 PaaS에 대한 자동 사설 레코드 생성.
App Gateway WAF_v2: 최신 WAF 기능 및 v2 확장 모델에 권장됨.
Azure Firewall (Standard/Policy): 중앙 DNS 프록시 옵션. 비용이 추가되지만 정책을 중앙 집중화함.
사용자 지정 DNS (VM 기반): 최대 제어권, 더 높은 운영 및 가용성 비용.

Private DNS 영역, 사설 엔드포인트 레코드 및 이름 지정 전략

공개적으로 호스팅되는 서비스를 사설 엔드포인트로 변환하거나 서버를 Azure로 마이그레이션할 때 DNS는 조정 지점이 됩니다. 사설 엔드포인트는 클라이언트가 사용하려는 공용 FQDN과 일치해야 하는 Private DNS 영역에 NIC 수준 A 레코드를 등록합니다. 올바른 패턴은 공용 네임스페이스(예: contoso.com)를 미러링하는 사설 영역을 만들거나 서비스별 privatelink 영역(플랫폼 서비스용)을 사용한 다음, 자동 등록을 활성화하거나 FQDN을 엔드포인트 사설 IP에 매핑하는 A/CNAME 레코드를 수동으로 생성하는 것입니다. 범위가 중요합니다. 사설 영역을 단일 VNet에 연결하면 이름 확인이 해당 VNet으로 제한됩니다. 허브-스포크 설계에서는 영역을 모든 스포크에 연결하거나 스포크에서 허브 확인자로 DNS 전달을 사용해야 합니다. 일반적인 마이그레이션 함정은 Azure 클라이언트는 사설 IP로 확인하는 동안 공용 DNS는 이전 온프레미스 IP를 가리키도록 두는 것입니다. 이러한 분할-뇌(split-brain) 혼란을 피하려면 깔끔한 전환 단계를 계획해야 합니다. 즉, 사설 DNS 및 전달이 확인된 후에만 공용 레코드를 업데이트하거나, 동일한 이름에 대해 명시적인 사설 영역을 사용하여 분할-수평(split-horizon) 이름 지정을 사용해야 합니다. 인증서와 호스트 헤더는 일치해야 합니다. 만약 Application Gateway가 사설 백엔드에 대해 종단 간 TLS를 수행할 것으로 예상한다면, 백엔드 인증서의 CN/SAN이 게이트웨이가 호스트 헤더로 보내는 호스트 이름과 일치하는지 확인해야 합니다. 그렇지 않으면 백엔드 TLS가 실패합니다.

Azure Private Resolver 및 하이브리드 이름 확인 패턴

Azure Private Resolver를 사용하면 DNS VM을 소유하지 않고도 Azure VNet과 온프레미스 네트워크 간에 관리되고 확장 가능한 DNS 전달을 활성화할 수 있습니다. 설계 패턴은 일반적으로 확인자 엔드포인트를 허브 VNet에 배치합니다. 인바운드 엔드포인트는 온프레미스에서 (VPN/ExpressRoute를 통해) Azure 사설 영역에 대한 쿼리를 수신하고, 아웃바운드 엔드포인트는 내부 전용 이름에 대해 Azure 쿼리를 온프레미스 DNS 서버로 전달합니다. 확인자 규칙 집합은 특정 네임스페이스(예: contoso.internal → 온프레미스 DNS IP)에 대한 조건부 전달을 정의하며 VNet과 연결될 수 있습니다. 전역 엔터프라이즈 배포의 경우 허브에서 규칙 관리를 중앙 집중화하고 스포크에서 허브 확인자로 트래픽을 피어링하거나 라우팅합니다. 성능 대 비용 장단점에는 복원력 및 대기 시간을 위해 여러 리전에 걸쳐 다중 인바운드 엔드포인트를 프로비저닝(비용 추가)하거나, 피어링은 사용하지만 리전 간 대기 시간이 더 높은 단일 리전 확인자 엔드포인트를 수용하는 것이 포함됩니다. 일반적인 함정으로는 온프레미스 조건부 전달자가 확인자 인바운드 IP를 가리키도록 업데이트하지 않는 것, 확인자 엔드포인트로의 DNS TCP/UDP 53을 차단하는 네트워크 보안 그룹 규칙을 잘못 구성하는 것, 그리고 Azure 제공 DNS(168.63.129.16)가 온프레미스로 전달할 것이라고 가정하는 것(조건부 전달에는 명시적인 확인자 구성이 필요함) 등이 있습니다.

DNS 포트: 일반적인 이름 확인 및 영역 전송을 위해 53 UDP 및 53 TCP가 허용되어야 합니다.
확인자 엔드포인트: 허브 VNet에 배포하고, NSG 및 방화벽이 인바운드 DNS를 허용하는지 확인합니다.

사용자 지정 DNS 서버, DNS 프록시, 그리고 운영상의 함정

Active Directory 통합, 복잡한 조건부 전달 또는 고급 DNS 정책이 필요한 경우 사용자 지정 DNS 서버(Windows DNS 도메인 컨트롤러 또는 Linux BIND)는 여전히 유용합니다. 하지만 패치, HA 클러스터링, 백업, 스케일링과 같은 운영 책임을 수반합니다. 운영 부담을 줄이는 대안으로는 Azure 내부 확인을 위한 Azure Private DNS zone과 전달 정책을 중앙 집중화하기 위한 Azure Private Resolver 또는 Azure Firewall DNS 프록시가 있습니다. DNS 프록시(Azure Firewall DNS 프록시 기능 또는 타사 NVA)는 DNS를 가로채서 선택된 확인자로 전달할 수 있어 정책 및 로깅을 단순화하지만, 단일 장애점(SPOF)과 추가 지연 시간을 유발할 수 있습니다. 주요 설계 결정 사항에는 허브에 VM 기반 전달자(저비용, 높은 유지 관리 부담)를 사용할지, 아니면 Azure Private Resolver(관리형, 더 나은 확장성)를 사용할지, 지연 시간/복원력을 위해 여러 리전에 배포할 확인자 엔드포인트 수, 그리고 프라이빗 엔드포인트 DNS 자동 등록 활성화 여부 등이 포함됩니다. 엔지니어들이 자주 저지르는 실수로는 DNS 확인을 위해 VNet 피어링에만 의존하는 것(피어링은 Private DNS zone을 자동으로 공유하지 않음), Private Endpoint에 DNS 레코드 자동 등록 권한 부여를 잊는 것, 게이트웨이를 통해 종단 간 TLS를 구현할 때 인증서 체인 검증을 소홀히 하는 것 등이 있습니다. 이 모든 실수는 프로덕션 환경에서 이름 확인이나 보안 연결을 중단시킵니다.

실제 문제: 사용 사례 시나리오

시나리오: Fabrikam Inc.는 다중 리전 허브-스포크 Azure 네트워크를 운영합니다. East US의 허브에는 Azure Firewall(Standard)이 있으며, Traffic Manager 프로필이 인터넷 사용자를 두 리전의 Application Gateway WAF_v2 인스턴스로 라우팅합니다. 두 개의 App Service 인스턴스가 www.fabrikam.com을 호스팅하며, 각각 온프레미스에서 마이그레이션되었고 해당 리전 스포크에 프라이빗 엔드포인트가 있습니다.

과제: 마이그레이션 후 온프레미스 클라이언트와 Azure 스포크는 www.fabrikam.com을 App Service 프라이빗 엔드포인트로 확인해야 합니다. Application Gateway는 종단 간 TLS를 활성화하기 위해 호스트 헤더를 보존해야 하며, DNS 확인은 리전 간에 복원력을 갖추어야 합니다.

권장 접근 방식:

허브에 fabrikam.com이라는 이름의 Azure Private DNS zone을 배포하고, 두 리전 스포크 VNet과 허브 VNet에 연결합니다. www.fabrikam.com에 대한 A 레코드를 추가하여 프라이빗 엔드포인트 IP를 가리키도록 하거나, App Service 프라이빗 엔드포인트에 대한 자동 등록을 활성화합니다.
허브에 Azure Private Resolver 인바운드 엔드포인트를 배포하고(필요 시 복원력을 위해 리전당 하나씩), 온프레미스 조건부 전달자를 구성하여 fabrikam.com 쿼리를 확인자 인바운드 IP로 전달하도록 합니다.
Application Gateway WAF_v2 HTTP 설정을 443 포트에서 HTTPS를 사용하도록 구성하고, 백엔드 호스트 헤더를 www.fabrikam.com으로 설정하며, 백엔드 상태 프로브가 인증서 CN/SAN과 일치하는 호스트 헤더와 함께 HTTPS를 사용하도록 보장합니다.
온프레미스와 스포크에서 DNS 쿼리를 실행하여 프라이빗 IP를 반환하는지 확인하고, 인증서 CN/SAN 및 프로브 성공 여부를 점검하여 Application Gateway 종단 간 TLS를 검증합니다.

근거: 허브에서 프라이빗 DNS와 확인자 기능을 중앙 집중화하면 단일 진실 공급원(single-source truth)을 제공하고 하이브리드 조건부 전달을 단순화합니다. 프라이빗 존을 모든 VNet에 연결하고 게이트웨이가 올바른 호스트 헤더를 사용하도록 보장하면 종단 간 TLS를 위한 인증서 검증을 유지하여, 운영 관리 용이성, 성능, 복원력의 균형을 맞출 수 있습니다.

← 하이브리드 네트워킹 · 모든 도메인 · 네트워크 보안 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →