도메인으로 접속이 안 될 때 DNS를 고치기 전에 어느 단계에서 실패하는지 나눠야 합니다. DNS가 올바른 주소를 돌려줘도 HTTPS 인증서, NAS 역방향 프록시, Django 설정에서 실패할 수 있습니다. win-j처럼 도메인과 NAS의 웹 서비스를 연결하는 구성에서 사용할 읽기 전용 점검 순서를 정리합니다.

이름 조회 이후에도 단계가 남는다

도메인 이름 조회
  → 반환된 주소로 연결
  → HTTPS라면 TLS 인증서 확인
  → 프록시가 요청 호스트·경로로 서비스 선택
  → 애플리케이션이 응답

DNS는 호스트 이름의 레코드를 찾는 단계입니다. /utility/text-counter/ 같은 URL 경로로 어떤 Django 화면을 보여줄지는 DNS가 결정하지 않습니다. 도메인이 여러 주소를 반환하거나 CDN·프록시 주소를 가리킬 수도 있어 DNS에서 나온 주소가 반드시 원본 NAS 주소인 것도 아닙니다.

어떤 레코드를 보는가

레코드 용도 웹 접속 점검에서의 의미
A IPv4 주소 IPv4 연결 대상 확인
AAAA IPv6 주소 IPv6 연결 대상 확인
CNAME 다른 이름의 별칭 별칭 대상의 후속 조회 필요
NS 권한 서버 정보 도메인의 위임·관리 위치 확인
MX / TXT 메일 경로·텍스트 정보 웹 A 레코드와 별개인 설정

IPv6 레코드 이름은 AAAA입니다. A만 새 서버로 바꾸고 오래된 AAAA가 남으면 클라이언트의 네트워크 조건에 따라 서로 다른 결과를 볼 수 있습니다. 실제로 그런 장애가 발생했다고 단정하기 전에 두 응답을 비교합니다.

DNS 해석기는 캐시를 사용할 수 있고, 필요한 경우 권한 서버까지 조회해 답을 구합니다. 매번 루트부터 모든 서버를 차례로 묻는 것은 아닙니다. 브라우저의 보안 DNS 설정은 운영체제의 조회와 다른 해석기를 사용할 수도 있습니다. DNS 개념과 캐시 구조, 브라우저 DNS over HTTPS

Windows에서 A와 AAAA를 따로 확인

다음 명령은 DNS 조회만 수행하며 레코드를 변경하지 않습니다. 현재 IP를 글에 고정해서 적지 않았으므로 실행 시점의 결과를 직접 기록합니다.

nslookup -type=A win-j.com
nslookup -type=AAAA win-j.com

출력의 Server·Address 앞부분은 질문을 받은 DNS 서버를 가리킬 수 있습니다. 답변 영역의 이름·주소와 혼동하지 않습니다. 기본 조회가 실패하면 네트워크에서 허용된 다른 해석기를 명시해 비교할 수 있습니다. 다만 사내·VPN 내부 이름은 외부 DNS에서 조회되지 않는 것이 정상일 수 있습니다. Microsoft nslookup 문서

AAAA에 답이 없다는 것만으로 웹사이트 장애라고 판단하지 않습니다. IPv4만 제공하는 사이트는 A 응답으로 동작할 수 있습니다. 반대로 주소가 하나 이상 나온다고 HTTPS 서비스까지 정상이라고 판단하지도 않습니다.

DNS 다음에 HTTP를 확인

Windows PowerShell에서는 아래처럼 curl.exe를 명시해 공개 페이지의 응답 헤더를 확인할 수 있습니다. GET 본문은 파일로 저장하지 않고 버립니다.

curl.exe --connect-timeout 5 --max-time 15 -sS -D - -o NUL https://win-j.com/

이 명령은 리디렉션을 자동으로 따라가지 않습니다. 301·302가 나오면 Location의 대상도 점검합니다. HTTP 상태가 나오기 전 인증서 오류가 발생하면 DNS 응답, 접속 호스트, 인증서 이름·기간·체인을 확인합니다. IP 주소로 직접 접속하면 Host·TLS 이름이 달라져 다른 결과가 나올 수 있으므로 도메인 접속과 동등한 시험으로 취급하지 않습니다. curl 옵션

관찰 다음에 볼 곳
이름을 찾지 못함·NXDOMAIN 오타, 레코드·위임, 사용한 DNS 서버
조회 시간 초과·SERVFAIL 해석기 연결, 권한 서버·DNSSEC 등
주소는 나오지만 연결 시간 초과 라우팅·방화벽·포트·서비스 상태
TLS 인증서 오류 인증서와 호스트, 시간, 프록시 설정
HTTP 400·404·502 등 Host 허용, URL, 프록시 대상, 애플리케이션

TTL은 모든 사용자에게 적용되는 타이머가 아니다

TTL은 레코드를 캐시에 보관하는 시간과 관련됩니다. 변경 전에 받은 옛 레코드는 당시 TTL의 영향을 받으므로 새 레코드의 TTL을 줄였다고 기존 캐시가 즉시 모두 바뀌지는 않습니다. 음성 응답 캐시나 DNS 서비스의 갱신 과정도 영향을 줄 수 있습니다. DNS 음성 응답 캐시

자신의 PC 캐시를 지우는 것은 다른 사용자의 브라우저·해석기 캐시를 지우지 않습니다. ping도 ICMP 응답 여부를 보는 것이므로 응답이 없다는 이유만으로 HTTPS 장애라고 결론내리지 않습니다. 문제를 기록할 때 조회 시각·해석기·A/AAAA 답변·HTTPS 결과를 함께 남기면 변경 전후를 비교하기 쉽습니다.

이 절차는 특정 과거 장애의 원인을 확정한 기록이 아닙니다. 도메인·프록시·애플리케이션을 분리해 원인을 찾는 점검 방법이며, HTTP 단계에 도달했다면 상태코드 해석을 이어서 사용합니다.