도메인 연결 안될 때 DNS 체크 순서 8단계 (2025)

빠른 결정 트리: 5분 안에 의심 구간 좁히기

호스팅 이전 직후나 네임서버 변경 직후 사이트가 갑자기 안 열리면 가장 먼저 의심 구간을 좁혀야 합니다. 도메인 연결 안될 때 DNS 체크 순서는 위에서 아래로 흐르는 계층 구조이므로, 상위 단계가 막혀 있으면 하위 단계 점검은 모두 의미가 없습니다. 아래 결정 트리를 보면서 어느 레이어부터 들어갈지 5분 안에 판단할 수 있습니다.

DNS 응답 코드별 분기 진단 (NXDOMAIN·SERVFAIL·REFUSED)

dig 또는 nslookup 실행 결과의 첫 줄에 나타나는 status: 필드만으로 의심 구간을 70퍼센트 좁힐 수 있습니다. 응답 코드는 RCODE라고 부르며, 가장 자주 마주치는 4종은 NXDOMAIN, SERVFAIL, REFUSED, NOERROR입니다. 도메인 연결 안될 때 DNS 체크 순서의 첫 분기점이 바로 이 코드 구분이므로, 본격적인 단계별 진단에 앞서 의미를 정확히 익혀야 합니다.

응답 코드 해석에 대한 공식 권위 자료가 필요하다면 Google Public DNS — 도메인 DNS 트러블슈팅 가이드를 함께 참고하시기 바랍니다. SERVFAIL의 DNSSEC 검증 실패, REFUSED의 NS 미설정, NXDOMAIN의 만료·미등록 케이스가 모두 정리되어 있습니다.

Extended DNS Errors(EDE) 코드로 한 단계 더 좁히기

최근 리졸버는 SERVFAIL을 반환할 때 EDE라는 보조 코드를 함께 제공해 세부 원인을 알려 줍니다. 예를 들어 EDE 6은 DNSSEC Bogus(서명 검증 실패), EDE 18은 Prohibited(정책상 차단), EDE 22는 No Reachable Authority(권한 NS 도달 불가)를 의미합니다. dig 9.18 이상 버전에서는 응답의 OPT PSEUDOSECTION 부분에 EDE 코드와 사람이 읽을 수 있는 텍스트가 함께 출력되므로, SERVFAIL이 떴을 때 EDE 한 줄만 봐도 다음 단계를 곧장 결정할 수 있습니다.

1단계: 레지스트라 네임서버 위임 점검

DNS 진단의 출발점은 레지스트라(상위 TLD)에 등록된 권한 NS 위임 정보입니다. 이 단계가 틀어지면 하위 단계는 모두 의미가 없으므로 가장 먼저 점검해야 합니다. 도메인 연결 안될 때 DNS 체크 순서에서 응답 코드가 NXDOMAIN이거나 dig +trace가 TLD 단계에서 멈춘다면, 99퍼센트 이 단계의 문제입니다.

# 레지스트라 측 등록 NS 확인
whois example.com | grep -i "Name Server"

# 권한 NS 측 응답 확인
dig NS example.com +short

# 두 결과가 다르면 위임 불일치

두 결과가 일치한다면 이 단계는 통과입니다. 그러나 새로 NS를 변경했거나 도메인을 다른 등록기관으로 이전한 직후라면, TLD 서버의 캐시 갱신 주기(보통 15분~2시간)가 남아 있어 일시적으로 옛 값이 보일 수 있다는 점도 고려해야 합니다.

글루 레코드(Glue Record) 누락 확인

ns1.example.com처럼 자기 도메인 내부에 NS를 두는 경우, 레지스트라가 해당 NS의 IP를 함께 등록해 주는 글루 레코드가 필요합니다. 글루가 누락되면 리졸버가 ns1.example.com의 IP를 알기 위해 다시 example.com에 질의해야 하는 닭과 달걀 문제가 발생해 결과적으로 NXDOMAIN이나 타임아웃이 납니다. 진단은 간단합니다. dig +trace example.com의 출력에서 권한 NS 이름은 보이는데 ;; ADDITIONAL SECTION에 IP가 없다면 글루 누락입니다. 레지스트라 관리 콘솔의 글루 레코드(또는 호스트 등록) 메뉴에서 IP를 추가하면 해결됩니다.

2단계: 권한 네임서버 응답 직접 질의

레지스트라 위임이 정상이면 다음은 권한 NS가 실제로 응답하는지 확인합니다. 이 단계에서는 리졸버 캐시를 우회하고 권한 NS에 직접 물어보는 방식이 핵심입니다. 도메인 연결 안될 때 DNS 체크 순서의 2단계는 캐시 효과를 배제하고 진실에 가까운 응답을 확보하는 작업이라고 이해하시면 됩니다.

# 특정 권한 NS에 직접 질의 (캐시 우회)
dig @ns1.example.com example.com SOA

# 모든 권한 NS의 SOA serial 비교
for ns in $(dig NS example.com +short); do
  echo "== $ns =="
  dig @$ns example.com SOA +short
done

권한 NS 중 하나가 REFUSED를 반환하거나 타임아웃이 난다면, 해당 NS 서버의 존 파일 미배포·방화벽 53번 포트 차단·NS 데몬 미동작 중 하나입니다. SOA serial이 NS마다 다르면 영역 전송 설정(예: bind의 also-notify, AXFR 권한)을 점검해야 하며, serial 동기화 전까지는 리졸버가 어느 NS에 붙느냐에 따라 응답이 달라지므로 사용자 체감 장애가 무작위로 발생합니다.

3단계: A·AAAA 레코드 IP 일관성 검증

권한 NS가 응답하면 A(IPv4)·AAAA(IPv6) 레코드의 IP가 의도한 서버를 가리키는지, 다중 NS 간 일관성이 있는지 확인합니다. 배포 자동화 파이프라인에서 NS 한 곳에만 새 IP가 반영되고 다른 NS는 옛 IP를 들고 있는 경우가 의외로 자주 발생합니다.

1. 의도한 IP 확인: dig A example.com +short와 dig AAAA example.com +short의 결과가 현재 서버 IP와 일치하는지 비교
2. NS별 응답 비교: 모든 권한 NS에 대해 dig @ns A를 돌려 동일 IP가 나오는지 확인
3. 외부 리졸버 응답 비교: dig @8.8.8.8, dig @1.1.1.1로 캐시 외 응답 점검
4. TTL 확인: dig A example.com 출력의 TTL 값이 의도한 값(예: 300초)과 일치하는지 확인

4단계: CNAME·MX 레코드 충돌 및 누락 점검

A·AAAA가 정상이면 다음은 CNAME과 MX입니다. CNAME은 RFC 1034 규칙상 같은 이름에 다른 레코드 타입과 공존할 수 없으며, 루트 도메인(@)에는 사용할 수 없습니다. 이 두 가지 규칙을 어기면 리졸버가 무시하거나 SERVFAIL을 반환해 단속적인 장애를 만듭니다. 도메인 연결 안될 때 DNS 체크 순서에서 4단계는 가장 자주 놓치는 함정 구간입니다.

• 루트 도메인(@)에 CNAME을 두지 않았다 — 필요하면 ALIAS·ANAME 가상 레코드 사용
• 같은 호스트(예: www)에 A와 CNAME이 동시에 존재하지 않는다
• CNAME 대상이 또 다른 CNAME을 가리키는 체인이 5단계를 넘지 않는다
• MX 레코드의 우선순위(priority)는 0 이상의 정수이며, 가장 낮은 값이 1순위다
• SPF TXT 레코드는 도메인당 1개로 통합되어 있다 (여러 개 등록 시 무효)
• TTL을 변경한 뒤 이전 TTL 값만큼 기다렸다 — 짧은 TTL이라도 캐시 만료 시간 필요

메일 발송 실패와 DNS의 관계

웹은 정상인데 메일만 받지 못한다면 MX·SPF·DKIM·DMARC 4종 레코드 의존 관계를 점검합니다. MX 누락 시 수신 자체가 안 되고, SPF 미등록은 발신 메일이 스팸 처리되며, DKIM 키 불일치는 수신 측에서 위변조로 판정합니다. DMARC는 SPF·DKIM 정책 강제 도구이므로, p=reject으로 두고 SPF·DKIM이 깨지면 모든 메일이 차단됩니다. 새 메일 서버 도입 직후 발생하는 발송 실패의 80퍼센트가 이 4종 중 하나의 누락입니다.

5단계: DNSSEC 검증 실패 함정

DNSSEC을 활성화한 직후 또는 키 롤오버 직후 사이트가 안 열린다면 거의 확실히 DNSSEC 검증 실패입니다. 응답 코드는 SERVFAIL이고, 일부 리졸버에서는 EDE 6(DNSSEC Bogus)이 함께 반환됩니다. DNSSEC은 보안 강화 메커니즘이지만 잘못 설정하면 정상 도메인을 서비스 불능 상태로 만드는 양날의 칼입니다.

# DNSSEC 검증 우회로 원인 격리
dig +dnssec +cd example.com

# DS 레코드 확인 (레지스트라 측)
dig DS example.com +short

# DNSKEY 확인 (권한 NS 측)
dig DNSKEY example.com +short

6단계: 리졸버 캐시·hosts 파일·로컬 단의 함정

권한 NS는 모두 정상인데 특정 사용자 PC만 연결이 안 된다는 제보가 들어오면 로컬 단을 점검할 차례입니다. TTL 캐시·hosts 파일·로컬 DNS·VPN·브라우저 자체 캐시 등 영향 요소가 많아 분리 진단이 핵심입니다.

• OS DNS 캐시 플러시 — Windows ipconfig /flushdns, macOS sudo dscacheutil -flushcache, Linux sudo systemd-resolve --flush-caches
• hosts 파일에 해당 도메인이 수동 매핑되어 있지 않은지 — Windows C:\Windows\System32\drivers\etc\hosts, Unix /etc/hosts
• 브라우저 자체 DNS 캐시 — Chrome chrome://net-internals/#dns에서 Clear host cache
• VPN·프록시 비활성화 후 재시도 — 일부 VPN은 자체 DNS 강제 적용
• 사내 DNS 서버(예: 윈도우 도메인 컨트롤러) 응답 비교
• 공유기 DNS 캐시 — 공유기 재부팅으로 즉시 해소
• 이전 TTL 만큼 대기했는지 — 변경 전 TTL이 24시간이면 최대 24시간 잔존
• 외부 공개 리졸버(8.8.8.8 / 1.1.1.1)로 변경 후 비교

7단계: DNS 이후 HTTP·SSL 계층 분리 진단

DNS는 정상인데 사이트가 안 열리는 경우는 의외로 자주 발생합니다. 이때는 DNS 단계에서 빠져나와 웹서버 응답·TLS 인증서 계층을 분리 진단합니다. 도메인 연결 안될 때 DNS 체크 순서의 마지막 실전 단계는 사실상 'DNS가 아닌 곳'을 빠르게 배제하는 작업입니다.

특히 HTTPS 인증서 케이스는 DNS와 자주 혼동됩니다. Let's Encrypt 자동 갱신 실패, 인증서의 SANs(Subject Alternative Name)에 새로 추가한 서브도메인이 빠진 경우, 중간 인증서(Intermediate CA) 누락으로 일부 클라이언트(특히 모바일·구형 브라우저)에서만 실패하는 경우가 대표적입니다. 인증서 갱신 직후라면 우선 도구로 SANs·체인·만료일을 한 번에 점검해 의심 시간을 줄이는 것이 좋습니다.

실전 dig·nslookup 명령어 모음 (복붙용 치트시트)

지금까지 등장한 dig·nslookup 옵션을 한 곳에 모아 복붙용 치트시트로 정리했습니다. 도메인 연결 안될 때 DNS 체크 순서를 따라가다 막힐 때 이 섹션만 펼쳐 두고 사용하시기 바랍니다.

# 위임 체인 시각적 추적 (루트 → TLD → 권한 NS)
dig +trace example.com

# 특정 권한 NS에 직접 질의 (캐시 우회)
dig @ns1.example.com example.com SOA

# 외부 공개 리졸버로 응답 비교
dig @8.8.8.8 example.com
dig @1.1.1.1 example.com

# 짧고 깨끗한 출력
dig example.com +short
dig NS example.com +short

# DNSSEC 검증 우회 (검증 비활성화로 원인 격리)
dig +dnssec +cd example.com

# DS·DNSKEY 비교
dig DS example.com +short
dig DNSKEY example.com +short

# 모든 권한 NS의 SOA serial 비교 (영역 전송 점검)
for ns in $(dig NS example.com +short); do
  echo "== $ns =="
  dig @$ns example.com SOA +short
done

# Extended DNS Errors 활성화 출력
dig example.com +ednsflags

# Windows nslookup 기본
nslookup example.com
nslookup -type=NS example.com
nslookup -type=MX example.com 8.8.8.8

# OS별 DNS 캐시 플러시
ipconfig /flushdns                              # Windows
sudo dscacheutil -flushcache                    # macOS
sudo killall -HUP mDNSResponder                 # macOS (mDNS 함께)
sudo systemd-resolve --flush-caches             # Linux systemd
sudo resolvectl flush-caches                    # Linux 신버전

# macOS 현재 리졸버 상태 (dig 미설치 시 대체)
scutil --dns

정리: 8단계 체크리스트와 다음 행동

도메인 연결 안될 때 DNS 체크 순서를 한 화면에 압축한 최종 체크리스트입니다. 장애가 다시 발생하면 이 순서대로 위에서 아래로 내려가면서 통과 여부를 표시하기만 해도 평균 진단 시간이 절반으로 줄어듭니다.

• 1단계 응답 코드 — dig example.com의 status로 NXDOMAIN·SERVFAIL·REFUSED·NOERROR 분기
• 2단계 레지스트라 위임 — WHOIS Name Servers와 dig NS 일치, 글루 레코드 등록 여부
• 3단계 권한 NS 직접 질의 — dig @ns SOA로 SOA serial NS별 비교
• 4단계 A·AAAA 일관성 — IPv4·IPv6 IP가 의도한 서버, 모든 NS 동일 응답
• 5단계 CNAME·MX — 루트 CNAME·A·CNAME 공존 금지, MX 우선순위 정수, SPF 1개 통합
• 6단계 DNSSEC — dig +cd로 검증 우회 테스트, DS·DNSKEY 일치 확인
• 7단계 로컬 캐시·hosts — OS·브라우저·VPN·사내 DNS 분리, 외부 리졸버 비교
• 8단계 HTTP·SSL — DNS 정상 후 웹서버 응답·TLS 인증서 SANs·체인 점검

DNS 정상화 이후에는 검색엔진 색인 상태, 백링크·도메인 권위 지표 변화도 함께 점검하시기 바랍니다. 장애 직후 며칠 동안은 색인 누락이나 도메인 평가 변동이 발생할 수 있으므로, 평소에 도메인 레이팅(DR)이란 글에서 다루는 도메인 권위 지표를 모니터링해 두면 회복 속도를 가늠할 수 있습니다.

장애가 반복적으로 일어난다면 단발성 점검을 넘어 모니터링 체계를 갖추는 단계로 나아가야 합니다. 권한 NS 응답 시간, SOA serial 동기화, 인증서 만료일을 정기 점검 항목에 포함하고, 변경 작업 전후로 항상 dig +trace 결과를 캡처해 변경 이력을 남기는 운영 습관이 다음 장애의 진단 시간을 결정합니다.