네임서버 조회 — 도메인 네임서버 확인

네임서버 조회로 모든 도메인의 네임서버를 확인하세요: 레지스트리가 알려 주는 NS 레코드를 글루와 TTL까지, 각 네임서버가 스스로 말하는 내용과 나란히 보여 줍니다. 도메인 네임서버 확인 중 lame 서버, 불일치, 오래된 글루가 있으면 해결 방법과 함께 알려 드립니다.

업데이트: 2026년 10월 23일

출처: 루트 서버에서 찾아간 레지스트리의 서버 · 각 네임서버의 IPv4 주소에 직접 질의 · Google Public DNS · Cloudflare 1.1.1.1 · Team Cymru · RDAP

레지스트리에 먼저 묻고, 레지스트리가 알려 준 모든 네임서버에 차례로 묻습니다. URL, 이메일 주소, 서브도메인도 입력할 수 있습니다.

예시

NS 레코드란?

NS 레코드는 존, 즉 도메인의 레코드가 있는 곳을 가진 서버를 지정합니다. 존에는 서버마다 NS 레코드가 하나씩 있으므로 google.com에는 ns1부터 ns4.google.com까지 4개가 있습니다(RFC 1035 §3.3.11).

같은 NS 레코드가 두 곳에 존재합니다. 상위 존(여기서는 .com)은 위임 지점에 사본을 두어 리졸버를 다음으로 보내는데, 이 사본은 권한 있는 응답이 아닙니다. 존은 자기 최상단에 자체 사본을 두며, 이쪽이 권한 있는 응답입니다(RFC 1034 §4.2.1, RFC 2181 §6.1). 둘은 완전히 같아야 합니다.

값은 언제나 호스트 이름이며 주소도, 별칭도 될 수 없습니다: 그 이름에는 자체 A 또는 AAAA 레코드가 있어야 합니다(RFC 2181 §10.3).

NS 레코드의 구조google.com · 2026-10-23 기록

google.com.소유자345600TTLIN클래스NS유형ns1.google.com.값

소유자이 레코드가 속한 존입니다.

TTL · 4일리졸버가 보관할 수 있는 시간입니다. .com 사본은 2일입니다.

NS레코드 유형 2: 이 존의 네임서버입니다.

값자체 A 또는 AAAA 레코드가 있는 호스트 이름입니다.

상위의 사본 · .comgoogle.com. 172800 NS ns1.google.com.ns1.google.com. 172800 A 216.239.32.10권한 없음: 글루가 있는 위임 응답

존 자체의 사본google.com. 345600 NS ns1.google.com.;; flags: qr aa권한 있음: 리졸버가 보관하는 것

ns1.google.com.자체 주소가 있는 호스트 이름

~~216.239.32.10~~주소는 유효한 값이 아님

~~ns.example.com. → CNAME~~별칭은 안 됨(RFC 2181 §10.3)

두 사본을 모두 실시간으로 기록했습니다: l.gtld-servers.net에서 받은 .com 레지스트리의 위임 응답과 ns1.google.com 자체의 응답입니다.

도메인 네임서버 확인 방법

위에 도메인을 입력하고 네임서버 조회를 누르세요: 저희가 레지스트리에 묻고, 레지스트리가 알려 준 서버 중 저희 서버가 닿을 수 있는 각 서버에 물어봅니다. 터미널에서는 macOS와 Linux에서 dig NS example.com, Windows에서 nslookup -type=ns example.com, PowerShell에서 Resolve-DnsName -Name example.com -Type NS를 사용합니다.

이 세 명령은 내 리졸버에 묻기 때문에 캐시된 사본이 나옵니다. 레지스트리의 목록을 보려면 재귀를 끄고 레지스트리 서버에 직접 물으세요: dig @a.gtld-servers.net example.com NS +norec. 네임서버 하나를 테스트하려면 +norec로 SOA를 묻고 플래그에서 aa를 찾으세요. whois도 존이 아니라 레지스트리의 목록을 보여 줍니다.

% dig NS example.com +short

내 리졸버의 사본이며 한 줄에 네임서버 하나입니다. .com 레지스트리 자체의 목록을 보려면 @a.gtld-servers.net과 +norec를 추가하세요.

dig의 두 응답 읽는 법google.com · 2026-10-23 기록

dig · macOS, Linux

$ dig @l.gtld-servers.net google.com NS +norec
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 91
;; AUTHORITY SECTION:
google.com.       172800  IN  NS  ns2.google.com.2
google.com.       172800  IN  NS  ns1.google.com.
…
;; ADDITIONAL SECTION:
ns1.google.com.   172800  IN  A   216.239.32.103
…

$ dig @216.239.32.10 google.com NS +norec
;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 04
google.com.       345600  IN  NS  ns1.google.com.5
…

aa 없음: 위임 응답. 레지스트리는 google.com을 직접 서비스하지 않고 어디로 가야 하는지 알려 줍니다.
상위의 목록 과 그 TTL: 2일, .com 레지스트리가 정합니다.
글루: ns1.google.com은 google.com 안에 있으므로 .com이 그 주소를 알려 줍니다.
aa: 존 자체. 서버가 하는 권한 있는 응답입니다.
존 자체의 TTL: 4일, 레지스트리가 아니라 Google이 정합니다.

nslookup · 8.8.8.8에 질의

$ nslookup -type=ns google.com 8.8.8.8
Server:   8.8.8.8
Address:  8.8.8.8#53

Non-authoritative answer:
google.com  nameserver = ns3.google.com.
google.com  nameserver = ns1.google.com.
…

PowerShell

# 내 리졸버의 사본
PS> Resolve-DnsName -Name google.com -Type NS

# 서버 하나, 재귀 꺼짐
PS> Resolve-DnsName -Name google.com -Type SOA -Server ns1.google.com -NoRecursion

whois

$ whois google.com
Registrar: MarkMonitor Inc.
Name Server: NS1.GOOGLE.COM
…
DNSSEC: unsigned

2026-10-23에 기록했습니다. "Non-authoritative answer"는 리졸버의 캐시된 사본이라는 뜻이며, 여기서는 NS 레코드를 최대 6시간까지 보관하는 Google Public DNS의 것입니다. whois는 레지스트리의 목록을 출력합니다. 어느 쪽도 각 서버가 하는 말은 보여 주지 않습니다.

네임서버 조회 결과 읽는 법

판정은 DNS 호스트와 등록대행자를 알려 줍니다. 위임 보기는 레지스트리의 목록을 존의 목록 옆에 서버별로 놓고, 각 서버의 응답과 TCP 응답 시간(연결 설정 포함이므로 왕복 약 두 번 분량)을 보여 줍니다.

남색 열은 리졸버가 가는 경로입니다: 루트, TTL과 DS가 있는 레지스트리, 그다음 각 네임서버. 이 존을 서비스하지 않는 서버는 끊어서 표시합니다.

github.com의 네임서버 조회 결과: NS1과 Route 53의 네임서버 8대, 각 서버의 응답과 .com 레지스트리의 위임 — github.com의 NS 조회 예시입니다. 판정, 레지스트리의 네임서버 8대와 존 자체의 목록, 각 서버의 응답, .com 레지스트리의 위임을 보여 줍니다. 번호를 선택하면 각 부분이 무엇을 보여 주는지 확인할 수 있습니다.

상위와 하위 네임서버가 다른 이유

두 목록은 서로 다른 주체가 관리합니다. 레지스트리는 등록대행자가 요청할 때 상위의 목록을 게시하고, DNS 호스트는 존 자체의 목록을 서비스합니다. 한쪽만 바꾸면 둘이 어긋납니다.

리졸버는 위임 응답보다 존 자체의 응답을 더 신뢰하므로(RFC 2181 §5.4.1), 존에 한 번 물어본 뒤에는 그 목록과 TTL을 유지합니다. 2026-10-23에 Cloudflare의 리졸버는 google.com의 NS 집합을 340,859초 남긴 채 보관하고 있었습니다: .com의 172,800초보다 크므로, 그 사본은 존의 4일 TTL에서 온 것입니다.

레지스트리 목록에만 있는 이름도 처음부터 시작하는 리졸버에게서는 여전히 트래픽을 받습니다. 존에만 있는 이름은 그 리졸버에게 보이지 않습니다. 둘 다 고칠 가치가 있지만, 그 자체로 장애는 아닙니다.

레지스트리의 목록과 존의 목록 비교2026-10-23 기록

xserver.ne.jp5 대 3

레지스트리 .jp1일

ns1.xserver.jp
ns2.xserver.jp
ns3.xserver.jp
ns4.xserver.jp레지스트리에만 있음
ns5.xserver.jp레지스트리에만 있음

존1시간

ns1.xserver.jp
ns2.xserver.jp
ns3.xserver.jp

ns4.xserver.jp 및 ns5.xserver.jp은 레지스트리에만 있습니다. 양쪽 모두 권한 있는 응답을 하므로 문제는 없지만, 목록은 여전히 다릅니다.

github.com같은 8개

레지스트리 .com2일

dns1.p08.nsone.net
dns2.p08.nsone.net
dns3.p08.nsone.net
dns4.p08.nsone.net
ns-1283.awsdns-32.org
ns-1707.awsdns-21.co.uk
ns-421.awsdns-52.com
ns-520.awsdns-01.net

존15분 · 1시간

dns1.p08.nsone.net
dns2.p08.nsone.net
dns3.p08.nsone.net
dns4.p08.nsone.net
ns-1283.awsdns-32.org
ns-1707.awsdns-21.co.uk
ns-421.awsdns-52.com
ns-520.awsdns-01.net

이름은 같고 시계가 다릅니다: 레지스트리의 사본은 2일, Route 53은 15분, NS1은 1시간 동안 유지됩니다.

.net 도메인(이름 비공개)공통된 이름 없음

레지스트리 .net2일

ns1.domaindirect.com레지스트리에만 있음
ns2.domaindirect.comREFUSED
ns3.domaindirect.com레지스트리에만 있음

존15분

ns1.hover.com존에만 있음
ns2.hover.com존에만 있음

레지스트리에는 여전히 이전 이름이 나열되어 있습니다. 그중 둘은 Hover 서버와 주소를 공유하며 응답하고, 셋째는 거부합니다.

선은 두 목록이 공유하는 이름을 잇고, 점선은 한 주소를 쓰는 두 이름을 잇습니다. 세 번째 사례는 무작위 스캔에서 찾은 실제 등록이며 이름은 공개하지 않습니다.

글루 레코드란?

글루는 상위가 위임 응답과 함께 알려 주는 주소로, 자신이 서비스하는 존 안에 이름이 있는 네임서버에 리졸버가 닿을 수 있게 합니다. 글루가 없으면 ns1.google.com을 찾으려고 google.com의 서버에 물어야 하는데, 그것이 처음 하던 질문입니다(RFC 1034 §4.2.1).

RFC 9471은 이를 규칙으로 정했습니다: 위임 응답은 도메인 내부 서버(google.com의 ns1.google.com)의 글루를 반드시 포함해야 하고(MUST), 같은 상위 아래의 형제 서버(github.com의 ns-421.awsdns-52.com)는 포함하는 것이 좋습니다(SHOULD). ns-520.awsdns-01.net 같은 무관한 이름은 따로 조회합니다.

글루는 등록대행자에서 호스트 레코드, 하위 네임서버, 개인 DNS 서버 등의 이름으로 설정합니다. 서버를 옮길 때는 글루도 함께 옮겨야 합니다: 오래된 글루는 리졸버를 더 이상 응답하지 않는 주소로 보냅니다.

글루와 필요한 경우.com에서 기록, 2026-10-23

도메인 내부 · google.com

.com: ns1.google.com에 질의
그 주소는 google.com 자체에 있음
글루가 없으면 조회가 순환
그래서 .com이 ns1.google.com A 216.239.32.10를 추가 · MUST: 필수

형제와 무관 · github.com

.com: ns-421.awsdns-52.com, ns-520.awsdns-01.net, …에 질의
awsdns-52.com도 .com 아래에 있음: 글루 205.251.193.165 · SHOULD: 포함
awsdns-01.net은 다른 곳에 있음: 리졸버가 .net에서 따로 조회 · 글루 없음

오래된 글루 · 실시간~~64.69.208.141~~ns1.register.com에 대한 .com의 글루 · 응답 없음, 두 번 질의162.214.41.25현재의 A 레코드 · 권한 있는 응답

2026-10-23에 rdap.verisign.com으로 읽은 .com의 ns1.register.com 호스트 객체입니다: 레지스트리는 서버가 떠난 주소를 아직 보관하고 있고, 그것을 글루로 알려 줍니다.

lame 위임이란? 해결 방법

상위가 리졸버를 존을 서비스하지 않는 서버로 보내면 그 위임은 lame입니다: 서버가 거부하거나, 아무 말도 하지 않거나, 권한 없이 응답합니다. 나열된 모든 서버가 lame이면 도메인이 해석되지 않고, 여럿 중 하나가 lame이면 리졸버가 재시도하는 동안 조회가 느려집니다.

RFC 9499는 "lame delegation"이 여러 가지 결함을 가리키게 되었다고 설명하므로, 이 도구는 각각에 이름을 붙입니다: 존을 거부(REFUSED), 응답 없음(두 번 질의), 권한 없이 응답(aa 없음), 서버 오류(SERVFAIL). TCP에서만 응답이 없는 경우는 Google과 Cloudflare가 여전히 도메인을 해석하는 동안 lame이라 하지 않고 TCP 응답 없음이라 부릅니다: 그 서버가 UDP로는 응답할 수 있기 때문입니다.

해결은 항상 두 쪽 중 하나입니다: 레지스트리가 가리키는 DNS 호스트에 존을 추가하거나, 레지스트리가 존이 있는 호스트를 가리키게 하는 것입니다. 리졸버는 수정 후에도 최대 5분 동안 실패를 기억할 수 있습니다(RFC 9520).

기록된 lame 서버 세 가지2026-10-23 · 도메인 비공개

존을 거부

ns63 · ns64.domaincontrol.com

.com이 지정한 GoDaddy의 두 서버가 모두 REFUSED로 응답합니다: 그곳에는 존이 설정되어 있지 않습니다.

bash

$ dig @ns63.domaincontrol.com \
    example.com SOA +norec
;; … status: REFUSED
;; flags: qr; … ANSWER: 0

시간 초과 뒤 REFUSED

ns1 · ns2.eftydns.com

서버 하나가 한 번 시간 초과되었다가 다시 묻자 REFUSED로 응답했습니다. 한 번의 시간 초과는 판정이 아닙니다: 이 도구는 상태에 이름을 붙이기 전에 다시 묻습니다.

bash

$ dig @ns1.eftydns.com \
    example.com SOA +norec
;; connection timed out
# 다시 질의
;; … status: REFUSED

세 대 중 하나

ns1 · ns2 · ns3.domaindirect.com

두 서버는 권한 있는 응답을 하고, 세 번째는 거부합니다. 도메인은 작동하지만 더 느립니다.

bash

$ dig @ns2.domaindirect.com \
    example.net SOA +norec
;; … status: REFUSED
# ns1, ns3: NOERROR, flags qr aa

레지스트리가 가리키는 곳 확인위임 보기에 레지스트리의 서버와 각 서버의 응답이 나열됩니다.
한쪽 수정그 호스트에 존을 추가하거나, 등록대행자에서 네임서버를 변경하세요.
다시 확인응답은 바로 돌아오며, 캐시된 실패는 최대 5분 동안 남습니다.

모든 서버가 lame일 때 방문자가 받는 응답:Google SERVFAILCloudflare SERVFAIL

무작위 스캔에서 찾은 등록에서 기록했으며, 이름은 공개하지 않고 example.com과 example.net으로 표시했습니다.

네임서버는 몇 개 필요한가요?

적어도 두 개입니다: "DNS 명세와 도메인 이름 등록 규칙은 모든 존에 적어도 두 서버를 요구합니다"(RFC 2182 §5, BCP 16). 같은 절은 대부분의 조직에 서버 세 대를 권장하며 그중 하나는 다른 서버들과 멀리 떨어뜨리고, 신뢰성이 더 중요하면 네 대나 다섯 대를 권장합니다.

이름이 아니라 네트워크를 세세요. 서버는 한 번의 장애가 모두에 닿지 않는 곳에 두어야 합니다(RFC 2182 §3.1): 하나의 /22에 있는 서버 6대는 라우팅 운명을 함께합니다. 애니캐스트는 한 주소를 여러 지점에 퍼뜨리는 일반적인 해법이지만 운영 주체는 여전히 하나입니다. 제공업체를 둘로 나누면 한 운영 주체의 장애에서도 살아남습니다(RFC 8901).

더 많아도 괜찮습니다. RFC 1912의 7개 제한은 512바이트 UDP 응답에서 비롯되었고, 큰 존은 오늘날 8개를 운영합니다(github.com, bbc.co.uk).

네트워크별로 묶은 서버2026-10-23 기록

도메인	네트워크별 서버	NS	네트워크	판독
google.com	Google · AS15169 · anycast	4	1	애니캐스트, 운영 주체 하나
github.com	NS1 · AS62597Route 53 · AS16509 · anycast	8	2	제공업체 두 곳
bbc.co.uk	NetActuate · AS63911NS1 · AS62597	8	2	네트워크 두 개
xserver.ne.jp	Xserver · AS131965Amazon · AS16509	5	2	네트워크 두 개
craigslist.org	craigslist · AS22414	6	1	/22 하나

"대부분의 조직 수준 존에는 서버 세 대를 제공하는 것이 권장되며, 그중 적어도 하나는 다른 서버들과 멀리 떨어져 있어야 합니다."
RFC 2182 §5 · BCP 16, 1997년 7월 · 두 대 필수, 세 대 권장

상자 하나는 네트워크(AS) 하나이고, 색이 칠해진 상자는 애니캐스트 제공업체입니다: 지점은 많지만 운영 주체는 하나입니다. xserver.ne.jp의 두 번째 네트워크는 Amazon의 네트워크에 있는 ns2.xserver.jp이고, craigslist.org의 서버 6대는 하나의 /22를 공유합니다.

네임서버 변경 방법과 소요 시간

DNS 호스트가 아니라 도메인을 등록한 곳에서 변경하세요: 등록대행자가 새 목록을 레지스트리에 보내고, 레지스트리가 게시합니다. 새 서버가 지정되는 즉시 응답할 수 있도록, 먼저 새 호스트에 모든 레코드와 함께 존을 추가하세요.

그다음 시계가 두 개 돕니다. 레지스트리의 위임 응답을 캐시한 리졸버는 상위 TTL 동안 이전 목록을 유지합니다: .com은 2일, .de와 .jp는 1일, .org는 1시간. 이미 존에 물어본 리졸버는 이전 존 자체의 NS 집합을 그 TTL 동안 보관하며 더 길 수 있습니다: google.com은 4일입니다. Google Public DNS는 NS를 최대 6시간 보관합니다.

그러므로 일률적인 "24~48시간"이 아닙니다. 더 긴 시계가 끝날 때까지 이전 DNS 호스트가 같은 레코드로 계속 응답하게 두고, 서명된 도메인이라면 이전하기 전에 DS를 삭제하세요(RFC 6781).

변경하는 곳과 시계TTL 측정일 2026-10-23

등록대행자에서: 각 등록대행자의 안내

레지스트리의 사본이 유지되는 시간(상위 NS TTL)

.ru4일345,600 s
.com2일172,800 s
.uk2일172,800 s
.de1일86,400 s
.jp1일86,400 s
.kr1일86,400 s
.tr12시간43,200 s
.dev3시간10,800 s
.org1시간3,600 s
.io1시간3,600 s
.in15분900 s

변경 후의 시계

캐시에 남은 이전 위임 응답상위 TTL.com: 최대 2일
캐시에 남은 이전 존의 NS 집합이전 존의 TTLgoogle.com: 최대 4일
Google Public DNSNS 보관 상한최대 6시간

상위 TTL은 각 레지스트리 자체 서버에서 측정했습니다(dig +norec). .io는 흔히 인용되는 300초가 아니라 3,600초로 응답했습니다. 등록대행자는 여전히 일률적인 시간을 안내합니다: GoDaddy "최대 48시간", Namecheap "최대 24시간".

NS vs SOA vs 글루 레코드

세 레코드가 위임 지점에서 만납니다. NS는 서버를 지정합니다: 상위의 사본은 길을 알려 주고, 존의 사본이 권한입니다. 글루는 상위가 존 안에 이름이 있는 서버에 대해서만 보관하는 A 또는 AAAA 레코드입니다. SOA는 존마다 하나, 존 최상단에 있습니다: 기본 서버, 연락 주소, 시리얼, 타이머입니다.

SOA에 aa 플래그로 응답하는 서버가 존을 가진 서버이며, 그래서 이 도구는 모든 서버에 SOA를 묻습니다. 시리얼은 서버들이 같은 버전을 가졌는지 알려 줍니다. Route 53은 1에서 시작해 스스로 바꾸지 않으며, 제공업체 두 곳에 있는 존은 시리얼이 두 개이지만 둘 다 정상입니다.

존 둘, 위임 지점 하나google.com · 2026-10-23 기록

.com 존운영: Verisign

NSgoogle.com. 172800 NS ns1.google.com.위임: 다음으로 갈 곳 · 권한 없음
Ans1.google.com. 172800 A 216.239.32.10글루: 서버의 주소, 서버에 닿을 수 있게 함
DSDS 없음: google.com은 서명되지 않음DS: 하위의 서명 키를 가리킴, 서명된 존만(cloudflare.com DS 2371 13 2)

위임 지점 · google.com

google.com 존운영: Google

NSgoogle.com. 345600 NS ns1.google.com.존 자체의 목록 · 권한 있음
SOAns1.google.com. dns-admin.google.com. 1003797344 900 900 1800 60존마다 하나: 기본 서버, 연락처, 시리얼, 타이머
Ans1.google.com. 345600 A 216.239.32.10서버 자체의 주소: 글루는 이와 일치해야 함

글루와 서버 자체의 A 레코드는 하나의 사실에 대한 두 사본입니다: 둘이 다르면 글루가 오래된 것입니다.

NS 조회와 nslookup 명령어의 차이

사람들은 "ns lookup"을 두 가지 뜻으로 검색합니다: 도메인의 네임서버, 그리고 Windows, macOS, Linux에 들어 있는 nslookup 명령어입니다. nslookup은 내 리졸버에 물어 캐시된 내용을 출력하며, -type=ns를 쓰면 내 리졸버가 가진 존의 NS 집합을 나열합니다.

그 사본은 몇 시간 묵었을 수 있고, 레지스트리의 목록, 글루, 각 서버가 존을 가지고 있는지는 절대 보여 주지 않습니다. 이 페이지는 닿을 수 있는 각 서버에 직접 묻습니다.

네임서버를 조회하는 세 가지 방법

	이 NS 조회dnsrobot.net	nslookup-type=ns	digNS · +norec
질의 대상	레지스트리, 그다음 모든 서버	내 리졸버	지정한 서버 하나
레지스트리 대 존	둘 다, 이름별로	캐시된 사본	명령마다 목록 하나
각 서버의 aa	각 IPv4 주소(A와 글루)	아니요	명령마다 서버 하나
글루와 TTL	두 TTL 모두	-debug 사용 시	출력에 있음
진단	이름과 해결 방법 제시	아니요	아니요
실행 환경	모든 브라우저	WindowsmacOSLinux	macOSLinux

NS 조회 자주 묻는 질문

NS 조회란?

NS 조회는 도메인의 존을 가진 네임서버가 어디인지 DNS에 묻는 것입니다. 이 도구는 먼저 레지스트리에 글루와 TTL이 포함된 상위의 목록을 묻고, 각 네임서버의 IPv4 주소에 TCP로 직접 존의 SOA와 자체 NS 집합을 물어 둘을 비교합니다. DNS를 누가 호스팅하는지, 어느 서버가 권한 있는 응답을 하는지, 리졸버가 실패하거나 느려질 만한 문제가 있는지 알 수 있습니다.

네임서버 확인으로 내 DNS 제공업체를 어떻게 알 수 있나요?

네임서버 이름을 보세요: ns1.google.com은 Google, *.ns.cloudflare.com은 Cloudflare, ns-*.awsdns-*는 Amazon Route 53, 01.dnsv.jp는 Onamae.com입니다. 이 조회는 각 제공업체의 공개된 이름 패턴으로 DNS 호스트를 식별하고 각 주소 뒤의 네트워크는 따로 보여 줍니다. 일부 호스트는 다른 회사의 네트워크에서 운영되기 때문입니다: Porkbun과 Hostinger는 Cloudflare, Vercel은 NS1입니다.

레지스트리와 존이 서로 다른 네임서버를 나열하는 이유는?

등록대행자에서 설정하는 레지스트리의 목록과 DNS 호스트에서 설정하는 존 자체의 NS 레코드는 별개의 두 사본이며, RFC 1034는 둘이 완전히 같아야 한다고 합니다. 한쪽만 바꾸면 어긋나는데, DNS 호스트를 옮긴 뒤에 흔합니다. 레지스트리에서 시작하는 리졸버는 그 목록을 쓰고, 존에 물어본 리졸버는 존의 목록을 유지합니다.

lame 위임이란?

lame 위임은 레지스트리가 나열했지만 존을 서비스하지 않는 네임서버입니다: REFUSED나 SERVFAIL로 응답하거나, 권한 없이 응답하거나, 아예 응답하지 않습니다. 나열된 서버가 모두 lame이면 도메인이 해석되지 않고 Google과 Cloudflare가 SERVFAIL로 응답합니다. 그 DNS 호스트에 존을 추가하거나, 등록대행자에서 존이 있는 호스트로 네임서버를 변경해 해결하세요.

네임서버 변경이 전파되는 데 얼마나 걸리나요?

두 시계 중 더 긴 쪽까지입니다: 레지스트리의 NS TTL(.com과 .net은 2일, .ru는 4일, .de와 .jp는 1일, .org와 .io는 1시간, .in은 15분)과, 이미 이전 호스트에 물어본 리졸버가 보관하는 이전 존 자체의 NS TTL입니다. Google Public DNS는 약 6시간으로 제한합니다. 일률적인 "24~48시간"은 양쪽 모두 틀립니다.

도메인에는 네임서버가 몇 개 있어야 하나요?

적어도 두 개입니다: RFC 2182는 두 개를 요구하고, 대부분의 조직에는 다른 서버들과 멀리 떨어진 서버를 적어도 하나 포함한 세 개를, 더 높은 신뢰성에는 네 개나 다섯 개를 권장합니다. 개수보다 중요한 것은 한 번의 장애가 모두에 닿지 않는 것입니다: 서로 다른 네트워크나 제공업체. Cloudflare나 Route 53처럼 한 운영 주체의 애니캐스트 서버는 지점은 많아도 운영 주체는 하나입니다.

글루 레코드란? 언제 필요한가요?

글루는 example.com의 ns1.example.com처럼 존 안에 이름이 있는 네임서버에 대해 레지스트리가 위임 응답과 함께 알려 주는 주소입니다: 글루가 없으면 서버를 찾으려고 서버의 주소가 필요한 셈이 됩니다. RFC 9471은 이런 도메인 내부 이름에 글루를 필수로 정합니다. 등록대행자에서 호스트 레코드, 하위 네임서버, 개인 DNS 서버 등의 이름으로 설정합니다.

도구마다 다른 네임서버가 나오는 이유는?

대부분의 네임서버 확인 도구는 리졸버에 물어 변경 후 며칠 묵었을 수 있는 캐시된 사본을 보여 주지만, 레지스트리와 존은 스스로 응답합니다. 존 자체의 목록만 보여 주는 도구도 있습니다. 이 조회는 레지스트리의 목록, 모든 서버 자체의 응답, Google과 Cloudflare의 캐시된 사본을 나란히 보여 주고 각 사본의 남은 시간도 표시합니다.

"직접 테스트하지 않음"은 무슨 뜻인가요?

저희 서버는 Cloudflare 네트워크에서 실행되며, Cloudflare Worker는 그 네트워크의 주소에 연결을 열 수 없습니다. 그곳에 있는 네임서버, 즉 Cloudflare 자체와 Porkbun, Hostinger, DigitalOcean처럼 Cloudflare 위에서 운영되는 호스트의 서버는 대신 Cloudflare의 리졸버 1.1.1.1로 읽습니다: NS 집합과 TTL은 알 수 있지만 각 서버의 AA 비트, 시리얼, 응답 시간은 알 수 없습니다.

NS 조회와 nslookup은 같은가요?

아닙니다. nslookup은 Windows, macOS, Linux의 명령줄 도구로, NS를 포함한 모든 레코드 유형을 리졸버에 묻습니다(nslookup -type=ns example.com). NS 조회는 질문 그 자체입니다: 어떤 네임서버가 도메인을 서비스하는가. dig NS처럼 nslookup도 내 리졸버의 캐시된 사본을 보여 줍니다. 이 도구처럼 레지스트리와 각 서버에 직접 물어야 둘이 일치하는지 알 수 있습니다.

네임서버를 바꿨는데 왜 아직 반영되지 않나요?

세 곳을 확인하세요: 레지스트리에 새 서버가 나열되어 있는지(아니라면 변경이 아직 등록대행자를 떠나지 않은 것), 새 존이 권한 있는 응답을 하는지, 이전 사본이 리졸버에 얼마나 남아 있는지입니다. "네임서버를 변경했습니다" 모드는 새 서버를 입력받아 각 사본을 그와 비교하고, 모든 리졸버가 새 집합을 받는 시점까지 카운트다운합니다.

네임서버를 바꾸기 전에 DNSSEC를 제거해야 하나요?

네, 이전 DNS 호스트와 새 DNS 호스트가 협력하지 않는 한 그렇습니다. 레지스트리에 새 호스트의 키와 맞지 않는 DS 레코드가 남아 있으면 Google과 Cloudflare 같은 검증 리졸버가 SERVFAIL로 응답하고 그 사용자에게는 도메인이 먹통이 됩니다. 등록대행자에서 DS를 삭제하고 TTL이 지나기를 기다린 뒤 네임서버를 바꾸고, 새 호스트의 DS를 게시하세요.

부족한 점이 있습니까?기능 또는 새 도구 제안하기

네임서버 조회 — 도메인 네임서버 확인

NS 레코드란?

도메인 네임서버 확인 방법

네임서버 조회 결과 읽는 법

상위와 하위 네임서버가 다른 이유

글루 레코드란?

lame 위임이란? 해결 방법

네임서버는 몇 개 필요한가요?

네임서버 변경 방법과 소요 시간

NS vs SOA vs 글루 레코드

NS 조회와 nslookup 명령어의 차이

NS 조회 자주 묻는 질문

NS 조회란?

네임서버 확인으로 내 DNS 제공업체를 어떻게 알 수 있나요?

레지스트리와 존이 서로 다른 네임서버를 나열하는 이유는?

lame 위임이란?

네임서버 변경이 전파되는 데 얼마나 걸리나요?

도메인에는 네임서버가 몇 개 있어야 하나요?

글루 레코드란? 언제 필요한가요?

도구마다 다른 네임서버가 나오는 이유는?

"직접 테스트하지 않음"은 무슨 뜻인가요?

NS 조회와 nslookup은 같은가요?

네임서버를 바꿨는데 왜 아직 반영되지 않나요?

네임서버를 바꾸기 전에 DNSSEC를 제거해야 하나요?

DNS 조회

WHOIS 조회

호스팅 확인 도구

MX 조회

도메인에서 IP로

역방향 DNS 조회

서브도메인 검색

도메인 나이 확인

NS 레코드란?

도메인 네임서버 확인 방법

네임서버 조회 결과 읽는 법

상위와 하위 네임서버가 다른 이유

글루 레코드란?

lame 위임이란? 해결 방법

네임서버는 몇 개 필요한가요?

네임서버 변경 방법과 소요 시간

NS vs SOA vs 글루 레코드

NS 조회와 nslookup 명령어의 차이

NS 조회 자주 묻는 질문

NS 조회란?

네임서버 확인으로 내 DNS 제공업체를 어떻게 알 수 있나요?

레지스트리와 존이 서로 다른 네임서버를 나열하는 이유는?

lame 위임이란?

네임서버 변경이 전파되는 데 얼마나 걸리나요?

도메인에는 네임서버가 몇 개 있어야 하나요?

글루 레코드란? 언제 필요한가요?

도구마다 다른 네임서버가 나오는 이유는?

"직접 테스트하지 않음"은 무슨 뜻인가요?

NS 조회와 nslookup은 같은가요?

네임서버를 바꿨는데 왜 아직 반영되지 않나요?

네임서버를 바꾸기 전에 DNSSEC를 제거해야 하나요?

관련 DNS 도구

DNS 조회

WHOIS 조회

호스팅 확인 도구

MX 조회

도메인에서 IP로

역방향 DNS 조회

서브도메인 검색

도메인 나이 확인