DNS 전파는 얼마나 걸리나요?

레코드를 바꿨다면 최대 이전 레코드의 TTL만큼입니다. 리졸버가 캐시된 사본을 그만큼 들고 있을 수 있기 때문입니다. 등록기관에서 네임서버를 바꿨다면 .com과 .net은 위임 레코드의 TTL이 이틀이라 최대 48시간을 잡아야 합니다.

DNS 전파를 빨리 끝낼 수 있나요?

바꾼 뒤에는 방법이 없습니다. 남의 캐시를 비울 수는 없으니까요. 내 컴퓨터 캐시는 비울 수 있고, Cloudflare(1.1.1.1)와 Google Public DNS는 특정 이름을 캐시에서 지우는 페이지를 제공합니다. 근본 해결책은 바꾸기 하루이틀 전에 TTL을 낮춰 두는 것입니다.

방금 만든 서브도메인이 왜 NXDOMAIN으로 나오나요?

레코드가 생기기 전에 누군가 그 이름을 조회했고, '없다'는 응답이 캐시된 것입니다. 부정 응답은 존의 SOA minimum 값과 SOA 레코드 자체의 TTL 중 작은 값만큼 캐시됩니다. 그만큼 기다리거나, 권한 있는 서버에 직접 물어 레코드가 있는지 확인하세요.

어떤 리졸버는 새 IP, 어떤 리졸버는 예전 IP를 줍니다. 뭔가 잘못된 건가요?

대개 아닙니다. 리졸버마다 예전 응답을 캐시한 시점이 달라서 만료되는 시점도 다릅니다. 권한 있는 서버가 새 값을 주고 예전 값을 주는 리졸버의 TTL이 줄어들고 있다면 곧 맞춰집니다. 끝없이 다르다면 GeoDNS나 예전 데이터를 내는 네임서버를 의심하세요.

DNS 전파 시간: 얼마나 걸리고 왜 늦어지나

전파되는 것은 없습니다. 캐시가 만료될 뿐입니다

“전파”라고 하면 변경 사항이 인터넷의 서버에서 서버로 퍼져 나가는 것처럼 들립니다. 실제로는 그렇지 않습니다. 레코드를 저장하면 DNS 업체의 권한 있는(authoritative) 서버는 대개 몇 초 안에 새 값을 냅니다. 그 뒤로 어디에도 밀어 보내는 것은 없습니다.

기다리는 대상은 다른 사람들의 캐시입니다. 최근에 내 도메인을 조회한 재귀 리졸버(통신사 DNS, 1.1.1.1, 8.8.8.8, 회사 내부 DNS)는 모두 그 응답을 TTL과 함께 저장해 두었습니다. TTL은 그 응답을 들고 있어도 되는 시간(초)입니다. 이 타이머가 끝날 때까지 리졸버는 캐시에서 답하고 내 서버에는 묻지 않습니다. 타이머가 끝나면 다음 조회 때 새 값을 가져옵니다.

여기서 세 가지가 나옵니다.

대기 시간은 새 TTL이 아니라 이전 TTL로 정해집니다. 캐시는 이전 레코드의 TTL로 채워졌습니다. 변경과 같은 작업에서 TTL을 낮춰 봐야 이미 캐시된 사본에는 아무 효과가 없습니다.
강제로 끝낼 수 없습니다. 전 세계 리졸버의 목록이라는 것이 없으니, “모든 리졸버에 반영” 버튼도 어디에도 없습니다.
사용자마다 바뀌는 시점이 다릅니다. 리졸버마다 캐시한 시점이 달라서 만료되는 시점도 다릅니다. 누구는 새 사이트를, 누구는 예전 사이트를 보는 기간이 생기는 것은 정상입니다.

사용자 가까이에도 캐시가 있습니다. 브라우저(크롬은 자체 캐시를 둡니다), 운영체제의 리졸버 서비스, 때로는 공유기입니다. 같은 규칙을 따르지만, 이쪽은 내가 직접 비울 수 있습니다.

실제로 걸리는 시간

바꾼 것	최대 대기 시간	정하는 값
기존 레코드 수정·삭제(A, CNAME, MX, TXT)	이전 레코드의 TTL	수정 전 TTL
아무도 조회한 적 없는 이름에 레코드 추가	거의 즉시	캐시된 것이 없음
없을 때 누군가 조회했던 이름에 레코드 추가	부정 캐시 TTL	존의 SOA minimum, 또는 그보다 작다면 SOA 레코드 자체의 TTL
기존 이름에 새 타입 추가(A만 있던 곳에 AAAA 등)	부정 캐시 TTL	같음: “그런 레코드 없음” 응답도 캐시됩니다
등록기관에서 네임서버 변경	.com·.net은 최대 48시간	상위 존의 위임 레코드 TTL + 등록기관 처리 시간

이전 TTL이 300초였다면, 정상적으로 동작하는 리졸버 기준으로 레코드 변경은 5분이면 끝납니다. 86400초였다면 하루가 걸릴 수 있고, 아무리 자주 확인해도 빨라지지 않습니다.

다들 말하는 “24~48시간”은 네임서버 변경과 긴 기본 TTL에서 나온 숫자입니다. 평범한 레코드 수정이라면 대개 과장입니다.

리졸버는 TTL보다 짧게 들고 있어도 되고, 아주 긴 TTL에 상한을 두는 곳도 많습니다. TTL보다 오래 들고 있는 잘못된 리졸버도 드물게 있습니다. 하지만 첫 번째로 의심할 만큼 흔하지는 않습니다.

1단계: 권한 있는 서버의 응답부터 확인

기다리기 전에, 기다릴 만한 올바른 값이 있는지부터 확인하세요. 캐시를 모두 건너뛰고, 실제로 이 도메인에 대해 권한 있는 서버에 물어봅니다.

$ dig +short NS example.com
ns1.dns-provider.example.
ns2.dns-provider.example.

$ dig @ns1.dns-provider.example www.example.com A +norecurse +noall +answer
www.example.com.        300     IN      A       198.51.100.20

권한 있는 서버가 예전 값을 준다면 기다려도 소용없습니다. 가장 흔한 원인은 네임서버는 다른 업체를 가리키는데 엉뚱한 관리 화면에서 레코드를 고친 경우입니다. 등록기관에는 대개 자체 DNS 관리 화면이 있는데, 도메인이 Cloudflare 같은 다른 업체의 네임서버를 쓰기 시작하면 그 화면은 아무 효과가 없습니다. 실제로 어느 업체가 담당하는지 가리는 법은 네임서버 불일치 가이드에 있습니다.

주(primary)·보조(secondary) 서버를 직접 운영한다면 서버마다 물어보세요. 보조 서버는 존 전송(zone transfer)으로만 변경을 받는데, NOTIFY를 받거나 refresh 타이머가 돌 때 일어나고, 그것도 SOA 시리얼이 올라갔을 때만입니다. 시리얼을 올리는 것을 잊으면 보조 서버는 계속 예전 존을 냅니다. 시리얼을 비교하세요.

dig @ns1.example.net example.com SOA +short
dig @ns2.example.net example.com SOA +short

2단계: 아직 예전 응답을 들고 있는 리졸버 찾기

공용 리졸버에 직접 물어봅니다.

$ dig @8.8.8.8 www.example.com A +noall +answer
www.example.com.        2714    IN      A       203.0.113.5

응답이 캐시에서 나온 것이라면 TTL 칸은 내가 설정한 TTL이 아니라 남은 시간입니다. 1분 뒤 다시 실행하면 숫자가 줄어 있습니다. 이 리졸버가 예전 주소를 그만큼 더 들고 있다가 다시 묻는다는 뜻입니다. 대형 공용 리졸버는 주소 하나 뒤에 별개의 캐시가 여러 개 있어서, 연달아 물어도 남은 시간이 다르게 나오거나 예전 값과 새 값이 번갈아 나올 수 있습니다.

전파 확인은 대형 공용 리졸버 6곳(Cloudflare, Google, OpenDNS, DNS.SB, NextDNS, AdGuard)에 한 번에 물어 각각의 응답과 남은 TTL을 보여 줍니다. 어디가 바뀌었고 나머지는 얼마나 남았는지 볼 수 있습니다. 통신사 리졸버나 회사 내부 DNS는 볼 수 없습니다. 그쪽은 그 네트워크 안에서 해당 리졸버를 대상으로 dig나 nslookup을 실행해야 합니다.

응답이 서로 다른데 끝내 맞춰지지 않는다면 전파 문제가 아닐 수 있습니다. CDN과 GeoDNS 서비스는 일부러 지역마다 다른 IP를 줍니다. 이 도구는 그런 패턴(짧은 TTL, 모든 리졸버가 응답, 값이 서로 다름)을 따로 표시합니다. 둘을 구분하는 법은 CDN 캐시와 DNS 전파 가이드에 있습니다.

3단계: 내 컴퓨터 쪽 원인 제거

공용 리졸버들은 새 값을 주는데 나만 예전 값이라면 캐시가 로컬에 있습니다.

# Windows
ipconfig /flushdns

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

# systemd-resolved를 쓰는 Linux
resolvectl flush-caches

크롬은 캐시를 따로 둡니다. chrome://net-internals/#dns를 열고 “Clear host cache”를 누르세요. hosts 파일(/etc/hosts, 또는 C:\Windows\System32\drivers\etc\hosts)에 누군가 테스트하다 넣고 잊어버린 줄이 있는지도 확인하세요.

Cloudflare와 Google은 자기 공용 리졸버 캐시에서 특정 이름을 지우는 페이지를 제공합니다(one.one.one.one/purge-cache, Google Public DNS의 “Flush Cache” 페이지). 그 두 리졸버를 쓰는 사용자에게만 효과가 있습니다.

dig는 새 IP를 주는데 브라우저에는 여전히 예전 사이트가 보인다면 이제는 DNS 문제가 아닙니다. 열려 있는 keep-alive 연결은 닫힐 때까지 예전 서버와 계속 통신하고, 브라우저나 CDN, 서비스 워커가 자기 캐시에서 예전 콘텐츠를 낼 수도 있습니다. HTTP 점검은 바깥에서 페이지를 가져오므로 새 서버가 실제로 무엇을 돌려주는지 볼 수 있습니다.

부정 캐시: 사라지지 않는 NXDOMAIN

newapp.example.com을 만들었고 내 컴퓨터에서는 잘 되는데, 동료 컴퓨터는 그런 이름이 없다고 고집합니다. 대개 레코드가 생기기 전에 누군가가, 혹은 모니터링 점검이나 인증서 발급 요청 같은 것이 그 이름을 조회한 경우입니다. 리졸버는 NXDOMAIN을 받았고 그 응답도 캐시했습니다(RFC 2308).

얼마나 캐시되는지는 존의 SOA 레코드에 있고, 부정 응답에는 늘 이 레코드가 함께 옵니다.

$ dig newapp.example.com A +noall +authority
example.com.    300     IN      SOA     ns1.dns-provider.example. hostmaster.example.com. 2026100701 7200 3600 1209600 300

이름 두 개 뒤의 숫자는 차례로 serial, refresh, retry, expire, minimum입니다. 부정 캐시 시간은 마지막 값과 SOA 레코드 자체의 TTL 중 작은 쪽이고, 여기서는 300초입니다. 1시간 이상으로 잡아 둔 존도 있습니다.

피하는 방법은 무언가 그 이름을 조회하기 전에 레코드부터 만드는 것입니다. 아직 만들지 않은 호스트명에 모니터링을 걸거나 인증서 발급을 시작하지 마세요. 이미 그렇게 됐다면 그 시간만큼 기다려야 합니다. 방문자에게는 크롬의 DNS_PROBE_FINISHED_NXDOMAIN으로 보이는 바로 그 NXDOMAIN이고, 다른 원인은 NXDOMAIN 가이드에 있습니다.

네임서버 변경: 48시간은 여기서 나옵니다

네임서버 변경은 내 존을 바꾸는 일이 아닙니다. 위임(delegation), 즉 상위 존(.com, .net, .kr)에 저장된 내 도메인의 NS 레코드를 바꾸는 일입니다. 이 레코드의 TTL은 내가 아니라 레지스트리가 정합니다. .com과 .net은 172800초, 48시간입니다.

.com 서버에 직접 물어 위임을 볼 수 있습니다.

$ dig @a.gtld-servers.net example.com NS +norecurse

;; AUTHORITY SECTION:
example.com.            172800  IN      NS      ns1.new-provider.example.
example.com.            172800  IN      NS      ns2.new-provider.example.

dig +trace example.com은 루트부터 내려오는 전체 경로를 보여 주므로, 레지스트리에 새 네임서버가 들어갔는지 알 수 있습니다. 등록기관이 레지스트리에 변경을 넘기는 데 걸리는 시간은 등록기관과 레지스트리마다 다릅니다.

상위 존에 새 네임서버가 보인 뒤에도, 예전 위임을 캐시한 리졸버는 그것이 만료될 때까지 예전 업체에 계속 묻습니다. 그래서 DNS 업체를 옮길 때는 지켜야 할 것이 있습니다.

바꾸기 전에 모든 레코드를 새 업체에 복사합니다. 전부입니다. MX, SPF·DKIM TXT, 소유 확인 레코드, CAA, SRV까지. 그다음 새 업체의 네임서버에 직접 물어 몇 개 이름을 비교합니다.
바꾼 뒤 최소 48시간, 가능하면 더 오래 예전 업체가 같은 존을 계속 내게 둡니다. 그 기간 동안 일부 사용자는 그쪽으로 갑니다. 첫날 예전 존을 지워 버리면 하루 동안 SERVFAIL이나 REFUSED를 겪게 됩니다.
옮기는 동안 레코드를 고치지 않습니다. 고쳐야 한다면 양쪽 업체에서 모두 고칩니다.
DNSSEC을 쓰는 도메인이라면 DS 레코드부터 처리합니다. 레지스트리에 있는 DS 레코드는 새 업체가 서명하는 키와 맞아야 합니다. 맞지 않으면 검증하는 리졸버는 SERVFAIL을 내는데, 1.1.1.1과 8.8.8.8도 둘 다 검증합니다. 옮기기 전에 DS를 제거하고 만료될 때까지 기다리거나, 두 업체가 모두 지원하는 키 교체 절차를 따르세요.

다음번에는: TTL부터 낮추기

변경을 빨리 반영하는 유일한 방법은 바꾸기 전에 준비하는 것입니다.

하루이틀 전: 바꿀 레코드의 TTL을 300초 정도로 짧게 낮춥니다.
최소한 이전 TTL만큼 기다립니다. 86400초였다면 하루를 꼬박 기다립니다. 그 전까지는 긴 TTL짜리 사본이 캐시에 남아 있습니다.
변경합니다. 이제 최악의 경우도 5분 정도입니다.
트래픽이 다 옮겨 왔다고 확신할 때까지 예전 서버를 살려 둡니다. 메일이라면 예전 서버가 한동안 메일을 계속 받게 두세요. 보내는 서버들은 자기 캐시를 거쳐 내 MX를 찾기 때문입니다.
안정되면 TTL을 다시 올립니다.

네임서버 변경에는 이 방법이 통하지 않습니다. 상위 존의 TTL은 내가 정할 수 없기 때문입니다. 그때는 예전 업체를 살려 두는 것이 안전장치입니다. 평소에 쓸 TTL 값은 TTL 가이드에 정리돼 있습니다.

정말로 고장 난 경우

권한 있는 서버의 응답이 맞고, 예전 값을 주는 리졸버의 TTL이 줄어들고 있다면 기다리는 것이 맞습니다. 다음 경우에는 기다리면 안 됩니다.

권한 있는 서버가 예전 값을 줍니다. 변경이 저장되지 않았거나, 다른 존에서 고쳤거나, 권한이 없는 업체에서 고친 것입니다.
네임서버끼리 응답이 다릅니다. SOA 시리얼을 비교하세요. 보조 서버가 존 전송을 받지 못하고 있습니다.
이전 TTL이 한참 지났는데 어느 리졸버도 새 값을 주지 않습니다. dig +trace로 위임을 확인하세요. 레지스트리에 아직 예전 네임서버가 등록돼 있을 수 있습니다.
네임서버를 바꾼 뒤 모든 곳에서 SERVFAIL이 납니다. 거의 언제나 DNSSEC입니다. DS 레코드가 새 업체의 키와 맞지 않습니다.
TTL이 짧은데 리졸버마다 응답이 계속 다릅니다. 아마 GeoDNS나 CDN이 원래 설계대로 동작하는 것입니다.

DNS 조회는 공용 리졸버가 보는 현재 레코드와 TTL을 보여 줍니다. 내가 설정한 값과 나란히 놓고 보면 대개 문제가 드러납니다.

내 도메인에서 바로 확인

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