영역 관리

관리형 영역은 동일한 도메인 이름(예: example.com)을 공유하는 모든 DNS 레코드의 컨테이너입니다. 해당 영역의 DNS 쿼리에 대한 응답을 처리하기 위해 관리형 영역을 만들면 관리형 영역에 자동으로 네임서버 집합이 할당됩니다. 관리형 영역에는 포함 가능한 리소스 레코드 수가 할당되어 있습니다.

시작하기 전에

Cloud DNS API를 사용하려면 Cloud DNS 프로젝트를 만들고 Cloud DNS API를 사용 설정해야 합니다.

REST API를 사용할 애플리케이션을 만드는 경우, OAuth 2.0 클라이언트 ID도 만들어야 합니다.

  1. 아직 계정이 없으면 Google 계정에 가입합니다.
  2. GCP Console에서 Cloud DNS API를 사용 설정합니다. 기존의 Compute Engine 또는 App Engine 프로젝트를 선택하거나 새 프로젝트를 만들 수 있습니다.
  3. REST API에 요청해야 하는 경우 OAuth 2.0 ID를 만들어야 합니다(OAuth 2.0 설정).
  4. 나중에 입력해야 하는 프로젝트의 다음 정보를 기록해 둡니다.
    • 클라이언트 ID(xxxxxx.apps.googleusercontent.com).
    • 사용할 프로젝트 ID. GCP Console의 개요 페이지 맨 위에서 ID를 확인할 수 있습니다. 또한 사용자에게 앱에서 사용할 프로젝트 이름을 제공하도록 요청할 수도 있습니다.

이전에 gcloud 명령줄 도구를 실행하지 않은 경우, 다음 명령어를 실행하여 프로젝트 이름을 지정하고 GCP Console에서 인증해야 합니다.

gcloud auth login

명령어에 --project 매개변수를 지정하여 해당 호출의 다른 프로젝트에서 실행할 수도 있습니다.

관리형 영역 만들기

Cloud DNS API를 시작하는 경우, DNS 레코드를 포함할 관리형 영역을 만들어야 합니다. 관리형 영역은 Cloud DNS 프로젝트와 연결됩니다. 영역을 만들면 도메인 등록을 업데이트하거나 영역 네임서버 중 하나를 리졸버로 명시적으로 가리키거나 직접 쿼리할 때까지 새 영역이 사용되지 않습니다.

영역을 만들려면 DNS 영역 이름, 설명, 영역 식별 이름을 제공해야 합니다. --visibility 플래그를 사용하면 관리형 영역을 공개 또는 비공개로 지정할 수 있고, --networks 플래그를 사용하면 비공개 영역이 표시되는 VPC 네트워크를 지정할 수 있습니다.

공개 영역 만들기

관리형 영역은 DNS 이름 서픽스가 동일한 DNS 레코드의 컨테이너입니다. 관리형 영역에는 쿼리를 수락하고 쿼리에 응답하는 네임서버 집합이 있습니다.

새 관리형 공개 영역을 만들려면 다음 단계를 따르세요.

콘솔

  1. GCP Console에서 DNS 영역 만들기 페이지로 이동합니다.

    DNS 영역 만들기 페이지로 이동

  2. 영역 유형으로 공개를 선택합니다.

  3. 영역 이름을 입력합니다. 예를 들면 my-new-zone입니다.

  4. 소유하고 있는 도메인 이름을 사용하여 영역의 DNS 이름 서픽스를 입력합니다. 예를 들면 example.com입니다.

  5. DNSSEC에서 Off, On 또는 Transfer를 선택합니다. 자세한 내용은 DNSSEC 구성을 참조하세요.

  6. 만들기를 클릭합니다.

영역 세부정보 페이지가 표시됩니다. 기본 NS 레코드와 SOA 레코드가 생성되어 있습니다.

gcloud

gcloud dns managed-zones create my-zone-name \
    --dns-name="example.com" \
    --description="A zone" \
    --visibility=public

Python

def create_zone(project_id, name, dns_name, description):
    client = dns.Client(project=project_id)
    zone = client.zone(
        name,  # examplezonename
        dns_name=dns_name,  # example.com.
        description=description)
    zone.create()
    return zone

비공개 영역 만들기

관리형 영역은 DNS 이름 서픽스가 동일한 DNS 레코드의 컨테이너입니다. 비공개 관리형 영역은 지정된 VPC 네트워크 하나 이상에서만 보이는 DNS 레코드의 컨테이너입니다.

새 비공개 영역을 만들려면 다음 단계를 따르세요.

콘솔

  1. GCP Console에서 DNS 영역 만들기 페이지로 이동합니다.

    DNS 영역 만들기 페이지로 이동

  2. 영역 유형으로 비공개를 선택합니다.

  3. 영역 이름을 입력합니다. 예를 들면 my-new-zone입니다.

  4. 소유하고 있는 도메인 이름을 사용하여 영역의 DNS 이름 서픽스를 입력합니다. 예를 들면 example.com입니다.

  5. 설명을 추가합니다(선택사항).

  6. 비공개 영역이 표시될 네트워크를 선택합니다.

  7. 만들기를 클릭합니다.

gcloud

비공개 영역을 만들려면 다음 명령어를 실행합니다.

gcloud dns managed-zones create my-zone-name \
    --dns-name="example.com" \
    --description="A zone" \
    --visibility=private \
    --networks=default

Python

def create_zone(project_id, name, dns_name, description):
    client = dns.Client(project=project_id)
    zone = client.zone(
        name,  # examplezonename
        dns_name=dns_name,  # example.com.
        description=description)
    zone.create()
    return zone

accessNotConfigured 오류가 발생하면 Cloud DNS API를 사용 설정해야 합니다.

전달 영역 만들기

전달 영역은 지정된 영역의 일반 DNS 확인을 재정의합니다. 대신 지정된 영역에 대한 쿼리가 나열된 전달 대상으로 전달됩니다.

콘솔

  1. GCP Console에서 DNS 영역 만들기 페이지로 이동합니다.

    DNS 영역 만들기 페이지로 이동

  2. 영역 유형으로 비공개를 선택합니다.

  3. 영역 이름my-new-zone을 입력합니다.

  4. 소유하고 있는 도메인 이름을 사용하여 영역의 DNS 이름 서픽스를 입력합니다. 예를 들면 example.com입니다.

  5. 설명을 추가합니다(선택사항).

  6. 비공개 영역이 표시될 네트워크를 선택합니다.

  7. 다른 서버로 쿼리 전달 옆에 있는 체크박스를 선택합니다.

  8. 목적지 DNS 서버에 전달 대상을 입력합니다.

    전달 대상은 고정 IP 주소 목록입니다. 이러한 IP 주소는 동일한 VPC 네트워크 또는 VPN이나 Interconnect를 통해 연결 가능한 네트워크에서 연결될 수 있으면 RFC 1918 주소도 가능합니다. 그렇지 않으면 공개적으로 연결 가능한 IP 주소여야 합니다.

  9. 만들기를 클릭합니다.

gcloud

 gcloud beta dns managed-zones create example-forwarding-zone \
     --dns-name="example.com" \
     --description="A zone" \
     --networks="default,my-network" \
     --visibility=private \
     --forwarding-targets="8.8.8.8,8.8.4.4"

각 항목의 의미는 다음과 같습니다.

  • --dns-name은 전달 영역에서 확인할 도메인 목록입니다.
  • --networks는 전달 영역을 사용할 수 있는 네트워크 목록입니다.
  • --visibility는 전달 영역이 public 또는 private인지 여부를 나타냅니다.
  • --forwarding-targets는 정적 IP 주소 목록입니다. 이러한 IP 주소는 동일한 VPC 네트워크 또는 VPN이나 Interconnect를 통해 연결 가능한 네트워크에서 연결될 수 있으면 RFC 1918 주소도 가능합니다. 그렇지 않으면 공개적으로 연결 가능한 IP 주소여야 합니다.

요구사항: 전달 대상 네임서버에서 VPC 네트워크의 VM에서 수신된 DNS 요청을 처리하도록 하려면 다음을 수행해야 합니다.

  • 전달 대상 네임서버가 VPC 네트워크 내에서 연결 가능한지 확인합니다. dig 명령어와 @ 연산자로 이 네임서버를 직접 쿼리하여 이를 테스트할 수 있습니다.
  • 네임서버에 적용된 온프레미스 네트워크 방화벽 규칙이 소스가 35.199.192.0/19에 있는 패킷을 허용하는지 확인합니다.
  • 온프레미스 네트워크에는 Cloud VPN 터널, Dedicated Interconnect 연결(VLAN) 또는 Partner Interconnect 연결(VLAN)을 통해 목적지가 35.199.192.0/19인 트래픽을 다시 VPC 네트워크로 보내는 경로가 있어야 합니다. VPC 네트워크에서 수신된 DNS 쿼리에 대한 응답은 35.199.192.0/19로 전송되어야 하지만 인터넷을 통해 전송할 수는 없습니다. 정적 라우팅을 사용하는 Cloud VPN 터널의 경우 목적지가 35.199.192.0/19이고 다음 홉이 VPN 터널인 경로를 온프레미스 네트워크에 직접 만들어야 합니다. 이 경로를 추가하는 것 외에 정책 기반 라우팅을 사용하는 Cloud VPN 터널의 경우 35.199.192.0/19를 포함하도록 온프레미스 VPN 게이트웨이의 원격 트래픽 선택기 및 Cloud VPN의 로컬 트래픽 선택기를 구성해야 합니다. 동적 라우팅, Dedicated Interconnect 또는 Partner Interconnect를 사용하는 Cloud VPN 터널의 경우 연결된 Cloud Router에서 커스텀 경로 공지를 구성해야 합니다.
  • 전달 영역을 통해 다른 VPC 네트워크에 위치한 대상으로 쿼리 전달은 지원되지 않습니다. 이 용도로는 피어링 영역을 대신 사용할 수 있습니다.

또한 다음에 유의해야 합니다.

  • VPC 네트워크의 GCP VM에서 전송된 모든 쿼리는 35.199.192.0/19를 통해 프록시됩니다. 모든 고객이 35.199.192.0/19를 사용하는 경우에도 온프레미스 네임서버는 VPC 네트워크의 요청만 수신합니다.
  • 35.199.192.0/19 주소 범위는 VPC 네트워크 또는 VPC 네트워크에 연결된 온프레미스 네트워크에서만 연결할 수 있습니다. 온프레미스 네트워크에서 목적지가 35.199.192.0/19인 패킷을 인터넷을 통해 라우팅하면 패킷이 중단됩니다.
  • GCP를 사용하려면 요청을 수신하는 온프레미스 네임서버가 응답을 35.199.192.0/19에 보내는 서버여야 합니다. 네임서버가 요청을 다른 네임서버에 보내고 다른 네임서버가 35.199.192.0/19에 응답하면 이 응답은 무시됩니다. 보안상의 이유로 GCP에서는 DNS 응답의 소스 주소가 요청의 목적지 주소와 일치해야 합니다.
  • 대상 네임서버에 연결할 수 있다면 Cloud DNS는 최대 60초 또는 레코드의 TTL 중 더 짧은 시간 동안 아웃바운드 전달 쿼리 결과를 캐시합니다. 대상 네임서버에 연결할 수 없는 경우에는 아웃바운드 전달 쿼리 결과가 TTL에 해당하는 시간 동안 캐시됩니다. 이는 전달 영역을 통한 아웃바운드 전달 쿼리 및 DNS 서버 정책에 따라 대체 네임서버로 전달된 아웃바운드 전달 쿼리에 적용됩니다.

요구사항 : 외부 네임서버가 전달된 DNS 쿼리를 수신하려면 다음을 수행해야 합니다.

  • VPC 네트워크가 외부 네임서버에 연결될 수 있는지 확인합니다.
    • 온프레미스 네트워크에서 Google 35.199.192.0/19 IP 주소 범위의 트래픽을 허용하도록 라우팅을 설정하고 방화벽을 구성합니다.
      • 이 주소 블록은 VPC 네트워크에서 다른 네임서버로 DNS 쿼리를 전달하기 위해 Google의 프록시에서만 사용됩니다.
      • 이 주소 블록은 VPC 네트워크 내에서만 연결될 수 있으며 전달 구성 시 온프레미스 네트워크에서도 연결될 수 있습니다.
      • 모든 GCP 고객에 35.199.192.0/19를 사용하지만 온프레미스 네임서버는 전달이 사용 설정된 비공개 영역에 대한 액세스 권한이 있는 VPC 네트워크의 요청만 수신합니다.
  • GCP는 전달된 쿼리를 수신하는 온프레미스 네임서버의 IP 주소에서 응답하도록 요구합니다. 온프레미스 네임서버가 다른 소스 IP 주소에서 응답하면 GCP는 보안상의 이유로 응답을 무시합니다.

피어링 영역 만들기

두 네트워크가 피어링되면 DNS 정보를 자동으로 공유하지 않습니다. DNS 피어링을 사용하면 한 네트워크(소비자 네트워크)에서 다른 네트워크(공급자 네트워크)로 DNS 요청을 전달할 수 있습니다. 소비자 네트워크에 일치하는 DNS 요청을 공급자 네트워크에 전달하는 피어링 영역을 만들면 됩니다.

콘솔

  1. GCP Console에서 DNS 영역 만들기 페이지로 이동합니다.

    DNS 영역 만들기 페이지로 이동

  2. 영역 유형으로 비공개를 선택합니다.

  3. 영역 이름my-new-zone을 입력합니다.

  4. 소유하고 있는 도메인 이름을 사용하여 영역의 DNS 이름 서픽스를 입력합니다. 예를 들면 example.com입니다.

  5. 설명을 추가합니다(선택사항).

  6. 비공개 영역이 표시될 네트워크를 선택합니다.

  7. DNS 피어링에서 DNS 피어링 사용 설정 옆에 있는 체크박스를 선택합니다.

  8. 피어 프로젝트에서 원하는 피어 프로젝트를 선택합니다.

  9. 피어 네트워크에서 원하는 피어 네트워크를 선택합니다.

  10. 만들기를 클릭합니다.

gcloud

이 절차에서는 두 네트워크가 이미 피어링되었다고 가정합니다.

  1. 실제로 DNS 요청을 처리하는 네트워크(공급자 네트워크)에 비공개 영역 또는 전달 영역이 아직 없는 경우 만듭니다.
gcloud beta dns managed-zones create example-private-zone \
    --dns-name="example.com" \
    --description="This is the zone for example.com" \
    --networks="default,my-network" \
    --visibility=private

각 항목의 의미는 다음과 같습니다.

  • --dns-name은 영역에서 확인할 서픽스를 포함합니다.
  • --description은 영역에 대한 짧은 설명을 포함합니다.
  • --networks는 이 영역을 사용할 수 있는 프로젝트의 네트워크를 나열합니다.
  • --visibilityprivate으로 설정하여 비공개 영역을 만듭니다.
  1. 리소스 레코드를 영역에 추가합니다.

  2. 공급자 네트워크 프로젝트에서 다른 네트워크에 피어링 영역을 만드는 계정에 dns.peer IAM 역할을 부여합니다. 피어링 영역을 만드는 계정은 일반적으로 서비스 계정입니다.

    gcloud beta projects add-iam-policy-binding [PRODUCER_PROJECT] \
        --member=[SERVICE_ACCOUNT] \
        --role=dns.peer
    

    각 항목의 의미는 다음과 같습니다.

    • [SERVICE_ACCOUNT]의 형식은 serviceAccount:test123@example.domain.com입니다.
  3. 소비자 네트워크에 DNS 요청을 공급자 네트워크에 전달하는 피어링 영역을 만듭니다. 요청을 처리하는 비공개 영역의 이름을 지정하지 않고 네트워크만 지정하면 됩니다. 공급자 네트워크의 모든 영역에서 요청을 처리할 수 있습니다.

    gcloud beta dns managed-zones create example-peering-zone \
        --account=[SERVICE_ACCOUNT] \
        --dns-name="example.com" \
        --description="This is the zone for example.com" \
        --networks=[CONSUMER_NETWORK] \
        --visibility=private \
        --target-network=[PRODUCER_NETWORK] \
        --target-project=[PRODUCER_PROJECT]
    

    각 항목의 의미는 다음과 같습니다.

    • --account=[SERVICE_ACCOUNT]는 공급자 네트워크의 dns.peer 역할이 있는 서비스 계정입니다.
    • --dns-name은 피어링된 영역에서 확인할 도메인 목록을 포함합니다.
    • --description은 영역에 대한 짧은 설명을 포함합니다.
    • --networks=[CONSUMER_NETWORK]는 피어링 영역이 생성되는 네트워크입니다.
    • 피어링 영역은 비공개 영역만 가능하므로 --visibilityprivate으로 설정됩니다.
    • --target-network=[PRODUCER_NETWORK]는 피어링 영역이 피어링할 네트워크입니다.
    • --target-project=[PRODUCER_PROJECT]는 피어링 영역이 피어링할 네트워크를 포함하는 프로젝트입니다.

모든 구성이 완료되면 소비자 네트워크에서 인스턴스에 로그인한 다음 구성한 영역의 DNS를 요청합니다. 피어링 영역은 IP 주소로 응답해야 하는 공급자 네트워크의 비공개 영역에 요청을 전달해야 합니다.

관리형 영역 업데이트

DNS 레코드를 포함할 관리형 영역을 만들면 그 속성 중 일부를 업데이트할 수 있습니다. 현재 공개 영역의 설명과 DNSSEC 구성만 업데이트할 수 있습니다.

영역을 업데이트하려면 영역 리소스 이름(DNS 이름과 달리 .를 포함할 수 없음) 및 영역과 관련된 업데이트된 정보를 제공해야 합니다.

gloud

gcloud dns managed-zones update --description="My zone" "myzonename"

Python

 BODY = {
      'name' : 'myzonename',
      'description' : 'My zone'
    }
    service = build('dns', 'v1')
    response = service.managedZones().create(project=PROJECT_NAME,
                                             body=BODY
                                             ).execute()
 

비공개 영역의 네트워크 변경

비공개 영역이 표시될 네트워크를 변경하려면 다음 명령어를 실행합니다.

gcloud

gcloud dns managed-zones update my-zone-name \
    --networks default,newnetwork 

이 명령어를 실행하면 비공개 영역이 네트워크 defaultnewnetwork에 표시됩니다. 비공개 영역이 표시된 모든 네트워크가 새로운 네트워크 목록으로 바뀝니다.

관리형 영역에 대한 라벨 추가 및 업데이트

관리형 영역에 라벨을 추가하고 기존 라벨을 삭제할 수 있습니다.

다음 예에서 [KEY]:[VALUE]Dept:Marketing 또는 Project:project1과 같은 임의의 키-값 쌍입니다.

관리형 영역 생성 시 라벨 추가

gcloud dns managed-zones create \
    --dns-name="example.com." \
    --labels [KEY]:[VALUE] \
    --description="A zone" "myzonename"

기존 관리형 영역에 라벨 추가

이 명령어는 라벨을 기존 관리형 영역에 추가합니다.

gcloud dns managed-zones update \
    --labels [KEY]:[VALUE],[[KEY]:[VALUE]] \
    "myzonename"

라벨 키-값 쌍 값 업데이트

이 명령어는 기존 키-값 라벨 쌍의 value를 업데이트합니다. key가 존재하지 않으면 새 키-값 쌍이 생성됩니다.

gcloud dns managed-zones update \
    --update-labels [KEY]:[VALUE],[[KEY]:[VALUE]] \
    "myzonename"

라벨 키-값 쌍 삭제

이 명령어는 지정된 키-값 라벨 쌍을 삭제합니다.

gcloud dns managed-zones update \
    --remove-labels [KEY]:[VALUE],[[KEY]:[VALUE]] \
    "myzonename"

모든 라벨 키-값 쌍 지우기

이 명령어는 모든 라벨을 지웁니다.

gcloud dns managed-zones update \
    --clear-labels \
    "myzonename"

관리형 영역 나열

프로젝트 내의 모든 영역을 나열할 수 있습니다.

gcloud

gcloud dns managed-zones list

Python

def list_zones(project_id):
    client = dns.Client(project=project_id)
    zones = client.list_zones()
    return [zone.name for zone in zones]

관리형 영역 세부정보 가져오기

연결된 네임서버를 조회하는 등 관리형 영역에 대한 세부정보를 가져올 수 있습니다.

gcloud

gcloud dns managed-zones describe "myzonename"

Python

def get_zone(project_id, name):
    client = dns.Client(project=project_id)
    zone = client.zone(name=name)

    try:
        zone.reload()
        return zone
    except NotFound:
        return None

관리형 영역 삭제

영역을 삭제하려면 delete 명령어에 영역 이름을 입력합니다.

gcloud

gcloud dns managed-zones delete "myzonename"

빈 영역만 삭제할 수 있습니다. 빈 관리형 영역에는 SOA 및 NS 레코드 모음만 있습니다. 다음과 같이 import 명령어를 사용하여 영역을 쉽게 비울 수 있습니다.

touch empty-file
gcloud dns record-sets import -z "myzonename" --delete-all-existing empty-file
rm empty-file

Python

def delete_zone(project_id, name):
    client = dns.Client(project=project_id)
    zone = client.zone(name)
    zone.delete()

DNS 서버 정책 사용

DNS 서버 정책은 영역을 호스팅하는 네임서버의 동작을 제어하는 Cloud DNS 규칙을 모아놓은 것입니다. DNS 서버 정책을 사용하여 다음을 수행할 수 있습니다.

  • 지정된 네트워크의 모든 DNS 쿼리를 처리하는 다른 네임서버 지정
  • DNS 쿼리의 인바운드 전달 수락을 사용 설정 또는 중지

GCP 네트워크 하나 이상에 DNS 서버 정책을 적용할 수 있습니다.

DNS 서버 정책의 개요를 참조하세요.

인바운드 DNS 전달을 사용 설정하는 DNS 정책 만들기

다음 정책은 프로젝트에서 default 네트워크에 대한 인바운드 DNS 전달을 사용 설정합니다.

gcloud beta dns policies create my-policy --project=myproject \
    --description="Inbound DNS forwarding for default network" \
    --enable-inbound-forwarding \
    --networks=default

인바운드 전달자 IP 주소 나열

gcloud compute addresses list --filter='name ~ ^dns-forwarding.*' \
    --format='csv[no-heading](address, subnetwork)'

대체 네임서버를 사용 설정하는 DNS 정책 만들기

이 정책은 VPC 네트워크에 온프레미스 네트워크에 위치한 대체 네임서버를 사용하도록 지시합니다.

gcloud beta dns policies create [OUTBOUND_POLICY_NAME] --project=[PROJECT_ID] \
    --description="Alternative nameservers for for the VPC network" \
    --networks=[NETWORK] \
    --alternative-name-servers="[ALTERNATIVE_NAMESERVERS]"

각 자리표시자를 적절한 값으로 바꿉니다.

  • [OUTBOUND_POLICY_NAME]은 아웃바운드 Cloud DNS 정책의 이름입니다.
  • [PROJECT_ID]는 프로젝트 ID입니다.
  • [NETWORK]는 VPC 네트워크의 이름입니다.
  • [ALTERNATIVE_NAMESERVERS]는 온프레미스 네트워크에 있는 대체 네임서버의 쉼표로 구분된 IP 주소 목록입니다.

요구사항: 대체 네임서버에서 VPC 네트워크의 VM에서 수신된 DNS 요청을 처리하도록 하려면 다음을 수행해야 합니다.

  • 대체 네임서버가 VPC 네트워크 내에서 연결 가능한지 확인합니다. dig 명령어와 @ 연산자로 이 대체 네임서버를 직접 쿼리하여 이를 테스트할 수 있습니다.
  • 대체 네임서버에 적용된 온프레미스 네트워크 방화벽 규칙이 소스가 35.199.192.0/19에 있는 패킷을 허용하는지 확인합니다.
  • 온프레미스 네트워크에는 Cloud VPN 터널, Dedicated Interconnect 연결(VLAN) 또는 Partner Interconnect 연결(VLAN)을 통해 목적지가 35.199.192.0/19인 트래픽을 다시 VPC 네트워크로 보내는 경로가 있어야 합니다. VPC 네트워크에서 수신된 DNS 쿼리에 대한 응답은 35.199.192.0/19로 전송되어야 하지만 인터넷을 통해 전송할 수는 없습니다. 정적 라우팅을 사용하는 Cloud VPN 터널의 경우 목적지가 35.199.192.0/19이고 다음 홉이 VPN 터널인 경로를 온프레미스 네트워크에 직접 만들어야 합니다. 이 경로를 추가하는 것 외에 정책 기반 라우팅을 사용하는 Cloud VPN 터널의 경우 35.199.192.0/19를 포함하도록 온프레미스 VPN 게이트웨이의 원격 트래픽 선택기 및 Cloud VPN의 로컬 트래픽 선택기를 구성해야 합니다. 동적 라우팅, Dedicated Interconnect 또는 Partner Interconnect를 사용하는 Cloud VPN 터널의 경우 연결된 Cloud Router에서 커스텀 경로 공지를 구성해야 합니다.

또한 다음에 유의해야 합니다.

  • VPC 네트워크의 GCP VM에서 전송된 모든 쿼리는 35.199.192.0/19를 통해 프록시됩니다. 모든 고객이 35.199.192.0/19를 사용하지만 내 온프레미스 대체 네임서버는 내 VPC 네트워크의 요청만 수신합니다.
  • 35.199.192.0/19 주소 범위는 VPC 네트워크 또는 VPC 네트워크에 연결된 온프레미스 네트워크에서만 연결할 수 있습니다. 온프레미스 네트워크에서 목적지가 35.199.192.0/19인 패킷을 인터넷을 통해 라우팅하면 패킷이 중단됩니다.
  • GCP를 사용하려면 요청을 수신하는 대체 네임서버가 응답을 35.199.192.0/19에 보내는 서버여야 합니다. 대체 네임서버가 요청을 다른 네임서버에 보내고 다른 네임서버가 35.199.192.0/19에 응답하면 이 응답은 무시됩니다. 보안상의 이유로 GCP에서는 DNS 응답의 소스 주소가 요청의 목적지 주소와 일치해야 합니다.

DNS 정책 나열

gcloud beta --project=my-project dns policies list

DNS 정책 삭제

gcloud beta --project=my-project dns policies delete example-policy

DNS 정책 업데이트

gcloud beta --project=myproject dns policies update --networks="default, somenewnetwork"

다음 단계

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

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

Cloud DNS 문서