본문 바로가기
공부/AWS

[AWS] 오류 : DNS_PROVE_FINISHED_NXDOMAIN

by 로디네로 2022. 6. 24.
반응형



오류내용 : DNS_PROVE_FINISHED_NXDOMAIN


위 에러는 많은 상황에서 발생할 수 있지만 내가 처한 상황은 아래와 같았다.


AWS에서 도메인구입
S3 정적 호스팅
ACM 발급
CloudFront 사용해 https 적용
Route53에 CloudFront호스팅

--- 여기까지 정상동작 했었음 ---

정적웹호스팅 S3 파일 전체삭제 후 재업로드
Route53의 호스팅영역 삭제 후 재생성


정확히 어떤작업후에서 부턴지 모르겠지만 오류가 뜨며 사이트 접속이 되지 않았다.

 

 

 

 




우선 dig 명령어를 통해 서버에서 내 도메인이 어디까지 연결되어있는지 확인해보았다


윈도우 환경에 dig를 설치하기는 싫으니 dig web interface라는 사이트에 접속해 분석해보았다.

 


사이트에 접속후 Hostnames or IP addresses 에 분석할 hostname 또는 ip를 적어준다.

 

분석 :

 

사진 1번 아래의 DNS server 8.8.4.4 에게 "." 을 찾으려면 어디로 가야되냐 고 물었고
8.8.4.4는 위 사진의 1번 바로 왼쪽에 있는 address 들을 찾아가라고 답해준다.


2번 아래의 192.58.128.30은 위의 address 들 중 하나의 ip 이다.
192.58.128.30 에게 우리의 url에 대해 물어봤더니 2번 바로 왼쪽에 있는 address 들 중 하나에게 물어보라고 한다.


3번 아래의 64.96.xx.xx 는 위의 adress 들 중 하나의 ip 이다.
64.96.xx.xx 에게 이제는 우리의 주소 전체를 물어보니 3번 바로 왼쪽에 있는 adress 들 중 하나에 물어보라고 한다.


마지막으로 3번 왼쪽 adress 들에게 물어보는데 대답이 없다.
DNS 주소가 맞지않는 듯 하다.

(그래서 오류이름이 DNS_PROVE_FINISHED_NXDOMAIN)

 

 

 


 

 

시도 1

Try :

 

CDN (AWS cloudfront)을 사용해 https 보안적용을 하면 ACM에 의해 CNAME이 붙기 마련이다

 

하지만 호스팅영역을 삭제 후 재생성 하니 당연하게도 레코드에 CNAME유형이 없는걸 발견했다

 


아래포스팅의 2.3 Route53에서 레코드생성 을 통해 CNAME을 Route53에 등록해보려했다

 

 

[AWS] Lambda 프로젝트-6 / S3 정적웹호스팅에 https 적용

이전장에서는 AWS S3 bucket을 이용한 정적 웹호스팅까지 진행해보았다. [AWS] Lambda 구축하기-5 / S3 이용한 정적웹호스팅 이전장에서는 AWS S3에 파일을 업로드 하는 동작을 React로 연동해보았다. [AWS] L

dbstndi6316.tistory.com

 

등록되지 않았고 Route53 내의 CNAME 이름과 CNAME 값을 ACM (Amazon Certificate Manager)에의 값으로 맞춰서 수동으로 생성해주었다.

 

> 그러나 접속 실패

 

 


 

 

시도2

 

Try :

그렇다면 CloudFront 의 배포중지 및 인증서를 재발급 받아 보도록 하자


Cloudfront 배포 중지 및 삭제


인증서 삭제


인증서(ACM)를 다시 발급받아준다.
자동으로 레코드 생성이 된다

 


하지만 최대 30분 정도 걸린다고 했던 검증시간이 하루가 지나도 끝나지않았다고 한다..

 

> 결국 실패

 

 


 

 

시도 3

 

Try :

 

여기부터는 단순 CDN service에서의 문제가 아니라고 생각해서 CDN을 뗀 후 Route53에 S3정적웹호스팅을 붙이는 기본 작업부터 완수해보고자 했다



Route53의 네임스페이스(유형:NS)가 도메인의 NS와 다른걸 확인



도메인>등록된도메인>이름서버>이름서버 추가 또는 편집을 눌러 도메인의 NS를 호스팅영역과 같이 변경해줬다

 

> 그럴듯 했지만 실패

 

 


 

시도 4


Try :

지금 물고있는 SOA 주소가 네임서버를 제대로 물고있을까? 생각해 호스팅영역의 SOA를 확인했다


SOA 주소가 NS에 있지만 실제론 다른 ip가 접근하고 있지는 않을까..?

의미없었을 수 있는 작업이다.

dig 에서 분석결과 맨 아래 ip가 정말 우리의 SOA인지 확인하는 과정이 필요했다.


아래와같이 dnschecker.org 에서 확인결과
현재 등록된 SOA주소와 dig 분석에서 맨 아래쪽 실제 ip 의 root 주소는 달랐다.

 

NS중 ip가 dnschecker의 결과와 일치하는 NS를 SOA로 변경해주었다.

 

> 이번에도 그럴듯했지만 실패

 

 


 


시도 5


Try :


그렇게 계속 방법을찾아 떠돌며 지칠때쯤 S3 버킷정책에 Cloudfront 내용이 적혀져있는걸 발견했다.

 

- 아래 사진은 다 삭제한 후의 캡쳐이다

 

지금은 S3 정적웹호스팅만 사용해서 이 정책은 사용하지 않는데 지워볼까?


지우고 정적웹호스팅만 위한 정책부터 생성해보자!!

 

> 끝없는 실패

 

 


 

 

시도 6

 

호스팅영역을 삭제하고 다시 해보자 그 중 네임서버 (=이름서버=NS) 의 변화에 집중해보자


호스팅영역을 삭제후 재생성해주니 역시 NS가 바뀐걸 볼수있었다


도메인의 NS는 바뀌지 않았다


그렇다면 도메인의 NS를 호스팅영역에 있는 NS로 내가 생각하던거와 반대로 설정해줘야되는게 아닌가??
생각했고 변경해주었다


 

Route53>도메인 >이름서버 추가 또는 편집
호스팅영역의 NS를 여기에 적어준다


이후 업데이트



dig로 확인해보자

 

드디어 동작한다.


사실 이 해결방법은 도메인을 외부에서 구매했다면 당연히 해야되는 과정이였기에 나만 몰랐던것 일 수 있다.


하지만 비슷한 삽질을 하고계시는 분들이 있을것같아 포스팅으로 공유한다


> 성공

-끝-




 


References :
https://www.youtube.com/watch?v=h1xG-eNUQdg&list=PLuHgQVnccGMCas8a4f0uIg5X4uERoG6gb&index=8 
https://aws.amazon.com/ko/premiumsupport/knowledge-center/route-53-propagate-dns-changes/

https://aws.amazon.com/ko/premiumsupport/knowledge-center/partial-dns-failures/

 

반응형

댓글