⏳
네임서버 변경은 왜 24~72시간 걸리나?
네임서버(NS) 변경 시 전파가 느린 진짜 이유와 각 단계별 캐시 구조
onamae.com에서 Cloudflare로 네임서버를 변경했는데 왜 바로 반영이 안 될까? A 레코드 변경은 수분~수시간이면 끝나는데, 네임서버(NS) 변경은 왜 24~72시간이나 걸린다고 할까? 이 글에서는 DNS 계층 구조에서 네임서버 변경이 어떤 경로로 전파되는지, 각 단계의 캐시 TTL이 왜 이렇게 긴지, 그리고 실무에서 빠르게 전환하는 팁을 정리합니다.
동작 흐름
1
레지스트라(onamae.com 등)에서 NS를 새 네임서버(예: Cloudflare)로 변경 요청
2
레지스트라가 EPP 프로토콜로 TLD 레지스트리(Verisign 등)에 변경 통보
3
레지스트리가 .com 존 파일을 업데이트 (수분~수시간)
4
전 세계 ISP 리졸버의 캐시가 만료될 때까지 대기 (TLD NS TTL: 48시간)
5
캐시 만료 후 리졸버가 TLD에 재조회 → 새 NS 정보 획득 → 새 NS에서 A/CNAME 응답
장점
- ✓ NS 변경 자체는 레지스트라 관리 화면에서 간단히 수행 가능
- ✓ 양쪽 NS에 동일 레코드를 설정하면 전환 중 다운타임 제로
- ✓ dig +trace와 whatsmydns.net으로 전파 상태를 실시간 확인 가능
- ✓ Public DNS(Google, Cloudflare)는 캐시 퍼지 기능을 제공
단점
- ✗ TLD NS 레코드의 TTL(48시간)은 도메인 소유자가 제어할 수 없음
- ✗ 전 세계의 모든 ISP 리졸버 캐시를 강제로 비울 수 없음
- ✗ 일부 ISP는 TTL을 무시하고 자체 최소 캐시 시간을 강제 (72시간까지 지연 가능)
- ✗ 전파 완료 시점이 정확히 예측 불가 — 사용자마다 ISP가 달라서 반영 시점이 제각각
사용 사례
레지스트라 기본 NS에서 Cloudflare DNS로 이전
Route 53 → Cloudflare 또는 반대 방향 NS 이전
도메인 이관(transfer) 시 NS 변경 동반
CDN 전환(Vercel → Cloudflare 등)에 따른 NS 변경