문제해결

이 페이지에서는 Cloud DNS 사용 시 발생할 수 있는 오류와 그 처리 방법을 설명합니다.

관리형 영역

이 섹션에는 관리형 영역과 관련된 오류가 나열되어 있습니다.

invalidFieldValue

'entity.managedZone.name' 값이 잘못되었습니다.

관리형 영역 이름이 문자로 시작되지 않거나 문자 또는 숫자로 끝나지 않거나 소문자, 숫자 또는 대시 외 다른 문자가 포함되면 이 오류가 발생하여 관리형 영역 만들기 작업이 실패할 수 있습니다.

managedZoneDnsNameNotAvailable

지정된 관리형 영역을 만들 수 없습니다.

다음과 같은 이유로 이 오류가 발생하여 관리형 영역 만들기 작업이 실패할 수 있습니다.

  • 제안된 영역의 DNS 이름이 예약되어 있습니다(예: 구두점(.), .com 또는 .co.uk).
  • 영역의 DNS 이름을 호스트할 수 있는 네임서버가 더 이상 없습니다. Cloud DNS는 네임서버 풀을 사용하며 이 풀은 유한합니다. 각 네임서버에서의 DNS 쿼리는 관리형 영역 한 개와 명확하게 매핑되어야 합니다.

권장 조치: 해당 DNS 이름의 등록된 소유자인 경우 중첩 영역이 있는지 확인하세요. 도메인과 하위 도메인에 대해 DNS를 설정하려면 단일 루트 영역을 만들고 해당 영역의 각 하위 도메인에 대한 레코드를 추가하는 것이 좋습니다.

verifyManagedZoneDnsNameOwnership

'EXAMPLE.COM' 도메인(또는 상위 항목)의 소유권을 http://www.google.com/webmasters/verification/에서 확인하고 다시 시도하세요.

권장 조치: 이 오류가 발생하면 도메인 소유권을 확인한 후 다시 시도해야 합니다.

레코드

이 섹션의 오류는 레코드와 관련이 있습니다.

containerNotEmpty

지정된 리소스가 비어 있지 않으므로 삭제될 수 없습니다.

권장 조치: 리소스를 삭제하려면 먼저 리소스를 비워야 합니다.

invalidZoneApex

영역의 루트에는 특정 유형의 리소스 레코드 모음이 하나만 포함되어야 하므로, 지정된 리소스 레코드 모음이 유효하지 않습니다.

DNS 환경설정에서 '루트'는 영역에서 허용되는 라벨 수가 최소인 DNS 이름을 의미합니다. 영역의 루트는 ManagedZone.dnsName과 동일한 DNS 이름입니다.

이 오류는 영역 루트의 DNS 규칙을 위반하는 변경을 시도했음을 의미합니다. 다음 작업으로 인해 이 오류가 발생할 수 있습니다.

  • 루트에서 필요한 NS 리소스 레코드 모음을 삭제하려 했습니다.
  • 루트에서 필요한 SOA 리소스 레코드 모음을 삭제하려 했습니다.
  • 루트가 아닌 곳에 SOA 유형의 리소스 레코드 모음을 만들려 했습니다.

권장 조치: 이 오류가 발생한다는 것은 DNS 규칙에서 허용되지 않는 작업을 수행하려고 한다는 것입니다. 요청에 잘못된 부분이 있는지 확인하세요. 이러한 필수 리소스 레코드 모음을 삭제할 필요는 없습니다.

invalidRecordCount

'<SOA_OR_CNAME>' 유형이므로, 리소스 레코드 모음 'entity.change.additions[XX]'는 레코드 한 개만 포함할 수 있습니다.

DNS 규칙은 특정 리소스 레코드 모음이 리소스 레코드 한 개로만 구성될 수 있다고 규정합니다. 현재 이 유형은 SOA 또는 CNAME일 수 있습니다. 이러한 규칙을 위반하는 변경사항을 만들려고 하면 이 오류가 발생합니다. 예를 들면 다음과 같습니다.

{
  kind: "dns#rrset"
  name: "blog.foo.com.",
  type: "CNAME",
  rrdata: [ "www.foo.com.", "www2.foo.com." ],
  ...
}

권장 조치: 이 오류가 발생하면 요청을 확인하세요. 허용되지 않는 작업을 수행하려 하는 중입니다.

cnameResourceRecordSetConflict

DNS 이름 'EXAMPLE.COM'은 CNAME 리소스 레코드 모음 한 개를 포함하거나 다른 유형의 리소스 레코드 모음을 포함할 수 있지만 둘 다 포함하지는 못하므로, 리소스 레코드 모음 'entity.change.additions[XX]'가 유효하지 않습니다.

이 오류는 동일한 DNS 이름에 대해 A 레코드와 CNAME 레코드와 같은 두 가지 유형의 리소스 레코드 모음을 만드는 경우에 발생할 수 있습니다. 이 오류의 일반적인 원인은 영역 루트에 CNAME 레코드를 만들려고 시도하는 것입니다. 동일한 이름의 필수 SOANS 레코드와 충돌하므로, 이 작업은 불가능합니다.

권장 조치: 둘 중 하나를 선택합니다

wildcardNotAllowed

지정된 리소스 레코드 모음의 유형이 와일드 카드가 아닙니다.

DNS에서 와일드 카드는 존재하지 않는 도메인 이름에 대한 요청과 일치하는 특수 유형의 리소스 레코드 모음입니다. Cloud DNS의 한 가지 제한사항은 NS 유형의 와일드 카드 리소스 레코드 모음을 만들 수 없다는 점입니다.

권장 조치: 현재 와일드 카드 NS 리소스 레코드 모음은 지원되지 않습니다. 지원팀에 연락하거나 cloud-dns-discuss에 가입하여 수행하려는 작업을 알려주세요.

invalidValue

서버의 상태와 관계없이 요청의 특정 부분이 유효하지 않음을 의미하는 일반 오류입니다. 오류 메시지에는 요청의 문제가 있는 부분에 대한 경로와 유효하지 않은 값이 포함됩니다. 이 오류는 다음과 같은 여러 가지 이유로 트리거될 수 있습니다.

  • 잘못된 이름의 리소스 레코드 모음을 지정했습니다. 예를 들어, 'foo..bar'는 유효한 DNS 이름이 아닙니다(중간 라벨이 비어 있음).
  • 잘못된 유형의 리소스 레코드 모음을 지정했습니다. 예를 들어, ACNAME은 유효한 유형이지만 'XXX'는 유효한 유형이 아닙니다.
  • 레코드가 없는 리소스 레코드 모음을 지정했습니다.
  • 잘못된 리소스 레코드 데이터를 지정했습니다. 예를 들어, '1.1.1.1'은 유형 A에 대한 유효한 리소스 레코드 데이터입니다. 'XXX'는 유형 A에 대한 잘못된 리소스 레코드 데이터입니다.
  • TTL이 잘못된 리소스 레코드 모음을 지정했습니다. TTL은 음수가 아닌 정수여야 합니다.
  • 너무 긴 리소스 이름을 지정했습니다.

권장 조치: 요청을 수정하세요.

일반적인 오류

이 섹션에서는 일반적인 오류를 설명합니다.

alreadyExists

지정된 리소스가 이미 있습니다. 복제본을 만들 수 없습니다.

권장 조치: 리소스 생성 시 적절한 get/list API를 사용하여 이미 있는 리소스를 검색하세요.

accessNotConfigured

액세스 권한이 구성되지 않았습니다.

이 오류를 해결하려면 프로젝트에 Cloud DNS API를 사용 설정해야 합니다.

inactiveBillingState

비활성 결제 상태에서는 EXAMPLE_PROJECT 프로젝트가 요청을 수락할 수 없습니다. 결제 상태를 업데이트하는 데 수 분이 걸릴 수 있습니다.

권장 조치: GCP Console의 프로젝트 설정 섹션에서 프로젝트의 결제를 사용 설정하세요.

preconditionFailed

요청의 특정 부분이 서버 리소스의 현재 상태와 호환되지 않음을 의미하는 일반 오류입니다. 클라이언트가 문제를 해결한 후 다시 시도해야 합니다. 이미 있는 리소스 레코드 모음(동일한 이름과 유형)과 일치하지 않는 리소스 레코드 모음을 삭제하려는 create 변경 요청을 전송하는 경우에 발생할 수 있습니다.

영역의 현재 상태를 다시 읽고 삭제할 대상을 결정합니다. 마지막으로 본 이후로 변경되었을 수 있습니다.

오류 메시지에는 요청의 문제가 있는 부분에 대한 경로가 포함됩니다. 예를 들어, entity.change.deletions[6]은 요청의 POST 본문에서 변경 객체의 'deletions' 배열에 있는 7번째 요소를 가리킵니다.

권장 조치: 문제가 있는 것으로 신고된 요청 부분을 수정하세요.

required

요청의 일부 필수 부분이 누락되었음을 의미하는 일반 오류입니다. 예를 들어, 관리형 영역 만들기 요청에는 이름, DNS 이름, 설명이 필요합니다. 이들 중 하나라도 없으면 이 오류가 발생하고 요청이 실패합니다.

권장 조치: 필수 매개변수를 입력하고 다시 시도하세요.

notFound

지정된 리소스가 없습니다.

권장 조치: 기존 리소스 이름을 사용하고 있는지 확인하세요.

quotaExceeded

임박한 변경이 현재 할당량을 초과하면 이 오류가 발생합니다. 예를 들어, 각 영역에는 특정 수의 리소스 레코드 모음만 허용됩니다. 할당량은 프로젝트와 관련됩니다. 할당량을 늘려야 하는 경우, Google 고객 서비스에 요청해야 합니다. 새 프로젝트에는 기본 할당량이 있습니다. DNS가 제한하는 서로 다른 모든 측정기준에 대해서는 Projects.get 작업을 참조하세요.

권장 조치: 프로젝트를 점검하여 해당 리소스를 많이 사용하고 있는 이유를 확인하세요. 사용량이 예상한 대로라면 Cloud DNS 할당량 증가 요청 양식을 사용하여 할당량 증가를 요청하세요.

비공개 영역(zone)

이 섹션에서는 비공개 영역 문제를 설명합니다.

공유 VPC 서비스 프로젝트의 비공개 영역 문제

베타 기간에 공유 VPC 네트워크와 비공개 영역 사용에 관한 중요한 정보는 개요 페이지에서 비공개 영역 및 공유 VPC를 참조하세요.

비공개 영역을 만들 수 없거나 정책을 나열 또는 만들 수 없음

DNS 서버 정책을 나열하거나 비공개 영역을 만드는 등 다양한 비공개 DNS 작업을 수행하려면 DNS 관리자 역할이 있어야 합니다. 이 역할은 Cloud IAM 도구를 통해 부여될 수 있습니다.

비공개 영역이 동일한 VPC 네트워크에서 확인되지 않음

기본 인터페이스가 만든 비공개 영역과 동일한 네트워크에 있는 VM에서 테스트를 수행하고 있는지 확인

트래픽이 다른 인터페이스 중 하나와 연결된 서브넷을 대상으로 하지 않거나 VM에 정책 기반 라우팅이 구성된 경우, VM은 기본 인터페이스에서 모든 트래픽을 전송합니다. 따라서 테스트 VM의 기본 인터페이스가 테스트 대상 비공개 영역과 같은 네트워크에 있는지 확인해야 합니다.

VM이 사용 중인 네트워크를 확인합니다.

gcloud compute instances describe ${vm_name} \
     --zone=${gce_zone} \
     --format="csv[no-heading](networkInterfaces['network'])"

네트워크가 비공개 영역 검색이 승인된 네트워크 목록에 있는지 확인합니다.

gcloud beta dns managed-zones describe ${private-zone-name} \
     --format="csv(privateVisibilityConfig['networks'])"

쿼리의 DNS 이름이 영역과 일치하는지 확인

GCP는 최장 서픽스 일치를 사용하여 지정된 DNS 이름을 쿼리할 영역을 결정합니다. 쿼리하는 레코드의 서픽스가 VPC 네트워크에서 액세스 가능한 비공개 영역 최소 하나 이상과 일치하는지 확인합니다. 예를 들어, GCP는 액세스 가능한 경우 gcp.example.lan을 제공하는 영역을 검색하기 전에 액세스 가능한 경우 dev.gcp.example.lan을 제공하는 영역에서 myapp.dev.gcp.example.lan을 먼저 검색합니다.

다음 명령어는 지정된 비공개 영역에 대한 DNS 서픽스를 출력합니다.

gcloud beta dns managed-zones describe ${private-zone-name} \
--format="csv[no-heading](dnsName)"

메타데이터 서버를 사용하여 DNS 이름 쿼리

dig를 사용하여 DNS 이름 쿼리를 GCP 메타데이터 서버 169.254.169.254에 직접 제출합니다.

dig ${dns-name} @169.254.169.254

dig를 사용하여 VM의 기본 네임서버를 쿼리합니다.

dig ${dns-name}

dig 명령어의 출력이 서로 다른 대답을 생성하는 경우, 두 번째 명령어의 ;; SERVER: 섹션을 확인합니다. 응답 서버는 메타데이터 서버 169.254.169.254여야 합니다. 그렇지 않으면 게스트 운영체제가 기본 GCP 메타데이터 서버 대신 커스텀 DNS 네임서버를 사용하도록 구성한 것입니다. Cloud DNS 비공개 영역에서는 메타데이터 서버를 사용하여 이름을 확인해야 합니다. Linux 게스트 환경Windows 게스트 환경 모두에서 이 작업을 수행합니다. VM에 사용 중인 이미지를 가져온 경우, 적절한 게스트 환경이 설치되어 있는지 확인해야 합니다.

Cloud VPN 또는 Cloud Interconnect를 통해 비공개 영역이 확인되지 않음

먼저 승인된 VPC 네트워크 내에서 DNS 이름을 성공적으로 쿼리 및 확인할 수 있어야 합니다.

Cloud VPN 또는 Cloud Interconnect를 통해 연결 확인

온프레미스 시스템과 VPC 네트워크 사이의 연결이 작동하는지 확인합니다. 특히, 포트 53의 TCP와 UDP 트래픽이 온프레미스 네트워크를 떠나 VPC 네트워크로 전달될 수 있어야 합니다. 이러한 송신 트래픽이 허용되는지 확인하기 위해 온프레미스 방화벽 구성을 확인합니다.

ping(ICMP)과 같은 프로토콜을 사용하면 온프레미스에서 VPC 네트워크의 샘플 VM에 대한 연결을 테스트할 수 있습니다. Cloud DNS 요청은 GCP VM으로 전송되지 않지만 샘플 VM에 대한 연결을 테스트하면 Cloud VPN 터널 또는 Cloud Interconnect를 통한 연결을 확인할 수 있습니다. 묵시적 수신 거부 규칙이 모든 들어오는 트래픽을 차단하므로, 샘플 GCP VM에 대해 적절한 수신 허용 방화벽 규칙을 구성해야 합니다.

승인된 VPC 네트워크에 대해 인바운드 전달 사용 설정 확인

Cloud DNS 비공개 영역을 쿼리하도록 승인된 각 VPC 네트워크에 인바운드 전달을 사용 설정해야 합니다. 다음 명령어를 사용하여 모든 정책을 나열합니다.

gcloud beta dns policies list

출력 테이블에서 네트워크를 식별하고, 전달 필드에서 전달이 사용 설정되어 있는지 확인합니다.

승인된 네트워크가 VPC 네트워크인지 확인

DNS 전달에서는 서브넷이 필요하며, 레거시 네트워크아닌 VPC 네트워크에만 서브넷을 사용할 수 있습니다.

gcloud compute networks list \
     --format="csv[no-heading](name, SUBNET_MODE)"

이전 네트워크는 출력에서 LEGACY로 식별됩니다.

해당 네트워크에 유효한 DNS 전달 주소가 예약되어 있는지 확인

아래 명령어는 프로젝트에 예약된 모든 DNS 전달자 IP 주소를 표시합니다.

gcloud compute addresses list \
     --filter="purpose=DNS_RESOLVER" \
     --format='csv[no-heading](address, subnetwork)'

필터에 AND 절을 추가하여 관심 있는 하위 네트워크로만 출력되도록 제한할 수 있습니다.

예: --filter="name ~ ^dns-forwarding AND subnetwork ${subnetwork-name}"

예상한 네트워크/리전에 IP 주소가 표시되지 않으면 Cloud 지원에 티켓을 제출합니다.

위에서 확인한 주소에서 쿼리를 가리키는 dig 명령어를 수행합니다. 동일한 네트워크에 있는 VM에서 이 작업을 수행합니다. 이 테스트는 인바운드 전달자가 작동하고 문제가 다른 곳에 있는지 확인합니다.

dig ${dns-name} @10.150.0.1 # - address returned by command above.

VPN을 통해 VM에서 동일한 dig 명령어를 반복합니다.

비공개 영역에 정의된 CNAME 레코드가 작동하지 않음

동일한 비공개 영역에서 다른 레코드를 참조하는 CNAME 레코드는 지원됩니다. 다른 비공개 영역, .internal 영역 또는 인터넷에 정의된 도메인 이름을 가리키는 CNAME 레코드는 지원되지 않습니다.

전달 영역(zone)

이 섹션에서는 전달 영역에 대한 문제해결 팁을 제공합니다. 일부 비공개 영역은 전달 영역에도 적용됩니다. 추가적인 도움말은 비공개 영역 문제해결 섹션을 참조하세요.

전달 영역(아웃바운드 전달)이 작동하지 않음

먼저 승인된 VPC 네트워크 내에서 DNS 이름을 성공적으로 쿼리 및 확인할 수 있어야 합니다.

Cloud VPN 또는 Cloud Interconnect를 통해 연결 확인

ping(ICMP)과 같은 프로토콜을 사용하면 온프레미스에서 VPC 네트워크의 샘플 VM에 대한 연결을 테스트할 수 있습니다. dig와 같은 도구를 사용하여 샘플 GCP VM에서 직접 온프레미스 네임서버를 쿼리해야 합니다.

dig ${dns-name} @192.168.x.x # - address of the onprem DNS server.

VPC 네트워크에서 방화벽 규칙 확인

묵시적인 송신 허용 방화벽 규칙은 송신을 거부하는 커스텀 규칙을 만든 경우가 아니면 VPC 네트워크에서 아웃바운드 연결과 VM의 설정된 응답을 허용합니다. 커스텀 송신 거부 규칙을 만든 경우에는 적어도 온프레미스 네임서버로 송신을 허용하는 더 높은 우선 순위의 허용 규칙을 만들어야 합니다.

온프레미스 방화벽 확인

온프레미스 방화벽이 35.199.192.0/19에서 들어오고 나가는 트래픽을 허용하도록 구성되어 있는지 확인합니다.

온프레미스 방화벽의 로그를 확인하여 35.199.192.0/19에서 DNS 요청을 검색합니다. 정규 표현식을 사용하여 검색하려면 다음을 사용합니다. "35\.199\.(19[2-9]|22[0-3]).*"

온프레미스 네임서버 확인

온프레미스 네임서버에 35.199.192.0/19의 쿼리를 차단하는 ACL이 구성되어 있지 않은지 확인합니다.

온프레미스 네임서버가 35.199.192.0/19에서 패킷을 수신하는지 확인합니다. 셸 액세스 권한이 있는 경우, tcpdump와 같은 도구를 사용하여 35.199.192.0/19에서 들어오고 나가는 패킷을 모두 검색합니다.

sudo tcpdump port 53 and tcp -vv

반환 경로 확인

온프레미스 네트워크에는 35.199.192.0/19 대상에 대한 경로가 있어야 하며, 다음 홉은 전달 영역 만들기에 설명된 대로 DNS 요청을 전송한 동일한 VPC 네트워크에 대한 VPN 터널이어야 합니다.

여러 VPN 터널을 사용하여 동일한 VPC 네트워크를 온프레미스 네트워크에 연결하는 경우, 응답을 전송한 동일한 터널을 사용하여 응답을 전달할 필요가 없습니다. 그러나 응답은 VPN 터널을 사용하여 전달되어야 하며 다음 홉은 요청이 발생한 동일한 VPC 네트워크에 있어야 합니다.

온프레미스 네트워크에 VPC 네트워크를 한 개 이상 연결한 경우, DNS 응답이 잘못된 네트워크로 전송되지 않도록 해야 합니다. GCP는 잘못된 VPC 네트워크로 전송된 DNS 응답을 무시합니다.

비공개 영역에 정의된 CNAME 레코드가 작동하지 않음

Cloud DNS에서는 다른 관리형 비공개 영역(CNAME 추적)의 A 레코드를 가리키는 CNAME을 통해 IP 주소를 재귀적으로 확인하는 것을 지원하지 않습니다. 예를 들어 2개의 관리형 비공개 영역인 zone-a.privatezone-b.private가 있고 다음과 같은 레코드를 만들었다고 가정해 보겠습니다.

  • target.zone-b.private을 가리키는 CNAME cname.zone-a.private
  • 192.168.1.9를 가리키는 A 레코드 target.zone-b.private

2개의 레코드가 동일한 영역에 없으므로(zone-a.privatezone-b.private은 다름) Cloud DNS는 cname.zone-a.private192.168.1.9로 확인하지 않습니다.

Cloud DNS는 관리형 비공개 영역 내에서 CNAME을 추적합니다.

RFC 1918 비공개 IP를 사용하지 않는 네임서버를 통한 전달 실패

온프레미스 DNS 네임서버가 공개적으로 라우팅 가능한 (RFC 1918이 아닌) IP 주소를 사용하는 경우에는 Cloud DNS가 전달을 지원하지 않습니다.

다음 단계

  • 개요에서 기능에 대한 더 많은 컨텍스트가 제공됩니다.
  • 추가 도움을 받으려면 지원 영역을 참조합니다.
이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

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

Cloud DNS 문서