Google PCNE: Cloud DNS, 서비스 검색 및 하이브리드 이름 확인 — 학습 가이드
다음의 일부입니다: Google Professional Cloud Network Engineer — 학습 가이드. 검증된 답안으로 연습하기: Google 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.
개요
Cloud DNS는 Google Cloud의 확장 가능하고 가용성이 높은 DNS 서비스로, 공개 권한 영역과 VPC용 비공개 DNS를 모두 지원합니다. 또한 전달, 피어링, 인바운드 서버, 응답 정책, DNS 정책과 같은 하이브리드 이름 확인 기본 요소를 제공하여 온프레미스 DNS 및 멀티 클라우드와 통합할 수 있습니다. 이 섹션에서는 권한 DNS 수명 주기, 비공개 영역 공개 범위 및 공유, 하이브리드 확인, 서비스 검색 패턴, 보안 및 무결성(DNSSEC 및 영역 전송 포함), 라우팅 정책을 사용한 고급 트래픽 관리, 비공개 서비스 엔드포인트용 DNS, 그리고 문제 해결, 캐싱, 로깅, 마이그레이션/공존 전략과 같은 Day-2 운영에 대해 다룹니다.
권한 DNS 및 DNS 수명 주기
- 관리형 영역 및 레코드
- 관리형 영역은 단일 DNS 이름(영역 apex)에 대한 리소스 레코드 세트(RRset)의 컨테이너입니다.
- 레코드 유형: A, AAAA, CNAME, MX, TXT, SRV, PTR, NS, SOA (및 기타). Cloud DNS는 영역 apex에서 CNAME을 지원하지 않으므로, apex 매핑에는 부하 분산기의 IP와 함께 A/AAAA를 사용해야 합니다.
- 수명 주기: 영역 생성, 레코드 추가/수정(트랜잭션 변경), 전파 및 운영(모니터링/로깅/보안).
- 기존 BIND 파일에서 가져와 마이그레이션 가속화:
- 예시: gcloud dns record-sets import ZONE_FILE –zone-file-format –zone MANAGED_ZONE
- 공개 영역과 비공개 영역
- 공개 영역은 Google 공개 권한 네임서버를 통해 전 세계적으로 액세스할 수 있습니다. 등록기관에서 상위 영역의 NS를 업데이트하여 위임합니다.
- 비공개 영역은 연결된 VPC 네트워크에 대해서만 응답합니다. 해당 VPC의 인스턴스에 대해서는 Google의 VPC 범위 확인자(resolver)가 확인하며, 선택적으로 인바운드 전달을 통해 하이브리드 클라이언트도 확인할 수 있습니다.
- 전파 및 TTL
- Google Cloud 내에서는 레코드 변경 사항이 몇 초 안에 활성화됩니다. 외부 캐시 무효화는 TTL에 따라 달라집니다.
- TTL 장단점: 짧은 TTL은 민첩성을 높이고 더 안전한 전환을 가능하게 하지만 쿼리 부하를 증가시키고 캐시 효율성을 감소시킬 수 있습니다. 긴 TTL은 부하를 줄이지만 오래된 응답이 더 오래 유지됩니다. 일반적인 관행: 동적 서비스는 60–300초, 안정적인 레코드는 600–3600초. 전환 작업 24–48시간 전에 미리 TTL을 줄여야 합니다.
비공개 영역 공개 범위, VPC 연결 및 교차 프로젝트 설계
- VPC에 비공개 영역 연결
- 비공개 영역은 하나 이상의 VPC 네트워크와 명시적으로 연결됩니다. 이 연결은 프로젝트를 넘나들 수 있습니다(영역에 대한 dns.admin과 같은 적절한 IAM 및 네트워크 바인딩 권한 필요).
- 우선순위: VPC에 연결된 비공개 영역들 중에서 가장 긴 접미사 일치(longest-suffix match)가 우선합니다. 비공개 영역이 겹칠 때(예: svc.corp.internal. 및 corp.internal.) 주의해야 합니다.
- 교차 VPC 공유 패턴
- 직접 연결: 동일한 비공개 영역을 여러 VPC에 연결합니다. 운영은 간단하지만, 장애 확산 범위(blast radius)를 줄이기 위해 불필요한 연결은 피해야 합니다.
- Shared VPC: 호스트 프로젝트에서 DNS 관리를 중앙 집중화하고, 서브넷의 VPC를 영역에 연결하여 서비스 프로젝트에 DNS를 노출합니다.
- DNS 피어링 영역: 네트워크 간에 VPC 피어링을 사용하는 경우, 소비자 VPC의 피어링 영역을 통해 영역을 복제하지 않고도 생산자 VPC의 비공개 레코드를 확인할 수 있습니다.
- 장애 모드 및 가드레일
- 섀도잉(Shadowing): 공개 영역과 이름이 같은 비공개 영역이 있으면 연결된 VPC의 클라이언트가 비공개 응답을 선호하게 되어 공개 엔드포인트에 대한 액세스가 중단될 수 있습니다. 분할 수평(split-horizon)은 의도적으로 사용하고, 문서화하며, 테스트해야 합니다.
- 과도한 연결: 비공개 영역을 너무 광범위하게 연결하면 내부 이름이 유출될 수 있습니다. 최소 권한 원칙을 따르고 별도의 하위 도메인(리전/서비스 범위)을 사용하여 범위를 제한해야 합니다.
- IAM 분리: 관리 도메인을 분리하기 위해 DNS 변경 권한(dns.admin)과 네트워크 연결 권한(네트워크 바인딩 권한)을 별도로 위임합니다.
간단한 예시: 비공개 영역 생성 및 연결
gcloud dns managed-zones create corp-internal \
--dns-name=corp.internal. \
--visibility=private \
--description="Private corp zone" \
--networks=prod-vpc,stg-vpc
하이브리드 이름 확인: 전달, 피어링 및 정책
- 전달 영역
- 특정 접미사(예: onprem.corp.)에 대한 쿼리를 특정 네임 서버(온프레미스 또는 다른 클라우드)로 신뢰성 있게 전달합니다. Cloud DNS에서 영역을 호스팅하지 않지만 GCP에서 원활한 이름 확인이 필요할 때 사용합니다.
- 루프 방지: 온프레미스 전달자가 동일한 접미사에 대해 Cloud DNS를 다시 가리키지 않도록 해야 합니다.
- 피어링 영역
- 피어링된 VPC에서 호스팅되는 비공개 영역을 확인합니다. VPC 피어링 연결이 필요하며, 전이적(transitive)이지 않습니다. 허브 VPC에 비공개 DNS를 중앙 집중화하는 허브 앤 스포크 설계에 사용합니다.
- DNS 정책
- 아웃바운드 전달: VPC의 인스턴스는 Cloud DNS 비공개 영역에서 확인되지 않는 도메인에 대해 온프레미스 리졸버로 재귀적 쿼리를 보냅니다. Cloud VPN/Interconnect를 통해 연결 가능한 대상 네임 서버 IP를 사용하여 DNS 정책을 통해 구성합니다.
- 인바운드 서버: 온프레미스 리졸버는 Google이 제공하는 인바운드 전달 IP(자동 할당된 35.199.192.0/20)로 쿼리를 전달하여 Cloud DNS 비공개 영역을 확인합니다. GCP 비공개 DNS를 온프레미스 및 다른 클라우드로 확장하는 데 사용합니다.
- 쿼리 로깅: 정책 수준에서 활성화하여 리졸버 쿼리 로그를 Cloud Logging으로 보내 분석 및 문제 해결에 사용합니다. 공개 영역의 경우, 신뢰성 있는 쿼리에 대해 영역별 쿼리 로깅을 활성화합니다.
- 응답 정책
- 응답을 수정하는 규칙을 정의합니다(예: 알려진 악성 도메인에 대해 NXDOMAIN 반환, 또는 공개 응답을 재정의하기 위해 내부 A 레코드 합성). 신중하게 적용하고, 중요한 서드파티 도메인이 의도치 않게 차단되지 않는지 확인해야 합니다.
- 연결 전제 조건
- 아웃바운드/인바운드가 작동하려면 하이브리드 연결(Cloud VPN 또는 Interconnect)을 보장하고 방화벽 규칙이 필요에 따라 양방향으로 UDP/TCP 53을 허용하는지 확인해야 합니다. EDNS0 및 UDP 단편화 동작은 네트워크마다 다르므로 MTU 문제가 발생하면 TCP 폴백(fallback)을 허용하고 온프레미스 리졸버에서 EDNS(0) 버퍼 튜닝을 고려해야 합니다.
- 일반적인 함정
- 비대칭 연결성: 아웃바운드 전달이 온프레미스 리졸버를 가리키지만 반환 트래픽이 방화벽이나 라우팅 비대칭으로 인해 차단되면 쿼리 시간이 초과됩니다. Cloud Router가 학습한 경로를 확인하고 DNS 응답 흐름을 허용해야 합니다.
- 접미사 분할: 겹치는 기업 접미사(corp.local vs corp.internal)는 예상치 못한 리졸버 검색 경로 일치를 유발할 수 있습니다. 검색 경로와 접미사 소유권을 표준화해야 합니다.
간단한 예시:
# Outbound forwarding policy to on-prem resolvers
gcloud dns policies create corp-outbound \
--networks=prod-vpc \
--forwarding-targets=10.1.0.10,10.1.0.11 \
--enable-logging
# Forwarding zone for partner domain
gcloud dns managed-zones create partner-fwd \
--dns-name=partner.example. \
--visibility=private \
--forwarding-targets=172.16.10.53,172.16.11.53 \
--networks=prod-vpc
서비스 디스커버리, 스플릿 호라이즌 및 비공개 엔드포인트
- 스플릿 호라이즌 DNS
- 동일한 이름에 대해 내부 및 외부에서 다른 응답을 제공합니다. 일반적인 패턴: 공개 foo.example.com은 공개 Anycast IP로 확인되고, 내부 foo.example.com은 ILB의 RFC1918 주소로 확인됩니다. 동일한 이름의 공개 영역과 비공개 영역으로 구현하며, 비공개 영역의 범위를 적절한 VPC로 신중하게 지정해야 합니다.
- 내부 서비스 이름 지정
- 일관된 내부 접미사(예: svc.corp.internal)와 서비스 지향 레코드(A/AAAA, SRV 또는 디스커버리 관련 TXT)를 사용합니다. 동적으로 확장되는 서비스에는 낮은 TTL을 유지합니다.
- GKE 서비스 디스커버리: 클러스터 내부 이름은 CoreDNS(svc.cluster.local) 내에 유지됩니다. 네임스페이스/VPC 간 노출을 위해서는 ILB VIP를 Cloud DNS 비공개 영역에 게시하거나 Service Directory 통합을 사용합니다.
- Service Directory 통합
- Service Directory와 Cloud DNS를 통해 서비스 엔드포인트를 DNS에 자동으로 게시하여 네임스페이스/서비스별로 SRV 및 A 레코드를 생성합니다. 생산자와 소비자를 분리하고 서비스 인스턴스의 상태 인식 디스커버리를 지원하는 데 유용합니다.
- 비공개 서비스 엔드포인트
- Google API에 대한 Private Service Connect(PSC): PSC 엔드포인트를 사용하여 googleapis.com을 비공개로 연결하거나, googleapis.com에 대한 비공개 영역과 함께 제한된 Google API VIP(199.36.153.8/30)를 사용합니다. PSC는 엔드포인트별 제어가 가능한 리전별 로컬 비공개 IP 연결을 제공합니다. 제한된 VIP는 더 간단하지만 여전히 기본 경로를 통해 연결 가능한 공용 IP 범위를 사용합니다.
- 생산자 서비스에 대한 PSC: 비공개 영역에 PSC 엔드포인트 또는 ILB VIP를 가리키는 A/AAAA 레코드를 생성합니다. 사용자 지정 내부 도메인의 경우, Cloud DNS에서 비공개 영역을 관리하고 소비자 VPC에 연결합니다.
- 장단점
- PSC 대 제한된 VIP: PSC는 세분화된 제어를 제공하고 이그레스(egress) 검사 경로를 피할 수 있지만, 리전별로 엔드포인트/DNS 설정이 필요합니다. 제한된 VIP는 배포가 빠르지만 공유 VIP를 사용하며 이그레스 라우팅 정책과 상호 작용할 수 있습니다.
- 스플릿 호라이즌 위험: 잘못 범위가 지정된 비공개 영역은 공개 SaaS에 대한 액세스를 블랙홀(black-hole) 상태로 만들 수 있습니다. 광범위한 배포 전에 카나리 VM과 쿼리 로깅을 통해 검증해야 합니다.
간단한 예시: 내부 ILB 매핑
; Private zone: corp.internal.
web.svc.corp.internal. 60 IN A 10.20.0.15
보안, 트래픽 관리, 운영 및 마이그레이션
- DNSSEC 및 무결성
- 공개 영역: Cloud DNS에서 DNSSEC 서명을 활성화하고 등록기관에 DS를 게시하여 스푸핑 및 캐시 포이즈닝으로부터 보호합니다. 키 롤오버 기간을 계획하고 유효성 검사 실패를 모니터링합니다.
- 비공개 영역: 일반적으로 신뢰할 수 있는 네트워크를 통해 확인이 이루어지므로 DNSSEC 유효성 검사/서명은 불필요합니다. 전송 보안(하이브리드 링크) 및 확인자(resolver) 강화에 중점을 둡니다.
- 관리형 영역 전송
- Cloud DNS는 AXFR/IXFR을 위한 기본(primary) 또는 보조(secondary) 역할을 할 수 있습니다. TSIG를 사용하여 전송을 인증/승인하고 NOTIFY를 사용하여 시기적절하게 전파합니다. 영역 전송 패턴은 마이그레이션 중 공존을 단순화하고 규제 또는 복원력 요구사항을 위해 온프레미스 보조 서버를 지원합니다.
- 실패 모드: 방화벽에 의해 전송이 차단되거나, TSIG 키가 일치하지 않거나, SOA 시리얼 번호가 증가하지 않거나, 기본 서버에서 IXFR이 비활성화되어 전체 AXFR이 발생하는 경우입니다.
- 라우팅 정책 및 상태 확인
- Cloud DNS는 트래픽 조종 정책(가중치, 지역, 지연 시간 및 장애 조치)을 지원합니다. 엔드포인트에 상태 확인을 연결하여 비정상 응답을 자동으로 제외합니다.
- 설계 팁: 정책 대상별 레코드 세트를 작게 유지하고, 사용자 분포에 맞춰 지역별 범위를 지정하며, 낮은 TTL과 장애 감지 간격을 결합하여 장애 조치 시간을 제한합니다.
- 함정: 지나치게 세분화된 지역 맵은 운영 복잡성을 야기할 수 있습니다. 일관된 상태 신호가 없으면 플래핑(flapping)이 발생할 수 있으므로 안정화 임계값과 애플리케이션 동작에 맞는 상태 확인 시간 초과를 사용합니다.
- 문제 해결
- 도구:
dig/nslookup에+trace,+short,+dnssec옵션을 사용하여 체인을 검증합니다. Cloud Logging에서 확인자 쿼리 로그(DNS 정책) 및 권한 있는 쿼리 로그(관리형 영역)를 검토합니다. - 캐싱: 테스트 중인 확인자를 확인합니다(VM의 /etc/resolv.conf는 일반적으로 Google의 VPC 확인자를 가리킴). TTL 변경 사항을 테스트할 때 로컬 확인자 캐시를 플러시합니다. 네거티브 캐싱(RFC 2308)을 고려하세요. NXDOMAIN 응답은 SOA MINIMUM/네거티브 TTL에 따라 캐시됩니다.
- 일반적인 문제: 아웃바운드 전달과 온프레미스 조건부 전달자 간의 루프, 차단된 UDP 53 또는 MTU 문제로 인한 잘린 응답, 비공개 영역에 의해 가려진 공개 영역 등이 있습니다.
- 도구:
- 운영 패턴
- 변경 제어: 트랜잭션을 사용하여 변경 사항을 일괄 처리하고, 전환 작업 전에 TTL을 줄이며, 카나리아 VPC 연결을 사용하여 가시성을 검증합니다.
- 로깅 및 모니터링: 선택적으로 쿼리 로깅을 활성화하고, 추세 분석을 위해 로그를 BigQuery로 내보내며, SERVFAIL/NXDOMAIN 급증 시 알림을 생성합니다.
- 액세스 제어: 레코드 변경 역할과 네트워크 연결 역할을 분리하고, 응답 정책 편집자에 최소 권한 원칙을 적용하여 의도치 않은 도메인 차단을 방지합니다.
- 마이그레이션 및 공존
- 공존: 온프레미스 DNS가 기본으로 유지되는 동안 AXFR/IXFR을 통해 Cloud DNS를 보조로 설정하거나, 그 반대(Cloud DNS가 기본, 온프레미스가 보조)로 설정합니다. TSIG 및 허용 목록을 사용합니다.
- 조건부 전달: 온프레미스에 남아 있는 도메인의 경우 전달 영역 또는 아웃바운드 전달 정책을 생성합니다. 하이브리드 링크가 고가용성(서로 다른 피어 및 Cloud Router를 사용하는 이중 VPN)을 갖도록 보장합니다.
- 다중 조직 브리징: Cloud VPN/Cloud Router를 통해 VPC를 연결하고, 필요에 따라 상호 조건부 전달 또는 피어링을 설정하며, 재배치되는 영역에 대해 영역 전송을 사용합니다. 등록기관의 NS 또는 DS를 변경하기 훨씬 전에 TTL을 낮춥니다.
짧은 예시:
# Enable authoritative query logging for a public zone
gcloud dns managed-zones update prod-public --enable-logging
# Create inbound servers policy (IP allocation is automatic)
gcloud dns policies create corp-inbound --networks=prod-vpc
실제 문제 시나리오
Contoso Retail과 Fabrikam Payments는 별개의 Google Cloud 조직으로, 네트워크와 DNS를 최소한의 다운타임으로 통합하는 동안 1년 동안 상호 운용해야 합니다. 각 조직은 겹치지 않는 10.0.0.0/8 공간을 사용합니다. Contoso는 svc.contoso.internal 아래에 내부 서비스를 호스팅하고, Fabrikam은 계속해서 pay.fabrikam.internal을 온프레미스에서 호스팅합니다. 양측 모두 서로의 비공개 이름을 확인하고 일부 영역을 점진적으로 Cloud DNS로 마이그레이션해야 합니다.
접근 방식:
복원력 있는 하이브리드 연결 설정
- Contoso의 허브 VPC와 Fabrikam의 온프레미스 라우터 사이에 두 개의 Cloud VPN 터널을 생성합니다. 각 터널은 Fabrikam의 고유한 공용 IP에 연결되며, 두 터널 모두에서 Cloud Router BGP를 사용합니다.
- 근거: 이중 터널과 동적 라우팅은 경로 이중화를 제공하고 DNS 대상에 대한 경로를 자동으로 전파하여 UDP/TCP 53에 대한 비대칭 라우팅 위험을 줄입니다.
양방향으로 조건부 이름 확인 구현
- Contoso에서 Fabrikam의 온프레미스 DNS 서버(예: 172.20.10.53 및 172.20.11.53)로 전달하는 fabrikam.internal 전달 영역을 생성하고 이를 앱 VPC에 연결합니다.
- Fabrikam에서 온프레미스 DNS에 조건부 전달자를 구성하여 svc.contoso.internal을 Cloud DNS 인바운드 정책에서 제공하는 Contoso의 Cloud DNS 인바운드 전달 IP로 전달합니다.
- 근거: 전달 영역은 권한 중복을 피하고 각 측이 현재 위치에서 DNS를 유지할 수 있도록 합니다. 인바운드 서버는 Fabrikam의 확인자를 광범위하게 변경하지 않고도 Cloud DNS 비공개 확인을 Fabrikam으로 확장합니다.
전달 루프로부터 보호하고 가시성 경계 적용
- Fabrikam의 조건부 전달자가 Fabrikam이 여전히 소유한 이름에 대해 contoso.internal을 Contoso로 다시 전달하지 않도록 하고, 마찬가지로 Contoso는 fabrikam.internal만 전달하도록 합니다.
- Contoso의 비공개 영역은 필요한 VPC에만 연결하고, 영향 반경을 줄이기 위해 전역적으로 연결하지 않습니다.
- 근거: DNS 재귀 루프를 제거하고 공개 도메인의 비공개 영역 섀도잉을 방지합니다.
관리형 영역 전송을 사용하여 공유 영역 마이그레이션
- 현재 Fabrikam의 BIND 기본 서버에서 호스팅되는 레거시 공유 영역 legacy.shared.internal에 대해, Cloud DNS를 TSIG를 사용하는 보조 서버로 구성하고 AXFR/IXFR을 위해 Fabrikam의 기본 서버를 허용 목록에 추가합니다. 공존 기간 동안 Fabrikam을 기본 서버로 유지합니다.
- 근거: 보조 모드는 클라이언트를 변경하지 않고 실시간 동기화를 제공합니다. 단일 정보 소스를 유지하면서 Contoso에서 안전한 검증을 가능하게 합니다.
외부 노출 서비스에 스플릿 호라이즌 도입
- 고객을 위한 전역 HTTPS 부하 분산기 IP를 가리키는 레코드가 있는 공개 영역 contoso.example을 생성합니다. 동일한 이름을 내부 ILB 주소에 매핑하는 동일한 이름의 비공개 영역을 생성하여 내부 VPC에 연결합니다.
- 근거: 외부 사용자는 계속해서 엣지 부하 분산기에 도달하고, 내부 서비스는 RFC1918을 통해 비공개 ILB에 도달하여 일관된 호스트 이름을 유지하면서 지연 시간과 비용을 최적화합니다.
방화벽을 통한 이그레스 없이 Google API에 대한 비공개 액세스 제공
- 외부 IP가 없는 Contoso VM의 경우, Google API용 Private Service Connect를 활성화하고 PSC 엔드포인트에 매핑되는 googleapis.com에 대한 관리형 비공개 DNS 영역을 생성합니다.
- 근거: BigQuery 및 Pub/Sub 액세스가 비공개로 VPC 내에서 유지되도록 보장하여 타사 이그레스 어플라이언스를 피하고 보안 태세를 유지합니다.
관측 가능성 및 제어 활성화
- 관련된 VPC에 대한 Contoso의 DNS 정책에서 Cloud DNS 쿼리 로깅을 켜고 공개 영역에서 권한 있는 쿼리 로깅을 켭니다. 조직 전체에서 알려진 악성 도메인을 차단하기 위해 응답 정책 규칙을 생성합니다.
- 근거: 쿼리 원격 측정은 문제 해결 및 용량 계획을 지원하며, 응답 정책은 모든 확인자를 건드리지 않고도 보안을 위한 중앙 집중식 제어를 제공합니다.
안전한 TTL로 변경 관리 실행
- 변경 일주일 전에 마이그레이션되는 레코드의 TTL을 60초로 줄입니다. 검증 및 전환(예: 서비스를 온프레미스에서 GCP ILB로 전환) 후 TTL을 점진적으로 300~600초로 높입니다.
- 근거: 짧은 TTL은 전환 중 위험을 제한하고, 안정화 후 높은 TTL로 복원하면 캐시 효율성이 향상됩니다.
테스트, 검증 및 강화
- 양측의 카나리아 VM에서
dig를+trace와 함께 실행하여 권한 있는 경로를 확인하고, 로그에서 SERVFAIL/NXDOMAIN 급증이 없는지 확인하며, 링크 장애를 시뮬레이션하여 VPN 이중화 시 DNS 동작을 관찰합니다. - 근거: 사전 검증은 루프/가시성 문제를 조기에 감지하고, 장애 시뮬레이션은 하이브리드 확인이 사용자 영향 없이 전송 사고에서 살아남는지 확인합니다.
- 양측의 카나리아 VM에서
← 부하 분산 · 모든 도메인 · Google 및 관리형 서비스에 대한 비공개 연결 →
이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
시험 합격하기 →