이 페이지는 Cloud Translation API를 통해 번역되었습니다.

Cloud DNS 문제 해결

이 페이지에서는 Cloud DNS를 사용하여 공개 영역, 비공개 영역, 역방향 조회 영역, 전달 영역, 리소스 레코드를 만들 때 발생할 수 있는 일반적인 문제에 대한 해결 방법을 제공합니다.

공개 영역

이 섹션에서는 공개 영역과 관련된 문제를 다룹니다.

공개 영역을 만들 수 없음

attempted action failed 오류가 발생한다면 프로젝트에 Cloud DNS API가 사용 설정되지 않은 것입니다.

Cloud DNS API를 사용 설정하려면 다음 단계를 따르세요.

Google Cloud 콘솔에서 API 라이브러리 페이지로 이동합니다.

API 라이브러리로 이동
최근 프로젝트 선택에서 API를 사용 설정할 Google Cloud 프로젝트를 선택합니다.
API 라이브러리 페이지에서 API 및 서비스 검색 상자를 사용하여 Cloud DNS API를 검색합니다. API를 설명하는 페이지가 나타납니다.
사용 설정을 클릭합니다.

비공개 영역

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

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

공유 VPC 네트워크와 함께 비공개 영역을 사용하는 방법에 대한 자세한 내용은 비공개 영역 및 공유 VPC를 참조하세요.

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

DNS(도메인 이름 시스템) 서버 정책 나열 또는 비공개 영역 생성과 같은 다양한 비공개 영역 작업을 수행하려면 DNS 관리자 역할이 있어야 합니다. Identity and Access Management(IAM) 도구를 통해 이 역할을 부여할 수 있습니다.

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

만든 비공개 영역과 동일한 네트워크에 기본 인터페이스가 있는 VM 인스턴스에서 테스트를 수행해야 합니다.

가상 머신(VM) 인스턴스는 트래픽이 다른 인터페이스 중 하나에 연결된 서브넷으로 지정되지 않은 경우 또는 VM에 정책 라우팅이 구성된 경우 기본 인터페이스로부터 모든 트래픽을 전송합니다. 테스트 VM이 테스트할 비공개 영역과 동일한 네트워크에 기본 인터페이스가 있는지 확인합니다.

VM이 사용 중인지 확인합니다.

gcloud compute instances describe VM_NAME \
    --zone=GCE_ZONE \
    --format="csv[no-heading](networkInterfaces['network'])"

네트워크가 비공개 영역을 쿼리하도록 승인된 네트워크 목록에 있는지 확인합니다.

gcloud dns managed-zones describe PRIVATE_ZONE_NAME \
    --format="csv(privateVisibilityConfig['networks'])"

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

Google Cloud는 이름 변환 순서에 따라 레코드를 확인하며, 가장 긴 서픽스가 있는 영역을 사용하여 지정된 DNS 이름으로 쿼리할 영역을 결정합니다. 쿼리할 레코드의 서픽스가 VPC 네트워크에서 액세스할 수 있는 비공개 영역 한 개 이상과 일치하는지 확인합니다. 예를 들어 Google Cloud는 액세스 가능한 경우 dev.gcp.example.lan을 제공하는 영역에서 myapp.dev.gcp.example.lan을 먼저 검색한 후 gcp.example.lan을 제공하는 영역(액세스 가능한 경우)에서 검색합니다.

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

gcloud dns managed-zones describe PRIVATE_ZONE_NAME \
    --format="csv[no-heading](dnsName)"

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

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

dig DNS_NAME @169.254.169.254

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

dig DNS_NAME

두 dig 명령어의 출력이 서로 다른 대답을 생성하는 경우 두 번째 명령어의 ;; SERVER: 섹션을 확인합니다. 응답 서버는 메타데이터 서버 169.254.169.254여야 합니다. 그렇지 않으면 게스트 운영체제가 기본 Google Cloud 메타데이터 서버 대신 커스텀 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 요청이 Google Cloud VM에 전송되지 않더라도 샘플 VM 연결을 테스트하면 Cloud VPN 터널 또는 Cloud Interconnect 연결을 통해 연결을 확인할 수 있습니다. 암시적 인그레스 거부 규칙이 들어오는 모든 트래픽을 차단하므로 샘플 Google Cloud VM에 적절한 인그레스 허용 방화벽 규칙을 구성해야 합니다.

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

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

gcloud 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 주소가 표시되지 않으면 Google Cloud 지원팀에 티켓을 제출하세요.

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

dig DNS_NAME @10.150.0.1 # address returned by previous command

VPN을 통해 온프레미스 호스트에서 동일한 dig 명령어를 반복합니다.

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

Cloud DNS는 CNAME 추적에 설명된 대로 CNAME 레코드만 추적합니다.

역방향 조회 영역

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

비RFC 1918 주소를 사용한 VM이 확인되지 않음

비RFC 1918 주소로 VM 조정

Cloud DNS 지원이 시작되기 전에 비RFC 1918 알파 동안 VM을 만들면 VM이 올바르게 확인되지 않을 수 있습니다. 이 문제를 해결하려면 VM을 다시 시작하세요.

전달 영역

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

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

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

소비자 VPC 네트워크의 VM에서 공급자 VPC 네트워크로 쿼리가 전달되지 않음

DNS 피어링을 사용 중이고 소비자 VPC 네트워크의 VM에서 공급자 VPC 네트워크로 쿼리를 전달한 후 온프레미스 네임서버 한 개 이상에 전달하려면 다음 기본 요건 중 하나를 충족해야 합니다.

동적 라우팅 모드가 GLOBAL로 설정된 프로듀서 VPC 네트워크
소비자 VPC 네트워크의 VM이 프로듀서 VPC의 VPN 터널 또는 Cloud Interconnect과 동일한 리전에 있음
(기본 VPN만 해당) 프로듀서 VPC 네트워크에는 기본 VPN 터널을 통해 온프레미스 네임서버로 향하는 트래픽을 전송하도록 정적 경로가 구성됩니다. 또한 프로듀서 VPC 네트워크에는 클라이언트 VM에서 사용하는 하위 네트워크와 동일한 리전에 VM 또는 VPN 터널이 있어야 합니다.
- 예를 들어 VPC1이 example.com.의 쿼리를 VPC2로 전송하는 피어링 영역을 사용한다고 가정해 보겠습니다. 또한 VPC2에는 기본 VPN 터널을 사용하여 쿼리를 온프레미스 네임서버로 전달하는 example.com.에 대한 비공개 전달 영역이 있습니다.
  
  us-east1에 있는 VPC1의 VM이 example.com.을 쿼리할 수 있으려면 VPC2의 VM이 us-east1에 있어야 합니다. 또한 온프레미스 네임서버의 CIDR 범위를 포함하는 정적 경로를 구성해야 하며, 다음 홉은 기본 VPN 터널로 구성해야 합니다.

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

ping(ICMP)과 같은 프로토콜을 사용하여 온프레미스에서 VPC 네트워크의 샘플 VM에 대한 연결을 테스트할 수 있습니다. 또한 dig와 같은 도구를 사용하여 샘플 Google Cloud 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 요청을 검색합니다. regex 표현식을 사용하여 검색하려면 다음을 사용합니다.

"35\.199\.(19[2-9]|20[0-9]|21[0-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 응답이 잘못된 네트워크로 전송되지 않도록 해야 합니다. Google Cloud는 잘못된 VPC 네트워크로 전송된 DNS 응답을 무시합니다. 권장 솔루션은 권장사항 가이드를 참조하세요.

비RFC 1918 IP 주소를 사용하는 네임서버로 아웃바운드 전달 실패

기본적으로 Cloud DNS는 대상 네임서버에 비RFC 1918 IP 주소가 포함된 경우 공개 인터넷을 통해 쿼리를 라우팅하는 표준 라우팅을 사용합니다. 표준 라우팅에서는 공개 인터넷에서 연결할 수 없는 비RFC 1918 주소로 네임서버에 대한 쿼리를 전달할 수 없습니다.

VPC 네트워크를 통해 비RFC 1918 IP 주소를 사용하는 네임서버로 쿼리를 전달하려면 대상 네임서버에 비공개 라우팅을 사용하도록 Cloud DNS 전달 영역이나 서버 정책을 구성합니다.

표준 라우팅과 비공개 라우팅의 차이점에 대한 설명은 전달 대상 및 라우팅 방법을 참조하세요.

이 제한은 대상 네임서버의 VPC 경로가 있더라도 적용됩니다. 표준 라우팅이 구성된 경우 비RFC 1918 주소의 경로는 Cloud DNS의 아웃바운드 전달 동작에 영향을 미치지 않습니다.

보조 NIC에 대한 아웃바운드 전달 실패

보조 네트워크 인터페이스 컨트롤러(NIC)가 올바르게 설정되었는지 확인합니다.

추가 NIC를 설정하는 방법은 여러 네트워크 인터페이스로 가상 머신 인스턴스 만들기를 참조하세요.

아웃바운드 전달된 쿼리의 SERVFAIL 오류 수신

Cloud DNS가 모든 대상 네임서버에서 오류를 수신하거나 어떠한 대상 네임서버에서도 응답을 수신하지 않으면 SERVFAIL 오류가 반환됩니다.

이 문제를 해결하려면 온프레미스 네임서버가 올바르게 구성되었는지 확인합니다. 그런 다음 Google Cloud 및 온프레미스 방화벽을 열어 DNS 트래픽 허용에 설명된 Cloud DNS 주소 범위로 부터의 쿼리에 온프레미스 네임서버가 4초 이내에 응답하는지 확인합니다. 온프레미스 네임서버가 업스트림 네임서버를 참조하는 경우(예: 캐싱 리졸버로 구성됨) 업스트림 네임서버에 문제가 없는지 확인합니다.

또한 전달 대상이 온프레미스 시스템이면 해당 경로에 대해 구성된 경로가 커스텀 동적 경로 또는 커스텀 정적 경로일 수 있습니다. 네트워크 태그가 포함된 커스텀 정적 경로는 DNS 쿼리를 전달하는 데 적합하지 않습니다. 온프레미스 네임서버 연결에 사용되는 경로는 네트워크 태그를 지정하지 않습니다.

리소스 레코드

이 섹션에서는 리소스 레코드의 문제 해결 도움말을 제공합니다.

영역에 있는 리소스 레코드 모음을 쿼리할 때 예기치 않은 데이터 수신

Cloud DNS 관리형 영역에 있는 리소스 레코드 모음을 쿼리할 때 예기치 않은 데이터가 수신될 수 있는 이유는 다음과 같습니다.

RFC 1035에 지정된 @ 구문을 사용하여 만든 리소스 레코드 모음은 지원되지 않습니다. Cloud DNS는 이러한 리소스 레코드 모음의 @ 기호를 문자 그대로 해석합니다. 따라서 example.com. 영역에서 QNAME @에 만든 레코드 모음은 example.com. 대신 @.example.com.으로 해석됩니다. 이 문제를 해결하려면 @ 기호 없이 레코드 모음을 만들어야 합니다. 즉, 영역의 루트를 모든 이름의 기준으로 합니다.
모든 레코드와 마찬가지로 와일드 카드 CNAME 레코드에는 RFC 4592에 설명된 기존 규칙이 적용됩니다. 예를 들어 example.com. 영역에 다음 레코드 모음을 정의한다고 가정해 보겠습니다.

*.images.example.com. IN CNAME _static.example.com.

srv1.images.example.com. IN A 192.0.2.91

_static.example.com. IN A 192.0.2.92

public.srv1.images.example.com.을 쿼리하면 빈 답변 섹션이 있는 NOERROR가 반환됩니다. CNAME과 QNAME 사이에 레코드가 있으면 CNAME이 반환되지 않습니다. 하지만 QNAME과 정확하게 일치하는 레코드가 없으므로 Cloud DNS는 빈 답변을 반환합니다. 이는 표준 DNS 동작입니다.

Google Cloud VM에 잘못된 포인터(PTR) 레코드가 표시됨

유지보수 이벤트 중에 VM이 마이그레이션되면 PTR 레코드 로직이 일부 특이 사례를 올바르게 처리하지 않고 DNS PTR 레코드를 googleusercontent.com 정규화된 도메인 이름(FQDN)으로 되돌립니다. 기능을 복원하려면 PTR 레코드를 다시 적용합니다.

VM에 PTR 레코드를 적용하는 방법에 대한 자세한 내용은 VM 인스턴스의 PTR 레코드 만들기를 참조하세요.

Cloud DNS 리소스 레코드 모음이 무작위 순서로 반환됨

DNS 업계 관행에 따라 Cloud DNS 네임서버는 이제 리소스 레코드 모음 순서를 무작위로 지정하고 권한 서버에서 지정된 순서를 무시합니다. 이는 정상적인 DNS 동작이며 공개 및 비공개 Cloud DNS 영역 모두에 적용됩니다.

지원되지 않는 영역별 리소스 유형

다른 Cloud DNS 영역을 대상으로 하는 기능에 대한 gcloud 명령어 또는 API 요청에 --location 플래그를 입력하면 요청이 거부됩니다. 예를 들어 영역 전용 기능 요청을 전역 서버에 보내거나 전역 전용 기능 요청을 영역 서버로 보내면 서버가 요청을 거부하고 _UNSUPPORTED_ZONAL_RESOURCETYPE 오류가 발생합니다.

영역 Cloud DNS가 지원하는 리소스 및 기능 목록은 영역 Cloud DNS 지원을 참조하세요.

다음 단계

기능에 대한 자세한 내용은 Cloud DNS 개요를 참조하세요.
오류를 해결하려면 오류 메시지를 참조하세요.
추가 도움을 받으려면 지원을 참조하세요.