문제해결

문제해결 페이지에서는 Cloud DNS를 만들 때 발생할 수 있는 일반적인 문제에 대해 설명합니다. 비공개 영역(zone), 전달 영역(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 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 주소가 표시되지 않으면 Cloud 지원에 티켓을 제출합니다.

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

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

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

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

동일한 비공개 영역에서 다른 레코드를 참조하는 CNAME 레코드는 지원됩니다. 다른 비공개 영역, .internal 영역 또는 인터넷에 정의된 도메인 이름을 가리키는 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 요청을 검색합니다. 정규 표현식을 사용하여 검색하려면 "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를 가리키는 레코드 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는 표준 라우팅을 사용합니다. 즉, 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 주소를 사용하는 VPC에서의 인바운드 전달이 실패함

Cloud DNS는 VPC에 비RFC 1918 주소 범위가 사용될 경우 인바운드 전달을 지원하지 않습니다.

다음 단계

  • 개요에서 기능에 대한 더 많은 컨텍스트가 제공됩니다.
  • 추가 도움을 받으려면 지원 영역을 참조합니다.