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 수명 주기

비공개 영역 공개 범위, VPC 연결 및 교차 프로젝트 설계

간단한 예시: 비공개 영역 생성 및 연결

gcloud dns managed-zones create corp-internal \
  --dns-name=corp.internal. \
  --visibility=private \
  --description="Private corp zone" \
  --networks=prod-vpc,stg-vpc

하이브리드 이름 확인: 전달, 피어링 및 정책

간단한 예시:

# 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

서비스 디스커버리, 스플릿 호라이즌 및 비공개 엔드포인트

간단한 예시: 내부 ILB 매핑

; Private zone: corp.internal.
web.svc.corp.internal.  60  IN  A 10.20.0.15

보안, 트래픽 관리, 운영 및 마이그레이션

짧은 예시:

# 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로 마이그레이션해야 합니다.

접근 방식:

  1. 복원력 있는 하이브리드 연결 설정

    • Contoso의 허브 VPC와 Fabrikam의 온프레미스 라우터 사이에 두 개의 Cloud VPN 터널을 생성합니다. 각 터널은 Fabrikam의 고유한 공용 IP에 연결되며, 두 터널 모두에서 Cloud Router BGP를 사용합니다.
    • 근거: 이중 터널과 동적 라우팅은 경로 이중화를 제공하고 DNS 대상에 대한 경로를 자동으로 전파하여 UDP/TCP 53에 대한 비대칭 라우팅 위험을 줄입니다.
  2. 양방향으로 조건부 이름 확인 구현

    • 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으로 확장합니다.
  3. 전달 루프로부터 보호하고 가시성 경계 적용

    • Fabrikam의 조건부 전달자가 Fabrikam이 여전히 소유한 이름에 대해 contoso.internal을 Contoso로 다시 전달하지 않도록 하고, 마찬가지로 Contoso는 fabrikam.internal만 전달하도록 합니다.
    • Contoso의 비공개 영역은 필요한 VPC에만 연결하고, 영향 반경을 줄이기 위해 전역적으로 연결하지 않습니다.
    • 근거: DNS 재귀 루프를 제거하고 공개 도메인의 비공개 영역 섀도잉을 방지합니다.
  4. 관리형 영역 전송을 사용하여 공유 영역 마이그레이션

    • 현재 Fabrikam의 BIND 기본 서버에서 호스팅되는 레거시 공유 영역 legacy.shared.internal에 대해, Cloud DNS를 TSIG를 사용하는 보조 서버로 구성하고 AXFR/IXFR을 위해 Fabrikam의 기본 서버를 허용 목록에 추가합니다. 공존 기간 동안 Fabrikam을 기본 서버로 유지합니다.
    • 근거: 보조 모드는 클라이언트를 변경하지 않고 실시간 동기화를 제공합니다. 단일 정보 소스를 유지하면서 Contoso에서 안전한 검증을 가능하게 합니다.
  5. 외부 노출 서비스에 스플릿 호라이즌 도입

    • 고객을 위한 전역 HTTPS 부하 분산기 IP를 가리키는 레코드가 있는 공개 영역 contoso.example을 생성합니다. 동일한 이름을 내부 ILB 주소에 매핑하는 동일한 이름의 비공개 영역을 생성하여 내부 VPC에 연결합니다.
    • 근거: 외부 사용자는 계속해서 엣지 부하 분산기에 도달하고, 내부 서비스는 RFC1918을 통해 비공개 ILB에 도달하여 일관된 호스트 이름을 유지하면서 지연 시간과 비용을 최적화합니다.
  6. 방화벽을 통한 이그레스 없이 Google API에 대한 비공개 액세스 제공

    • 외부 IP가 없는 Contoso VM의 경우, Google API용 Private Service Connect를 활성화하고 PSC 엔드포인트에 매핑되는 googleapis.com에 대한 관리형 비공개 DNS 영역을 생성합니다.
    • 근거: BigQuery 및 Pub/Sub 액세스가 비공개로 VPC 내에서 유지되도록 보장하여 타사 이그레스 어플라이언스를 피하고 보안 태세를 유지합니다.
  7. 관측 가능성 및 제어 활성화

    • 관련된 VPC에 대한 Contoso의 DNS 정책에서 Cloud DNS 쿼리 로깅을 켜고 공개 영역에서 권한 있는 쿼리 로깅을 켭니다. 조직 전체에서 알려진 악성 도메인을 차단하기 위해 응답 정책 규칙을 생성합니다.
    • 근거: 쿼리 원격 측정은 문제 해결 및 용량 계획을 지원하며, 응답 정책은 모든 확인자를 건드리지 않고도 보안을 위한 중앙 집중식 제어를 제공합니다.
  8. 안전한 TTL로 변경 관리 실행

    • 변경 일주일 전에 마이그레이션되는 레코드의 TTL을 60초로 줄입니다. 검증 및 전환(예: 서비스를 온프레미스에서 GCP ILB로 전환) 후 TTL을 점진적으로 300~600초로 높입니다.
    • 근거: 짧은 TTL은 전환 중 위험을 제한하고, 안정화 후 높은 TTL로 복원하면 캐시 효율성이 향상됩니다.
  9. 테스트, 검증 및 강화

    • 양측의 카나리아 VM에서 dig+trace와 함께 실행하여 권한 있는 경로를 확인하고, 로그에서 SERVFAIL/NXDOMAIN 급증이 없는지 확인하며, 링크 장애를 시뮬레이션하여 VPN 이중화 시 DNS 동작을 관찰합니다.
    • 근거: 사전 검증은 루프/가시성 문제를 조기에 감지하고, 장애 시뮬레이션은 하이브리드 확인이 사용자 영향 없이 전송 사고에서 살아남는지 확인합니다.

부하 분산 · 모든 도메인 · 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.

시험 합격하기 →

Google 찾아보기 →

Related guides

올인원 액세스

하나의 구독. 모든 시험.

모든 플랜은 무제한 답변 검색, 모의고사, AI 해설, 전체 자료 라이브러리를 20개 이상의 언어로 잠금 해제합니다.

월간
24.87
Just €0.83/day
모든 포함:
  • 무제한 답변 검색
  • 무제한 모의고사
  • AI 기반 해설
  • 전체 자료 라이브러리
  • 20개 이상의 언어
  • 주간 콘텐츠 업데이트
  • 보상 및 추천
  • 우선 지원
무료 체험 시작

신용카드 필요 없음*

최고의 가치
12개월
179.87
Just €0.49/daySave 40%
모든 포함:
  • 무제한 답변 검색
  • 무제한 모의고사
  • AI 기반 해설
  • 전체 자료 라이브러리
  • 20개 이상의 언어
  • 주간 콘텐츠 업데이트
  • 보상 및 추천
  • 우선 지원
무료 체험 시작

신용카드 필요 없음*

✓ 무료 플랜 포함 · ✓ 언제든지 취소 가능 · ✓ 모든 플랜은 전체 제품을 잠금 해제합니다