개요

이 페이지에서는 Cloud DNS의 특징과 기능을 간략히 설명합니다. Cloud DNS 사용을 시작하려면 빠른 시작을 참조하세요.

소개

Cloud DNS는 비용 효율적인 방식으로 도메인 이름을 전역 DNS에 게시하는 복원력이 우수한 고성능 전역 DNS(도메인 이름 시스템) 서비스입니다.

개념

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

일반 DNS 개념

일반 DNS 용어 목록에 대해서는 RFC 7719를 참조하세요.

Cloud DNS는 공개 및 비공개 관리형 DNS 영역을 모두 제공합니다. 공개 영역은 공용 인터넷에서 노출되지만 비공개 영역은 지정된 VPC 네트워크 하나 이상에서만 노출됩니다.

VPC 네트워크와 관련된 다른 DNS 레코드 모음으로 비공개 영역을 만들 수 있으므로, 비공개 영역을 사용 설정하면 분할된 범위의 DNS 구성을 만들 수 있습니다.

Cloud DNS 개념

Cloud DNS API는 프로젝트, 관리형 영역, 레코드 모음, 레코드 모음의 변경사항을 토대로 빌드됩니다.

프로젝트
Google Cloud Platform Console 프로젝트는 리소스 컨테이너이자 액세스 제어를 위한 도메인이고 결제가 구성되고 집계되는 곳입니다. 모든 Cloud DNS 리소스가 프로젝트 내에 상주하며, 모든 Cloud DNS 작업에서는 사용할 프로젝트를 지정해야 합니다.
관리형 영역
관리형 영역은 DNS 이름 서픽스(예: example.com)가 동일한 DNS 레코드를 보관합니다. 프로젝트 한 개에 관리형 영역이 여러 개 있을 수 있지만, 각 영역마다 고유한 이름을 가져야 합니다. Cloud DNS에서 관리형 영역은 DNS 영역을 모델링하는 리소스입니다. 관리형 영역의 모든 레코드는 Google이 운영하는 동일한 네임서버에 호스팅됩니다. 이러한 네임서버는 영역 구성 방식에 따라 관리형 영역에 대한 DNS 쿼리에 응답합니다. 프로젝트 한 개에 관리형 영역이 여러 개 포함될 수 있습니다. 관리형 영역이 존재하는 기간 동안 매일 각 영역별로 요금이 청구됩니다. 관리형 영역은 라벨을 지원하며, 이러한 라벨은 결제를 구성하는 데 사용됩니다. 영역 관리 섹션에서는 영역 내 레코드를 관리하는 방법을 설명합니다.
공개 영역(zone)

공개 영역은 인터넷에 노출됩니다. Cloud DNS에는 쿼리의 출처와 관계없이 공개 영역에 대한 쿼리에 응답하는 공개 권한 네임서버가 있습니다. 공개 영역에 DNS 레코드를 만들어 인터넷에 서비스를 게시할 수 있습니다. 예를 들어, 공개 영역 example.com에 공개 웹사이트 www.example.com에 대한 다음 레코드를 만들 수 있습니다.

DNS 이름 유형 TTL(초) 데이터
www.example.com A 300 [public_ip_address]

공개 영역이 생성되면 Cloud DNS는 일련의 네임서버를 할당합니다. 공개 영역의 DNS 레코드를 인터넷을 통해 확인하려면 등록기관에서 도메인 등록의 네임서버 설정을 업데이트해야 합니다.

비공개 영역(zone)

비공개 영역을 사용 설정하면 기본 DNS 데이터를 공용 인터넷에 노출시키지 않고도 가상 머신, 부하 분산기, 기타 GCP 리소스의 커스텀 도메인 이름을 관리할 수 있습니다. 비공개 영역은 승인된 VPC 네트워크 하나 이상에서만 쿼리할 수 있는 DNS 레코드의 컨테이너입니다.

비공개 영역은 정의된 동일한 프로젝트의 리소스에서만 쿼리할 수 있습니다. 승인된 VPC 네트워크가 비공개 영역과 동일한 프로젝트에 있어야 합니다. 다른 네트워크와 DNS 피어링을 설정하여 이 제한사항을 재정의할 수 있습니다.

비공개 영역 생성 또는 업데이트 시 비공개 영역에 쿼리할 수 있는 승인된 VPC 네트워크의 목록을 지정합니다. 승인된 네트워크만 비공개 영역에 쿼리할 수 있습니다. 즉, 승인된 네트워크를 지정하지 않으면 비공개 영역에 전혀 쿼리할 수 없습니다.

공유 VPC와 함께 비공개 영역을 사용할 수 있습니다. 공유 VPC 네트워크와 함께 비공개 영역을 사용하는 방법에 대한 자세한 내용은 이 페이지의 비공개 영역 및 공유 VPC를 참조하세요.

비공개 영역은 DNSSEC(DNS Security Extensions)을 지원하지 않습니다.

비공개 영역의 DNS 레코드 요청은 Google 제공 이미지로 만든 VM의 기본 내부 네임서버인 메타데이터 서버 169.254.169.254를 통해 제출되어야 합니다. 승인된 VPC 네트워크를 사용하는 모든 VM에서 이 네임서버에 쿼리를 제출할 수 있습니다.

예를 들어, 시험용 애플리케이션의 내부 DNS 레코드를 호스팅하기 위해 dev.gcp.example.com에 대한 비공개 영역을 만들 수 있습니다. 다음 테이블은 해당 영역의 레코드 예제를 보여줍니다. 데이터베이스 클라이언트는 IP 주소 대신 내부 DNS 이름을 사용하여 데이터베이스 서버 db-01.dev.gcp.example.com에 연결될 수 있습니다. 데이터베이스 클라이언트는 DNS 쿼리를 메타데이터 서버 169.254.169.254에 제출하는 VM의 호스트 리졸버를 사용하여 이 내부 DNS 이름을 확인합니다. 메타데이터 서버는 비공개 영역에 쿼리하기 위한 반복 리졸버로 작동합니다.

DNS 이름 유형 TTL(초) 데이터
db-01.dev.gcp.example.com A 5 10.128.1.35
instance-01.dev.gcp.example.com A 50 10.128.1.10
전달 영역

전달 영역은 Cloud DNS 관리형 비공개 영역의 한 유형으로 해당 영역에 대한 요청은 전달 대상의 IP 주소로 전송됩니다. 자세한 내용은 DNS 전달을 참조하세요.

피어링 영역

피어링 영역은 Cloud DNS 관리형 비공개 영역의 한 유형으로 다른 VPC 네트워크의 이름 확인 순서를 따르며 다른 VPC 네트워크에 정의된 이름을 확인하는 데 사용됩니다.

영역 작업

Cloud DNS의 관리형 영역에 대한 변경사항은 작업 컬렉션에 기록되며, 여기에는 관리형 영역 업데이트(설명, DNSSEC 상태 또는 구성 수정)가 나열됩니다.

등록기관

도메인 이름 등록기관은 인터넷 도메인 이름의 예약을 관리하는 조직입니다. 등록기관은 일반 최상위 도메인(gTLD) 레지스트리 또는 국가 코드 최상위 도메인(ccTLD) 레지스트리의 인증을 받아야 합니다.

내부 DNS

Cloud DNS를 사용하지 않더라도 GCP는 VM에 대한 내부 DNS 이름을 자동으로 만듭니다. 내부 DNS에 대한 자세한 내용은 내부 DNS 문서를 참조하세요.

위임된 하위 영역

DNS를 사용하면 영역 소유자가 NS 레코드를 사용하여 하위 도메인을 다른 네임서버에 위임할 수 있습니다. 리졸버는 이러한 레코드를 따르고 하위 도메인에 대한 쿼리를 위임에서 지정된 타겟 네임서버로 전송합니다.

리소스 레코드 모음 컬렉션

리소스 레코드 모음 컬렉션에는 관리형 영역을 구성하는 DNS 레코드의 현재 상태가 저장됩니다. 이 컬렉션을 읽을 수 있지만 직접 수정할 수는 없습니다. 대신 변경사항 컬렉션에 Change 요청을 만들어 관리형 영역에 있는 리소스 레코드 모음을 편집합니다. 리소스 레코드 모음 컬렉션은 모든 변경사항을 즉시 반영합니다. 그러나 API에서 변경되는 시점과 권한 DNS 서버에서 적용되는 시점 사이에 지연이 발생합니다. 레코드 관리 섹션에서는 레코드 관리 방법을 설명합니다.

리소스 레코드 변경

리소스 레코드 모음 컬렉션을 변경하려면 추가 또는 삭제가 포함된 Change 요청을 제출합니다. 추가 및 삭제는 단일 원자성 트랜잭션에서 일괄적으로 수행될 수 있으며 각 권한 DNS 서버에서 동시에 적용됩니다.

예를 들어 다음과 같은 A 레코드가 있다고 가정하겠습니다.

www  A  203.0.113.1 203.0.113.2

그리고 다음과 같은 명령어를 실행합니다.

DEL  www  A  203.0.113.2
ADD  www  A  203.0.113.3

그러면 레코드는 일괄 변경 후 다음과 같이 표시됩니다.

www  A  203.0.113.1 203.0.113.3

ADD 및 DEL은 동시에 실행됩니다.

SOA 일련번호 형식

Cloud DNS 관리형 영역에서 생성된 SOA 레코드의 일련번호는 gcloud dns record-sets transaction 명령어를 사용하여 영역의 레코드 모음에 대한 트랜잭션이 변경될 때마다 일정하게 증가합니다. 그러나 SOA 레코드의 일련번호를 RFC 1912에서 권장하는 ISO 8601 형식의 날짜를 포함한 임의의 번호로 직접 자유롭게 변경할 수 있습니다. 다음 SOA 레코드를 예로 들어보면,

ns-gcp-private.googledomains.com. cloud-dns-hostmaster.google.com. [serial number] 21600 3600 259200 300

레코드에서 공백으로 분리된 세 번째 필드에 원하는 값을 입력하여 Google Cloud Platform Console에서 직접 일련번호를 변경할 수 있습니다.

DNS 서버 정책

DNS 서버 정책을 사용하면 인바운드 전달을 통해 VPC 네트워크에서 GCP가 제공하는 이름 확인 서비스에 액세스하거나 아웃바운드 전달을 통해 VPC 이름 확인 순서를 변경할 수 있습니다.

도메인, 하위 도메인, 위임

대부분의 하위 도메인은 관리형 영역에 있는 상위 도메인의 레코드일뿐입니다. 상위 도메인의 영역에 NS(네임서버) 레코드를 만들어 위임된 하위 도메인에는 자체 영역도 필요합니다. 위임된 하위 도메인의 영역을 만들기 전에 Cloud DNS에서 상위 도메인의 관리형 영역을 만듭니다. 다른 DNS 서비스에 상위 도메인을 호스팅하는 경우에도 이 작업을 수행해야 합니다. 하위 도메인 영역이 여러 개 있는 경우 상위 영역을 만들지 않으면 나중에 Cloud DNS로 이동하려고 할 때 상위 영역을 만드는 것이 복잡해질 수 있습니다.

DNSSEC

DNSSEC(Domain Name System Security Extension)는 도메인 이름 조회에 대한 응답을 인증하는 DNS에 대한 IETF(Internet Engineering Task Force) 확장 기능을 모아놓은 것입니다. DNSSEC는 이러한 조회에 대해 개인정보 보호를 제공하지 않지만 공격자가 DNS 요청에 대한 응답을 조작하거나 악성 처리하는 것을 방지합니다.

DNSKEY 컬렉션

DNSKEY 컬렉션에는 DNSSEC 사용 설정 관리형 영역에 서명하는 데 사용되는 DNSKEY 레코드의 현재 상태가 저장됩니다. 이 컬렉션은 읽는 것만 가능합니다. 즉, DNSKEY에 대한 모든 변경사항은 Cloud DNS에서 수행됩니다. DNSKEY 컬렉션에는 도메인 등록기관이 DNSSEC를 활성화하는 데 필요한 모든 정보가 있습니다.

VPC 이름 확인 순서

각 VPC 네트워크는 서비스를 사용하는 VM 인스턴스에 DNS 이름 확인 서비스를 제공합니다. VM이 메타데이터 서버 169.254.169.254를 네임서버로 사용하면 GCP는 다음 순서에 따라 DNS 레코드를 검색합니다.

  1. 아웃바운드 전달을 위한 대체 네임서버를 지정하는 DNS 정책이 VPC 네트워크에 대해 구성된 경우, GCP는 모든 DNS 쿼리를 해당 서버에만 전달합니다. 자세한 내용은 대체 네임서버를 사용하여 아웃바운드 DNS 전달을 참조하세요.
  2. GCP는 최장 서픽스 일치를 통해 다음 GCP 이름 확인 서비스에 이 순서로 쿼리합니다.
    • GCP는 전달 타겟의 IP 주소로 요청을 전송하여 VPC 네트워크에 대해 승인된 모든 Cloud DNS 관리형 비공개 전달 영역을 쿼리합니다.
    • GCP는 해당 영역의 레코드를 위해 VPC 네트워크에 대해 승인된 모든 Cloud DNS 관리형 비공개 영역을 쿼리합니다.
    • GCP는 자동으로 생성된 Compute Engine 내부 DNS 레코드에서 프로젝트를 검색합니다.
  3. GCP는 적절하게 구성된 SOA(Start-Of-Authority)에 따라 공개적으로 사용 가능한 영역을 쿼리합니다. 여기에는 Cloud DNS 공개 영역이 포함됩니다.

비공개 영역에 PTR 레코드 사용

RFC 1918 주소의 PTR 레코드

VPC 이름 확인 순서의 설명대로 가장 긴 프리픽스가 일치하므로 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 레코드가 Compute Engine 내부 DNS에서 자동으로 만든 PTR 레코드에 의해 재정의됩니다. 이는 Compute Engine 내부 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. Compute Engine 내부 DNS 영역에서 응답합니다. test.example.domain의 Cloud DNS 비공개 영역에서 PTR 레코드는 무시됩니다.

VM에 대해 자동으로 생성된 Compute Engine 내부 DNS PTR 레코드를 재정의하려면 최소한 이 섹션에 나와 있는 영역 중 하나와 같이 구체적인 비공개 영역에서 커스텀 PTR 레코드를 만들어야 합니다. 예를 들어 10.in-addr.arpa.의 비공개 영역에서 다음 PTR 레코드를 만드는 경우 자동으로 생성된 레코드를 재정의합니다.

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

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

RFC 1918 외 주소의 PTR 레코드

RFC 1918 외 주소의 PTR 레코드는 자동으로 생성된 Compute Engine 내부 DNS PTR 레코드와 충돌하지 않습니다.

VPC 이름 확인 순서에 따라 비공개 영역은 인터넷에 공개된 사용 가능한 영역보다 먼저 쿼리됩니다.

예를 들어 공용 인터넷에서 PTR IN 2.2.0.192.in-addr.arpa 쿼리가 example.com을 반환하지만 VPC 네트워크 하나 이상에서 VM 인스턴스에 대해 이 값을 재정의한다고 가정해 보겠습니다. 이는 DNS 이름이 in-addr.arpa인 비공개 영역을 만들고 다음 PTR 레코드를 해당 영역에 추가하여 완료할 수 있습니다.

2.2.0.192.in-addr.arpa -> test.com

이 비공개 영역에서 쿼리하도록 승인된 VPC 네트워크에 있는 VM이 PTR IN 2.2.0.192.in-addr.arpa를 쿼리하면 example.com 대신 test.com 응답이 수신됩니다.

공개 영역에 PTR 레코드 사용

RFC 1918 외 주소의 공개 영역을 쿼리하려면 루트에서 위임된 IP 블록의 in-addr.arpa 공간의 일부를 Cloud DNS 네임서버에 위임해야 합니다.

역방향 DNS 구성에 대한 자세한 내용은 여기에서 확인하세요. 단, 역방향 DNS를 구성하는 정확한 단계는 레지스트리 연산자에 따라 다릅니다.

지원되는 DNS 레코드 유형

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

레코드 유형 설명
A

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

AAAA

IPv6 주소 레코드입니다. 호스트 이름을 IPv6 주소로 매핑하는 데 사용됩니다.

CAA

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

CNAME

표준 이름 레코드입니다. 별칭 이름을 지정하는 데 사용됩니다.
Cloud DNS는 다양한 관리형 비공개 영역(CNAME 추적) 전반에서 재귀적으로 CNAME 해결을 지원하지 않습니다. 자세한 내용은 문제해결을 참조하세요.

IPSECKEY

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

MX

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

NAPTR

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

NS

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

PTR

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

SOA

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

SPF

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

SRV

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

SSHFP

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

TLSA

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

TXT

텍스트 레코드입니다. 임의 텍스트가 포함될 수 있으며 보안 또는 악용 방지 정보와 같은 머신이 읽을 수 있는 데이터를 정의하는 데 사용됩니다. TXT 레코드 한 개에 텍스트 문자열을 한 개 이상 포함할 수 있으며, 각 개별 문자열 최대 길이는 255자(영문)입니다. 메일 에이전트와 기타 소프트웨어 에이전트는 여러 문자열을 연결합니다. 각 문자열을 따옴표로 묶습니다. 예를 들면 다음과 같습니다.


"Hello world" "Bye world"

레코드 관리는 DNS 레코드 작업 방법을 보여줍니다.

와일드 카드 DNS 레코드

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

DNSSEC

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

이 명령어를 사용하면 관리형 영역에 DNSSEC를 사용 설정할 수 있습니다.

gcloud dns managed-zones update my-zone --dnssec-state on

새로 생성된 영역에도 DNSSEC를 사용 설정할 수 있습니다.

gcloud dns managed-zones create my-zone \
    --description "Signed Zone" --dns-name myzone.example --dnssec-state=on

또한 기본 설정이 배포에 적합하지 않은 경우, 지정할 수 있는 여러 가지 DNSSEC 매개변수가 있습니다.

DNS 전달

GCP 외 네임서버와 GCP의 내부 네임서버 사이에 DNS 전달을 설정할 수 있습니다. 양방향 전달을 구성하면 VPC 네트워크의 인스턴스에서 온프레미스 또는 다중 클라우드 네트워크에 있는 호스트의 주소를 조회할 수 있고 연결된 네트워크의 호스트에서 VPC 네트워크의 리소스 주소를 조회할 수 있습니다.

GCP는 다음과 같은 방법으로 DNS 전달을 지원합니다.

  • VPC 네트워크는 DNS 서버 정책을 사용하여 인바운드 및 아웃 바운드 DNS 전달을 모두 지원합니다. 인바운드 요청은 온프레미스 데이터 센터와 같이 Cloud VPN 터널 또는 Cloud Interconnect를 통해 VPC에 연결된 네트워크의 시스템에서 발생해야 합니다.

  • Cloud DNS 비공개 관리형 영역은 전달 영역을 통해 아웃바운드 DNS 전달을 지원합니다.

다음 예는 DNS 전달이 구성된 VPC 네트워크 두 개(proddev)를 보여줍니다.

온프레미스 DNS 서버를 사용하여 DNS 전달(확대하려면 클릭)
온프레미스 DNS 서버를 사용하여 DNS 전달(확대하려면 클릭)
  • dev 네트워크는 동적 라우팅을 사용하는 Cloud VPN 터널을 통해 유럽의 온프레미스 데이터 센터와 연결됩니다.
  • prod 네트워크는 동적 라우팅을 사용하는 Cloud VPN 터널을 통해 아시아, 유럽, 미국의 온프레미스 데이터 센터와 연결됩니다.
  • 모든 네트워크는 전역 동적 라우팅을 사용하도록 구성되었습니다.
  • 데이터 센터 세 개 모두 서로 연결되어 있습니다. 각 온프레미스와 VPC 네트워크에서 사용되는 IP 주소는 RFC 1918 IP 주소이며 중첩되지 않습니다.
  • 온프레미스 BIND 서버는 각 온프레미스 데이터 센터에 위치하며, 이러한 네임서버는 corp.example.com 영역에 서비스를 제공하기 위해 중복 방식으로 구성되어 있습니다.
  • 온프레미스 네임서버에 아웃바운드 전달을 사용 설정하기 위해 devprod Cloud VPN 네트워크 모두에 대한 DNS 정책을 만들어야 합니다.
  • GCP의 VM은 메타데이터 서버 169.254.169.254를 사용하여 GCP 내부 DNS, 해당 dev 또는 prod 네트워크의 승인된 Cloud DNS 비공개 영역, 공개 DNS 영역, 온프레미스 corp.example.com 영역을 확인합니다.

DNS 서버 정책

DNS 서버 정책을 사용하면 VPC 네트워크의 인바운드 및 아웃바운드 DNS 전달을 구성할 수 있습니다. 주어진 VPC 네트워크에 DNS 서버 정책 한 개를 적용할 수 있습니다.

단계별 지침은 DNS 서버 정책 사용을 참조하세요.

인바운드 DNS 전달

각 VPC 네트워크는 서비스를 사용하는 VM 인스턴스에 DNS 이름 확인 서비스를 제공합니다. VM이 메타데이터 서버(169.254.169.254)를 네임서버로 사용하면 GCP는 VPC 이름 확인 순서에 따라 DNS 레코드를 검색합니다.

기본적으로 해당 네트워크 외부에서 VPC 네트워크의 이름 확인 서비스를 사용할 수 없습니다. VPC 네트워크로의 인바운드 DNS 전달을 사용 설정하는 DNS 정책을 만들면 Cloud VPN 또는 Cloud Interconnect를 통해 연결된 온프레미스 네트워크의 시스템에서 이름 확인 서비스를 사용할 수 있습니다. 이 기능을 사용 설정하면 연결된 네트워크의 시스템이 이름 확인 서비스를 사용하기 위해 VPC 네트워크의 내부 IP 주소를 쿼리할 수 있습니다.

VPC 네트워크에 인바운드 전달을 허용하는 DNS 정책을 구성하는 방법은 인바운드 DNS 전달을 사용 설정하는 DNS 정책 만들기를 참조하세요. 이 정책을 구성하면 GCP가 인바운드 DNS 요청에 대한 프록시 역할을 하도록 VPC 네트워크 서브넷(리전 내)의 내부 IP 주소를 할당합니다. 리전을 지정하거나 GCP가 자동으로 리전을 선택하도록 할 수 있습니다. 인바운드 DNS 전달을 위한 각 DNS 정책은 인바운드 요청에 대해 단일 프록시 IP 주소를 할당합니다. 그러나 이 단일 IP 주소는 VPC 네트워크의 이름 확인 서비스로의 진입점 역할만 수행합니다. 그런 다음 필요에 따라 온프레미스 네임서버가 프록시 주소로 전달하도록 온프레미스 네임서버를 구성할 수 있습니다.

대체 네임서버를 사용한 아웃바운드 DNS 전달

대체 네임서버 목록을 지정하는 DNS 정책을 만들어 VPC 이름 확인 순서를 변경할 수 있습니다. 이렇게 하면 대체 네임서버가 메타데이터 서버(169.254.169.254)를 사용하여 VPC에서 VM이 제출한 모든 DNS 요청에 대해 GCP가 쿼리하는 유일한 원본이 됩니다.

아웃바운드 전달을 위해 DNS 정책을 구성하는 방법에 대해서는 대체 네임서버를 사용 설정하는 DNS 정책 만들기를 참조하세요. RFC 1918 IP 주소를 사용하는 대체 네임서버를 지정하는 경우, VPC 네트워크의 다른 GCP VM의 내부 IP 주소이거나 Cloud VPN 또는 Cloud Interconnect를 통해 VPC 네트워크에 연결된 온프레미스 네트워크에 있는 시스템의 IP 주소여야 합니다. 공개 IP 주소를 사용하는 대체 네임서버를 지정하는 경우, 인터넷에서 해당 주소에 액세스할 수 있어야 합니다.

DNS 전달 영역

대체 네임서버 외에도 전달 영역을 정의하여 다른 형태의 아웃바운드 DNS 전달을 사용할 수 있습니다. 이는 DNS 이름과 연결되어 있고 여러 네트워크에 바인딩될 수 있다는 점에서 비공개 영역 설정과 유사합니다. 그러나 전달 영역에는 레코드가 없습니다. 전달 영역에 대한 일치하는 모든 쿼리는 대신 일련의 대상 DNS 서버에 전달됩니다. 대체 네임서버의 경우와 마찬가지로 대상은 IP 주소 목록입니다.

시스템은 모든 대상 네임서버를 통해 이름을 확인하려 합니다. 위의 예에서 일치하는 쿼리는 172.16.1.28, 172.16.4.34, 172.16.8.50 모두 또는 이들 중 일부에 전달됩니다. 시스템은 서버 응답성 및 네트워크 조건 변동에 따라 확인 전략을 변경할 수 있습니다.

여러 전달 영역의 전달 조건이 서로 중첩되면 쿼리에 최장 일치하는 영역이 다른 영역보다 우선 시 됩니다. 예를 들어, DNS 서버에 다음과 같은 세 가지 전달 영역이 있다고 가정합니다.

  • 전달 영역 1: onprem.example.com, 대상: 172.16.8.40
  • 전달 영역 2: dev.onprem.example.com, 대상: 172.16.8.50
  • 전달 영역 3: prod.onprem.example.com, 대상: 172.16.8.60

mysvc.onprem.example.com에 대한 쿼리는 영역 1에 따라 172.16.8.40에 전달됩니다. mysvc.dev.onprem.example.com에 대한 쿼리는 영역 2에 따라 172.16.8.50에 전달됩니다. mysvc.prod.onprem.example.com에 대한 쿼리는 영역 3에 따라 172.16.8.60에 전달됩니다.

자세한 내용은 전달 영역 만들기를 참조하세요.

DNS 피어링

DNS 피어링을 사용하면 한 영역의 네임스페이스에 있는 레코드의 요청을 다른 VPC 네트워크에 전달할 수 있습니다.

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

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

승인되면 DNS 소비자 네트워크의 GCP 리소스는 DNS 공급자 네트워크에 있는 것처럼 피어링 영역의 네임스페이스에서 레코드를 조회할 수 있습니다. 피어링 영역 네임스페이스의 레코드 조회는 DNS 공급자 네트워크의 이름 확인 순서를 따릅니다. 따라서 DNS 소비자 네트워크의 GCP 리소스는 DNS 공급자 네트워크에서 사용할 수 있는 다음 소스의 레코드를 영역 네임스페이스에서 조회할 수 있습니다.

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

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

  • DNS 피어링은 단방향 관계입니다. 따라서 DNS 소비자 네트워크의 GCP 리소스는 DNS 공급자 네트워크에 있는 것처럼 피어링 영역의 네임스페이스에서 레코드를 조회할 수 있습니다.
  • DNS 공급자 및 소비자 네트워크는 GCP VPC 네트워크여야 합니다.
  • DNS 피어링과 VPC 네트워크 피어링은 다른 서비스입니다. DNS 피어링은 VPC 네트워크 피어링과 함께 사용할 수 있지만 VPC 네트워크 피어링은 DNS 피어링에 필요하지 않습니다.

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

사용 사례

SaaS 예

SaaS 제공업체(공급자)가 SaaS 고객(소비자)에게 피어링된 네트워크에서 호스팅되는 서비스에 대한 액세스 권한을 부여하고자 합니다. 공급자는 서비스를 호스팅하는 네트워크를 만든 후 소비자 네트워크와 피어링합니다. 또한 공급자는 소비자가 서비스에 액세스하기 위해 사용하는 DNS 이름을 제공하기를 원합니다.

소비자는 공급자가 소비자 네트워크에서 피어링 영역을 만들기 위해 사용할 수 있는 서비스 계정을 사용할 권한을 공급자에게 부여할 수 있습니다. 또한 공급자는 해당 서비스 계정에 자체 네트워크의 dns.peer 역할도 부여하므로, 피어링 영역의 요청이 리졸버 영역에 도달할 수 있습니다. 또는 공급자는 소비자가 올바른 설정할 수 있도록 안내할 수도 있습니다.

조직 내 설정

동일한 프로젝트에 있는 여러 VPC 네트워크에서 사용할 수 있도록 Cloud DNS 관리형 비공개 영역을 승인할 수 있습니다. 하지만 조직 내 여러 프로젝트 간에 DNS 영역을 공유해야 합니다.

하나의 공급자 네트워크에 대해 승인된 하나의 관리형 비공개 영역을 만들기 위해 DNS 피어링을 사용할 수 있습니다. 그런 다음 서로 다른 프로젝트에 있는 각 소비자 네트워크에 대해 승인된 동일한 네임스페이스에 사용할 만큼 충분한 수의 피어링 영역을 만듭니다. 동일한 공급자 네트워크를 사용하도록 각 피어링 영역을 구성하면 소비자 네트워크의 GCP 리소스가 공급자 네트워크의 이름 확인 순서를 따르게 됩니다. 이렇게 하면 공급자 네트워크에 대해 승인된 모든 관리형 비공개 영역의 네임스페이스에서 레코드를 확인할 수 있게 됩니다.

피어링 영역의 다음 단계

자세한 내용은 피어링 영역 구성을 참조하세요.

비공개 영역(zone) 및 공유 VPC

Shared VPC와 함께 비공개 영역을 사용하려면 호스트 프로젝트에서 비공개 영역을 만들어야 하고, 해당 공유 VPC 네트워크를 해당 영역에 승인된 네트워크 목록에 추가해야 합니다.

중첩 영역(zone)

프로젝트 한 개에 관리형 영역이 여러 개 포함될 수 있습니다. 한 영역의 원본 도메인 이름이 다른 영역의 원본과 같거나 하위 도메인인 경우에는 두 영역이 서로 중첩됩니다. 예를 들어, dev.gcp.example.com과 gcp.example.com은 중첩 영역입니다.

동일한 Cloud DNS 네임서버에는 중첩 공개 영역이 허용되지 않습니다. 중첩 영역을 만들면 Cloud DNS가 해당 영역을 대체 네임서버에 배치하려 합니다. 그렇게 할 수 없으면 중첩 영역 만들기가 실패합니다.

공개 영역과 비공개 영역 간에 중첩이 허용됩니다.

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

중첩 영역이 있는 쿼리 확인

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

다음 예는 DNS 레코드 쿼리 시 메타데이터 서버가 사용하는 순서를 보여줍니다. 이러한 예 각각에 대해 비공개 영역을 두 개(gcp.example.comdev.gcp.example.com)를 만들었고 동일한 VPC 네트워크에서 이 영역에 액세스할 수 있도록 승인됐다고 가정합니다. 그러면 GCP가 VPC 네트워크에 있는 VM의 DNS 쿼리를 처리합니다.

  • example.com에 대한 비공개 영역이 없으므로, 메타데이터 서버가 공개 네임서버를 사용하여 myapp.example.com을 확인합니다.
  • gcp.example.com이 요청된 DNS 레코드와 사용 가능한 비공개 영역 사이의 최장 공통 서픽스이므로, 메타데이터 서버가 비공개 영역 gcp.example.com을 사용하여 myapp.gcp.example.com을 확인합니다. 공개 네임서버에서 정의된 myapp.gcp.example.com에 대한 레코드가 있더라도 gcp.example.com 비공개 영역에서 정의된 myapp.gcp.example.com에 대한 레코드가 없다면 NXDOMAIN이 반환됩니다.
  • 마찬가지로, myapp.dev.gcp.example.com에 대한 쿼리는 비공개 영역 dev.gcp.example.com의 레코드에 따라 확인됩니다. 다른 비공개 또는 공개 영역에 myapp.dev.gcp.example.com에 대한 레코드가 있더라도 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에서 쿼리 발생 시 동일한 레코드의 쿼리에 대해 서로 다른 응답을 정의할 수 있습니다. 분할된 범위의 DNS는 개발, 기업, 프로덕션 VPC 네트워크가 별도인 경우에 유용합니다.

  • 비공개 영역을 정의하고 개발 VPC 네트워크에서 액세스할 수 있도록 승인하면 해당 네트워크의 VM에서 해당 영역의 DNS 레코드에 대한 쿼리가 동일한 네트워크의 다른 VM에 전달될 수 있습니다.
  • 기업 네트워크의 액세스를 승인하여 다른 응답으로 동일한 DNS 레코드(이름)를 제공하는 두 번째 비공개 영역을 정의할 수 있습니다.
  • 프로덕션에 적합한 공개 응답으로 동일한 DNS 레코드를 제공하는 세 번째 공개 영역을 정의할 수 있습니다.

예를 들어, gcp.example.com에 대해 공개 영역과 비공개 영역을 모두 만들고, Cloud DNS 네임서버를 사용하도록 gcp.example.com에 대한 등록기관을 구성하여 인터넷에서 공개 영역에 액세스할 수 있도록 하고 VPC 네트워크에서 비공개 영역에 액세스할 수 있도록 승인했다고 가정합니다.

비공개 영역에서 단일 레코드를 만듭니다.

DNS 이름 유형 TTL(초) 데이터
foo.gcp.example.com A 5 10.128.1.35

공개 영역에서 레코드 두 개를 만듭니다.

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

다음 예는 DNS 레코드에 대한 쿼리가 어떻게 확인되는지 보여줍니다.

  • 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 Platform Console의 IAM 및 관리자 페이지에서 DNS 레코드를 변경할 수 있는 사용자를 관리할 수 있습니다. 변경 권한이 있는 사용자는 GCP Console의 권한 섹션에서 editor 또는 owner로 나열되어야 합니다. 뷰어 권한 수준은 Cloud DNS 레코드에 대한 읽기 전용 액세스 권한을 부여합니다.

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

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

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

DNS 관리자 또는 DNS 리더 역할을 가진 사용자는 액세스 권한이 있는 모든 프로젝트에서 관리형 영역을 관리 또는 볼 수 있습니다.

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

성능과 타이밍

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

변경사항 전파

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

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

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

다음 단계

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

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

Cloud DNS 문서