DNS 전파가 느린 이유와 빨리 확인하는 법
DNS 변경이 즉시 반영되지 않는 이유(TTL·캐싱)와 전파 상태를 확인·단축하는 방법.
도메인의 A 레코드나 네임서버를 바꾸고 나서 "왜 아직도 옛날 서버로 들어가지?"라고 답답해 본 적이 있을 것이다. 결론부터 말하면 DNS 변경은 절대 즉시 반영되지 않는다. 어떤 사용자에게는 1분 만에 보이고, 어떤 사용자에게는 24~48시간 뒤에야 새 IP가 보인다. 이 글에서는 그 차이가 왜 생기는지, 그리고 변경 전후로 무엇을 해야 전파를 빠르게 끝낼 수 있는지를 정리한다.
가장 먼저 바로잡아야 할 오해가 있다. 흔히 "DNS 전파(propagation)"라고 부르지만, 실제로는 데이터가 전 세계로 "퍼져 나가는" 과정이 아니다. 정확히는 전 세계에 흩어진 리졸버(resolver)들이 들고 있던 옛날 캐시가 만료되어 사라지는 과정이다. 이 차이를 이해하면 전파 시간이 왜 TTL에 달려 있는지 한 번에 납득이 된다.
TTL이란 무엇이고 캐싱을 어떻게 제어하는가
TTL(Time To Live)은 각 DNS 레코드에 붙는 "유효기간"이다. 단위는 초이며, 리졸버가 "이 응답을 몇 초 동안 캐시에 보관해도 되는가"를 알려준다. 예를 들어 A 레코드의 TTL이3600이면, 어떤 리졸버가 그 레코드를 한 번 조회한 뒤 최대 1시간(3600초) 동안은 권한 네임서버에 다시 묻지 않고 캐시에 있는 값을 그대로 돌려준다.
- TTL이 길수록(예: 86400 = 24h) 조회 부하·지연이 줄지만, 변경 반영은 느려진다.
- TTL이 짧을수록(예: 300 = 5m) 변경이 빨리 퍼지지만, 권한 네임서버 조회가 잦아진다.
- TTL은 변경 "이후"가 아니라, 이전에 캐시된 응답의 수명을 결정한다는 점이 핵심이다.
현재 레코드와 TTL 값이 궁금하다면 DNS 조회 도구로 A·CNAME·MX·NS 레코드와 함께 응답에 실린 TTL을 직접 확인할 수 있다.
전파가 느린 진짜 이유: 캐시는 한 군데가 아니다
최종 사용자가 도메인을 입력하면 응답은 여러 캐시 계층을 거친다. 이 계층 중 어느 하나라도 옛날 값을 들고 있으면, 그 캐시가 만료될 때까지 사용자는 변경 전 서버로 연결된다.
- 운영체제·브라우저 캐시 — 내 PC 안에서도 잠깐 캐싱한다(보통 가장 짧다).
- ISP·공용 리졸버 캐시 — 통신사 DNS나 8.8.8.8 같은 공용 리졸버가 TTL만큼 보관한다. 전파 지연의 대부분이 여기서 발생한다.
- 권한 네임서버(NS) 변경 — 네임서버 자체를 바꾸는 경우는 상위 TLD에 등록된 NS 레코드의 TTL(보통 24~48시간)이 적용되어 가장 느리다.
그래서 동일한 변경이라도 사용자 위치·통신사에 따라 반영 시점이 제각각이다. 내 PC에서는 새 IP가 보여도 다른 지역 사용자에겐 아직 옛 IP가 보일 수 있다. 이 편차를 한눈에 보려면 여러 지역 리졸버에서 동시에 조회하는 DNS 전파 확인 도구가 가장 확실하다.
구체적 예시: TTL 3600인 A 레코드를 바꾸면
상황: A 레코드 TTL이 3600(1시간)이고, IP를 1.1.1.1에서2.2.2.2로 바꿨다. 한 ISP 리졸버가 변경 5분 전에 옛 값(1.1.1.1)을 막 캐시했다고 하자.
| 시점 | 그 리졸버가 주는 IP | 이유 |
|---|---|---|
| 변경 직후 | 1.1.1.1 (옛 IP) | 캐시가 아직 살아 있음 |
| 변경 +55분 | 1.1.1.1 (옛 IP) | TTL 3600초가 끝나지 않음 |
| 변경 +1시간 이후 첫 조회 | 2.2.2.2 (새 IP) | 캐시 만료 → 권한 NS에 재조회 |
요점은 명확하다. 이 리졸버를 쓰는 사용자는 변경 후 최대 1시간 동안 옛 서버로 연결된다. 데이터가 늦게 도착해서가 아니라, 캐시가 만료될 때까지 기다려야 하기 때문이다.
계획된 변경이라면: 24~48시간 전에 TTL을 낮춰라
IP 이전이나 서버 마이그레이션처럼 일정을 미리 아는 경우, 전파 지연을 거의 없앨 수 있다. 핵심은 변경 그 자체보다 변경 이전에 짧은 TTL을 미리 퍼뜨려 두는 것이다.
- 변경 24~48시간 전: 해당 레코드의 TTL을
3600에서300(5분)으로 낮춘다. - 기존(긴) TTL이 전부 만료될 때까지 기다린다 → 이제 모든 리졸버가 짧은 TTL을 알고 있다.
- 실제 변경을 적용한다(새 IP/네임서버).
- 이제 옛 값은 길어야 5분이면 사라지므로 전파가 거의 즉시 끝난다.
- 변경이 안정되면 TTL을 다시
3600이상으로 올려 평상시 부하를 줄인다.
이전을 진행하기 전에 빠뜨린 레코드가 없는지 점검하려면 DNS 변경 체크리스트를 따라가고, 전환 후에는 다시 DNS 전파 확인으로 모든 지역에서 새 값이 보이는지 검증하는 흐름을 권한다.