문제 해결

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

비공개 영역

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

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

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

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

DNS(도메인 이름 시스템) 서버 정책 나열 또는 비공개 영역 생성과 같은 다양한 비공개 영역 작업을 수행하려면 DNS 관리자 역할이 있어야 합니다. ID 및 액세스 관리(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 레코드가 작동하지 않음

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

역방향 조회 영역

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

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

비RFC 1918 주소로 VM 조정

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

전달 영역

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

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

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

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

DNS 피어링을 사용 중이고 소비자 VPC 네트워크의 VM에서 공급자 VPC 네트워크로 쿼리를 전달한 후 온프레미스 네임서버 한 개 이상에 전달하려면 공급자 VPC 네트워크의 VM이나 VPN 터널이 클라이언트 VM에서 사용된 서브네트워크와 동일한 리전에 있는지 확인해야 합니다.

예를 들어 VPC1이 example.com.의 쿼리를 VPC2로 전송하는 피어링 영역을 사용한다고 가정해 보겠습니다. 또한 VPC2에는 Cloud VPN 터널 또는 Cloud Interconnect를 사용하여 쿼리를 온프레미스 네임서버로 전달하는 example.com.에 대한 비공개 전달 영역이 있습니다. us-east1에 있는 VPC1의 VM이 example.com.을 쿼리할 수 있으려면 VPC2의 VM 또는 VPN 터널도 us-east1에 있어야 합니다.

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 응답을 무시합니다.

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

Cloud DNS에서는 다른 관리형 비공개 영역(CNAME 추적)의 A 레코드를 가리키는 CNAME을 사용하여 IP 주소를 재귀적으로 확인할 수 없습니다. 예를 들어 zone-a.privatezone-b.private이라는 관리형 비공개 영역이 두 개 있고 다음과 비슷한 레코드를 만든다고 가정해 보겠습니다.

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

두 레코드가 같은 영역에 있지 않으므로(zone-a.privatezone-b.private은 서로 다름) Cloud DNS에서 cname.zone-a.private192.168.1.9로 확인하지 않습니다.

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

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

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

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

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

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

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

Cloud DNS는 현재 Compute Engine VM의 보조 NIC에 대한 전달을 지원하지 않습니다.

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

Cloud DNS 제어 영역은 알고리즘을 사용하여 전달 대상의 응답성을 결정합니다. 응답성 점수는 SERVFAIL 오류 수와 수신된 응답의 지연 시간을 기반으로 합니다. SERVFAIL 오류는 지연 시간보다 점수에 더 큰 영향을 미칩니다. 점수는 1시간마다 재설정됩니다.

영역의 모든 대상 점수가 낮으면 Cloud DNS는 이러한 대상으로 쿼리를 전송하지 않습니다. 다음 증상이 한 개 이상 나타날 수 있습니다.

  • Cloud DNS 전달을 사용하면 빠른(약 2ms) SERVFAIL 오류가 발생합니다.
  • 쿼리의 Cloud Logging 로그에서 destinationIP, egressIP, egressError 필드가 채워지지 않습니다.
  • DNS 서버에 쿼리 시도가 표시되지 않습니다.
  • 전달 대상에 직접 보내는 쿼리(예: dig @<TARGET> <QNAME>)가 성공할 수 있습니다.

이 문제를 해결하려면 온프레미스 네임서버가 올바르게 구성되었는지 확인합니다. 그런 다음 온프레미스 네임서버가 4초 이내에 쿼리에 응답하는지 확인합니다. 온프레미스 네임서버가 업스트림 네임서버를 참조하는 경우(예: 캐싱 리졸버로 구성됨) 업스트림 네임서버에 문제가 없는지 확인합니다.

비RFC 1918 IP 주소 범위를 사용하는 VPC 네트워크에서 인바운드 전달 실패

Cloud DNS는 VPC 네트워크에서 비RFC 1918 주소 범위를 사용하는 경우 인바운드 전달을 지원하지 않습니다.

리소스 레코드

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

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

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

  1. RFC 1035에 지정된 @ 구문을 사용하여 만든 리소스 레코드 모음은 지원되지 않습니다. Cloud DNS는 이러한 리소스 레코드 모음의 @ 기호를 문자 그대로 해석합니다. 따라서 example.com. 영역에서 QNAME @에 만든 레코드 모음은 example.com. 대신 @.example.com.으로 해석됩니다. 이 문제를 해결하려면 @ 기호 없이 레코드 모음을 만들어야 합니다. 즉, 영역의 루트를 모든 이름의 기준으로 합니다.

  2. 모든 레코드와 마찬가지로 와일드 카드 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 동작입니다.

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

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

다음 단계

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