파워포인트 자막(라이브 캡션) 안될 때 1분 진단과 완전 해결 가이드

날짜:

DNS_PROBE_FINISHED_NXDOMAIN 오류 해결 가이드: 원인 분석부터 즉시 복구 체크리스트까지

날짜:

이 글의 목적은 브라우저에서 발생하는 DNS_PROBE_FINISHED_NXDOMAIN 오류를 신속하게 진단하고 복구하는 절차를 체계적으로 제공하여 개인과 기업 현장에서 바로 적용할 수 있도록 돕는 것이다.

1. 오류 의미와 동작 원리 이해

DNS_PROBE_FINISHED_NXDOMAIN은 브라우저가 요청한 도메인 이름에 대한 IP 주소를 DNS에서 찾지 못했음을 의미한다. NXDOMAIN은 “존재하지 않는 도메인” 응답 코드이며, 쿼리를 처리한 리졸버가 해당 이름에 대한 유효한 레코드를 돌려주지 못했음을 뜻한다. 이 오류는 도메인 자체가 실제로 없거나, 이름 서버 설정 오류, 로컬 또는 네트워크의 DNS 캐시 문제, VPN·보안 소프트웨어 간섭, 라우터 문제 등으로 발생한다.

2. 가장 빠른 복구: 5분 해결 루트

  1. 다른 네트워크로 즉시 교차검증을 수행한다. 휴대폰 LTE·5G 테더링이나 다른 Wi-Fi로 동일 URL 접속을 시도한다.
  2. 브라우저 사설 DNS 비활성화 또는 변경을 시도한다. 브라우저 보안 설정에서 “보호된 DNS(DoH/DoT)”를 끄거나 공용 DNS로 지정한다.
  3. 로컬 DNS 캐시 플러시를 수행한다. OS별 명령을 아래 표에서 실행한다.
  4. 네트워크 어댑터 초기화를 진행한다. IP 갱신과 Winsock 리셋을 포함한다.
  5. 라우터 재부팅 후 공용 DNS(예: 1.1.1.1, 8.8.8.8)를 임시로 설정한다.

3. OS·브라우저별 실무 명령어와 설정

환경캐시 플러시/초기화 명령DNS 임시 변경비고
Windows 10/11 CMD(관리자)에서 실행하다:
ipconfig /flushdns
ipconfig /release
ipconfig /renew
netsh winsock reset
netsh int ip reset 		어댑터 속성 → IPv4/IPv6 → 기본 DNS에 1.1.1.1 또는 8.8.8.8 지정하다. 재부팅 후 테스트하다.
macOS 터미널에서 실행하다:
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder 		시스템 설정 → 네트워크 → 세부정보 → DNS → 서버 추가하다. 버전에 따라 UI 경로가 다를 수 있다.
Linux (systemd-resolved) sudo resolvectl flush-caches /etc/resolv.conf 또는 NetworkManager에서 서버 지정하다. 배포판별 서비스명 확인이 필요하다.
Android 설정에서 네트워크 재설정 또는 기기 재부팅하다. Wi-Fi → 네트워크 수정 → 고급 → IP 설정 고정 → DNS1/DNS2 입력하다. 셀룰러는 OS 정책상 직접 변경 제한이 있을 수 있다.
iOS/iPadOS 설정 → 일반 → 전송 또는 재설정 → 네트워크 설정 재설정하다. Wi-Fi 상세 → DNS 구성 → 수동 → 서버 추가하다. 프로파일·VPN 영향 점검하다.
Chrome 주소창에 chrome://net-internals/#dns 또는 chrome://dns 입력 후 Host cache clear 실행하다. 설정 → 보안 → “보호된 DNS 사용” 해제 또는 제공자 선택하다. 버전에 따라 메뉴 문구가 다를 수 있다.
Edge/Firefox 브라우저 캐시 삭제 후 재시작하다. 보안 또는 네트워크 설정에서 DoH 해제 또는 제공자 지정하다. 확장프로그램 간섭 점검하다.

4. 원인별 진단 알고리즘

아래 순서를 따르면 현장 진단 효율을 높일 수 있다.

  1. 범위 확인: 특정 도메인만 실패인지, 모든 도메인이 실패인지 구분하다. 특정 도메인 실패면 도메인 설정 이슈 가능성이 높다.
  2. 이름 확인: 오탈자, 서브도메인, www 접두어 혼선 여부를 확인하다. 루트 도메인과 www의 레코드가 분리될 수 있다.
  3. 기기·프로파일 영향: 회사용 MDM·보안 클라이언트, VPN, 프록시, 광고차단, 필터링 소프트웨어를 일시 비활성화하고 재시도하다.
  4. 로컬 충돌: hosts 파일에 수동 매핑이 있는지 확인하다. Windows %SystemRoot%\System32\drivers\etc\hosts, macOS/Linux /etc/hosts를 점검하다.
  5. 리졸버 교차검증: 공용 DNS와 사내 DNS로 각각 질의해 비교하다. 공용에서는 성공하나 사내에서 실패하면 사내 분할 DNS 또는 포워딩 이슈로 본다.
  6. 레코드 존재성: A/AAAA/CNAME/CAA/MX 등 핵심 레코드 존재와 TTL 값을 확인하다.
  7. 권한 NS·레지스트리 상태: WHOIS 정보, 네임서버 위임, 글루 레코드, 도메인 만료 여부를 점검하다.
  8. DNSSEC: DNSSEC 사용 시 서명·체인 검증 실패 여부를 확인하다.

5. 도구 활용: 현장 테스트 명령 모음

목적명령 예시해석 포인트
A/AAAA 조회 nslookup example.com 1.1.1.1
dig A example.com @8.8.8.8 +trace		 권한 NS에서 NXDOMAIN이면 도메인/레코드 미존재 가능성이 높다.
네임서버 위임 dig NS example.com +trace 루트→TLD→권한 NS 체인이 완결되는지 확인하다.
DNSSEC 검증 dig A example.com +dnssec AD 플래그 유무, RRSIG 유효기간 확인하다.
브라우저/네트워크 ping example.com, curl -I https://example.com DNS는 성공하나 HTTP 실패 시 원인이 DNS가 아님을 구분하다.
사내 리졸버 비교 nslookup intranet.local 10.0.0.2 스플릿 DNS 정책 하에서 내부 전용 레코드 확인하다.

6. 공용 DNS 설정 가이드

문제 원인 분리를 위해 임시로 공용 DNS를 지정한다. 대표값은 IPv4: 1.1.1.1, 8.8.8.8, 9.9.9.9이며 IPv6: 2606:4700:4700::1111, 2001:4860:4860::8888 등이 있다. 기업 환경에서는 보안 및 로깅 요구사항에 따라 사내 리졸버를 우선 사용하되, 장애 시 자동 페일오버를 고려한다.

7. 도메인 운영자 체크리스트

  • 도메인 등록·연장 상태가 유효하다.
  • 레지스트리의 NS 위임과 호스팅 사업자 측 NS 설정이 일치한다.
  • 루트 도메인과 www의 레코드 전략을 명확히 한다. 필요 시 ALIAS/ANAME 또는 www→루트 CNAME 대체 정책을 사용한다.
  • IPv6를 활성화했다면 AAAA 레코드와 방화벽 정책을 동기화한다.
  • DNSSEC 사용 시 DS 레코드와 권한 서버의 서명 키 롤오버 일정을 관리한다.
  • TTL을 단계적으로 조정하여 변경 배포·롤백을 계획한다.
  • CDN 사용 시 CNAME 체인과 인증서, 오리진 헬스체크를 일관되게 유지한다.

8. 기업 네트워크에서 자주 발생하는 원인

  1. 스플릿 DNS 오구성: 내부와 외부가 서로 다른 레코드를 사용하므로 포워더 및 존 우선순위를 점검하다.
  2. 보안 게이트웨이 차단: DNS 필터링, DLP, SSL 가시성 기능이 DoH/DoT 트래픽을 차단하여 질의 실패가 발생할 수 있다.
  3. AD 통합 DNS 레코드 누락: 도메인 컨트롤러 마이그레이션 후 SRV/A 레코드가 비어 오류가 발생할 수 있다.
  4. DHCP 옵션 불일치: 클라이언트가 다른 서브넷의 리졸버를 참조하여 지연 또는 실패가 발생할 수 있다.

9. VPN·보안 소프트웨어 점검 포인트

  • VPN 연결 시 “DNS 강제 터널링”이 활성화되어 사내 리졸버만 사용하도록 강제되는지 확인하다.
  • 엔드포인트 보안 제품의 웹 필터·광고 차단·안전 검색 기능을 일시 해제 후 재현 테스트하다.
  • 브라우저 확장프로그램을 모두 비활성화하고 시크릿 모드로 재시도하다.

10. 라우터·게이트웨이 레벨 조치

  • ISP 제공 장비의 DNS 프록시 기능을 비활성화하거나 최신 펌웨어로 업데이트하다.
  • 라우터의 DNS 리바인딩 보호가 합법적 내부 도메인을 차단하지 않는지 확인하다.
  • WAN 장애 시 백업 회선 또는 셀룰러 페일오버 정책을 적용하다.

11. 단계별 트러블슈팅 플로우차트 요약

  1. 다른 네트워크로 재현 테스트하다.
  2. 브라우저 보호 DNS 해제 또는 제공자 변경하다.
  3. OS DNS 캐시 플러시 및 네트워크 초기화하다.
  4. 공용 DNS로 임시 고정 후 접속 확인하다.
  5. 도메인 WHOIS·NS 위임·레코드 유무 확인하다.
  6. DNSSEC 사용 시 DS·RRSIG 유효성 점검하다.
  7. VPN·보안 제품·라우터 설정 영향 제거 후 재시도하다.
  8. 사내 리졸버·포워더·스플릿 DNS 정책 검토하다.

12. 현장 체크리스트 템플릿

항목체크 방법기준/판단결과
도메인 만료 여부 WHOIS 조회 만료 예정 30일 이내 경보 OK / 조치
NS 위임 일치 NS 레코드/글루 확인 레지스트리·호스팅 일치 OK / 조치
A/AAAA/CNAME 유효 dig/nslookup NXDOMAIN/NOERROR 판별 OK / 조치
DNSSEC 유효 +dnssec 쿼리 AD 플래그, RRSIG 유효 OK / 조치
리졸버 비교 공용 vs 사내 응답 일관성 확보 OK / 조치
클라이언트 캐시 flush 후 재시도 재현 여부 변경 OK / 조치
VPN/보안 영향 일시 해제 테스트 변화 있으면 정책 조정 OK / 조치
라우터/게이트웨이 재부팅·펌웨어 DNS 프록시 정상 OK / 조치

13. 사례로 보는 원인별 해결

  • 도메인 신규 개설 직후: TTL 및 전파 지연으로 특정 ISP에서 NXDOMAIN이 발생할 수 있다. 전파 기간 동안 공용 DNS 교체 또는 CDN의 즉시 활성화 기능을 활용하다.
  • 서브도메인 이전: CNAME 체인 중간의 레코드 누락으로 NXDOMAIN이 발생한다. 체인 전 구간을 추적 쿼리로 검증하고 누락 구간을 보완하다.
  • DNSSEC 키 롤오버 실패: 새 KSK/ZSK 적용 후 DS가 레지스트리에 반영되지 않아 검증 실패가 난다. 이전 키와의 중첩 기간을 두고 단계적 롤오버를 수행하다.
  • 사내 전용 도메인: VPN 미연결 상태에서 내부 전용 FQDN을 질의하여 NXDOMAIN이 발생한다. 분할 터널 정책 검토 또는 로컬 호스트 항목 임시 매핑을 적용하다.

14. 예방 전략

  1. 변경 전 TTL을 낮추고 변경 후 정상화되면 TTL을 복구하다.
  2. 모니터링을 도입하여 NXDOMAIN 비율과 응답시간을 상시 관측하다.
  3. 이중화된 권한 네임서버와 지역 분산을 구성하다.
  4. CI/CD 파이프라인에 DNS 검증 단계(dig +trace, 레코드 유효성 검사)를 포함하다.
  5. 도메인 만료 알림, DNSSEC 키 갱신 알림을 자동화하다.

FAQ

공용 DNS로 바꾸면 항상 해결되나?

항상 그렇지 않다. 도메인 자체의 레코드 누락, 위임 오류, DNSSEC 문제는 공용 DNS로도 해결되지 않는다. 원인 분리용 임시 조치로 활용하다.

브라우저 캐시와 DNS 캐시는 무엇이 다른가?

브라우저 캐시는 콘텐츠 파일을 저장하고 DNS 캐시는 도메인→IP 매핑을 저장한다. NXDOMAIN은 주로 DNS 캐시와 리졸버 단계에서 발생한다.

www는 접속되는데 루트 도메인은 안 된다. 왜 그런가?

루트 도메인과 www에 서로 다른 레코드가 설정되었을 수 있다. 루트에 A/AAAA 또는 ALIAS가 필요하다.

DNSSEC을 끄면 문제가 해결되나?

검증 실패가 원인인 경우 임시로 해결될 수 있으나 보안 저하가 발생한다. 올바른 키·DS 동기화로 정상화하는 것이 원칙이다.

모바일 데이터에서는 되는데 회사 Wi-Fi에서만 안 된다. 왜 그런가?

사내 리졸버 정책, 콘텐츠 필터, 스플릿 DNS, 프록시가 원인일 수 있다. 사내 리졸버 로그와 정책을 점검하다.