DNS 전파, 변경이 오래 걸리는 진짜 이유

A 레코드를 수정했습니다. 새 사이트는 휴대폰에서는 열리는데 노트북에서는 열리지 않습니다. 다른 지역에 있는 동료는 여전히 이전 사이트를 봅니다. 누군가는 “전파될 때까지 기다리세요”라고 말합니다.

이 표현은 오해를 불러일으키며, 그대로 믿으면 문제를 논리적으로 따져 보기가 더 어려워집니다. 전파되는 것은 없습니다. 어디에도 데이터가 배포되지 않습니다.

실제로 일어나는 일

리졸버가 도메인을 조회하면 응답과 함께 TTL, 즉 초 단위 카운트다운을 저장합니다. 이 카운트다운이 0이 될 때까지 리졸버는 메모리에 있는 값으로 응답하며 네임서버에 다시 접속하지 않습니다.

그래서 레코드를 변경하면 다음과 같이 진행됩니다.

1. 권한 네임서버는 즉시 갱신됩니다. 이제 질의하는 모든 곳에 새 값을 제공합니다.
2. 이전 값을 캐시한 모든 리졸버는 각자의 카운트다운이 끝날 때까지 이전 값을 계속 제공합니다.
3. 이 카운트다운은 각 리졸버가 레코드를 처음 가져온 시점에 따라 서로 다른 순간에 시작되었으므로 만료되는 시점도 서로 다릅니다.
4. 각 리졸버는 만료되는 즉시 새 값을 가져옵니다. 그 리졸버를 쓰는 사용자는 바로 그 순간 새 값으로 전환됩니다.

시차를 두고 나타나는 이 결과가 변경이 “퍼져 나가는” 것처럼 보이는 이유입니다. 실제로는 수많은 독립적인 타이머가 각자 끝나는 것일 뿐입니다.

실제 대기 시간은 얼마나 될까요

최대 대기 시간은 변경하기 전에 레코드에 설정되어 있던 TTL입니다. 이 점이 전파를 예측 가능하게 만듭니다.

DNS 변경을 계획하는 올바른 방법

1. 1

   하루 전: TTL 낮추기

   TTL을 300초로 변경하고 다른 것은 바꾸지 마세요. 모든 캐시가 더 짧은 값을 가져가도록 최소한 이전 TTL만큼 기다리세요.

2. 2

   낮은 TTL이 적용되었는지 확인

   dig example.com을 실행해 응답 섹션의 TTL을 확인하세요. 3600이 아니라 300에서부터 카운트다운된다면 모든 리졸버가 짧은 타이머로 전환된 것입니다.

3. 3

   실제 변경 수행

   레코드를 수정합니다. 이제 누구든 최대 대기 시간은 1시간이 아니라 5분입니다.

4. 4

   여러 관측 지점에서 검증

   여러 공용 리졸버에 직접 질의하세요. 이들은 독립적인 캐시이므로 서로 다른 사용자가 실제로 보는 결과를 표본으로 확인할 수 있습니다.

5. 5

   TTL 다시 높이기

   트래픽이 새 값으로 안정되면 TTL을 3600 이상으로 되돌리세요. TTL이 낮으면 질의가 늘어나 모든 사용자의 조회가 조금씩 느려집니다.

리졸버마다 보이는 값 확인하기

dig +short example.com @1.1.1.1
dig +short example.com @8.8.8.8
dig +short example.com @9.9.9.9

dig +short example.com @ns1.example.com

마지막 명령이 중요합니다. 권한 서버가 새 값을 반환한다면 변경은 올바르고 완료된 것입니다. 나머지는 수정이 아니라 기다림의 문제입니다. 이전 값을 반환한다면 변경이 저장되지 않았거나, 도메인이 위임된 곳이 아닌 제공업체에서 수정한 것입니다.

기기마다 다르게 보이는 이유

여러분과 응답 사이에는 캐시가 하나가 아니라 여러 개 있으며, 각각 자체 타이머를 가지고 있습니다.

• 브라우저는 짧은 내부 DNS 캐시를 유지합니다.
• 운영 체제는 독립적으로 자체 캐시를 유지합니다.
• 공유기는 가정 전체를 대상으로 캐시하는 경우가 많습니다.
• ISP의 리졸버는 잠재적으로 수백만 사용자를 대상으로 캐시합니다.
• 기업 또는 VPN 리졸버는 관리되는 네트워크에서 또 하나의 계층을 더합니다.

모바일 데이터를 쓰는 휴대폰은 집 와이파이를 쓰는 노트북과 완전히 다른 리졸버 체인을 사용합니다. 한쪽은 새 사이트를 보여 주고 다른 쪽은 그렇지 않은 이유가 바로 이것입니다. 직접 제어할 수 있는 계층은 비울 수 있습니다. DNS 캐시를 비우는 방법을 참고하세요.