이 문서에서는 Google Distributed Cloud (GDC) 에어 갭에서 Cloud DNS 문제를 해결하는 방법을 안내합니다. DNS 구성에서 관리 작업을 수행할 때 발생할 수 있는 잠재적 오류와 문제를 다루고 DNS 변환 문제를 디버깅하기 위한 도움말과 제안을 제공합니다. 이 문서의 주요 대상은 프로젝트 내에서 DNS 레코드를 관리하는 플랫폼 관리자와 애플리케이션 운영자입니다.
Cloud DNS 관리 작업 문제 해결
이 섹션에서는 Cloud DNS 영역 및 레코드 세트에서 만들기, 읽기, 업데이트, 삭제 (CRUD) 작업을 수행할 때 발생하는 일반적인 문제에 대한 문제 해결 정보를 제공합니다.
기본 문제 해결
- IAM 권한 준비에 설명된 대로 올바른 IAM 역할이 있는지 확인합니다.
gdcloud을 사용하는 경우gdcloud auth login을 실행하여 인증 토큰을 새로고침할 수 있습니다.
리소스 이름 지정 및 검증 (RFC 1123)
문제: 잘못된 인수 또는 검증 오류로 인해 생성 또는 업데이트가 실패합니다.
Details:
- 리소스 이름: DNS 영역 및 레코드 세트의 이름은 RFC를 준수해야 합니다.
- 소문자 영숫자 문자 또는
-만 포함해야 하며 영숫자 문자로 시작하고 끝나야 합니다.
- 소문자 영숫자 문자 또는
- DNS 이름: 도메인 이름 및 정규화된 도메인 이름(FQDN)의 값은 유효한 도메인 이름이어야 합니다.
- Enum 값: 공개 상태 (
PUBLIC또는PRIVATE) 및 레코드 유형 (예:A,CNAME)과 같은 값은 대소문자를 구분하며 예상되는 정확한 문자열과 일치해야 합니다.
비어 있지 않은 영역을 삭제할 수 없음
문제: 관리형 영역을 삭제할 수 없습니다. 작업이 거부됩니다.
세부정보: 관리형 DNS 영역을 삭제하려면 리소스 레코드 세트가 비어 있어야 합니다. 먼저 영역 내의 모든 레코드를 삭제해야 합니다.
이름 지정 및 도메인 충돌
문제: 이름 또는 도메인이 이미 사용 중임을 나타내는 오류로 인해 리소스를 만들 수 없습니다.
Details:
- Kubernetes 리소스 이름: 객체 이름 (예:
metadata.name의 이름)은 특정 프로젝트 네임스페이스 내에서 고유해야 합니다. - DNS 이름 (FQDN): 실제 도메인 이름 (예: 영역 또는 레코드의 경우
dnsName)은 지정된 공개 상태 (공개 또는 비공개) 내에서 고유해야 합니다. 동일한 공개 상태 등급에서 동일한 도메인 이름으로 두 개의 영역 또는 두 개의 레코드를 만들 수 없습니다.
DNS 변환 문제 해결
이 섹션에서는 플랫폼 관리자와 애플리케이션 운영자가 Google Distributed Cloud에서 호스팅되는 서비스에 액세스할 때 DNS 변환 문제를 해결하는 데 도움이 됩니다.
전파 대기 및 DNS 캐시 삭제
DNS 레코드가 생성되거나 업데이트되면 변경사항이 즉시 표시되지 않을 수 있습니다. 이러한 지연은 일반적으로 다음과 같은 이유로 발생합니다.
- 조정 시간: 시스템에서 요청을 처리하고 DNS 서버 구성을 업데이트하는 데 시간이 필요합니다. 보통 몇 분 정도 걸립니다.
- DNS 전파 지연 (캐싱): DNS 리졸버와 클라이언트는 조회를 가속화하기 위해 레코드를 캐시합니다. 클라이언트는 TTL (수명) 기간이 지날 때까지 이전 레코드를 계속 사용할 수 있습니다.
권장사항:
- 대기: 조정 및 캐시 만료에 충분한 시간을 허용합니다.
- 캐시 플러시: 로컬 DNS 캐시를 삭제하여 새 조회를 강제 실행합니다.
로컬 리졸버 구성 확인
클라이언트가 올바른 DNS 서버를 사용하고 있는지 확인합니다. 올바른 IP 주소를 모르는 경우 인프라 운영 (IO)팀에 문의하여 올바른 DNS 서버 IP를 찾으세요.
- Linux/macOS:
/etc/resolv.conf의 콘텐츠를 확인합니다. - Windows:
ipconfig /all를 실행하고 나열된 DNS 서버를 확인합니다.
고객 네트워크의 플랫폼 관리자 (PA) 및 애플리케이션 운영자 (AO) 워크스테이션은 IO WAN 및 OIRv2 네트워크와 별개인 DNS 변환을 사용해야 합니다. 동일한 GDC 도메인 이름은 쿼리가 IO WAN을 통해 도착하는지 아니면 고객 상호 연결을 통해 도착하는지에 따라 다른 IP 주소로 확인되므로 IO 및 PA 또는 AO 워크스테이션 모두에 공유 DNS 구성을 사용할 수 없습니다. 자세한 내용은 시스템 상호 연결, DNS 도메인 이름 지정 스키마, DNS-R0016 런북을 참조하세요.
표준 도구를 사용하여 해결 방법 테스트
표준 명령줄 도구를 사용하여 확인을 테스트하고 오류가 발생하는 위치를 식별합니다.
기본 조회:
dig <domain_name>또는
nslookup <domain_name>특정 DNS 서버 쿼리: 공개 ManagedDNS 서버의 IP를 알고 있는 경우 직접 쿼리하여 로컬 리졸버를 우회합니다.
dig @<public_dns_server_ip> <domain_name>공개 네임서버 쿼리: 로컬 리졸버 문제를 배제하려면 Google DNS와 같은 공개 리졸버를 쿼리해 보세요.
dig @8.8.8.8 <domain_name>
DNS 응답 코드 분석
dig 또는 nslookup을 사용하는 경우 응답의 상태 코드를 확인합니다.
- NXDOMAIN: 도메인 이름을 찾을 수 없습니다. 오타가 있는지 확인하거나 레코드가 있는지 확인하세요.
- SERVFAIL: 서버에서 쿼리를 처리하지 못했습니다. 이는 서버 측 문제 또는 DNS 서버 간의 통신 실패를 나타내는 경우가 많습니다.
- NOERROR: 쿼리가 성공했지만 답변이 없을 수 있습니다. 요청된 레코드 유형 (예: A, CNAME)이 있는지 확인합니다.
- REFUSED: 서버가 정책 또는 액세스 제어 설정으로 인해 쿼리에 대한 응답을 거부했습니다.
네트워크 연결 확인
DNS 서버로의 네트워크 트래픽이 차단되지 않는지 확인합니다.
- DNS는 UDP와 TCP 모두에 포트 53을 사용합니다.
nc(netcat)를 사용하여 연결을 테스트합니다.nc -zv <dns_server_ip> 53방화벽 규칙이 포트 53의 트래픽을 허용하는지 확인합니다.
DNS 캐시 삭제
DNS 캐시를 플러시하면 로컬 DNS 캐시에서 모든 항목이 삭제됩니다. 이렇게 하면 운영체제가 도메인 이름에 대해 DNS 서버에 다시 쿼리하여 오래된 캐시 레코드가 아닌 최신 레코드를 가져옵니다.
- Windows:
ipconfig /flushdns- 기능: DNS 클라이언트 서비스에서 유지관리하는 DNS 리졸버 캐시를 삭제합니다.
- macOS:
sudo killall -HUP mDNSResponder- 기능:
mDNSResponder프로세스에 끊기 신호 (HUP)를 전송하여 강제로 새로고침하고 캐시를 지웁니다.
- 기능:
- Linux (systemd-resolved):
sudo systemd-resolve --flush-caches또는sudo resolvectl flush-caches- 기능:
systemd-resolved서비스에 내부 DNS 캐시를 삭제하도록 지시합니다.
- 기능:
API 또는 gdcloud로 리소스 상태 확인
테넌트이거나 GDC API에 액세스할 수 있는 경우 리소스 상태를 직접 확인할 수 있습니다.
DNS 영역 확인:
kubectl describe manageddnszone <zone_name> -n <project_namespace>리소스 레코드 세트 확인:
kubectl describe resourcerecordset <record_name> -n <project_namespace>조정 프로세스의 실패를 나타낼 수 있는 조건과 이벤트를 찾습니다.
gdcloud 명령줄에 액세스할 수 있는 경우 DNS 레코드 나열 또는 DNS 영역 나열에 설명된 대로 describe 하위 명령어를 사용할 수 있습니다.