문제
서브 도메인 컬럼을 잘 등록했는데도, 아무리 nslookup api.fitpass.co.kr
해도 매핑된 IP가 뜨지 않았다.
또, Cerbot에서 sudo certbot --nginx -d api.fitpass.co.kr 해도 certbot.errors.AuthorizationError: Some challenges have failed. 라며 DNS가 연결이 되지 않았다는 오류만 뱉었다.
이해가 되지 않아서 보안그룹을 확인해봤지만 443과 80 모두 잘 열려있었다..
지피티한테 열심히 물어보니까 현재 ec2 우분투 서버가 DNS 해석을 제대로 하지 못하고 있다는 것이다.
이게 뭔 뜻이지 해서 cat /etc/resolv.conf 명령어로 DNS 해석을 확인해보니, nameserver 127.0.0.53 를 뱉었다. 이 경우는, systemd-resolved가 로컬에서만 DNS를 처리하고 있다는 것이었다.
sudo nano /etc/resolv.conf 명령어로 DNS 서버를 직접 google DNS 인(외부 DNS)
nameserver 8.8.8.8
nameserver 8.8.4.4로 수정했더니 해결되었다..
원인
SSL 인증서를 발급받을 때, 인증 기관인 CA는 도메인이 실제로 존재하고, 해당 서버에서 도메인에 대한 소유권을 확인하는 작업을 한다. 이때 DNS 리졸버, 즉 도메인의 IP주소를 찾는 서비스가 제대로 작동하지 않으면 인증기관에서 도메인을 확인할 수 없다.
도메인 이름이 올바르게 DNS에 등록되어있고, DNS 서버가 이를 발견해야하는데 서버의 DNS설정이 잘못되어있어서 SSL인증서 발급이 되지 않았다는 것이다.
리눅스 서버에서 /etc/resolv.conf 는 DNS 서버를 설정하는 곳이다. 리눅스의 systemd-resolved 는 로컬 DNS 리졸버 서버로서, 이 리졸버가 DNS 요청을 처리한다. 이 리졸버가 동작을 잘 하지 않았나보다..
따라서 외부 리졸버인 Google DNS(8.8.8.8) 으로 수정을 해줬더니 해결되었다...
그럼 리눅스의 DNS 리졸버의 문제인가?
그건 아닌 것 같다. 이번 경우가 처음이었다... 그냥 로컬 리졸버가 느려서 외부로 변경했더니 바로 반영된 느낌이었다. 원래 우리 서버가 Route 53으로 등록되어 있었는데, 이것을 삭제하고 바로 하다보니 네임 서버 변경이 좀 걸렸던 것 같다. 따라서 급하거나 하면 DNS 서버를 변경해서 연결을 빨리 하는것도 방법 중에 하나일 것 같다.
'BACKEND' 카테고리의 다른 글
| 쿠버네티스에 대해서 (0) | 2025.02.06 |
|---|---|
| nginx 의 SSL 인증서를 옮겨오는 법..? (0) | 2025.01.29 |
| 제목: 엔지닉스에 OPTION 처리 달지말자 (0) | 2024.12.02 |
