Cloud DNS 개요

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

소개

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

개념

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

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

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

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

공유 VPC 고려사항

Cloud DNS 관리형 비공개 영역, Cloud DNS 전달 영역, 공유 VPC와 함께 사용하는 Cloud DNS 피어링 영역을 사용하려면 호스트 프로젝트에서 영역을 만든 다음 해당 영역에 대해 승인된 네트워크 목록에 적절한 공유 VPC 네트워크를 추가해야 합니다.

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

VPC 이름 확인 순서

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

  • VPC 네트워크에 아웃바운드 서버 정책이 있는 경우 Google Cloud는 모든 DNS 쿼리를 해당 대체 서버로 전달합니다. VPC 이름 확인 순서는 이 단계로만 구성됩니다.

  • VPC 네트워크에 아웃바운드 서버 정책이 없는 경우:

    1. Google Cloud는 요청된 레코드와 최대한 일치하는(최장 서픽스 일치) 비공개 영역을 찾습니다. 여기에는 다음이 포함됩니다.
      • 비공개 영역에서 만든 레코드 검색
      • 전달 영역의 전달 대상 쿼리
      • 피어링 영역을 사용하여 다른 VPC 네트워크의 이름 확인 순서 쿼리
    2. Google Cloud는 자동으로 생성된 Compute Engine 내부 DNS 레코드에서 프로젝트를 검색합니다.
    3. Google Cloud는 적절하게 구성된 SOA(Start-Of-Authority)에 따라 공개적으로 사용 가능한 영역을 쿼리합니다. 여기에는 Cloud DNS 공개 영역이 포함됩니다.

DNS 전달 방법

Google Cloud는 비공개 영역에 대한 인바운드 및 아웃바운드 DNS 전달을 제공합니다.

  • 인바운드 전달은 온프레미스 DNS 클라이언트 또는 서버가 Cloud DNS에 DNS 요청을 보낼 수 있도록 설정하는 것을 의미합니다. 그러면 DNS 클라이언트 또는 서버가 VPC 네트워크의 이름 확인 순서에 따라 레코드를 확인할 수 있습니다. 인바운드 전달을 사용하면 온프레미스 클라이언트가 VPC 네트워크가 승인된 비공개 영역, 전달 영역, 피어링 영역의 레코드를 확인할 수 있습니다. 온프레미스 클라이언트는 Cloud VPN 또는 Cloud Interconnect를 사용하여 VPC 네트워크에 연결합니다.

  • 아웃바운드 전달은 Google Cloud의 VM이 선택한 DNS 네임서버에 DNS 요청을 보낼 수 있도록 설정하는 것을 의미합니다. 네임서버는 동일한 VPC 네트워크, 온프레미스 네트워크, 인터넷에 위치할 수 있습니다.

전달 영역을 만들거나 Cloud DNS 서버 정책을 만들어서 DNS 전달을 구성합니다. 두 가지 방법은 다음 표에 요약되어 있습니다.

전달 Cloud DNS 방법
인바운드 VPC 네트워크에 인바운드 서버 정책을 만드는 경우 해당 네트워크의 VPC 이름 확인 순서를 사용하기 위해 온프레미스 시스템이 VPC 네트워크에 요청을 보낼 수 있습니다.
아웃바운드 VPC 네트워크의 VM은 다음과 같이 구성할 수 있습니다.
  • VPC 네트워크에서 사용하도록 승인된 전달 영역의 전달 대상으로 구성된 네임서버에 호스팅된 레코드를 확인합니다. Google Cloud가 트래픽을 전달 대상의 IP 주소로 라우팅하는 방법에 대한 중요한 정보는 전달 대상 및 라우팅 방법을 참조하세요.
  • VPC 네트워크에 대한 아웃바운드 서버 정책을 만들어 모든 DNS 요청을 대체 네임서버에 보냅니다. 대체 네임서버를 사용하면 VPC 네트워크의 VM이 더 이상 Cloud DNS 비공개 영역, 전달 영역, 피어링 영역의 레코드를 확인할 수 없습니다. 자세한 내용은 VPC 이름 확인 순서를 자세히 검토하세요.

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

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

비공개 영역의 PTR 레코드

RFC 1918 주소의 PTR 레코드

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

  • 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 레코드 보관하는 데 사용할 수 있습니다.

지원되는 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에 대한 자세한 내용은 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 네트워크를 통해 라우팅됩니다. 모든 내부 IP 주소. 트래픽은 항상 승인된 VPC 네트워크를 통해 라우팅됩니다. 35.199.192.0/19
유형 2 Cloud VPN 또는 Cloud Interconnect를 사용하여 전달 영역을 쿼리하도록 승인된 VPC 네트워크에 연결된 온프레미스 시스템의 IP 주소 RFC 1918 IP 주소여야 합니다. 트래픽은 항상 승인된 VPC 네트워크를 통해 라우팅됩니다. 모든 내부 IP 주소. 트래픽은 항상 승인된 VPC 네트워크를 통해 라우팅됩니다. 35.199.192.0/19
유형 3 인터넷에 있는 DNS 네임서버의 외부 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 대상의 네트워크 요구 사항에 대한 자세한 안내는 대상 네트워크 요구 사항 전달을 참조하세요.

전달 영역 사용

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

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

중첩 전달 영역

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

캐싱 및 전달 영역

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

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

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

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

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

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

  • VPC 네트워크 피어링을 사용하여 VPC 네트워크 vpc-net-avpc-net-b에 연결했습니다. 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 피어링은 단방향 관계입니다. DNS 소비자 네트워크의 Google Cloud 리소스가 DNS 제작자 네트워크에 있는 것처럼 피어링 영역의 네임스페이스에서 레코드를 조회할 수 있게 해줍니다.
  • DNS 공급자와 소비자 네트워크는 VPC 네트워크여야 합니다.
  • DNS 피어링과 VPC 네트워크 피어링은 다른 서비스입니다. DNS 피어링을 VPC 네트워크 피어링과 함께 사용할 수 있지만 DNS 피어링에 VPC 네트워크 피어링이 필요한 것은 아닙니다.
  • 전환 DNS 피어링은 지원되지만 단일 전환 홉을 통해서만 지원됩니다. 즉, 3개의 이하의 VPC 네트워크(중간 네트워크가 전환 홉)를 포함할 수 있습니다. 예를 들어 vpc-net-avpc-net-b를 대상으로 하는 피어링 영역을 만든 다음 vpc-net-bvpc-net-c를 대상으로 하는 피어링 영역을 만들면 됩니다.
  • 전달 영역을 타겟팅하기 위해 DNS 피어링을 사용하는 경우 전달 영역이 있는 대상 VPC 네트워크에는 DNS 피어링 영역을 사용하는 소스 VM과 동일한 리전에 VM, Interconnect 연결(VLAN)이 있어야 합니다. 이 제한사항에 대한 상세 설명은 문제 해결 섹션을 참조하세요.

피어링 영역을 만들려면 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는 VPC 이름 확인 순서에 설명된 대로 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의 레코드를 확인합니다.
  • 요청된 레코드 이름과 이용 가능한 승인된 비공개 영역의 공통적인 최장 서픽스가 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가 반환됩니다.

DNS 서버 정책

각 VPC 네트워크에 대해 하나의 DNS 서버 정책을 구성할 수 있습니다. 정책으로 인바운드 전달, 아웃바운드 전달 또는 둘 다를 지정할 수 있습니다. 이 섹션에서 인바운드 서버 정책은 인바운드 DNS 전달을 허용하는 정책을, 아웃바운드 서버 정책은 아웃바운드 DNS 전달 구현을 위한 하나의 가능한 방법을 나타냅니다. 정책이 두 서버 정책의 특징을 모두 구현한다면 정책이 인바운드 서버 정책이면서 동시에 아웃바운드 서버 정책일 수 있습니다.

자세한 내용은 서버 정책 적용을 참조하세요.

인바운드 서버 정책

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

기본적으로 VPC 네트워크의 이름 확인 서비스는 이름 확인 순서를 통해 해당 VPC 네트워크에서만 사용할 수 있습니다. VPC 네트워크에 인바운드 DNS 정책을 만들어 Cloud VPN 또는 Cloud Interconnect를 사용하여 연결된 온프레미스 네트워크에서 이러한 이름 확인 서비스를 사용할 수 있습니다.

인바운드 정책을 만들면 Cloud DNS는 VPC 네트워크가 사용하는 각 리전의 서브넷 기본 IP 주소 범위에서 내부 IP 주소를 가져옵니다. 이 내부 IP 주소를 인바운드 DNS 요청의 진입점으로 사용합니다.

인바운드 정책 진입점

Cloud DNS에서 인바운드 DNS 정책에 사용하는 리전 내부 IP 주소는 VPC 네트워크의 이름 확인 서비스에 대한 진입점 역할을 합니다. 인바운드 DNS 정책을 사용하려면 온프레미스 시스템 또는 네임서버가 DNS 쿼리를 온프레미스 네트워크를 VPC 네트워크에 연결하는 Cloud VPN 터널 또는 Cloud Interconnect 연결(VLAN)과 같은 리전에 있는 프록시 IP 주소로 전달하도록 구성해야 합니다.

인바운드 서버 정책을 만드는 방법에 대한 자세한 내용은 인바운드 서버 정책 만들기를 참조하세요.

아웃바운드 서버 정책

대체 네임서버 목록을 지정하는 아웃바운드 DNS 정책을 만들어 VPC 이름 확인 순서를 변경할 수 있습니다. VPC 네트워크의 대체 네임서버를 지정하면, 메타데이터 서버(169.254.169.254)를 사용하도록 구성된 VPC 네트워크의 VM에서 오는 DNS 요청을 처리할 때 Google Cloud가 그러한 네임서버 쿼리합니다.

아웃바운드 서버 정책을 만드는 방법에 대한 자세한 내용은 아웃바운드 서버 정책 만들기를 참조하세요.

대체 네임서버 및 라우팅 방법

Cloud DNS는 네 가지 유형의 대체 네임서버를 지원하며 그러한 서버로의 트래픽 라우팅을 위한 표준 및 비공개 라우팅 방법을 제공합니다.

대체 네임서버는 다음 표에 정의되어 있습니다.

대체 네임서버 설명 표준 라우팅 비공개 라우팅 요청의 출처
유형 1 아웃바운드 서버 정책이 정의된 동일한 VPC 네트워크에 있는 Google Cloud VM의 내부 IP 주소 RFC 1918 IP 주소여야 합니다. 트래픽은 항상 승인된 VPC 네트워크를 통해 라우팅됩니다. 모든 내부 IP 주소. 트래픽은 항상 승인된 VPC 네트워크를 통해 라우팅됩니다. 35.199.192.0/19
유형 2 Cloud VPN 또는 Cloud Interconnect를 사용하여 아웃바운드 서버 정책으로 VPC 네트워크에 연결된 온프레미스 시스템의 IP 주소 RFC 1918 IP 주소여야 합니다. 트래픽은 항상 승인된 VPC 네트워크를 통해 라우팅됩니다. 모든 내부 IP 주소. 트래픽은 항상 승인된 VPC 네트워크를 통해 라우팅됩니다. 35.199.192.0/19
유형 3 인터넷에 있는 DNS 네임서버의 외부 IP 주소입니다.
Google Cloud 리소스의 외부 IP 주소를 포함합니다.
인터넷 라우팅이 가능한 주소여야 합니다. 트래픽은 항상 인터넷으로 라우팅됩니다. 비공개 라우팅은 지원되지 않습니다. Google Public DNS 소스 범위
유형 4 다른 VPC 네트워크에 있는 Compute Engine VM의 외부 IP 주소
비RFC 1918 IP 주소여야 합니다. 비공개 라우팅은 지원되지 않습니다. 비공개 라우팅을 선택 해제해야 합니다. Google Public DNS 소스 범위

아웃바운드 전달 정책의 대체 네임서버를 지정할 때 다음 두 가지 라우팅 방법 중 하나를 선택할 수 있습니다.

  • 표준 라우팅: 대체 네임서버가 RFC 1918 IP 주소인지 여부에 따라 승인된 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 네임서버의 네트워크 요구사항에 대한 자세한 안내는 대체 네임서버 네트워크 요구사항을 참조하세요.

액세스 제어

일반 액세스 제어

Google Cloud Console의 IAM 및 관리 페이지에서는 DNS 레코드 변경이 허용된 사용자를 관리할 수 있습니다. 사용자가 항목을 변경하도록 허용하려면 Cloud Console의 권한 섹션에 editor 또는 owner로 나열되어 있어야 합니다. 뷰어 권한 수준은 Cloud DNS 레코드에 대한 읽기 전용 액세스 권한을 부여합니다.

이러한 권한은 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 리졸버의 부하를 줄일 수 있습니다.

다음 단계