DNS 영역 개요

Cloud DNS는 다양한 유형의공개 및 비공개 영역을 지원합니다. 이 문서에서는 다양한 영역 유형 및 유형 하나와 다른 유형을 사용할 수 있는 시기에 대해 자세히 설명합니다.

전달 영역

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

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

전달 대상 및 라우팅 방법

Cloud DNS는 세 가지 유형의 대상을 지원하며 연결을 위한 표준 또는 비공개 라우팅 방법을 제공합니다.

전달 대상 설명 표준 라우팅 지원 비공개 라우팅 지원 요청 소스
유형 1 Google Cloud VM의 내부 IP 주소 또는 전달 영역을 사용할 수 있도록 승인된 동일한 VPC 네트워크의 내부 패스 스루 네트워크 부하 분산기입니다. RFC 1918 IP 주소만 지원합니다. 트래픽은 항상 승인된 VPC 네트워크를 통해 라우팅됩니다. 금지된 전달 대상 IP 주소를 제외한 모든 내부 IP 주소(예: RFC 1918 비공개 주소, RFC 1918 이외의 비공개 IP 주소, 비공개적으로 재사용되는 외부 IP 주소)입니다. 트래픽은 항상 승인된 VPC 네트워크를 통해 라우팅됩니다. 35.199.192.0/19
유형 2 Cloud VPN 또는 Cloud Interconnect를 사용하여 전달 영역을 쿼리하도록 승인된 VPC 네트워크에 연결된 온프레미스 시스템의 IP 주소입니다. RFC 1918 IP 주소만 지원합니다. 트래픽은 항상 승인된 VPC 네트워크를 통해 라우팅됩니다. 금지된 전달 대상 IP 주소를 제외한 모든 내부 IP 주소(예: RFC 1918 비공개 주소, RFC 1918 이외의 비공개 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 대상의 네트워크 요구 사항에 대한 자세한 안내는 대상 네트워크 요구 사항 전달을 참조하세요.

금지된 전달 대상 IP 주소

Cloud DNS 전달 대상에는 다음 IP 주소를 사용할 수 없습니다.

  • 169.254.0.0/16
  • 192.0.0.0/24
  • 192.0.2.0/24
  • 192.88.99.0/24
  • 198.51.100.0/24
  • 203.0.113.0/24
  • 224.0.0.0/4
  • 240.0.0.0/4
  • ::1/128
  • ::/128
  • 2001:db8::/32
  • fe80::/10
  • fec0::/10
  • ff00::/8

전달 대상 선택 순서

Cloud DNS를 사용하면 전달 영역의 전달 대상 목록을 구성할 수 있습니다.

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

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

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

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

전달 영역 사용

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

  • VPC 네트워크가 Cloud DNS 전달 영역을 사용할 수 있도록 승인되었습니다. 전달 영역을 사용하려면 VPC 네트워크가 동일한 조직 내에 있는 한 동일한 프로젝트 또는 여러 프로젝트에서 여러 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-a를 vpc-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-a 및 vpc-net-b의 Compute Engine 인스턴스가 온프레미스 전달 대상을 쿼리할 수 있습니다.

전달 영역을 만드는 방법은 전달 영역 만들기를 참조하세요.

피어링 영역

피어링 영역은 서로 다른 VPC 네트워크의 Cloud DNS 영역 간에 DNS 요청을 전송할 수 있는 Cloud DNS 비공개 영역입니다. 예를 들어 Software as a Service (SaaS) 제공업체는 고객에게 Cloud DNS의 관리형 DNS 레코드에 대한 액세스 권한을 부여할 수 있습니다.

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

피어링 영역은 영역 구성 중에 선택된 VPC 네트워크에만 표시됩니다. 피어링 영역을 사용하도록 승인된 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 조회를 실행할 수 있습니다.

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

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

  • DNS 피어링은 단방향 관계입니다. DNS 소비자 네트워크의 Google Cloud 리소스가 DNS 제작자 네트워크에 있는 것처럼 피어링 영역의 네임스페이스에서 레코드를 조회할 수 있게 해줍니다.
  • DNS 공급자와 소비자 네트워크는 VPC 네트워크여야 합니다.
  • DNS 공급자 및 소비자 네트워크가 일반적으로 동일한 조직에 포함되지만, 조직 간 DNS 피어링도 지원됩니다.
  • DNS 피어링과 VPC 네트워크 피어링은 다른 서비스입니다. VPC 네트워크 피어링은 DNS 정보를 자동으로 공유하지 않습니다. 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 네트워크로 쿼리가 전달되지 않음을 참조하세요.

피어링 영역을 만드는 방법은 피어링 영역 만들기를 참조하세요.

관리형 역방향 조회 영역

관리형 역방향 조회 영역은 Cloud DNS가 Compute Engine DNS 데이터에 대해 PTR 조회를 수행하도록 지정하는 특수한 속성이 포함된 비공개 영역입니다.

비공개 영역의 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 레코드를 저장할 수 있습니다.

관리형 역방향 조회 영역을 만드는 방법은 관리형 역방향 조회 영역 만들기를 참고하세요.

중첩 영역

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

  • gcp.example.com의 영역과 gcp.example.com의 영역은 도메인 이름이 동일하기 때문에 중첩됩니다.
  • dev.gcp.example.com의 영역과 gcp.example.com의 영역은 dev.gcp.example.com이 gcp.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.com과 dev.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(초) 데이터
myrecord1.gcp.example.com A 5 10.128.1.35

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

녹화 유형 TTL(초) 데이터
myrecord1.gcp.example.com A 5 104.198.6.142
myrecord2.gcp.example.com A 50 104.198.7.145

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

  • VPC 네트워크의 VM에서 myrecord1.gcp.example.com을 쿼리하면 10.128.1.35가 반환됩니다.
  • 인터넷에서 myrecord1.gcp.example.com을 쿼리하면 104.198.6.142가 반환됩니다.
  • 비공개 영역 gcp.example.com에 myrecord2.gcp.example.com의 레코드가 없으므로 VPC 네트워크의 VM에서 myrecord2.gcp.example.com을 쿼리하면 NXDOMAIN 오류가 반환됩니다.
  • 인터넷에서 myrecord2.gcp.example.com을 쿼리하면 104.198.7.145가 반환됩니다.

프로젝트 간 바인딩

프로젝트 간 바인딩을 사용하면 전체 VPC 네트워크의 DNS 네임스페이스 소유권과 관계없이 서비스 프로젝트의 DNS 네임스페이스 소유권을 유지할 수 있습니다.

일반적인 공유 VPC 설정에는 가상 머신(VM) 애플리케이션이나 서비스의 소유권을 가져오는 서비스 프로젝트가 있는 반면, 호스트 프로젝트는 VPC 네트워크와 네트워크 인프라의 소유권을 가져옵니다. DNS 네임스페이스가 서비스 프로젝트 리소스와 일치하도록 VPC 네트워크 네임스페이스에서 생성되는 경우가 많습니다. 이러한 설정의 경우 각 서비스 프로젝트(다른 부서나 비즈니스인 경우가 많음)의 관리자에게 각 서비스 프로젝트의 DNS 네임스페이스 관리를 간편하게 위임할 수 있습니다. 프로젝트 간 바인딩을 사용하면 서비스 프로젝트의 DNS 네임스페이스 소유권을 전체 VPC 네트워크의 DNS 네임스페이스 소유권에서 분리할 수 있습니다.

다음 그림에서는 DNS 피어링을 사용하는 일반적인 공유 VPC 설정을 보여줍니다.

DNS 피어링을 사용한 공유 VPC 설정
DNS 피어링을 사용한 공유 VPC 설정(확대하려면 클릭)

다음 그림에서는 프로젝트 간 바인딩을 사용하는 설정을 보여줍니다. Cloud DNS를 사용하면 각 서비스 프로젝트에서 DNS 영역을 만들고 소유할 수 있지만 계속 호스트 프로젝트가 소유한 공유 네트워크에 바인딩될 수 있습니다. 이렇게 하면 DNS 영역 관리를 위한 보다 자율적이면서 더욱 정확한 권한 경계를 사용할 수 있습니다.

프로젝트 간 바인딩을 사용한 설정
프로젝트 간 바인딩을 사용한 설정(확대하려면 클릭)

프로젝트 간 바인딩은 다음을 제공합니다.

  • 서비스 프로젝트 관리자와 사용자는 고유한 DNS 영역을 만들고 관리할 수 있습니다.
  • 자리표시자 VPC 네트워크를 만들 필요가 없습니다.
  • 호스트 프로젝트 관리자는 서비스 프로젝트를 관리할 필요가 없습니다.
  • IAM 역할은 프로젝트 수준에서 계속 적용됩니다.
  • 모든 DNS 영역은 공유 VPC 네트워크와 직접 연결됩니다.
  • Any-to-Any DNS 변환을 즉시 사용할 수 있습니다. 공유 VPC 네트워크의 모든 VM에서 연결된 영역을 확인할 수 있습니다.
  • 전환 홉 제한이 없습니다. 허브 및 스포크 설계에서 관리할 수 있습니다.

프로젝트 간 바인딩이 사용 설정된 영역을 만드는 방법은 프로젝트 간 바인딩 영역 만들기를 참조하세요.

영역 Cloud DNS 영역

영역 Cloud DNS를 사용하면 Google Cloud 영역으로만 범위가 지정된 비공개 DNS 영역을 만들 수 있습니다. 클러스터 범위를 선택하면 GKE용 영역 Cloud DNS 영역이 생성됩니다.

기본 Cloud DNS 서비스는 기본적으로 전역이며 VPC 이름은 VPC 네트워크 내에서 전역적으로 표시됩니다. 이렇게 구성하면 서비스가 전역 서비스 중단에 노출됩니다. 영역 Cloud DNS는 각 Google Cloud 영역 내에 존재하는 새 비공개 Cloud DNS 서비스입니다. 장애 도메인은 Google Cloud 영역 내에 포함되어 있습니다. 전역 서비스 중단이 발생해도 영역 Cloud DNS 비공개 영역은 영향을 받지 않습니다. 모든 Google Cloud 영역 서비스 중단은 해당 Google Cloud 영역 내의 해당 특정 Google Cloud 영역 및 Cloud DNS 영역에만 영향을 줍니다. 영역 서비스에서 생성된 모든 리소스는 해당 Google Cloud 영역에서만 볼 수 있습니다.

영역 Cloud DNS 클러스터 범위 영역을 구성하는 방법은 영역 GKE 클러스터 범위 영역 구성을 참조하세요.

영역 Cloud DNS 지원

다음 표에는 영역 Cloud DNS 서비스에서 지원하는 Cloud DNS 리소스와 기능이 나와 있습니다.

리소스 또는 기능 전역 Cloud DNS에서 사용 가능 영역 Cloud DNS에서 사용 가능
관리형 공개 영역
관리형 비공개 영역(네트워크 또는 VPC 범위)
관리형 비공개 영역(GKE 범위)
전달 영역1
피어링 영역
관리형 역방향 조회 영역
변경사항 만들기 또는 레코드 관리2
서비스 디렉터리 영역
정책
응답 정책(네트워크 범위)
응답 정책(GKE 클러스터 범위)
응답 정책 규칙

1영역 Cloud DNS는 GKE 클러스터로 범위가 지정된 전달 영역만 지원합니다.

2GKE 컨트롤러는 다시 시작될 때 레코드의 변경사항을 덮어씁니다.

영역 Cloud DNS 영역 결제

영역 Cloud DNS 영역 및 응답 정책의 결제는 대응하는 전역과 동일한 방식입니다.

다음 단계