이 오류가 뜻하는 것

ERR_NAME_NOT_RESOLVED(크로미움 net error -105)는 브라우저가 DNS에 호스트명의 주소를 물었는데 쓸 수 있는 답을 받지 못했다는 뜻입니다. 서버에는 닿지도 않았습니다. TCP 연결도, TLS도, HTTP도 없었습니다. 그래서 이름이 풀리기 전까지는 웹 서버나 인증서, 방화벽이 어떤 상태인지는 상관이 없습니다.

어디서 보이는지는 무엇이 실패했느냐에 따라 다릅니다.

  • 페이지 주소 자체가 실패하면 크롬은 대개 실패 뒤에 간단한 DNS 점검을 돌리고 그 결과를 대신 보여 줍니다. DNS_PROBE_FINISHED_NXDOMAIN, DNS_PROBE_FINISHED_NO_INTERNET, DNS_PROBE_FINISHED_BAD_CONFIG 같은 코드입니다. 이 화면은 DNS_PROBE_FINISHED_NXDOMAIN 가이드에서 다룹니다.
  • 페이지가 불러오는 것들, 즉 이미지·스크립트·폰트·API 호출은 점검을 거치지 않습니다. 개발자 도구 콘솔에 실패한 호스트명과 함께 net::ERR_NAME_NOT_RESOLVED가 찍힙니다.
  • 크로미움 기반 앱(Electron 앱, 안드로이드 WebView)에서는 원래 코드가 그대로 보이는 경우가 많습니다.

다른 도구들도 같은 실패를 자기 말로 알려 줍니다. curl은 curl: (6) Could not resolve host: example.com, Node.js는 이름이 없으면 getaddrinfo ENOTFOUND, 조회가 일시적으로 실패하면 EAI_AGAIN을 냅니다. 리눅스의 파이썬은 Name or service not known 또는 Temporary failure in name resolution입니다. 브라우저 코드는 이 경우들을 구분하지 않지만 해결 방법은 서로 다릅니다. 그래서 다음 단계는 DNS에 직접 물어보는 것입니다.

30초 진단: 내 문제인가, 도메인 문제인가

  1. 호스트명을 다시 읽습니다. 글자 하나 빠짐, .com 대신 .co, 엉뚱한 하이픈. 가장 흔한 원인이고, 오타는 DNS를 아무리 들여다봐도 고쳐지지 않습니다.
  2. 다른 네트워크에서 열어 봅니다. 휴대폰 와이파이를 끄고 같은 주소를 열어 보세요. 모바일 데이터는 통신사 리졸버를 쓰므로 완전히 다른 경로입니다.
  3. 바깥에서 물어봅니다. DNS 조회는 내 네트워크가 아니라 우리 서버에서 공용 리졸버에 묻습니다. 전파 확인은 여러 대형 리졸버에 한꺼번에 묻습니다.

바깥에서는 풀린다면 도메인은 정상이고, 원인은 내 기기나 브라우저, 네트워크에 있습니다(아래 ‘내 PC에서만 안 될 때’로 건너뛰세요). 어디서나 실패한다면 도메인의 DNS가 고장 난 것이고, 도메인을 운영하는 쪽만 고칠 수 있습니다.

DNS에 직접 묻고 상태 읽기

dig www.example.com A

dig가 없는 윈도우라면 nslookup www.example.com 1.1.1.1, 또는 PowerShell에서 Resolve-DnsName www.example.com -Server 1.1.1.1을 쓰세요.

dig 헤더의 상태 줄이 곧 진단입니다.

dig에 보이는 것뜻대개 고치는 쪽
status: NXDOMAIN그런 이름이 아예 없음도메인 운영자: 레코드 누락, 오타, 만료·hold된 도메인
status: NOERROR, ANSWER: 0이름은 있는데 A/AAAA 레코드가 없음(‘NODATA’)도메인 운영자: 주소 레코드 추가
status: SERVFAIL리졸버가 믿을 만한 답을 얻지 못함도메인 운영자: 위임 오류 또는 DNSSEC
connection timed out; no servers could be reached내 리졸버가 아예 응답하지 않음나: 네트워크, 공유기, 리졸버 설정

이제 리졸버끼리 비교합니다. 같은 질의를 두세 곳에 던져 보세요.

dig @1.1.1.1 www.example.com A +short
dig @8.8.8.8 www.example.com A +short
dig www.example.com A +short          # 시스템이 쓰는 리졸버

모두 똑같이 실패하면 도메인 문제입니다. 기본 리졸버만 실패하면 내 리졸버 문제입니다. 검증하는 공용 리졸버는 SERVFAIL인데 통신사 리졸버는 된다면 아래 DNSSEC 부분을 읽으세요.

SERVFAIL: 가장 많이 잘못 짚는 경우

NXDOMAIN은 ‘답’입니다. SERVFAIL은 리졸버가 시도했지만 믿을 만한 답을 얻지 못했다는 뜻입니다. 브라우저에는 똑같은 오류로 보이지만, 해결 방법은 서로 전혀 다릅니다.

DNSSEC 검증 실패

전형적인 경우는 이렇습니다. 예전 DNS 제공자에서 DNSSEC을 켜 두었던 도메인을, 존에 서명하지 않는(또는 다른 키로 서명하는) 새 제공자로 옮겼는데 레지스트리에는 옛 DS 레코드가 그대로 남아 있습니다. DNSSEC을 검증하는 리졸버는 신뢰 사슬이 맞지 않으니 아무것도 돌려주지 않습니다. 검증하지 않는 리졸버는 DNSSEC을 무시하고 정상적으로 답합니다. 그래서 어떤 리졸버를 쓰느냐에 따라 ‘되는 사람과 안 되는 사람’이 갈립니다.

확인 방법은 검증을 건너뛰라고 요청하는 +cd(checking disabled)입니다.

dig @1.1.1.1 example.com A          # status: SERVFAIL
dig @1.1.1.1 example.com A +cd      # status: NOERROR, 답이 있음

+cd로는 답이 오고 일반 질의로는 안 온다면 DNSSEC 문제입니다. 최근 dig 버전은 리졸버가 확장 DNS 오류(EDE)를 함께 보내면 그 줄도 보여 줍니다(Cloudflare 리졸버가 자주 보냅니다). EDE: 6 (DNSSEC Bogus)나 EDE: 7 (Signature Expired) 같은 형태입니다.

그다음 레지스트리가 게시하는 내용을 봅니다.

dig DS example.com +short
dig DNSKEY example.com +short

DS 레코드는 있는데 존에 맞는 DNSKEY가 없다면 옛 DS가 남은 경우입니다. 해결: 레지스트라에서 DS 레코드를 지우거나, 새 제공자에서 DNSSEC을 켜고 거기서 주는 DS로 바꾸세요. 검증하는 리졸버들은 옛 DS가 캐시에서 만료되면 정상으로 돌아옵니다. Signature Expired라면 존의 자동 재서명이 멈춘 것이므로, 존에 서명하는 쪽의 문제입니다.

위임 오류

레지스트리에는 도메인의 네임서버가 등록돼 있는데, 정작 그 서버들이 존을 서비스하지 않는 경우입니다. 네임서버를 바꿨는데 새 제공자에 존을 만들지 않았을 때, 네임서버 이름을 잘못 적었을 때, 옛 제공자가 전환 전에 존을 지워 버렸을 때 생깁니다. 그 서버들은 REFUSED로 답하거나 아예 답하지 않고, 리졸버는 SERVFAIL로 포기합니다. Cloudflare 리졸버는 이런 경우에 EDE: 22 (No Reachable Authority)를 붙이는 경향이 있습니다.

레지스트리가 어디로 위임하는지 묻고, 그 서버들에 하나씩 직접 물어보세요.

dig NS com +short                                    # TLD의 네임서버
dig NS example.com @a.gtld-servers.net +norecurse    # 레지스트리가 위임한 곳
dig SOA example.com @ns1.dns-provider.example +norecurse

레지스트리의 답은 위임(referral)이라서 네임서버가 answer가 아니라 authority 섹션에 나옵니다. com 자리에 내 TLD(kr, net, io)를 넣고 거기서 나온 서버 중 하나를 쓰세요.

정상적인 네임서버는 status: NOERROR와 aa(권한 있음) 플래그로 답합니다. 등록된 네임서버가 REFUSED, SERVFAIL을 주거나 시간 초과가 나면 그 위임이 고장 난 것입니다. 네임서버 불일치 진단 가이드에서 레지스트리 목록과 각 서버가 실제로 서비스하는 내용을 비교하는 방법을 다룹니다.

변형이 하나 더 있습니다. 도메인 안에 있는 네임서버(example.com을 서비스하는 ns1.example.com)에는 글루 레코드, 즉 레지스트라에 등록한 네임서버 IP가 필요합니다. 글루가 없으면 리졸버는 네임서버 주소를 알기 위해 그 네임서버가 서비스하는 도메인부터 풀어야 하는 처지가 됩니다. 대부분의 레지스트라는 이를 ‘호스트 등록’이나 ‘네임서버 등록’ 같은 메뉴에서 처리합니다.

NXDOMAIN과 NODATA: 이름이 정말 없음

자세한 내용은 DNS_PROBE_FINISHED_NXDOMAIN 가이드에 있습니다. 가장 자주 나오는 경우만 짧게 정리하면 이렇습니다.

  • 레코드가 사람들이 입력하는 이름에는 없음. 사이트는 www.example.com에 만들어 뒀는데 사람들은 example.com을 입력하거나, 그 반대입니다. 루트 도메인에 MX와 TXT만 있고 A가 없으면 NXDOMAIN이 아니라 NODATA가 나옵니다. 두 이름을 모두 만들고 한쪽을 다른 쪽으로 리다이렉트하세요.
  • 도메인이 TLD 존에서 빠짐. clientHold, serverHold, 유예 기간이 지난 만료. 레지스트리가 도메인을 게시하지 않으므로 그 아래 모든 이름이 실패합니다. 새로 등록한 .com 같은 gTLD 도메인에서 등록자가 연락처 확인 메일을 처리하지 않아도 같은 방식으로 정지됩니다. RDAP 조회로 상태를 확인하세요. 단계별 의미는 도메인 만료·Hold·Pending Delete 가이드에 있습니다.
  • CNAME이 삭제된 대상을 가리킴. dig의 answer 섹션에 내 CNAME이 보이고, 사슬 전체는 NXDOMAIN입니다. 호스팅된 쇼핑몰, 앱, 스토리지 버킷을 지웠는데 DNS 레코드는 남겨 둔 경우에 흔합니다. 레코드를 고치거나 지우세요. 주인 없는 CNAME은 서브도메인 탈취의 출발점이기도 합니다.
  • 레코드는 새로 만들었는데 ‘없음’이 캐시됨. 레코드를 만들기 전에 무언가가 그 이름을 조회했고, 리졸버는 그 부정 응답을 내 존의 SOA 레코드가 정한 시간 동안 들고 있습니다. dig @<내 네임서버> 이름 A +norecurse로 레코드가 게시됐는지 확인한 뒤 기다리세요.
  • 실제로 쓰이지 않는 존을 고침. dig NS example.com +short 결과와 내가 설정을 바꾼 대시보드의 제공자를 비교하세요.

내 PC에서만 안 될 때

바깥에서는 풀리는데 나만 안 되는 경우입니다. 대략 가능성이 높은 순서입니다.

오래된 캐시. 운영체제나 브라우저가 실패한 결과를 캐시했습니다. 사이트가 정말 잠깐 죽어 있던 순간의 결과일 수도 있습니다.

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# systemd-resolved를 쓰는 리눅스
resolvectl flush-caches

크롬은 자체 캐시도 있습니다. chrome://net-internals/#dns를 열고 “Clear host cache”를 누르세요.

크롬의 보안 DNS. 설정 → 개인정보 및 보안 → 보안 → ‘보안 DNS 사용’. 특정 제공자로 지정돼 있으면 크롬은 네트워크의 리졸버 대신 그 제공자에게 묻습니다. 그 제공자는 회사나 집 네트워크 안에만 있는 이름을 볼 수 없으므로, 같은 PC에서 nslookup은 되는데 크롬에서는 실패합니다. 지정한 제공자에 내 네트워크에서 닿을 수 없다면 모든 조회가 실패하고, 크롬이 페이지 주소에 대해 DNS_PROBE_FINISHED_BAD_SECURE_CONFIG를 보여 줄 수 있습니다. 현재 서비스 제공업체를 쓰도록 바꿔 비교해 보세요. 안드로이드에도 비슷한 시스템 설정인 ‘비공개 DNS’가 있는데, 지정한 호스트명에 닿지 못하면 똑같이 실패합니다.

VPN. VPN은 대개 자기 리졸버를 밀어 넣습니다. 내부 이름은 연결돼 있을 때만 풀리고, 어떤 VPN 리졸버는 공개 이름을 제대로 처리하지 못하며, 깔끔하지 않게 연결을 끊으면 닿을 수 없는 VPN 리졸버가 설정에 남기도 합니다. 완전히 끊고, 캐시를 비우고, 다시 시도하세요. 리눅스에서는 resolvectl status로 인터페이스별로 실제 어떤 리졸버를 쓰는지, 윈도우에서는 ipconfig /all로 확인할 수 있습니다.

차단하는 리졸버. 이름을 차단하는 리졸버는 그 이름에 NXDOMAIN으로 답하는 경우가 많습니다. 보안 필터링을 하는 공용 리졸버, Pi-hole, AdGuard Home, NextDNS, 자녀 보호 기능, 일부 통신사가 그렇습니다. nslookup example.com 1.1.1.1은 되고 nslookup example.com은 안 된다면 내 리졸버가 차단하고 있거나 고장 난 것입니다. 차단 로그를 확인하세요.

로그인 전의 공용 와이파이. 일부 캡티브 포털은 로그인 전까지 DNS를 막습니다. http://neverssl.com 같은 평문 HTTP 페이지를 열어 로그인 화면을 띄운 뒤 다시 시도하세요.

hosts 파일이 하는 일과 하지 않는 일. /etc/hosts(윈도우는 C:\Windows\System32\drivers\etc\hosts)의 항목은 이름을 풀리게 만들기 때문에 이 오류의 원인이 될 수 없습니다. 대신 반대의 혼란을 만듭니다. 오래된 항목 때문에 내 PC에서는 사이트가 되고, 다른 사람들은 모두 ERR_NAME_NOT_RESOLVED를 봅니다. 이전 작업을 hosts 항목으로 시험했다면, 내 브라우저를 믿기 전에 그 줄부터 지우세요.

페이지는 뜨는데 그 안의 무언가가 안 될 때

페이지 자체는 되는데 콘솔에 다른 호스트명의 net::ERR_NAME_NOT_RESOLVED가 찍힌다면, 고장 난 이름은 의존성입니다. 흔한 이유는 이렇습니다.

  • 서비스를 종료했거나 도메인을 놓친 외부 업체의 스크립트, 폰트, 위젯.
  • 운영 빌드나 환경 변수에 박혀 들어간 스테이징·내부용 호스트명.
  • 사내망이나 VPN에서만 풀리는 내부 API 이름. 직원에게는 되고 다른 모두에게는 깨집니다.
  • 방문자의 DNS 차단기가 NXDOMAIN으로 답하는 추적·광고 도메인. 그건 방문자의 선택이고, 내 페이지는 그것 없이도 동작해야 합니다.

빌드가 참조하는 모든 호스트명을 한 번에 확인하려면:

grep -rhoE 'https?://[A-Za-z0-9.-]+' dist/ | sed 's#^.*://##' | sort -u |
while read -r h; do
  [ -n "$(dig +short "$h" A "$h" AAAA)" ] || echo "does not resolve: $h"
done

dist/는 내 빌드 출력 디렉터리로 바꾸세요. 목록에 나온 이름은 고치거나 빼야 합니다.

고친 다음에

  • 네임서버나 위임을 고쳤다면 모든 리졸버에 반영되기까지 시간이 걸립니다. 옛 위임이 TTL 동안 캐시에 남기 때문입니다. 시간 계산은 DNS 전파 시간 가이드에 있고, 전파 확인으로 대형 리졸버들이 따라왔는지 볼 수 있습니다.
  • DNSSEC을 고쳤다면 검증하는 리졸버에 +cd 없이 시험하세요(dig @1.1.1.1 example.com A). 실패하던 쪽이 바로 그쪽입니다.
  • 사람들이 쓰는 모든 이름을 시험하세요. 루트, www, 링크나 메일에 들어 있는 서브도메인까지.

함께 보면 좋은 글

내 도메인에서 바로 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.