이 오류가 말하는 것

크롬은 “사이트에 연결할 수 없음”, “이름의 서버 IP 주소를 찾을 수 없습니다”를 보여 주고 아래에 DNS_PROBE_FINISHED_NXDOMAIN이라는 코드를 붙입니다. 이 코드는 두 부분으로 읽습니다.

DNS_PROBE_FINISHED는 이름 조회가 실패해서 크롬이 이 연결에서 DNS가 아예 동작하는지 빠르게 점검(probe)했다는 뜻입니다. NXDOMAIN은 그 결과입니다. DNS는 동작하니 문제는 그 이름이라는 것입니다. NXDOMAIN은 DNS 응답 코드로 “그런 도메인 없음”입니다. 해당 영역에 권한이 있는 서버가, 이 이름은 어떤 레코드 타입으로도 존재하지 않는다고 답한 것입니다.

여기까지가 원리입니다. 실제로는 크롬이 이웃한 몇 가지 실패에도 같은 화면을 씁니다. 이름은 있는데 주소 레코드가 없는 경우, 그리고 SERVFAIL로 끝난 일부 조회도 그렇습니다. 오류 화면은 “이름 조회가 안 됐다”로만 받아들이고, 실제로 어떤 실패였는지는 dig나 nslookup으로 확인하세요. 같은 상황을 파이어폭스는 “사이트를 찾는 데 문제가 있습니다”로, 사파리는 “Safari가 서버를 찾을 수 없습니다”로 보여 줍니다.

방문자라면

30초면 누구 문제인지 가를 수 있습니다.

  1. 주소를 다시 읽어 보세요. 글자 하나 빠짐, .com 대신 .co, 엉뚱한 위치의 하이픈. 이 오류의 원인으로는 이게 압도적으로 많습니다.
  2. 휴대폰에서 와이파이를 끄고 같은 주소를 열어 보세요. 모바일 데이터는 통신사 DNS를 쓰므로 완전히 다른 경로입니다.
  3. 공개 리졸버에 직접 물어보세요. 운영체제와 관계없이 nslookup example.com 1.1.1.1이면 됩니다. 아니면 우리 네트워크 밖의 여러 공개 리졸버에 묻는 DNS 조회를 쓰세요.

휴대폰이나 공개 리졸버에서 이름이 조회된다면 도메인은 정상이고 원인은 내 쪽에 있습니다. 아래 내 기기나 네트워크 쪽 원인으로 넘어가세요.

어디서도 안 된다면 도메인이 고장 났거나 사라진 것이고, 내 컴퓨터에서 무엇을 해도 달라지지 않습니다. 꼭 써야 하는 사이트라면 운영자에게 알리세요. 도메인 만료가 흔한 이유입니다.

브라우저 말고 status 줄을 보세요

$ dig www.example.com A

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41207
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.com.   300   IN   SOA   ns1.dns-provider.example. hostmaster.example.com. 2026100701 7200 3600 1209600 300

Windows에서는 Resolve-DnsName www.example.com -Server 1.1.1.1이 NXDOMAIN일 때 “DNS name does not exist”를, nslookup은 “Non-existent domain”을 출력합니다.

진단은 status로 합니다.

status뜻
NXDOMAIN이름 자체가 없습니다. 어떤 타입의 레코드도 없고, 덮어 주는 와일드카드도 없습니다.
NOERROR인데 ANSWER: 0이름은 있지만 물어본 타입의 레코드가 없습니다(흔히 NODATA라고 부릅니다). 전형적인 예: 루트 도메인에 MX와 TXT는 있는데 A가 없음.
SERVFAIL리졸버가 믿을 만한 답을 얻지 못했습니다. 네임서버에 닿지 않거나 설정이 잘못됐거나, DNSSEC 검증이 실패한 경우입니다.
REFUSED물어본 서버가 이 이름에 대해 답하지 않겠다고 합니다. 대개 그 zone을 갖고 있지 않은 네임서버에 직접 물었을 때입니다.

진짜 NXDOMAIN은 첫 번째뿐입니다. 나머지 셋도 방문자에게는 같은 오류 화면을 띄울 수 있지만, 고치는 방법은 각각 다릅니다.

누가 “없다”고 했나: SOA를 보세요

NXDOMAIN 응답에는 그 답을 낸 zone의 SOA 레코드가 authority 섹션에 실려 옵니다. 이 한 줄이 어디를 봐야 하는지 알려 줍니다.

위 예처럼 SOA가 내 도메인의 것이라면 위임은 정상입니다. 레지스트리가 리졸버를 내 네임서버로 보냈고, 내 zone이 www는 없다고 답한 것입니다. 문제는 내 zone 안에 있습니다.

SOA가 최상위 도메인(TLD)의 것이라면, 레지스트리에 이 도메인의 위임 자체가 없습니다.

$ dig nosuch-example-name-4821.com A

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5121

;; AUTHORITY SECTION:
com.   900   IN   SOA   a.gtld-servers.net. nstld.verisign-grs.com. 1759823456 1800 900 604800 86400

도메인이 등록된 적이 없거나, 철자가 틀렸거나, TLD zone에서 빠진 것(만료, hold, 삭제)입니다. 리졸버가 내 DNS 공급자까지 오지도 않으므로 DNS 대시보드에서 무엇을 바꿔도 소용없습니다.

dig +trace는 루트부터 전체 경로와 어디서 멈추는지를 보여 줍니다.

$ dig +trace www.example.com
.                 518400  IN  NS  a.root-servers.net.
...
com.              172800  IN  NS  a.gtld-servers.net.
...
example.com.      172800  IN  NS  ns1.dns-provider.example.
example.com.      172800  IN  NS  ns2.dns-provider.example.
...
example.com.      300     IN  SOA ns1.dns-provider.example. hostmaster.example.com. 2026100701 7200 3600 1209600 300
;; Received 105 bytes from 192.0.2.53#53(ns1.dns-provider.example) in 24 ms

.com 서버에서 example.com. NS 위임(referral)을 받지 못한다면 문제는 레지스트리에 있습니다. 위임은 받았는데 네임서버가 시간 초과나 거부로 응답한다면 위임이 깨진 것입니다. 내 네임서버가 SOA로 답한다면 레코드가 없는 것입니다.

도메인을 운영하는 쪽의 원인

도메인이 TLD zone에 없음: hold, 만료, 삭제

RDAP 조회나 whois example.com | grep -i status로 레지스트리 상태를 확인하세요. 도메인을 DNS에서 빼 버리는 상태는 다음과 같습니다.

  • clientHold: 등록대행사가 건 상태입니다. 갱신 미결제, 악용 신고, 그리고 등록자 이메일을 인증하지 않은 경우가 흔합니다. ICANN은 gTLD 도메인에 대해 등록대행사가 연락처를 확인하고, 확인되지 않으면 도메인을 정지하도록 요구합니다. 등록자 연락처 메일함에서 인증 메일을 찾아보세요.
  • serverHold: 레지스트리가 건 상태로, 대개 법적·악용·정책 사유입니다. 이유는 등록대행사를 통해서만 알 수 있습니다.
  • redemptionPeriod, pendingDelete: 도메인이 만료되고 등록대행사의 유예 기간도 지났습니다. zone에서 빠진 상태이며, redemption 기간에는 대개 수수료를 내고 복구할 수 있습니다.
  • inactive: 레지스트리에 네임서버가 하나도 등록돼 있지 않습니다.

레지스트리가 따르는 EPP 규칙상 hold가 걸린 도메인은 zone에 게시되지 않으므로, 그 아래 모든 이름이 TLD 서버에서 NXDOMAIN을 받습니다. 막 만료된 도메인은 다르게 보이는 경우가 많습니다. 많은 등록대행사가 자기 주차(parking) 네임서버로 돌려놓기 때문에 방문자는 오류 대신 광고 페이지를 보게 됩니다.

해결은 등록대행사에서 합니다. 갱신하거나, 연락처를 인증하거나, hold의 원인을 해소하세요. 레지스트리가 위임을 다시 게시해도, TLD의 NXDOMAIN을 캐시한 리졸버는 TLD의 negative cache 시간 동안 그 답을 유지합니다. SOA 레코드의 TTL과 마지막 필드 중 작은 값이고, 위 .com 예에서는 900초입니다. 내 TLD는 dig com SOA(또는 kr, net 등)로 확인하세요.

실제로 쓰이지 않는 zone을 수정함

레코드는 “있는데” 조회가 안 되는 가장 흔한 이유입니다. 도메인의 네임서버는 다른 공급자를 가리키는데 엉뚱한 대시보드에 레코드를 추가한 것입니다. 등록대행사는 대개 자체 DNS 관리 화면을 주는데, 도메인을 Cloudflare나 Route 53 같은 곳에 위임한 순간부터 그 화면은 아무 효과가 없습니다.

dig +short NS example.com

여기 나오는 이름이 변경 작업을 한 공급자의 것이 아니라면 원인을 찾은 것입니다. 그 네임서버의 공급자에서 수정하거나, 네임서버를 바꾸세요. 레지스트리가 보는 값과 네임서버 각각의 응답을 비교하는 방법은 네임서버 불일치 가이드에 있습니다.

레코드가 다른 이름으로 만들어짐

어떤 DNS 관리 화면은 입력한 이름 뒤에 zone 이름을 자동으로 붙입니다. 이름 칸에 www.example.com을 넣으면 www.example.com.example.com이 만들어집니다. 겹친 이름을 조회해 보세요.

dig +short www.example.com.example.com

여기서 내 IP가 나온다면 레코드를 지우고 www만(루트는 @) 넣어 다시 만드세요. zone 파일에서는 끝의 점을 빠뜨리는 것이 같은 실수입니다. shop CNAME stores.example.net처럼 마지막 .이 없으면 stores.example.net.example.com.이 됩니다.

사람들이 실제로 입력하는 이름을 만들었는지도 보세요. www.example.com에만 사이트를 만들었다면, 루트 도메인에 레코드가 하나도 없을 때 example.com은 NXDOMAIN, MX와 TXT만 있을 때는 NODATA가 됩니다. 둘 다 만들고 한쪽을 다른 쪽으로 리다이렉트하세요.

CNAME이 삭제된 대상을 가리킴

$ dig shop.example.com A

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 18822

;; ANSWER SECTION:
shop.example.com.   3600   IN   CNAME   example-store.old-platform.example.

;; AUTHORITY SECTION:
old-platform.example.   900   IN   SOA   ns.old-platform.example. dns.old-platform.example. 2026090101 3600 600 604800 900

내 레코드는 있는데 그것이 가리키는 이름이 없습니다. 응답은 CNAME 체인 전체에 대해 NXDOMAIN을 돌려주고, SOA는 내 zone이 아니라 대상 쪽 zone의 것입니다. 호스팅 플랫폼의 쇼핑몰, 앱, 스토리지 버킷을 지우면서 CNAME은 남겨 둘 때 생깁니다.

CNAME을 올바른 대상으로 바꾸거나 지우세요. 그대로 두면 안 됩니다. 같은 플랫폼에서 다른 사람이 그 이름으로 리소스를 만들 수 있다면 내 서브도메인을 가져가게 됩니다. 이것이 서브도메인 탈취(subdomain takeover)이고, 주인 없는 CNAME이 보통 그 출발점입니다.

새 레코드인데 NXDOMAIN이 캐시됨

newapp.example.com을 만들었고 내 노트북에서는 되는데 동료 PC는 그런 이름이 없다고 합니다. 레코드가 생기기 전에 누군가, 흔히 모니터링 점검이나 인증서 발급 요청이 그 이름을 조회했고 리졸버가 NXDOMAIN을 캐시한 것입니다.

캐시를 거치지 않고 내 네임서버에 직접 물어 레코드가 게시됐는지 확인하세요.

dig @ns1.dns-provider.example newapp.example.com A +norecurse +noall +answer

권한 서버가 답한다면 레코드는 정상이고 negative cache가 만료되기를 기다리는 중입니다. 얼마나 걸리는지는 SOA에 있고, 계산 방법은 DNS 전파 가이드와 TTL 가이드에 설명돼 있습니다. Cloudflare와 Google은 각각 1.1.1.1과 8.8.8.8의 캐시에서 이름을 지우는 페이지를 제공하므로, 그 두 리졸버 사용자에게는 도움이 됩니다. 다음부터는 이름에 무언가를 연결하기 전에 레코드부터 만드세요.

위임이 깨짐(대개 SERVFAIL, 오류 화면은 같음)

도메인을 등록했거나 네임서버를 바꾼 뒤, 레지스트리에 등록된 서버가 실제로는 zone을 서비스하지 않는 경우가 있습니다. 새 공급자에 zone을 만들지 않았거나, 네임서버 이름에 오타가 있거나, 이전 공급자가 zone을 너무 일찍 지운 경우입니다. 그 서버들은 REFUSED로 답하거나 아예 답하지 않고, 리졸버는 SERVFAIL을 돌려줍니다.

DNSSEC 불일치도 SERVFAIL을 냅니다. 대개 이전 공급자 시절의 DS 레코드가 레지스트리에 남아 있는 경우인데, 1.1.1.1이나 8.8.8.8처럼 검증하는 리졸버에서만 실패합니다. dig @1.1.1.1 example.com A와 같은 조회에 +cd(검증 끄기)를 붙인 결과를 비교하세요. +cd에서만 답이 나온다면 DNSSEC 문제입니다. 두 경우 모두 네임서버 불일치 가이드에서 다룹니다.

내부 네트워크에만 있는 이름

intranet.corp.example.com 같은 이름은 내부 DNS 서버에만 있는 경우가 많습니다. 바깥에서나 VPN을 끊은 상태에서는 원래 NXDOMAIN입니다. 회사에서는 되고 집에서는 안 된다면 이것부터 확인하세요.

내 기기나 네트워크 쪽 원인

공개 리졸버는 이름을 찾는데 내 기기만 못 찾는다면 도메인은 정상입니다. 가능성이 높은 순서대로 보면 이렇습니다.

캐시된 ‘없음’ 응답. 사이트가 실제로 잠깐 안 되던 순간의 NXDOMAIN을 운영체제나 브라우저가 캐시했을 수 있습니다. 비우세요.

# Windows
ipconfig /flushdns

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

# Linux (systemd-resolved)
resolvectl flush-caches

크롬은 자체 캐시가 따로 있습니다. chrome://net-internals/#dns에서 “Clear host cache”를 누르세요.

VPN이나 회사 DNS. VPN은 보통 자기 리졸버를 밀어 넣습니다. 내부 이름은 연결돼 있을 때만 조회되고, 어떤 VPN 리졸버는 공개 이름을 제대로 처리하지 못하거나 연결을 끊은 뒤에도 계속 쓰이기도 합니다. 완전히 끊고, 캐시를 비우고, 다시 시도하세요.

크롬의 보안 DNS. 크롬 설정의 개인정보 및 보안 → 보안에 있는 “보안 DNS 사용”은 네트워크 리졸버 대신 내가 고른 공급자로 조회를 보낼 수 있습니다. 그러면 내부 이름이나 split-horizon 이름이 크롬에서만 NXDOMAIN이 되고, 같은 PC의 nslookup은 정상으로 나옵니다. 현재 서비스 제공업체를 쓰도록 되돌린 뒤 비교해 보세요.

필터링 리졸버. 차단한 이름에 NXDOMAIN으로 답하는 리졸버가 있습니다. Quad9은 위협 목록에 있는 도메인에 그렇게 하고, Pi-hole, AdGuard Home, NextDNS, 유해 사이트 차단 서비스, 통신사 차단도 설정에 따라 그렇습니다. nslookup example.com 1.1.1.1은 되는데 nslookup example.com(기본 리졸버)이 “Non-existent domain”이라면 내 리졸버가 막고 있거나 고장 난 것입니다. 차단 로그를 보거나 네트워크 설정에서 DNS 서버를 바꾸세요.

hosts 파일, 반대 방향으로. hosts 항목은 NXDOMAIN을 만들 수 없습니다. 이름을 조회되게 만드는 쪽입니다. 대신 정반대의 불만, “나는 되는데 방문자는 NXDOMAIN”을 설명해 줍니다. 이전 작업을 테스트하면서 /etc/hosts나 C:\Windows\System32\drivers\etc\hosts에 이름을 넣고 잊어버린 경우입니다. 내 브라우저 결과를 믿기 전에 그 줄을 지우세요.

고친 다음에

NXDOMAIN이 얼마나 빨리 사라지는지는 어디에 캐시됐느냐에 달려 있습니다.

  • 내 zone에 레코드를 추가하거나 고친 경우: NXDOMAIN을 캐시한 리졸버에서 최대 내 zone의 negative cache 시간.
  • 도메인이 TLD zone에 돌아온 경우(hold 해제, 신규 등록, redemption 복구): 최대 TLD의 negative cache 시간, 그 뒤로는 정상 조회.
  • 네임서버를 바꾼 경우: 이전 위임을 캐시한 리졸버는 위임 TTL 동안 그것을 유지합니다. .com은 48시간입니다. 자세한 내용은 전파 가이드에 있습니다.

전파 점검은 대형 공개 리졸버 여섯 곳에 동시에 물어보므로, NXDOMAIN에서 정상 응답으로 바뀌는 과정을 지켜볼 수 있습니다. 레코드가 보이기 시작하면 DNS 조회로 레코드와 TTL을 확인하세요.

관련 가이드

내 도메인에서 바로 확인

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