Route 53를 DNS 서비스로 사용할 때 NXDOMAIN 응답 문제를 해결하려면 어떻게 해야 합니까?

해결 방법

도메인 등록 대행자에 올바른 이름 서버가 구성되었는지 확인

1.    도메인에 대해 whois 쿼리를 실행합니다.    
Windows의 경우: Windows 명령 프롬프트를 연 다음 whois -v example.com을 입력합니다.
Linux의 경우: SSH 클라이언트를 엽니다. 명령 프롬프트에서 whois example.com을 입력합니다.
참고: 도메인이 Amazon Registrar에 등록된 경우 Amazon Registrar whois 조회 도구를 사용할 수 있습니다.

2.    도메인이 일시 중단되지 않았는지 확인합니다. 자세한 내용과 이 시나리오를 해결하는 방법은 도메인이 일시 중단된 경우(상태는 ClientHold)를 참조하세요.

3.    whois 출력에서 도메인에 대한 권한이 있는 이름 서버를 확인합니다.

        whois 출력 예:

whois example.com
   Domain Name: EXAMPLE.COM
   Registry Domain ID: 87023946_DOMAIN_COM-VRSN
   Registrar WHOIS Server: whois.godaddy.com
   Registrar URL: http://www.godaddy.com
   Updated Date: 2020-05-08T10:05:49Z
   Creation Date: 2002-05-28T18:22:16Z
   Registry Expiry Date: 2021-05-28T18:22:16Z
   Registrar: GoDaddy.com, LLC
   Registrar IANA ID: 146
   Registrar Abuse Contact Email: abuse@godaddy.com
   Registrar Abuse Contact Phone: 480-624-2505
   Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
   Domain Status: clientRenewProhibited https://icann.org/epp#clientRenewProhibited
   Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
   Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited
   Name Server: ns-1470.awsdns-55.org.
   Name Server: ns-1969.awsdns-54.co.uk.
   Name Server: ns-736.awsdns-28.net.
   Name Server: ns-316.awsdns-39.com.

Linux 시스템에서 구성된 이름 서버를 확인하는 또 다른 방법은 dig 유틸리티를 사용하는 것입니다.

dig +trace 출력 예:

dig +trace example.com

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.2 <<>> +trace example.com
;; global options: +cmd
.                       518400  IN      NS      H.ROOT-SERVERS.NET.
.                       518400  IN      NS      I.ROOT-SERVERS.NET.
.                       518400  IN      NS      J.ROOT-SERVERS.NET.
.                       518400  IN      NS      K.ROOT-SERVERS.NET.
;; Received 239 bytes from 10.0.0.2#53(10.0.0.2) in 0 ms

com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
C41A5766
com.                    86400   IN      RRSIG   DS 8 1 86400 20210329220000 20210316210000 42351 . 
;; Received 1174 bytes from 192.112.36.4#53(G.ROOT-SERVERS.NET) in 104 ms

example.com.         172800  IN      NS      ns-1470.awsdns-55.org.   ------>Name servers of interest.
example.com.         172800  IN      NS      ns-1969.awsdns-54.co.uk.
example.com.         172800  IN      NS      ns-736.awsdns-28.net.
example.com.         172800  IN      NS      ns-316.awsdns-39.com.

;; Received 732 bytes from 192.33.14.30#53(b.gtld-servers.net) in 91 ms

example.com.         3600    IN      A       104.200.22.130
example.com.         3600    IN      A       104.200.23.95
example.com.         3600    IN      NS      ns-1470.awsdns-55.org.
example.com.         3600    IN      NS      ns-1969.awsdns-54.co.uk.
example.com.         3600    IN      NS      ns-736.awsdns-28.net.
example.com.         3600    IN      NS      ns-316.awsdns-39.com.

;; Received 127 bytes from 173.201.72.25#53(ns-1470.awsdns-55.org) in 90 ms

4.    Route 53 콘솔을 엽니다.

5.    탐색 창에서 [호스팅 영역(Hosted zones)]을 선택합니다.

6.    [호스팅 영역(Hosted zones)] 페이지에서 호스팅 영역의 라디오 버튼(이름 아님)을 선택합니다. 그런 다음 [세부 정보 보기(View details)]를 선택합니다.

7.    호스팅 영역의 세부 정보 페이지에서 [호스팅 영역 세부 정보(Hosted zone details)]를 선택합니다.

8.    호스팅 영역 세부 정보에 나열된 이름 서버가 whois 또는 dig +trace 출력에 나열된 이름 서버와 동일한지 확인합니다.

중요: 이름 서버가 동일하지 않은 경우 도메인 등록 대행자에서 업데이트해야 합니다. 도메인이 Route 53에 등록된 경우 도메인의 이름 서버 및 glue 레코드 추가 또는 변경을 참조하세요. 도메인이 서드 파티에 등록된 경우 해당하는 설명서에서 이름 서버 업데이트 방법에 대한 단계를 참조하세요.

요청된 레코드가 있는지 확인합니다.

도메인의 호스팅 영역에 요청된 레코드가 포함되어 있는지 확인합니다. 예를 들어 www.example.com을 확인하려고 할 때 NXDOMAIN 응답이 수신되면 www.example.com 레코드의 example**.com** 호스팅 영역을 확인합니다. Route 53의 레코드를 나열하는 방법에 대한 단계는 레코드 나열을 참조하세요.

하위 도메인 위임 문제 확인

1.    확인하려는 도메인 이름의 이름 서버(NS) 레코드에 대한 상위 호스팅 영역을 확인합니다. 하위 도메인에 대한 NS 레코드가 있는 경우 도메인 및 해당 하위 도메인에 대한 권한이 다른 영역으로 위임된 것입니다. 예를 들어 www.example.com의 NS 레코드가 있는 경우 www.example.com의 권한이 NS 레코드의 이름 서버로 위임된 것입니다. 위임이 유효한 경우 example.com의 상위 영역이 아닌 위임된 영역에 도메인의 레코드를 생성해야 합니다.

2.    위임이 유효하지 않으면 도메인에 대한 NS 레코드를 삭제합니다. 상위 호스팅 영역(example.com)에 확인하려는 도메인 이름에 대한 레코드가 포함되어 있는지 확인합니다.

DNS 확인 문제가 VPC에서만 발생하는지 확인

1.    클라이언트 운영 체제(OS)에 구성된 확인자 IP 주소를 확인합니다. Linux의 경우 /etc/resolv.conf 파일을 확인합니다. Windows의 경우 ipconfig/all 출력에서 DNS 서버를 확인합니다. 기본 VPC DNS 확인자(VPC CIDR+2)를 찾습니다. 예를 들어 VPC CIDR이 10.0.0.0/8인 경우 DNS 확인자 IP 주소는 10.0.0.2여야 합니다. /etc/resolv.conf에 VPC DNS 확인자가 없으면 사용자 지정 DNS 확인자를 확인합니다.

2.    VPC DNS 확인자를 사용하는 경우 프라이빗 호스팅 영역과 Route 53 확인자 규칙을 확인합니다.

확인자 규칙 및 프라이빗 호스팅 영역을 사용하는 경우:

확인자 규칙과 프라이빗 호스팅 영역이 겹치는 경우 확인자 규칙이 우선합니다. 자세한 내용은 프라이빗 호스팅 영역 작업 시 고려 사항을 참조하세요. 이 경우 DNS 쿼리는 확인자 규칙에서 대상으로 구성된 대상 IP 주소로 전송됩니다.

프라이빗 호스팅 영역을 사용하고 확인자 규칙을 사용하지 않는 경우:

VPC에 연결된 도메인 이름과 일치하는 프라이빗 호스팅 영역이 있는지 확인합니다. 예를 들어 VPC에 연결된 도메인에 대해 프라이빗 호스팅 영역과 퍼블릭 호스팅 영역이 둘 다 있을 수 있습니다. VPC의 클라이언트는 퍼블릭 호스팅 영역에 생성된 레코드를 확인할 수 없습니다. 프라이빗 호스팅 영역에 레코드가 없는 경우 VPC DNS는 퍼블릭 호스팅 영역에서 대체되지 않습니다.

확인자 규칙만 사용하고 프라이빗 호스팅 영역을 사용하지 않는 경우:

Route 53 확인자 규칙을 확인합니다. 도메인 이름과 일치하는 규칙이 있는 경우 도메인에 대한 쿼리는 기본 퍼블릭 확인자 대신 구성된 대상 IP 주소로 라우팅됩니다.

문제가 부정 캐싱의 결과인지 확인

부정 캐싱은 권한 이름 서버의 부정 응답을 캐시에 저장하는 프로세스입니다. NXDOMAIN 응답은 부정 응답으로 간주됩니다. 다음 예시를 고려하세요.

클라이언트에서 neg.example.com에 대한 DNS 쿼리를 제출하고 NXDOMAIN 응답 코드를 수신합니다. 이 응답이 수신되는 이유는 neg.example.com 레코드가 없기 때문입니다.

이 사용자는 example.com도 소유하고 있으므로 neg.example.com에 대한 새 레코드를 생성합니다. 다른 네트워크의 사용자는 레코드를 성공적으로 확인할 수 있지만 이 사용자는 계속해서 NXDOMAIN 응답을 수신합니다.

이 사용자가 새 레코드를 생성하기 전에 neg.example.com에 대한 쿼리를 제출했을 때 다른 사용자들은 NXDOMAIN 응답을 수신했습니다. 확인자 설정에 부정 캐싱이 설정되어 있으면 확인자가 이 응답을 캐싱합니다. 다른 사용자들은 사용자가 새 레코드를 생성한 후 쿼리를 다시 제출했습니다. 확인자는 이전에 이 쿼리를 수신하여 캐싱했으므로 캐시의 응답을 반환했습니다.

부정 응답의 답변에는 반환된 레코드가 없으므로 긍정 응답과 비교할 Time to Live(TTL) 값이 없습니다. 이 경우 확인자는 권한 시작(SOA) 레코드의 최소 TTL 값 또는 SOA 레코드의 TTL 값 중에서 낮은 값을 사용하여 NXDOMAIN 응답을 캐싱합니다.

이 문제를 확인하려면 이름 서버로 쿼리를 직접 보내 응답이 수신되는지 확인합니다. 예를 들어 다음과 같습니다.

dig www.example.com @ns-1470.awsdns-55.org

---