Route 53에 호스팅되는 내 애플리케이션 또는 웹 사이트에 액세스할 수 없는 이유는 무엇입니까?
최종 업데이트 날짜: 2021년 4월 20일
Amazon Route 53에서 애플리케이션 또는 웹 사이트를 실행하고 있습니다. 그러나 애플리케이션이나 웹 사이트에 액세스할 수 없습니다. 이 문제를 해결하려면 어떻게 해야 합니까?
해결 방법
참고: AWS CLI(AWS 명령줄 인터페이스) 명령을 실행할 때 오류가 발생할 경우 AWS CLI의 최신 버전을 사용하고 있는지 확인하세요.
도메인 상태 문제 확인
1. 다음 명령을 사용하여 도메인 상태를 확인합니다.
whois domain_name |grep 'status'
“inactive” 또는 “ServerHold” 또는 “ClientOld”를 비롯한 비정상적인 도메인 상태 코드가 표시되는 경우 등록기관에 문의하세요.
2. “inactive” 또는 “ServerHold” 또는 “ClientOld”를 비롯한 비정상적인 도메인 상태 코드가 표시되는 경우 등록기관에 문의하세요.
다음 명령을 사용하여 도메인 등록기관을 결정합니다.
whois domain_name |grep 'Registrar'
기본 Whois 유틸리티(도메인 등록 조회 도구)에 일반 또는 국가 지정 최상위 도메인(TLD)을 쿼리합니다.
네임 서버 문제 확인
1. 도메인 등록기관에 신뢰할 수 있는 네임 서버가 올바르게 구성되었는지 확인합니다. 신뢰할 수 있는 네임 서버를 찾으려면 퍼블릭 호스팅 영역의 NS(네임 서버) 리소스 레코드 세트에서 authoritative_nameserver 값을 확인합니다.
2. Route 53을 DNS 서비스 공급자로 사용하는 경우 네 개의 네임 서버 각각을 올바르게 구성했는지 확인합니다.
다음 명령을 사용하여 네임 서버 구성을 확인합니다.
whois domain_name |grep 'Name Server'
예를 들어, whois amazon.com |grep 'Name Server'의 출력은 다음과 같습니다.
Name Server: NS1.P31.DYNECT.NET
Name Server: NS2.P31.DYNECT.NET
Name Server: NS3.P31.DYNECT.NET
Name Server: NS4.P31.DYNECT.NET
Name Server: PDNS1.ULTRADNS.NET
Name Server: PDNS6.ULTRADNS.CO.UK
레코드 세트 문제 확인
dig Domain_name record_type
예를 들어, $dig amazon.com A의 출력은 다음과 같습니다.
; <<>> DiG 9.10.6 <<>> amazon.com +question
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29804
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;amazon.com. IN A
;; ANSWER SECTION:
amazon.com. 44 IN A 54.239.28.85
amazon.com. 44 IN A 205.251.242.103
amazon.com. 44 IN A 176.32.103.205
;; Query time: 4 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Mar 19 20:28:51 IST 2021
;; MSG SIZE rcvd: 87
참고: 레코드 유형은 해당 리소스 레코드 세트의 유형 열에 나열됩니다. 자세한 내용은 지원되는 DNS 레코드 유형을 참조하세요.
소스 문제 확인
로컬 브라우저 또는 모바일 장치의 경우:
- 브라우저 캐시를 지운 다음 도메인에 액세스하세요.
- 올바른 도메인을 요청하고 있는지 확인합니다. 도메인을 요청할 때 모바일 디바이스 브라우저에 ‘www’가 추가될 수 있습니다.
VPC 2 Resolver를 사용하여 Amazon Virtual Private Cloud(Amazon VPC) 또는 AWS 리소스에 연결된 온프레미스 머신의 경우:
‘example.com’ 및 ‘accounting.example.com’과 같이 겹치는 네임스페이스가 있는 프라이빗 및 퍼블릭 호스팅 영역이 있는 경우 Resolver는 가장 구체적인 일치 항목을 기반으로 트래픽을 라우팅합니다. 일치하는 프라이빗 호스팅 영역이 있지만 요청의 도메인 이름 및 유형과 일치하는 레코드가 없는 경우 확인 서버는 요청을 퍼블릭 DNS 확인 서버로 전달하지 않습니다. 대신 NXDOMAIN(존재하지 않는 도메인) 오류를 클라이언트에 반환합니다. 실수로 네임스페이스가 겹치는 프라이빗 호스팅 영역을 생성한 경우 프라이빗 호스팅 영역을 삭제할 수 있습니다.
레코드 캐싱 문제 확인
1. 다음 명령을 사용하여 DNS 확인 서버에서 반환된 레코드 값이 신뢰할 수 있는 네임 서버에서 반환된 값과 일치하는지 확인합니다. 도메인이 예상 IP 주소로 확인되지 않는 경우 DNS 확인 서버가 값을 캐시했을 수 있습니다. 도메인이 예기치 않은 IP 주소로 확인되는 경우 브라우저 캐시를 지웁니다.
dig domain_name record_type @authorative_name_server
예를 들어, $dig amazon.com @NS1.P31.DYNECT.NET의 출력은 다음과 같습니다.
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.68.rc1.64.amzn1 <<>> amazon.com @NS1.P31.DYNECT.NET
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63711
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;amazon.com. IN A
;; ANSWER SECTION:
amazon.com. 60 IN A 205.251.242.103
amazon.com. 60 IN A 54.239.28.85
amazon.com. 60 IN A 176.32.103.205
;; Query time: 2 msec
;; SERVER: 208.78.70.31#53(208.78.70.31)
;; WHEN: Fri Mar 19 15:08:52 2021
;; MSG SIZE rcvd: 76
2. 다음 명령을 사용하여 퍼블릭 확인 서버와 동일한 결과가 표시되는지 확인합니다. 퍼블릭 확인 서버가 예상된 대답을 반환하는 경우 로컬 컴퓨터의 DNS 확인 서버에 문제가 있을 수 있습니다.
dig domain @public_resolver_Ip
예를 들어, $dig amazon.com @8.8.8.8의 출력은 다음과 같습니다
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.68.rc1.64.amzn1 <<>> amazon.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26860
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;amazon.com. IN A
;; ANSWER SECTION:
amazon.com. 15 IN A 205.251.242.103
amazon.com. 15 IN A 54.239.28.85
amazon.com. 15 IN A 176.32.103.205
;; Query time: 1 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Mar 19 15:09:41 2021
;; MSG SIZE rcvd: 76
DNSSEC 문제 확인
도메인에 대해 DNSSEC를 올바르게 구성했는지 확인합니다. DNSSEC 분석기 도구 또는 선호하는 유틸리티를 사용하여 도메인에 DNSSEC 문제가 있는지 확인합니다.
DNSSEC를 전달하고 예상된 결과가 나오는지 확인하세요.
dig domain_name +cd
예를 들어, $ dig amazon.com +cd의 출력은 다음과 같습니다
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.68.rc1.64.amzn1 <<>> amazon.com +cd
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55636
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;amazon.com. IN A
;; ANSWER SECTION:
amazon.com. 29 IN A 205.251.242.103
amazon.com. 29 IN A 176.32.103.205
amazon.com. 29 IN A 54.239.28.85
;; Query time: 2 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Fri Mar 19 15:10:13 2021
;; MSG SIZE rcvd: 76
웹 서버 문제 확인
curl 명령 출력에서 도메인의 예상 IP 주소가 표시되면 서버로부터 예상 HTTP 응답을 받고 있는지 확인하세요.
- 1XX (정보)
- 2XX (성공)
- 3XX (리디렉션)
- 4XX (클라이언트 오류)
- 5XX (서버 오류)
DNS 확인이 예상대로 작동하지만 서버가 응답하지 않는 경우 웹 사이트 또는 애플리케이션이 호스팅되는 웹 서버에 문제가 있는 것입니다.
명령:
curl -Iv http://domain_name:Port/Path
예를 들어, $ curl -Iv http://amazon.com:80의 출력은 다음과 같습니다.
* Rebuilt URL to: http://amazon.com:80/
* Trying 176.32.103.205... <--- Indicates no issues with the DNS resolution as we are getting expected IP address for the domain amazon.com.
* TCP_NODELAY set
* Connected to amazon.com (176.32.103.205) port 80 (#0)
> HEAD / HTTP/1.1
> Host: amazon.com
> User-Agent: curl/7.61.1
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
HTTP/1.1 301 Moved Permanently
< Server: Server
Server: Server
< Date: Fri, 19 Mar 2021 15:11:18 GMT
Date: Fri, 19 Mar 2021 15:11:18 GMT
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 179
Content-Length: 179
< Connection: keep-alive
Connection: keep-alive
< Location: https://amazon.com/
Location: https://amazon.com/
<
* Connection #0 to host amazon.com left intact
참고: Port 값은 웹 사이트 또는 애플리케이션이 수신 대기하도록 구성된 웹 서버 포트입니다.