네임서버 변경 반영 확인 도구

네임서버 변경이 반영됐는지 확인하는 방법

세 단계, 모두 이 페이지 안에서 끝납니다. 브라우저에서 HTTPS로 공개 DNS와 레지스트리 RDAP를 읽을 뿐이라 도메인 구입처 계정에는 손대지 않고, 설치나 가입도 없습니다.

1. 도메인을 넣습니다. 도메인, 호스트명, URL 중 무엇이든 넣고 [위임 확인하기]를 누릅니다. 페이지는 레지스트리 자신의 기록을 RDAP로 읽고(.kr·.한국이면 KISA), 동시에 dns.google과 cloudflare-dns에 NS·SOA·A·AAAA·MX·TXT를 묻습니다 — 레지스트리의 현재 답과 서로 독립된 캐시 두 개를 나란히 놓는 셈입니다.
2. 위임 줄을 먼저 읽습니다. 상태는 셋 중 하나입니다. NOERROR와 네임서버가 오면 위임은 멀쩡하고 캐시를 기다리는 중입니다. NXDOMAIN이면 상위 존에 내 위임이 없어서 기다려도 달라지지 않습니다. SERVFAIL이면 위임은 있지만 그 뒤의 네임서버가 존을 내주지 않고 있습니다.
3. 그다음 레지스트리와 리졸버를 비교합니다. 레지스트리에 이미 새 네임서버가 있는데 리졸버가 아직 옛 값을 돌려준다면, 그 리졸버가 캐시 사본을 들고 있는 것입니다 — 이것이 전파이고 저절로 끝납니다. 레지스트리 자체에 아직 옛 네임서버가 있다면 진행 중인 것은 없습니다. 변경이 레지스트리에 닿지 않았으니 기다려도 소용없습니다. RDAP가 없는 TLD라면 대신 두 리졸버를 비교하세요.

답은 둘이 아니라 셋: NOERROR, NXDOMAIN, SERVFAIL

이 주제의 안내는 대부분 세상을 두 칸으로 나눕니다. 된다, 아니면 아직 전파 중이다. 그 구분이 틀린 탓에, 저절로는 절대 낫지 않을 상태를 사흘씩 기다리는 일이 생깁니다. 도메인에 NS를 물었을 때 답은 둘이 아니라 셋입니다: NOERROR + NS 레코드 = 위임이 살아 있고 캐시 만료를 기다리는 중, NXDOMAIN = 상위 존에 내 도메인의 위임이 없음, SERVFAIL = 위임은 있지만 권한 네임서버가 아무도 답하지 않음.

도구는 앞의 두 경우를 확실히 가르는 SOA도 읽습니다. 건강한 존은 SOA 질의에 자기 SOA로 답합니다 — 루트에서 TLD를 거쳐 내 네임서버까지 사슬이 이어졌다는 증거입니다. 위임이 없는 도메인은 NXDOMAIN과 함께 authority 섹션에 상위 존의 SOA를 넣어 보냅니다. 레지스트리 존이 "당신 것은 없다"고 말하는 셈입니다. .co.kr 도메인이라면 거부하는 쪽은 kr이 아니라 co.kr 존입니다 — co.kr은 kr 안에 따로 나뉜, 자기 SOA를 가진 존입니다(2026년 9월 26일 dig로 확인). 브라우저에서는 이 모두가 "안 열리는 페이지"일 뿐이고, KISA의 DNS FAQ도 서명 검증 실패로 캐시 DNS서버가 SERVFAIL을 낼 때 일반 웹 브라우저로는 장애인지 검증 실패인지 알 수 없다고 적고 있습니다. 응답 코드를 직접 읽어야 하는 이유입니다.

「DNS 전파」의 정체: 캐시가 하나씩 만료될 뿐입니다

가비아는 네임서버를 바꾼 뒤 기다리는 시간을 「DNS 전파 시간」이라 부르고, 후이즈는 「네임서버정보 동기화」라고 씁니다. 실제로는 아무것도 전파되거나 동기화되지 않습니다. 네임서버를 바꾸면 레지스트리가 새 위임을 기록하고, 관련된 권한 서버는 그 순간부터 새 답을 갖습니다. 시간이 걸리는 것은 반대쪽입니다. 이미 물어본 캐시 DNS가 옛 답을 TTL이 끝날 때까지 들고 있는 것 — 전파란 캐시들이 각자의 시계에 따라 하나씩 만료되는 과정입니다.

카페24 도움말이 이 기간에 "지역/회선별로 캐시가 달라" 접속이 안 되거나 이전 화면이 보일 수 있다고 쓰는 것이 정확한 묘사입니다. KT·SK브로드밴드·LG유플러스 회선의 캐시 DNS는 각자 따로 캐시를 들고 있고, 이 페이지가 묻는 구글·클라우드플레어와도 별개입니다. 내 PC에서는 새 사이트가 뜨는데 고객 휴대폰에서는 옛 사이트가 뜨는 일이 그래서 생깁니다.

도구는 전설 대신 숫자를 줍니다. 모든 답에 그 리졸버가 들고 있는 사본의 남은 TTL이 붙습니다 — 그 캐시가 옛 답을 돌려줄 수 있는 남은 시간 그대로입니다. 두 리졸버가 서로 다른 네임서버를 돌려주면 그것이 전파의 실제 모습입니다. 두 리졸버가 내가 설정하지 않은 값에 똑같이 동의한다면 그것은 전파가 아니라 변경이 레지스트리에 닿지 않은 것이고, 기다릴 게 아니라 도메인 구입처로 돌아가야 합니다.

출력 맨 위의 레지스트리 행은 대부분의 TLD에서 이것을 추측 없이 판정합니다. RDAP — gTLD에서 WHOIS를 대체한 등록정보 프로토콜 — 는 레지스트리가 지금 가진 네임서버를 HTTPS로 돌려주고, RFC 7480은 RDAP 서버가 공개 기록을 브라우저가 읽도록 열어 두기를 권합니다. 레지스트리에 이미 새 네임서버가 있으면 캐시를 기다리는 중이고, 아직 옛 네임서버가 있으면 변경이 들어가지 않은 것입니다. Verisign(.com, .net), Google Registry(.app, .dev), Identity Digital(.ai, .info), PIR(.org), AFNIC(.fr), registro.br, TWNIC(.tw), KISA(.kr·.한국)가 이렇게 답하고, .de·.jp·.es·.it·.io처럼 브라우저가 읽을 RDAP가 없는 곳에서는 이 행이 비며 페이지도 추측 대신 그렇다고 말합니다.

반영 시간이 10분이기도, 24시간이기도, 48시간이기도 한 이유

같은 질문에 국내 업체들의 답은 제각각입니다. 호스팅케이알 도움말은 한 글에서 "국내 도메인은 10분 내외, 국제 도메인은 약1~2일", 다른 글에서 "약 24시간 내외"라고 하고, 카페24는 약 24시간(접속 안내에서는 24~48시간), 가비아는 최대 48시간, 후이즈는 최대 24시간을 말합니다. 모두 틀린 말은 아닙니다. 세 숫자는 서로 다른 층의 시간으로 읽어야 맞고, 「반영 시간」이라는 한 단어가 그 층들을 덮고 있을 뿐입니다. 아래는 2026년 9월 26일 .kr 권한 서버(c.dns.kr, d.dns.kr)와 .com 권한 서버에 dig로 직접 물어 읽은 값입니다.

$ dig @c.dns.kr NS naver.co.kr +norec +noall +authority
      naver.co.kr.  86400  IN  NS  ns1.naver.com.
      naver.co.kr.  86400  IN  NS  ns2.naver.com.
      $ dig @c.dns.kr A zzz-nx-test.co.kr +noall +authority
      co.kr.  900  IN  SOA  g.dns.kr. domain-manager.nic.or.kr. ... 3600 900 604800 900
      $ dig @c.dns.kr SOA kr +short      # 세 번째 값(시리얼)이 몇 분 사이에 바뀝니다

레지스트리 층은 빠릅니다. 옛 위임을 캐시한 적이 없는 리졸버는 KISA가 존을 다시 게시한 직후부터 새 네임서버를 따라갑니다 — 「10분이면 된다」는 말이 맞는 것은 이런 리졸버입니다. 옛 위임을 이미 든 리졸버는 그 사본이 만료될 때까지 옛 네임서버에 묻고, 레지스트리 쪽 위임 TTL로 보면 그 기간이 .kr은 24시간, .com은 48시간입니다.

예외도 하나 있습니다. 리졸버가 도메인 자신의 존에서 NS 레코드를 받아 캐시하면, 레지스트리가 아니라 그 존이 붙인 TTL이 기준이 됩니다. 같은 날 coupang.co.kr의 존(AWS Route 53)은 NS에 172800초를, lg.co.kr의 존은 28800초를 붙이고 있었고, 1.1.1.1은 coupang.co.kr의 NS를 남은 TTL 172442초로 들고 있었습니다. 옛 DNS 업체의 NS TTL이 길면 .co.kr에서도 48시간을 볼 수 있고, 도구의 남은 TTL이 하루보다 길게 찍혀도 이상한 일이 아닙니다.

결국 기다릴 시간을 정하는 것은 달력이 아니라 두 가지입니다. 레지스트리 행에 새 네임서버가 있는가, 그리고 리졸버가 든 사본의 남은 TTL. 둘 다 위의 도구가 보여 줍니다. 다음 이전을 위해 TTL을 미리 낮춰 두는 순서는 DNS TTL 계산기로 계산할 수 있습니다.

KISA 레지스트리 행 읽는 법: RDAP와 후이즈검색

.kr과 .한국의 레지스트리인 KISA는 RDAP를 rdap.nic.or.kr에서 공개하고, IANA의 RDAP 부트스트랩 파일에도 kr과 한국(xn--3e0b707e) 모두 이 주소로 올라가 있습니다. 2026년 9월 26일 확인했을 때 응답에 Access-Control-Allow-Origin: *가 붙어 있어 브라우저가 그대로 읽을 수 있었고, .co.kr·.or.kr과 한글 .한국 도메인도 같은 주소에서 답했습니다. 등록되지 않은 이름은 404로 답해 도구에 「레지스트리에 없는 도메인」으로 나옵니다. 응답마다 last update of RDAP database가 조회한 그 시각으로 찍혀 나왔습니다 — 레지스트리 행은 어제의 사본이 아니라 조회 시점의 KISA 기록입니다.

같은 기록은 KISA 후이즈검색(whois.kr)과 터미널의 whois -h whois.kr로도 볼 수 있습니다. 표시 이름이 다를 뿐 같은 필드입니다.

마지막 줄은 실제로 헷갈립니다. naver.co.kr의 RDAP 만료 시각은 2027-10-14T15:00:00Z, 한국 시간으로 2027년 10월 15일 0시입니다. 후이즈검색은 사용 종료일을 2027. 10. 15.로, 이 도구는 날짜 부분만 잘라 2027-10-14로 보여 줍니다. 하루 차이는 오류가 아니라 시간대 차이입니다.

호스트 등록. 네임서버를 내 도메인 아래(ns1.내도메인.co.kr 같은 이름)에서 직접 운영한다면, 그 이름과 IP를 먼저 레지스트리에 등록해야 네임서버로 지정했을 때 제대로 인식됩니다. 메뉴 이름은 업체마다 다릅니다 — 카페24는 「네임서버 호스트 관리」, 후이즈는 「DNS 호스트 관리」, 호스팅케이알은 「호스트 등록」입니다. KISA 후이즈 결과가 .kr 이름의 네임서버에만 IP를 보여 주는 것("네임서버 이름이 .kr이 아닌 경우는 IP주소가 보이지 않습니다")도 그 때문입니다. 등록 후 적용까지 카페24는 24~48시간, 호스팅케이알은 약 2~3일이 걸릴 수 있다고 안내합니다.

네거티브 캐시: 고친 위임이 계속 NXDOMAIN을 내는 이유

가장 고약한 경우는 문제를 고쳤는데 아무 일도 일어나지 않는 경우입니다. 위임을 고친 뒤에도, 네거티브 캐시 TTL — SOA의 minimum — 동안은 NXDOMAIN이 계속 돌아올 수 있습니다. 리졸버는 "이 이름은 없다"는 사실도 주소처럼 캐시합니다. RFC 2308은 그 기억의 수명을 SOA의 minimum 필드와 SOA 레코드 자신의 TTL 중 작은 값으로 정하고, 그래서 도구는 이것을 숫자 하나로 보여 줍니다. 2026년 9월 26일 실측으로 kr.·co.kr.·or.kr.·한국. 모두 900초(15분), com.도 900초, 루트는 하루(86400초)였습니다.

우리 도메인에서 실제로 겪은 일입니다. 2026년 6월, .app 도메인 네 개가 레지스트리의 위임을 잃고 약 나흘 동안 전 세계에서 NXDOMAIN을 냈습니다. 레지스트라가 6월 30일 17:30 UTC에 위임을 되돌려 놓았지만, 그날 저녁 인터넷 대부분에서는 여전히 도메인이 돌아오지 않았습니다. 장애 중에 물어봤던 리졸버들이 아직 네거티브 캐시 창 안에 있었기 때문입니다. 그 내내 대시보드 두 개는 모든 게 정상이라고 했습니다. Cloudflare 존은 active, 레지스트라 화면의 상태 칸은 verified. 참이었던 신호는 두 독립 리졸버로 읽은 공개 권한 DNS뿐이었습니다. 그래서 네 층짜리 도메인 건강 검사는 어느 업체의 상태 칸이 아니라 레지스트리 층에서 시작합니다(전체 경위는 레지스트라가 우리 네임서버를 잃어버린 날, 모두 영어).

실무적으로는 이렇습니다. .kr 도메인에서 도구가 NXDOMAIN과 네거티브 캐시 900초를 보여 준다면, 위임을 고친 뒤 15분은 기다린 다음에 "안 고쳐졌다"고 판단하세요. 그 사이에 두 번째로 "고치지" 마세요.

네임서버 변경 뒤 실제로 망가지는 것

아래 열 가지가 거의 전부입니다. 위임 상태가 어느 갈래인지 알려 주면, 여기서 무엇을 보러 갈지 고르면 됩니다. 앞의 세 가지는 변경이 레지스트리에 닿지도 않은 경우라, 레지스트리 행이 옛 네임서버를 보여 줍니다.

1. 소유자 인증을 끝내지 않았다. 국내 업체는 네임서버 변경에 등록인 인증을 붙입니다. 가비아는 값을 입력한 뒤 [소유자 인증](등록된 이메일 또는 휴대폰)을 거쳐야 [확인]으로 넘어가고, 카페24는 본인인증을 마친 뒤에만 변경할 수 있으며, 호스팅케이알은 .kr·.한국 도메인에 소유자 이메일·휴대폰 인증을 요구합니다. 인증 창을 닫고 나왔다면 변경은 제출되지 않은 것입니다. 증상: 레지스트리 행에 여전히 옛 네임서버.
2. 등록대행자가 변경을 받고도 레지스트리에 넘기지 못했다. 화면에는 저장됐다고 나오는데 공개 인터넷은 옛 값을 돌려줍니다. 카페24는 「변경 실패」의 두 가지 원인으로 현재와 같은 네임서버를 다시 넣은 경우와 값 끝에 점(.)을 붙인 경우를 듭니다. 증상: 레지스트리 행에 옛 네임서버(RDAP가 없는 TLD라면 두 리졸버가 옛 값에 동의).
3. 잠금이 변경을 거부했다. client update prohibited는 레지스트리에 도메인 정보 변경을 거부하라는 표시이고, server update prohibited는 같은 잠금의 레지스트리 쪽 판입니다. KISA는 이것을 「도메인 정보보호 설정」으로 운영합니다. server…Prohibited는 KISA 후이즈검색에서, client…Prohibited는 등록대행자를 통해 걸고, 보호가 걸려 있으면 등록인이 휴대폰·이메일 인증으로 해지해야 네임서버를 바꿀 수 있습니다. 레지스트리 행에서 옛 네임서버 옆에 이 상태가 보이면 잠금이 첫 번째 용의자입니다.
4. 새 네임서버에 존을 만들지 않았다. 위임이 가리키는 서버가 내 도메인을 모르니 답하지 못합니다. 증상: 두 리졸버 모두 SERVFAIL. 존을 먼저 만들고 위임을 나중에 바꾸세요 — 순서가 전부입니다.
5. DNSSEC를 켠 채 옮겼다. 상위 존의 DS가 여전히 옛 업체의 키를 가리키니, 검증하는 리졸버는 새 업체의 답을 모두 거부합니다. 증상: 어디서나 SERVFAIL인데 새 네임서버에 직접 물으면 멀쩡히 답함. 후이즈검색의 「DNSSEC : 서명」이 이 경우입니다. 도메인 구입처에서 DS를 지우고, 그 TTL을 기다린 뒤, 새 쪽에서 DNSSEC를 다시 켜세요.
6. 레코드를 옮기지 않았다. 위임도 정상, 존도 살아 있는데 사람들이 실제로 치는 호스트명에 A·AAAA가 없습니다. 카페24는 네임서버를 바꾸면 "기존에 설정된 DNS 레코드 값이 초기화"될 수 있다고 경고합니다. 증상: 위임은 정상인데 주소 행이 비어 있음. "변경은 잘 됐는데 사이트가 안 나온다"의 가장 흔한 이유입니다.
7. MX·SPF·DKIM·DMARC를 잊었다. 메일은 웹사이트보다 조용히, 그리고 늦게 망가집니다. 보내는 쪽 서버가 며칠씩 재시도하니 반송을 알아채는 게 늦어집니다. 주소 행만이 아니라 MX와 TXT 행도 보세요. 에이전트가 쓰는 받은편지함(영어)이 이 도메인에 있다면 같은 순간에 조용해집니다.
8. 새 존의 NS 목록이 레지스트리와 다르다. KISA의 DNS 점검 가이드도 「위임 네임서버와 존 설정 네임서버 목록 일치」를 점검 항목으로 둡니다. 증상: 레지스트리 행에는 새 네임서버가 있는데, 남은 TTL이 지난 뒤에도 리졸버가 다른 목록을 돌려줌. 존 안의 NS 레코드를 레지스트리와 맞추세요.
9. 그저 오래되고 긴 TTL 안에 있다. 아무것도 잘못되지 않았습니다. 옛 레코드가 긴 수명으로 게시됐고 일부 캐시가 아직 들고 있을 뿐입니다. 위의 남은 TTL이 카운트다운입니다.
10. 옮기는 사이에 도메인이 만료됐거나 TLD 존에서 빠졌다. 아무도 찾지 않는 경우입니다. 브라우저에서는 구별이 안 되고, DNS 응답에서는 놓칠 수가 없습니다. 증상: NXDOMAIN과 authority 섹션의 상위 존 SOA, 그리고 레지스트리 행의 client hold·server hold·redemption period 같은 상태. 갱신하거나 복구하거나 등록대행자와 이야기하세요 — 기다리는 것은 아무 소용이 없습니다.

터미널에서 같은 확인을 하려면

여기 있는 것은 모두 공개된 것입니다. 이 페이지는 공개 리졸버 두 곳과 레지스트리 RDAP를 편하게 묶었을 뿐이고, 출력의 모든 줄은 dig와 curl로 재현됩니다. 도구는 입력한 도메인에 맞춘 명령을 직접 찍어 주고, .kr 도메인이라면 다음 줄들이 요긴합니다.

dig NS example.co.kr +short                # 위임이 무엇으로 풀리는지
      dig @8.8.8.8 NS example.co.kr +short       # 특정 캐시 하나에
      dig @1.1.1.1 NS example.co.kr +short       # 다른 캐시에 — 두 답이 다르면 전파 중
      dig @c.dns.kr NS example.co.kr +norec      # .kr 권한 서버에 직접: KISA가 지금 게시한 위임
      dig SOA example.co.kr                      # NXDOMAIN이면 authority 섹션이 거부한 존을 알려 줌
      curl -s https://rdap.nic.or.kr/domain/example.co.kr   # KISA 레지스트리 기록: NS·상태·DNSSEC
      whois -h whois.kr example.co.kr            # KISA 후이즈: 1차·2차 네임서버, 등록정보 보호

dig @c.dns.kr 줄은 브라우저로는 할 수 없는 확인입니다. 캐시를 거치지 않고 레지스트리가 지금 존에 올린 위임을 그대로 읽습니다. 여기에 새 네임서버가 나오면 KISA 쪽 일은 끝났고, 남은 것은 캐시뿐입니다. 사슬 전체를 보려면 dig +trace NS example.co.kr 명령이 루트에서 TLD를 거쳐 내 네임서버까지 위임을 하나씩 따라가며 어느 단계에서 끊기는지 보여 줍니다.

Windows라면 명령 프롬프트의 nslookup으로 같은 질문을 할 수 있습니다. 끝에 붙이는 주소가 물어볼 캐시 DNS입니다. 아래 세 주소는 KISA의 IP 주소 WHOIS에서 각각 KT, SK브로드밴드, LG유플러스에 할당된 것으로 나오고, 2026년 9월 26일 모두 우리 질의에 답했습니다.

nslookup -type=ns example.co.kr 8.8.8.8          # Google
      nslookup -type=ns example.co.kr 168.126.63.1     # KT
      nslookup -type=ns example.co.kr 219.250.36.130   # SK브로드밴드
      nslookup -type=ns example.co.kr 164.124.101.2    # LG유플러스

이 페이지가 실제로 보내는 요청은 이것이고, dig가 없는 환경에서도 돌아갑니다. 응답 JSON의 Status가 RCODE(0 NOERROR, 2 SERVFAIL, 3 NXDOMAIN)이고, 거부된 경우 Authority에 그 거부를 낸 존의 SOA가 들어 있습니다.

curl -s -H 'accept: application/dns-json' 'https://dns.google/resolve?name=example.co.kr&type=NS'

브라우저가 볼 수 없는 것, 그리고 CLI가 더 보는 것

이 페이지의 경계도 분명히 해 둡니다. 브라우저는 HTTPS로 재귀 리졸버와, 대부분의 TLD에서는 레지스트리의 RDAP와 이야기할 수 있습니다. 그래서 세 가지를 읽습니다. 레지스트리가 가진 것, 위임 사슬이 풀리는지, 존이 무엇을 답하는지. TLD의 네임서버(c.dns.kr 같은)에 직접 묻지는 못하고, 도메인 구입처의 계정이나 소유자 인증을 기다리는 변경도 볼 수 없으며, 브라우저가 읽을 RDAP가 없는 TLD에서는 레지스트리를 아예 볼 수 없습니다. 공개 DNS의 위아래도 보지 못합니다 — 사이트 앞의 프록시, 아직 발급되지 않은 인증서, 만들어지지 않은 호스팅 연결, 502를 돌려주는 원본 서버. 모두 "네임서버를 바꿨더니 사이트가 죽었다"처럼 느껴지지만, 어느 것도 DNS 문제가 아닙니다.

clize domain check <domain> 명령은 같은 첫 층 위에 세 층을 더 얹은 것입니다. 똑같은 두 리졸버 DoH 확인 — dns.google 먼저, cloudflare-dns는 대비용, RCODE를 세 상태로 읽기 — 을 돌린 뒤 Cloudflare 존, 호스트명이 사이트 워커에 연결됐는지, 사이트 내용이 실제로 서빙되는지를 확인합니다. 네 층, 명령 하나라서 초록불은 "위임됨"이 아니라 "접속됨"을 뜻합니다. 도메인 인자 없이 실행하면 계정의 모든 도메인을 훑습니다. 플랫폼도 정해진 주기로 확인합니다. 30분마다 cron이 돌고, 두 번 연속 실패했을 때만 알림 메일을 보내서 DoH 응답이 한 번 흔들린 것으로 아무도 깨우지 않습니다.

이 확인은 앞에서 말한 6월 장애에서 나왔습니다 — 사고 뒤에 나온 수정이고, 배포할 때마다 도는 위임 확인도 함께 생겼습니다. 나머지가 궁금하다면 Agent Domains가 CLI로 도메인을 사고·가져오고·연결하는 법을, 명령 레퍼런스가 CLI의 모든 명령을 다룹니다(모두 영어). 도메인 위에 올라가는 사이트를 배포하는 것은 별도의 명령이자 별도의 층입니다 — 건강 검사가 그것을 따로 보고하는 이유가 바로 그것입니다.

$ npm i -g @clize/clize && clize install
$ clize domain check example.co.kr