도메인 문제 해결

Google Public DNS에서 도메인을 변환할 수 없는 경우 주로 해당 도메인 또는 권한 네임서버에 문제가 있기 때문입니다. 다음 단계는 도메인 관리자가 직접 문제를 해결할 수 있도록 문제의 원인을 파악하는 데 도움이 됩니다.

이 단계를 시작하기 전에 일반적인 문제 해결 페이지에 설명된 대로 dns.google에서 도메인을 확인합니다. 이 페이지에서는 아래의 특정 진단 단계를 참조할 수 있습니다. 그렇지 않으면 원인을 찾을 때까지 다음 단계를 모두 수행합니다.

1단계: DNSSEC 유효성 검사 문제 확인

도메인의 dns.google 웹 조회에 "Status": 2(SERVFAIL) 및 DNSSEC가 없는 쿼리가 성공하면 도메인의 네임서버 또는 등록된 도메인의 DNSSEC 유효성 검사를 위해 DS 레코드를 게시하는 최상위 도메인(TLD) 레지스트리에 DNSSSEC 문제가 있는 것일 수 있습니다.

등록기관 또는 DNS 서비스 변경사항

DNSSEC는 도메인이 DNSSEC를 지원하는 등록기관 또는 DNS 서비스에서 전환된 후에 발생할 수 있습니다. 이전 서비스가 TLD 레지스트리에 오래된 DS 레코드를 남기고 새 서비스가 TLD 레지스트리에 일치하는 DS 레코드로 새 DNSKEY 레코드를 만들지 않는 경우, Google Public DNS와 같은 유효성 검사 리졸버는 도메인을 확인할 수 없습니다.

이 경우 도메인 등록기관에 TLD 레지스트리에서 비활성 DS 레코드를 삭제하도록 요청하세요.

DNSSEC 응답이 너무 큼

DNSSEC 문제의 또 다른 원인은 하나의 IP 패킷에 들어가지 못할 정도로 큰 DNSSEC 응답이므로 삭제될 수 있는 분할된 응답입니다. DNSViz에서 UDP 페이로드 크기가 줄어들 때까지 응답이 수신되지 않은 것으로 표시되면 매우 큰 응답으로 인해 DNSSEC 실패가 발생할 수 있습니다. 응답 크기는 다음 작업 중 하나 이상으로 줄일 수 있습니다.

• 신뢰할 수 있는 네임서버에 대한 최소 응답 구성
• 활성 DNSKEY 레코드 수를 2~3개로 줄입니다.
• 1280비트 또는 2048비트 DNSKEY 레코드(RFC 6781, StackExchange)를 사용합니다.
• RSA 서명에서 더 작은 ECDSA 서명으로 전환 (RFC 8624)

또한 2단계의 도구에서 보고된 다른 DNSSEC 문제가 있는지 확인합니다. 예를 들어 잘못된 NSEC 또는 NSEC3 존재 거부 레코드가 하위 도메인 (외부 데이터베이스에 저장된 영역이 있는 PowerDNS)이 없음을 증명하거나 만료된 RRSIG 서명 (손상된 구성 프로세스 손상)을 포함합니다.

2단계: 권한 있는 네임서버 확인하기

Google Public DNS (또는 열려 있는 리졸버)에서 도메인을 확인하는 데 문제가 있으면 DNSViz에 도메인 및 네임서버 문제가 표시됩니다. DNSViz 웹페이지로 이동하여 문제가 있는 도메인 이름을 입력합니다. DNSViz에 이전 데이터가 없거나 페이지에 표시된 것과 같이 하루 이상 지난 데이터만 있는 경우, 큰 분석 버튼을 클릭하여 아래의 더 작은 분석 버튼(아직 표시되지 않은 경우)을 표시하고 클릭합니다. 분석이 완료되면 '계속'을 클릭하여 결과를 표시합니다. 왼쪽 사이드바의 빨간색 오류 및 노란색 경고를 클릭하여 세부정보를 표시하거나 다이어그램의 객체 위에 포인터를 가져가면 해당 정보가 컨텍스트에 표시됩니다.

이전 진단에서 도메인에 DNSSEC 문제가 있을 수 있다면 DNSSEC Analyzer 웹페이지로 이동하여 도메인 이름을 입력합니다. 이 분석기가 DNSSEC 오류 또는 경고를 보고하는 경우 빨간색 ⊗ 또는 노란색 ⚠⚠ 아이콘 위로 마우스 포인터를 가져가면 알맞은 해결 방법이 표시됩니다.

intoDNS 웹페이지는 기본 페이지에 입력된 도메인과 DNSSEC가 아닌 문제에 관해 보고하고 문제 해결을 위한 추천 사항도 표시합니다.

도메인 관리자는 이러한 도구에서 보고하는 대부분의 오류를 해결해야 합니다. Google 공개 DNS뿐 아니라 다른 리졸버에도 문제가 발생할 수 있기 때문입니다.

3단계: 위임 문제 확인하기

Google 공개 DNS는 상위 도메인의 추천에 반환된 네임서버만 사용하는 '상위 항목 중심' 리졸버입니다. TLD의 네임서버 이름과 글루 주소가 오래되거나 부정확하면 위임 문제가 발생할 수 있습니다.

DNSViz 또는 intoDNS에서 TLD에서 위임된 네임서버와 하위 도메인 자체에 있는 네임서버 간의 불일치를 보고하는 경우 Google Public DNS에서 도메인을 확인하기 전에 이를 해결해야 할 수 있습니다. 이러한 도구에서 등록된 도메인 (NXDOMAIN)이 없다고 보고되면 어떤 이유로든 도메인이 만료되지 않았거나 등록 보류 상태가 아닌지 확인하세요.

위임 문제는 도메인의 네임서버 이름을 확인하는 데 실패하여 발생할 수도 있습니다. dns.google의 네임서버에서 A 및 AAAA 레코드를 확인하여 네임서버 도메인에 문제가 있는지 확인합니다.

4단계: 대용량 응답 확인

DNS는 UDP를 사용하여 트래픽의 대부분을 전달합니다. 큰 UDP 데이터그램은 조각화될 수 있으며 조각화된 UDP는 불안정한 전송을 겪습니다. 이는 전 세계의 DNS 안정성을 개선하기 위한 노력의 일환으로 2020년 DNS 플래그 데이에 중점을 두었습니다. Google 공개 DNS가 이러한 작업에 참여했으며 UDP를 통해 수락할 UDP 응답의 크기를 제한합니다. 자체 명령 프롬프트 또는 Google Cloud Shell을 사용하여 아래와 같은 쿼리를 사용해 보세요.

$ dig +short example.com NS
ns1.example.com
ns2.example.com
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com A
...
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com TXT
...
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com DNSKEY
...
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com com DNSKEY
...

다양한 레코드 유형에 대한 다음 쿼리는 다음을 지정합니다.

+dnssec

DNSSEC를 사용 설정합니다. 특히 DNSSEC 유효성 검사에 필요한 레코드를 사용할 수 있게 되면 반환합니다. 그러면 결과 크기가 크게 확장됩니다. 이렇게 하면 Google Public DNS의 동작이 에뮬레이션됩니다.

+bufsize=1400

허용된 UDP 버퍼 크기를 제한합니다. 이렇게 하면 2020년 DNS 플래그 데이를 기준으로 Google 공개 DNS의 동작을 에뮬레이션할 수 있습니다.

+timeout=1

제한 시간을 1초로 설정합니다. 이렇게 하면 Google Public DNS의 동작이 에뮬레이션됩니다.

@ns1.example.com

쿼리할 권한 서버 – @ 기호를 유지하되 첫 번째 명령어에서처럼 자체 도메인 권한 서버로 교체합니다.

출력을 살펴봅니다. 다음과 같은 줄이 표시됩니다.

;; Truncated, retrying in TCP mode.

응답이 요청된 UDP 버퍼 크기보다 커서 잘렸음을 나타내며 클라이언트가 TCP로 전환했습니다. 권한 서버는 TCP 포트 53에서 DNS 트래픽을 처리할 수 있어야 합니다. RFC 7766을 참조하여 '구현'은 UDP 및 TCP 전송을 모두 지원해야 합니다(MUST).

;; MSG SIZE rcvd: 2198

1,400을 초과하는 수치 이때도 응답이 많음을 나타냅니다.

;; Query time: 727 msec

500을 초과하는 번호는 무엇인가요? 느린 응답 (특히 1초 이상)은 Google Public DNS에서 삭제될 수 있습니다. 이는 UDP 시도 후 시간을 들여 TCP 시도가 발생한 경우일 가능성이 큽니다. 서버와 클라이언트의 지리적 위치는 지연 시간에 상당한 영향을 줄 수 있습니다.

;; connection timed out; no servers could be reached

특히 일부 쿼리의 경우에만 서버가 시의적절하게 DNS 쿼리에 응답할 수 없는 문제를 나타냅니다.

다음과 같은 쿼리 변형을 시도해 볼 수 있습니다.

+tcp 매개변수를 추가합니다.

이렇게 하면 dig에서 즉시 TCP를 사용할 수 있습니다. 권한 서버에서 이런 방식으로 TCP 쿼리를 직접 처리할 수 있는지 확인할 수 있습니다.

+bufsize=1400 매개변수를 삭제합니다.

이렇게 하면 dig의 기본 동작(4096 크기의 색)이 복원됩니다. 이 설정으로 쿼리가 실패하지만 설정 없이 작동하는 경우 서버가 TCP 장애 조치를 제대로 처리하지 못한다는 의미입니다. 대규모 응답을 전달하기 위해 UDP를 사용하는 경우도 종종 있습니다. 가장 좋은 방법은 DNS용 TCP 전송을 지원하는 것입니다.

각 네임서버에서 반복합니다.

위의 예시에는 2개의 권한 있는 네임서버 (ns1 및 ns2)가 있습니다. 일부 문제는 서로 다른 서버가 서로 다른 답을 반환하여 발생합니다. 모든 권한 서버에서 동일한 쿼리를 반복하여 모든 응답자가 일관적으로 답변하는지 확인합니다.

모든 쿼리의 응답이 작고 (1,400바이트 이하), 빠르고 (빠르게 500밀리초 이상), 안정성 (TCP 및 UDP를 통해 일관성 있게 작동)인 경우 응답 크기가 문제가 되지 않습니다. 다른 문제 해결 섹션을 읽어보세요. 응답이 빠르더라도 지리적으로 멀리 있는 쿼리는 더 느려질 수 있습니다.

이러한 검사 중 하나라도 실패 (대규모 또는 느림? 신뢰할 수 없음)하는 경우 기본 작업은 A) 응답에서 요청된 UDP 버퍼 크기와 B를 초과할 때 서버가 UDP 잘림으로 응답하도록 하는 것입니다. 그러면 이후 TCP 쿼리 재시도를 처리할 수 있게 됩니다. DNS 안정성 문제를 진단하는 데 도움이 되는 몇 가지 도구가 있습니다.

• DNSViz
• DNSSEC 디버거
• EDNS 규정 준수 테스터
• DNS Checker -- 'CD'를 선택 해제해야 합니다(DNSSEC 선택 사용 중지).

이러한 도구에서 오류 또는 경고가 표시되면 문제를 해결해야 합니다. 또한 이 사이트의 다른 문제 해결 안내를 모두 읽어 보시기 바랍니다.

5단계: 다른 공개 리졸버가 도메인을 확인하는지 확인

위 단계를 따른 후에도 문제의 원인을 찾지 못한 경우 명령어 프롬프트에서 다음 명령어를 실행하여 example.test.을 해당 도메인으로 바꾸고 후행 점은 유지합니다.

Windows

nslookup example.test. resolver1.opendns.com.
nslookup example.test. dns.quad9.net.
nslookup example.test. one.one.one.one.

macOS 또는 Linux

dig example.test. '@resolver1.opendns.com.'
dig example.test. '@dns.quad9.net.'
dig example.test. '@one.one.one.one.'

이 명령어는 OpenDNS, Quad9, Cloudflare 1.1.1.1의 DNS 리졸버를 사용합니다. Google Public DNS와 더불어 이 두 가지에서 해결 실패가 발생하는 경우 도메인 또는 네임서버에 문제가 있을 수 있습니다.

둘 이상의 다른 공개 리졸버에서 성공적인 결과를 얻으면 Google 공개 DNS에 문제가 있을 수 있습니다. 도메인 (또는 TLD)에서 Issue Tracker에 유사한 문제가 신고되지 않은 경우 보고서에 명령어 출력 및 진단 페이지 텍스트나 스크린샷을 포함하여 문제를 신고해야 합니다.