Cloud DNS 개요

이 페이지에서는 Cloud DNS의 특징과 기능을 간략히 설명합니다. Cloud DNS는 비용 효율적인 방식으로 도메인 이름을 전역 DNS에 게시하는 복원력이 우수한 고성능 전역 DNS(도메인 이름 시스템) 서비스입니다.

DNS는 IP 주소 및 기타 데이터를 저장하고 이름별로 조회할 수 있는 계층형 분산 데이터베이스입니다. Cloud DNS를 사용하면 자체 DNS 서버와 소프트웨어 관리 부담 없이 DNS에 영역 및 레코드를 게시할 수 있습니다.

Cloud DNS는 공개 및 비공개 관리형 DNS 영역을 모두 제공합니다. 공개 영역은 공개 인터넷에 표시되고, 비공개 영역은 지정된 하나 이상의 Virtual Private Cloud(VPC) 네트워크에만 표시됩니다.

일반적인 DNS 용어 목록은 일반 DNS 개요를 참조하세요.

Cloud DNS가 빌드된 핵심 용어 목록은 핵심 용어를 참조하세요.

Cloud DNS 사용을 시작하려면 빠른 시작을 참조하세요.

직접 사용해 보기

Google Cloud를 처음 사용하는 경우 계정을 만들어 실제 시나리오에서 Cloud DNS의 성능을 평가할 수 있습니다. 또한 신규 고객에게는 워크로드를 실행, 테스트, 배포하는 데 사용할 수 있는 $300의 무료 크레딧이 제공됩니다.

Cloud DNS 무료로 사용해 보기

공유 VPC 고려사항

Cloud DNS 관리형 비공개 영역, Cloud DNS 전달 영역, Cloud DNS 피어링 영역을 공유 VPC에 사용하려면 호스트 프로젝트에 영역을 만든 후 해당 영역의 승인된 네트워크 목록에 하나 이상의 공유 VPC 네트워크를 추가해야 합니다.

자세한 내용은 Cloud DNS 비공개 영역 권장사항을 참조하세요.

DNS 전달 방법

Google Cloud는 비공개 영역에 대한 인바운드 및 아웃바운드 DNS 전달을 제공합니다. 전달 영역 또는 Cloud DNS 서버 정책을 만들어 DNS 전달을 구성할 수 있습니다. 두 가지 방법은 다음 표에 요약되어 있습니다.

DNS 전달 Cloud DNS 방법
인바운드

온프레미스 DNS 클라이언트 또는 서버가 Cloud DNS로 DNS 요청을 전송하도록 인바운드 서버 정책을 만듭니다. 그러면 DNS 클라이언트 또는 서버가 VPC 네트워크의 이름 확인 순서에 따라 레코드를 확인할 수 있습니다.

온프레미스 클라이언트는 VPC 네트워크가 승인된 비공개 영역, 전달 영역, 피어링 영역의 레코드를 확인할 수 있습니다. 온프레미스 클라이언트는 Cloud VPN 또는 Cloud Interconnect를 사용하여 VPC 네트워크에 연결합니다.

아웃바운드

VPC 네트워크에서 다음을 수행하도록 VM을 구성할 수 있습니다.

  • 원하는 DNS 네임서버로 DNS 요청을 전송합니다. 네임서버는 동일한 VPC 네트워크, 온프레미스 네트워크, 인터넷에 배치할 수 있습니다.
  • VPC 네트워크에서 사용하도록 승인된 전달 영역의 전달 대상으로 구성된 네임서버에 호스팅된 레코드를 확인합니다. Google Cloud가 전달 대상의 IP 주소로 트래픽을 라우팅하는 방법에 대한 자세한 내용은 전달 대상 및 라우팅 방법을 참조하세요.
  • VPC 네트워크가 모든 DNS 요청에 대체 네임서버를 전송하도록 아웃바운드 서버 정책을 만듭니다. 대체 네임서버를 사용하면 VPC 네트워크의 VM이 더 이상 Cloud DNS 비공개 영역, 전달 영역, 피어링 영역의 레코드를 확인할 수 없습니다. 자세한 내용은 이름 확인 순서를 참조하세요.

VPC 네트워크의 인바운드 전달과 아웃바운드 전달을 동시에 구성할 수 있습니다. 양방향 전달을 사용하면 VPC 네트워크의 VM이 온프레미스 네트워크 또는 다른 클라우드 제공업체에서 호스팅하는 네트워크의 레코드를 확인할 수 있습니다. 이러한 유형의 전달을 통해 온프레미스 네트워크의 호스트가 Google Cloud 리소스의 레코드를 확인할 수도 있습니다.

Cloud DNS 제어 영역은 알고리즘을 사용하여 전달 대상의 응답성을 결정합니다. 아웃바운드 전달 쿼리로 인해 SERVFAIL 오류가 발생할 수 있습니다. 이 문제를 해결하는 방법에 대한 자세한 내용은 아웃바운드 전달된 쿼리의 SERVFAIL 오류 수신을 참조하세요.

서버 정책을 적용하는 방법에 대한 자세한 내용은 DNS 서버 정책 만들기를 참조하세요. 전달 영역을 만드는 방법은 전달 영역 만들기를 참조하세요.

비공개 영역의 RFC 1918 주소의 PTR 레코드

RFC 1918 주소에 대한 커스텀 PTR 레코드를 사용하여 역방향 조회를 수행하려면 최소한 다음 예시 영역 중 하나만큼 구체적인 Cloud DNS 비공개 영역을 만들어야 합니다. 이는 이름 확인 순서에 설명된 최장 서픽스 일치의 결과입니다.

예시 영역에는 다음이 포함됩니다.

  • 10.in-addr.arpa.
  • 168.192.in-addr.arpa.
  • 16.172.in-addr.arpa., 17.172.in-addr.arpa., ...~ 31.172.in-addr.arpa.

RFC 1918 주소에 대해 Cloud DNS 비공개 영역을 만드는 경우 해당 영역의 VM에 대해 만드는 커스텀 PTR 레코드는 내부 DNS가 자동으로 만드는 PTR 레코드로 재정의됩니다. 이는 내부 DNS PTR 레코드가 이전의 더 구체적인 영역 목록에서 생성되기 때문입니다.

예를 들어 IP 주소가 10.1.1.1인 VM에 대해 다음 PTR 레코드를 사용하여 in-addr.arpa.에 대한 관리형 비공개 영역을 만든다고 가정해 보겠습니다.

1.1.1.10.in-addr.arpa. -> test.example.domain

1.1.1.10.in-addr.arpa.에 대한 PTR 쿼리는 보다 구체적인 10.in-addr.arpa. 내부 DNS 영역에 의해 답변됩니다. test.example.domain의 Cloud DNS 비공개 영역에 있는 PTR 레코드는 무시됩니다.

VM에 대해 자동으로 생성된 내부 DNS PTR 레코드를 재정의하려면 이 섹션에 있는 영역 중 하나만큼 구체적인 비공개 영역에 커스텀 PTR 레코드를 만들어야 합니다. 예를 들어 10.in-addr.arpa.에 대해 비공개 영역에 1.1.1.10.in-addr.arpa. -> test.example.domain PTR 레코드를 만들면 해당 레코드가 이전에 생성된 레코드를 자동으로 재정의합니다.

네트워크 블록의 일부만 재정의해야 하는 경우에는 보다 구체적인 역방향 Cloud DNS 비공개 영역을 만들 수 있습니다. 예를 들어 5.10.in-addr.arpa.의 비공개 영역을 사용하여 10.5.0.0/16 주소 범위의 IP 주소로 VM에 대해 자동으로 생성되는 내부 DNS PTR 레코드를 재정의하는 PTR 레코드를 저장할 수 있습니다.

지원되는 DNS 레코드 유형

Cloud DNS는 다음 유형의 레코드를 지원합니다.

레코드 유형 설명
A

호스트 이름을 IPv4 주소로 매핑하는 주소 레코드입니다.

AAAA

호스트 이름을 IPv6 주소에 매핑하는 IPv6 주소 레코드입니다.

CAA

도메인에 대해 인증서를 만들 수 있는 CA를 지정하는 인증 기관(CA) 승인입니다.

CNAME

별칭 이름을 지정하는 표준 이름 레코드입니다.

Cloud DNS는 다양한 관리형 비공개 영역(CNAME 추적) 전반에서 재귀적으로 CNAME 해결을 지원하지 않습니다. 자세한 내용은 비공개 영역에 정의된 CNAME 레코드가 작동하지 않음을 참조하세요.

DNSKEY

보안 전송을 위한 다른 연산자의 DNSSEC 키입니다. 이 레코드 집합 유형은 전송 상태에서 DNSSEC가 사용 설정된 영역에만 추가할 수 있습니다.

DS

보안이 위임된 영역에 사용될 DNSSEC 키 지문입니다. 이 레코드 집합 유형은 사용자가 이 영역에 대해 DNSSEC를 사용 설정(및 활성화)하지 않는 한 위임된 영역에 대해 DNSSEC를 활성화하지 않습니다.

IPSECKEY

상황별 암호화를 사용 설정을 하기 위한 IPsec 지원 클라이언트에 대한 IPsec 터널 게이트웨이 데이터 및 공개 키입니다.

MX

요청을 메일 서버로 라우팅하는 메일 교환 레코드입니다.

NAPTR

이름 지정 기관 포인터 레코드입니다. RFC 3403에 의해 정의됩니다.

NS

네임서버 레코드입니다. DNS 영역을 권한 서버에 위임합니다.

PTR

포인터 레코드입니다. 주로 역방향 DNS 조회에 사용됩니다.

SOA

기관 레코드의 시작입니다. DNS 영역에 대한 권한 정보를 지정합니다. SOA 리소스 레코드는 관리형 영역을 만들면 생성됩니다. 필요에 따라 레코드를 수정할 수 있습니다(예: 날짜 기반 버전 관리를 지원하기 위해 일련번호를 임의의 숫자로 변경 가능).

SPF

보내는 사람 정책 프레임워크 레코드입니다. 이메일 유효성 검사 시스템에서 이전에 사용된 지원 중단 레코드 유형입니다(대신 TXT 레코드 사용).

SRV

서비스 로케이터 레코드입니다. 일부 Voice over IP(VoIP), 인스턴트 채팅 프로토콜, 기타 애플리케이션에서 사용됩니다.

SSHFP

SSH 서버의 공개 키 유효성을 검사를 하기 위한 SSH 클라이언트의 SSH 지문입니다.

TLSA

X.509 서버 인증서의 유효성을 검사하기 위한 TLS 클라이언트의 TLS 인증 레코드입니다.

TXT

텍스트 레코드입니다. 임의 텍스트가 포함될 수 있으며 보안 또는 악용 방지 정보와 같은 머신이 읽을 수 있는 데이터를 정의하는 데 사용됩니다.

TXT 레코드는 하나 이상의 텍스트 문자열을 포함할 수 있으며, 각 개별 문자열의 최대 길이는 255자(영문 기준)입니다. 메일 에이전트와 기타 소프트웨어 에이전트는 여러 문자열을 연결합니다. 각 문자열을 따옴표로 묶습니다.

DNS 레코드로 작업을 수행하려면 레코드 관리를 참조하세요.

와일드 카드 DNS 레코드

와일드 카드 레코드는 NS 레코드를 제외한 모든 레코드 유형에 지원됩니다.

DNSSEC

Cloud DNS는 관리형 DNSSEC를 지원하여 도메인을 위상 및 캐시 악성 공격으로부터 보호합니다. Google Public DNS와 같은 유효성 검사 리졸버를 사용하면 DNSSEC가 도메인 조회 시 강력한 인증 기능(암호화 아님)을 제공합니다. DNSSEC에 대한 자세한 내용은 DNSSEC 구성 관리를 참조하세요.

전달 영역

Cloud DNS 전달 영역을 사용하면 특정 비공개 영역에 대상 네임서버를 구성할 수 있습니다. 전달 영역을 사용하면 VPC 네트워크에서 아웃바운드 DNS 전달을 구현할 수 있습니다.

Cloud DNS 전달 영역은 특수한 유형의 Cloud DNS 비공개 영역입니다. 영역 내에서 레코드를 만드는 대신 전달 대상 집합을 지정합니다. 각 전달 대상은 VPC 네트워크 또는 Cloud VPN이나 Cloud Interconnect로 VPC 네트워크에 연결된 온프레미스 네트워크에 있는 DNS 서버의 IP 주소입니다.

전달 대상 및 라우팅 방법

Cloud DNS는 세 가지 유형의 대상을 지원하며 대상에 트래픽을 라우팅하는 표준 또는 비공개 방법을 제공합니다.

전달 대상 설명 표준 라우팅 지원 비공개 라우팅 지원 요청 소스
유형 1 전달 영역 사용 권한이 있는 동일한 VPC 네트워크에 있는Google Cloud VM의 내부 IP 주소입니다. RFC 1918 IP 주소만 지원합니다. 트래픽은 항상 승인된 VPC 네트워크를 통해 라우팅됩니다. 비RFC 1918 비공개 IP 주소 및 비공개적으로 재사용되는 공개 IP 주소를 포함하여 모든 내부 IP 주소를 지원합니다. 트래픽은 항상 승인된 VPC 네트워크를 통해 라우팅됩니다. 35.199.192.0/19
유형 2 Cloud VPN 또는 Cloud Interconnect를 사용하여 전달 영역을 쿼리하도록 승인된 VPC 네트워크에 연결된 온프레미스 시스템의 IP 주소입니다. RFC 1918 IP 주소만 지원합니다. 트래픽은 항상 승인된 VPC 네트워크를 통해 라우팅됩니다. 비RFC 1918 비공개 IP 주소 및 비공개적으로 재사용되는 공개 IP 주소를 포함하여 모든 내부 IP 주소를 지원합니다. 트래픽은 항상 승인된 VPC 네트워크를 통해 라우팅됩니다. 35.199.192.0/19
유형 3 Google Cloud의 내부 또는 외부 IP 주소에 액세스할 수 있는 DNS 네임서버의 외부 IP 주소입니다(예: 다른 VPC 네트워크에 있는 VM의 외부 IP 주소). 인터넷으로 라우팅할 수 있는 외부 IP 주소만 지원합니다. 트래픽은 항상 인터넷 또는 Google Cloud 리소스의 외부 IP 주소로 라우팅됩니다. 비공개 라우팅은 지원되지 않습니다. 비공개 라우팅이 선택되지 않았는지 확인하세요. Google Public DNS 소스 범위

전달 영역에 전달 대상을 추가할 때 다음 두 가지 라우팅 방법 중 하나를 선택할 수 있습니다.

  • 표준 라우팅: 전달 대상이 RFC 1918 주소인지 여부에 따라 승인된 VPC 네트워크 또는 인터넷을 통해 트래픽을 라우팅합니다. 전달 대상이 RFC 1918 IP 주소이면 Cloud DNS는 대상을 유형 1 또는 유형 2 대상으로 분류하고 승인된 VPC 네트워크를 통해 요청을 라우팅합니다. 대상이 RFC 1918 IP 주소가 아니라면 Cloud DNS는 대상을 유형 3으로 분류하고 대상이 인터넷에 액세스할 것으로 예상합니다.

  • 비공개 라우팅: 대상의 IP 주소(RFC 1918 여부)에 관계없이 항상 승인된 VPC 네트워크를 통해 트래픽을 라우팅합니다. 따라서 유형 1유형 2 대상만 지원됩니다.

유형 1 또는 유형 2 전달 대상에 액세스하려면 Cloud DNS가 DNS 클라이언트가 있는 승인된 VPC 네트워크의 경로를 사용합니다. 이러한 경로는 전달 대상에 대한 보안 경로를 정의합니다.

유형 1유형 2 대상의 네트워크 요구 사항에 대한 자세한 안내는 대상 네트워크 요구 사항 전달을 참조하세요.

전달 대상 선택 순서

Cloud DNS를 사용하면 아웃바운드 서버 정책에 대한 대체 네임서버 목록과 전달 영역에 대한 전달 대상 목록을 구성할 수 있습니다.

전달 대상이 여러 개인 경우 Cloud DNS는 내부 알고리즘을 사용하여 전달 대상을 선택합니다. 이 알고리즘은 각 전달 대상의 순위를 정합니다.

요청을 처리하기 위해 Cloud DNS는 먼저 순위가 가장 높은 전달 대상에 문의하여 DNS 쿼리를 시도합니다. 해당 서버가 응답하지 않으면 Cloud DNS는 다음으로 순위가 높은 전달 대상으로 요청을 반복합니다. 전달 대상이 응답하지 않으면 Cloud DNS는 SERVFAIL 응답을 합성합니다.

순위 알고리즘은 자동으로 처리되며 다음 요소가 전달 대상의 순위를 높입니다.

  • 전달 대상에서 처리되는 성공적인 DNS 응답 수가 많을수록 순위가 높아집니다. 성공적인 DNS 응답에는 NXDOMAIN 응답이 포함됩니다.
  • 전달 대상과 통신하기 위한 지연 시간(왕복 시간)이 낮을수록 순위가 높아집니다.

전달 영역 사용

VPC 네트워크의 VM은 다음과 같은 경우에 Cloud DNS 전달 영역을 사용할 수 있습니다.

  • VPC 네트워크가 Cloud DNS 전달 영역을 사용할 수 있도록 승인되었습니다. 동일한 프로젝트의 여러 VPC 네트워크가 전달 영역을 사용하도록 승인할 수 있습니다.
  • VPC 네트워크에 있는 각 VM의 게스트 운영체제가 VM의 메타데이터 서버인 169.254.169.254를 네임서버로 사용합니다.

중첩 전달 영역

Cloud DNS 전달 영역은 Cloud DNS 관리형 비공개 영역의 한 유형이므로 중첩되는 여러 영역을 만들 수 있습니다. 위 설명대로 구성된 VM은 최장 서픽스가 있는 영역을 사용하여 이름 확인 순서에 따라 레코드를 확인합니다. 자세한 내용은 중첩 영역을 참조하세요.

캐싱 및 전달 영역

Cloud DNS는 Cloud DNS 전달 영역으로 전송된 쿼리에 대한 응답을 캐시합니다. Cloud DNS는 다음 기간보다 짧은 기간 내에 도달할 수 있는 전달 대상의 응답 캐시를 유지합니다.

  • 60초
  • 레코드 TTL(수명) 기간

전달 영역의 모든 전달 대상에 도달할 수 없는 경우 Cloud DNS는 각 레코드의 TTL 기간 동안 해당 영역에서 이전에 요청한 레코드의 캐시를 유지합니다.

대신 피어링을 사용해야 하는 경우

Cloud DNS는 전환 라우팅을 사용하여 전달 대상에 연결할 수 없습니다. 아래 시나리오는 잘못된 구성에 대한 설명입니다.

  • 온프레미스 네트워크를 vpc-net-a라는 VPC 네트워크에 연결하기 위해 Cloud VPN 또는 Cloud Interconnect를 사용했습니다.

  • VPC 네트워크 vpc-net-avpc-net-b에 연결하기 위해 VPC 네트워크 피어링을 사용했습니다. vpc-net-a를 커스텀 경로를 내보내도록 구성하고 vpc-net-b를 커스텀 경로를 가져오도록 구성했습니다.

  • 전달 대상이 vpc-net-a가 연결된 온프레미스 네트워크에 있는 전달 영역을 만들었습니다. vpc-net-b에서 해당 전달 영역을 사용하도록 승인했습니다.

이 시나리오에서는 vpc-net-b가 온프레미스 네트워크와 연결되어 있더라도 전달 대상이 제공하는 영역의 레코드를 확인하지 못합니다. 이 실패를 확인하려면 vpc-net-b의 VM에서 다음 테스트를 수행합니다.

  • 전달 영역에 정의된 레코드에 대해 VM의 메타데이터 서버 169.254.169.254를 쿼리합니다. Cloud DNS가 전달 대상에 대한 전환 라우팅을 지원하지 않기 때문에 이 쿼리는 실패합니다. 전달 영역을 사용하려면 해당 메타데이터 서버를 사용하도록 VM을 구성해야 합니다.

  • 전달 대상에 직접 동일한 레코드를 쿼리합니다. Cloud DNS에 이 경로가 사용되지 않더라도 이 쿼리는 전환 연결이 성공하는 것을 보여줍니다.

Cloud DNS 피어링 영역을 사용하여 이 잘못된 시나리오를 수정할 수 있습니다.

  1. vpc-net-a를 대상으로 하는 vpc-net-b에 대해 승인된 Cloud DNS 피어링 영역을 만듭니다.
  2. 전달 대상이 온 프레미스 네임서버인 vpc-net-a에 대해 승인된 전달 영역을 만듭니다.

이 단계는 순서에 관계없이 수행할 수 있습니다. 이 단계를 완료하면 vpc-net-avpc-net-b의 Compute Engine 인스턴스가 온프레미스 전달 대상을 쿼리할 수 있습니다.

DNS 피어링

DNS 피어링을 사용하면 한 영역의 네임스페이스에서 오는 레코드의 요청을 다른 VPC 네트워크에 전달할 수 있습니다. 예를 들어 SaaS 제공업체는 SaaS 고객에게 SaaS가 관리하는 DNS 레코드에 대한 액세스 권한을 부여할 수 있습니다.

DNS 피어링을 제공하려면 Cloud DNS 피어링 영역을 만들고 해당 영역의 네임스페이스에 레코드를 사용할 수 있는 VPC 네트워크에서 DNS를 조회할 수 있도록 구성해야 합니다. DNS 피어링 영역이 조회 작업을 수행하는 VPC 네트워크를 DNS 제작자 네트워크라고 합니다.

DNS 피어링을 사용하려면 피어링 영역을 사용하도록 네트워크를 승인해야 합니다. 피어링 영역을 사용하도록 승인된 VPC 네트워크를 DNS 소비자 네트워크라고 합니다.

DNS 소비자 네트워크에서 Google Cloud 리소스가 승인된 다음에는 DNS 공급자 네트워크에 있는 것처럼 피어링 영역의 네임스페이스에 있는 레코드 조회를 수행할 수 있습니다. 피어링 영역 네임스페이스의 레코드 조회는 DNS 제작자 네트워크의 이름 확인 순서를 따릅니다.

따라서 DNS 소비자 네트워크에 있는 Google Cloud 리소스가 DNS 공급자 네트워크에 있는 다음 소스로부터 영역의 네임스페이스에 있는 레코드를 조회할 수 있습니다.

  • DNS 공급자 네트워크에서 사용하도록 승인된 Cloud DNS 관리형 비공개 영역
  • DNS 공급자 네트워크에서 사용하도록 승인된 Cloud DNS 관리형 전달 영역
  • DNS 공급자 네트워크의 Compute Engine 내부 DNS 이름
  • 대체 네임서버(아웃바운드 서버 정책이 DNS 공급자 네트워크에 구성되어 있는 경우)

DNS 피어링 제한사항 및 핵심 사항

DNS 피어링 구성 시 다음 사항에 유의하세요.

  • DNS 피어링은 단방향 관계입니다. DNS 소비자 네트워크의 Google Cloud 리소스가 DNS 제작자 네트워크에 있는 것처럼 피어링 영역의 네임스페이스에서 레코드를 조회할 수 있게 해줍니다.
  • DNS 공급자와 소비자 네트워크는 VPC 네트워크여야 합니다.
  • DNS 공급자 및 소비자 네트워크가 일반적으로 동일한 조직에 포함되지만, 조직 간 DNS 피어링도 지원됩니다.
  • DNS 피어링과 VPC 네트워크 피어링은 다른 서비스입니다. DNS 피어링은 VPC 네트워크 피어링에 사용될 수 있지만 DNS 피어링을 위해 VPC 네트워크 피어링이 필요하지는 않습니다.
  • 전환 DNS 피어링은 지원되지만 단일 전환 홉을 통해서만 지원됩니다. 즉, 3개의 이하의 VPC 네트워크(중간 네트워크가 전환 홉)를 포함할 수 있습니다. 예를 들어 vpc-net-b 대상의 vpc-net-a에 피어링 영역을 만든 후 vpc-net-c 대상의 vpc-net-b에 피어링 영역을 만들 수 잇습니다.
  • DNS 피어링을 사용하여 전달 영역 대상을 지정하는 경우 전달 영역이 포함된 대상 VPC 네트워크에는 DNS 피어링 영역을 사용하는 소스 VM과 동일한 리전에 VM, VLAN 연결, Cloud VPN 터널이 있어야 합니다. 이 제한사항에 대한 자세한 내용은 소비자 VPC 네트워크의 VM에서 공급자 VPC 네트워크로 쿼리가 전달되지 않음을 참조하세요.

피어링 영역을 만들려면 DNS 제작자 네트워크를 포함한 프로젝트에 대한 DNS 피어 IAM 역할이 있어야 합니다.

중첩 영역

한 영역의 원본 도메인 이름이 다른 영역의 원본과 같거나 하위 도메인인 경우에는 두 영역이 서로 중첩됩니다. 예를 들면 다음과 같습니다.

  • gcp.example.com의 영역과 gcp.example.com의 영역은 도메인 이름이 동일하기 때문에 중첩됩니다.
  • dev.gcp.example.com의 영역과 gcp.example.com의 영역은 dev.gcp.example.comgcp.example.com의 하위 도메인이기 때문에 중첩됩니다.

중첩 영역 규칙

Cloud DNS는 중첩 영역에 다음 규칙을 적용합니다.

  • 동일한 Cloud DNS 네임서버에는 중첩 공개 영역이 허용되지 않습니다. 중첩 영역을 만들면 Cloud DNS가 서로 다른 네임서버에 이를 배치하려고 시도합니다. 그렇게 할 수 없으면 Cloud DNS가 중첩 영역을 만들지 못합니다.

  • 비공개 영역은 모든 공개 영역과 중첩될 수 있습니다.

  • 서로 다른 VPC 네트워크에 대해 범위가 지정된 비공개 영역은 서로 중첩될 수 있습니다. 예를 들어 두 VPC 네트워크는 gcp.example.com 영역에 database.gcp.example.com이라는 데이터베이스 VM을 각각 포함할 수 있습니다. database.gcp.example.com에 대한 쿼리는 각 VPC 네트워크의 승인된 영역에 정의된 영역 레코드에 따라 서로 다른 답변을 받습니다.

  • 한 영역이 다른 영역의 하위 도메인이 아니면 동일한 VPC 네트워크에서 액세스할 수 있도록 승인된 두 비공개 영역은 동일한 원본을 가질 수 없습니다. 메타데이터 서버는 최장 서픽스 일치를 사용하여 지정된 영역의 레코드에 쿼리할 원본을 결정합니다.

쿼리 확인 예시

Google Cloud는 이름 확인 순서의 설명대로 Cloud DNS 영역을 확인합니다. 특정 레코드에 대해 쿼리할 영역을 결정할 때 Cloud DNS는 요청된 레코드와 최대한 일치하는(최장 서픽스 일치) 영역을 찾습니다.

아웃바운드 서버 정책에 대체 네임서버를 지정하지 않는 한 Google Cloud는 공개 영역에서 레코드를 조회하기 전에 먼저 VPC 네트워크에 대해 승인된 비공개 영역(또는 전달 영역 또는 피어링 영역)에서 레코드를 찾습니다.

다음 예시는 DNS 레코드 쿼리 시 메타데이터 서버가 사용하는 순서를 보여줍니다. 이러한 각 예시에서는 gcp.example.comdev.gcp.example.com이라는 비공개 영역을 두 개 만들었고 동일한 VPC 네트워크에서 이에 대한 액세스를 승인했다고 가정합니다. Google Cloud는 VPC 네트워크에 있는 VM에서의 DNS 쿼리를 다음과 같은 방식으로 처리합니다.

  • VPC 네트워크에 대해 승인된 example.com의 비공개 영역이 없으므로 메타데이터 서버는 공개 네임서버를 사용하여 myapp.example.com.(후행 점 참조)의 레코드를 확인합니다. Compute Engine VM의 dig를 사용하여 VM의 기본 네임서버를 쿼리합니다.

    dig myapp.example.com.
    

    자세한 내용은 메타데이터 서버를 사용하여 DNS 이름 쿼리를 참조하세요.

  • 요청된 레코드 이름과 이용 가능한 승인된 비공개 영역의 공통적인 최장 서픽스가 gcp.example.com이기 때문에 메타데이터 서버는 승인된 비공개 영역 gcp.example.com을 사용하여 레코드 myapp.gcp.example.com을 확인합니다. 비공개 영역 gcp.example.com에 정의된 myapp.gcp.example.com에 대한 레코드가 없을 경우 공개 영역에 정의된 myapp.gcp.example.com에 대한 레코드가 있더라도 NXDOMAIN이 반환됩니다.

  • 마찬가지로 myapp.dev.gcp.example.com에 대한 쿼리는 승인된 비공개 영역 dev.gcp.example.com의 레코드에 따라 확인됩니다. dev.gcp.example.com 영역에 myapp.dev.gcp.example.com에 대한 레코드가 없을 경우 다른 비공개 또는 공개 영역에 myapp.dev.gcp.example.com에 대한 레코드가 있더라도 NXDOMAIN이 반환됩니다.

  • gcp.example.com이 요청된 DNS 레코드와 사용 가능한 비공개 영역 사이의 최장 공통 서픽스이므로 myapp.prod.gcp.example.com에 대한 쿼리는 비공개 영역 gcp.example.com의 레코드에 따라 확인됩니다.

분할된 범위의 DNS 예시

분할된 범위의 DNS 구성에서 공개 영역과 비공개 영역의 조합을 사용할 수 있습니다. 비공개 영역을 사용 설정하면 승인된 VPC 네트워크 내의 VM에서 쿼리 발생 시 동일한 레코드의 쿼리에 대해 서로 다른 응답을 정의할 수 있습니다. 출처 VPC 네트워크에 따라 동일한 DNS 쿼리에 대해 다른 레코드를 제공해야 할 때 분할된 범위의 DNS가 유용합니다.

다음 분할된 범위 예시를 고려하세요.

  • 공개 영역 gcp.example.com을 만들고 등록기관에서 Cloud DNS 네임서버를 사용하도록 구성했습니다.
  • 비공개 영역 gcp.example.com을 만들고 VPC 네트워크가 이 영역에 액세스하도록 승인했습니다.

비공개 영역에서 다음 표에 표시된 것처럼 단일 레코드를 만들었습니다.

레코드 유형 TTL(초) 데이터
foo.gcp.example.com A 5 10.128.1.35

공개 영역에서 두 개의 레코드를 만들었습니다.

레코드 유형 TTL(초) 데이터
foo.gcp.example.com A 5 104.198.6.142
bar.gcp.example.com A 50 104.198.7.145

다음 쿼리가 설명된 대로 해결됩니다.

  • VPC 네트워크의 VM에서 foo.gcp.example.com을 쿼리하면 10.128.1.35가 반환됩니다.
  • 인터넷에서 foo.gcp.example.com을 쿼리하면 104.198.6.142가 반환됩니다.
  • VPC 네트워크의 VM에서 bar.gcp.example.com을 쿼리하면 비공개 영역 gcp.example.combar.gcp.example.com에 대한 레코드가 없기 때문에 NXDOMAIN 오류가 반환됩니다.
  • 인터넷에서 bar.gcp.example.com을 쿼리하면 104.198.7.145가 반환됩니다.

액세스 제어

Google Cloud Console의 IAM 및 관리 페이지에서는 DNS 레코드 변경이 허용된 사용자를 관리할 수 있습니다. 사용자가 항목을 변경할 수 있으려면 Cloud Console의 권한 섹션에서 편집자 역할(roles/editor) 또는 소유자 역할(roles/owner)을 지정해야 합니다. 뷰어 역할(roles/viewer)은 Cloud DNS 레코드에 대해 읽기 전용 액세스 권한을 부여합니다.

이러한 권한은 DNS 서비스 관리에 사용할 수 있는 서비스 계정에도 적용됩니다.

관리형 영역에 대한 액세스 제어

프로젝트 소유자 역할 또는 편집자 역할이 있는 사용자는 관리 중인 특정 프로젝트의 관리형 영역을 관리하거나 볼 수 있습니다.

DNS 관리자 역할 또는 DNS 리더 역할(roles/dns.admin 또는 roles/dns.reader)이 있는 사용자는 액세스 권한이 있는 모든 프로젝트에서 관리형 영역을 관리하거나 볼 수 있습니다.

프로젝트 소유자, 편집자, DNS 관리자, DNS 리더는 현재 프로젝트의 모든 VPC 네트워크에 적용된 비공개 영역 목록을 볼 수 있습니다.

성능 및 타이밍

Cloud DNS는 고가용성을 위해 anycast를 사용하여 전 세계의 여러 위치에서 관리형 영역을 제공합니다. 요청은 자동으로 가장 가까운 위치로 라우팅되므로, 지연 시간이 줄어들고 사용자의 권한 이름 조회 성능이 향상됩니다.

변경사항 전파

변경사항은 두 가지 부분으로 전파됩니다. 먼저 API 또는 명령줄 도구를 통해 전송되는 변경사항을 Cloud DNS의 권한 DNS 서버로 푸시해야 합니다. 두 번째로, 레코드의 캐시가 만료되면 DNS 리졸버가 이 변경사항을 선택해야 합니다.

레코드에 설정하는 초 단위로 지정되는 TTL(수명) 값은 DNS 리졸버의 캐시를 제어합니다. 예를 들어, TTL 값을 86400(24시간을 초로 환산한 값)으로 설정하면 DNS 리졸버가 24시간 동안 레코드를 캐시합니다. 일부 DNS 리졸버는 TTL 값을 무시하거나 자체 값을 사용하여 레코드의 전체 전파를 지연시킬 수 있습니다.

짧은 기간이 필요한 서비스 변경을 계획 중이면 항목을 변경하기 전 TTL을 더 짧은 값으로 변경해야 할 수 있습니다. 이 접근방식은 캐싱 기간을 줄이고 새 레코드 설정을 더욱 빠르게 변경할 수 있습니다. 변경 후에는 값을 이전 TTL 값으로 변경하여 DNS 리졸버의 부하를 줄일 수 있습니다.

다음 단계