DNS 전파

DNS 전파는 네임서버에서 바꾼 값이 전 세계 사용자에게 반영되기까지 걸리는 시간을 부르는 말입니다. 이름과 달리 값이 서버에서 서버로 퍼져 나가는 과정이 아니라, 이전 값을 캐시하고 있던 리졸버들이 각자의 TTL이 끝나 다시 물어보는 과정입니다. 그래서 전파는 동시에 끝나지 않고, 리졸버마다 캐시를 채운 시점이 달라 사용자마다 반영 시각이 다릅니다.

왜 즉시 반영되지 않는가

DNS는 캐시를 전제로 설계된 체계입니다. 모든 접속마다 루트 서버부터 다시 묻는다면 전 세계 DNS 인프라가 감당하지 못합니다. 그래서 리졸버는 받은 답을 TTL 동안 보관하고 그 사이 같은 질의에는 저장된 값으로 답합니다.

값을 바꾸는 쪽에서 할 수 있는 일은 권한 네임서버의 값을 고치는 것까지입니다. 이미 답을 받아 간 리졸버에게 "그 답은 폐기하라"고 알릴 방법은 없습니다. 캐시를 지우는 권한은 각 리졸버 운영자에게 있습니다.

두 종류의 TTL

전파 시간을 좌우하는 TTL은 하나가 아닙니다.

레코드만 바꾸는 작업은 TTL을 미리 낮춰 두면 몇 분 안에 끝납니다. 반면 네임서버 변경은 상위 레지스트리의 TTL이 걸리므로 등록자가 시간을 줄일 수 없고, 보통 몇 시간에서 최대 48시간을 잡습니다. 이 차이 때문에 서버 이전은 네임서버를 그대로 두고 레코드만 바꾸는 편이 훨씬 빠릅니다.

dig로 확인하는 방법

전파 상태는 여러 리졸버에 같은 질의를 던져 응답이 갈리는지 보면 알 수 있습니다.

# 권한 네임서버에 직접 물어 새 값이 들어갔는지 확인
dig @ns1.example-dns.com example.co.kr A +short

# 공개 리졸버 두 곳의 캐시 상태 비교
dig @8.8.8.8 example.co.kr A
dig @1.1.1.1 example.co.kr A

# 위임 정보가 바뀌었는지 확인
dig example.co.kr NS +trace

권한 네임서버가 새 값을 답하는데 공개 리졸버가 예전 값을 답한다면 설정은 끝났고 캐시만 남은 상태입니다. 응답의 TTL 숫자가 남은 대기 시간이며, 이 값이 0에 가까워지면 곧 갱신됩니다. 반대로 권한 네임서버조차 예전 값을 답한다면 설정 자체를 다시 봐야 합니다.

현실적인 소요 시간

• 레코드 값 변경, TTL을 미리 낮춘 경우: 대개 5분에서 10분.
• 레코드 값 변경, TTL이 3600초인 경우: 최대 1시간.
• 네임서버 변경: 보통 몇 시간, 여유 있게 잡으면 48시간.
• 일부 사내 DNS나 오래된 장비: TTL을 무시하고 더 오래 붙잡는 경우가 있어 예외적으로 길어질 수 있습니다.

전환 기간에 서비스를 멈추지 않으려면 기존 서버와 새 서버를 함께 열어 두고, 두 곳 모두 정상 응답하는 상태에서 TTL이 지나기를 기다립니다. 메일까지 포함한 전체 순서는 무중단 이전 가이드를 참고하세요. 레코드별 설정 방법은 DNS 레코드 종류에 있습니다.