DNS 변경이 바로 반영되지 않는 이유: 전파와 TTL

"전파"란 실제로 무엇인가

"전파(propagation)"는 오해를 부르는 말입니다. 어디로도 밀어 보내지 않기 때문입니다. DNS 업체에서 레코드를 바꾸면 그 변경은 권한 있는 네임서버에 즉시 반영됩니다. 시간이 걸리는 것은 인터넷의 나머지가 그 사실을 알아차리는 일이고, 그것은 각자가 이미 가진 사본이 만료될 때에야 일어납니다.

최근에 그 이름을 조회한 재귀 리졸버들은 저마다 카운트다운이 붙은 답을 들고 있습니다. 그 카운트다운이 0이 되기 전까지는 아무에게도 묻지 않고 옛 값을 계속 내어 줍니다. 변경이 퍼져 나가는 것이 아니라, 그들의 사본이 만료되는 것입니다.

TTL: 기다리는 시간을 정하는 숫자

TTL(Time To Live)은 모든 DNS 레코드에 붙는 초 단위 숫자입니다. 레코드 소유자가 리졸버에게 주는 지시로, 이 답을 이만큼은 다시 묻지 않고 재사용해도 된다는 뜻입니다.

중요한 점은 대기 시간을 결정하는 것이 이전 TTL, 즉 리졸버가 답을 캐시할 때 게시돼 있던 값이라는 것입니다. 레코드를 바꾸면서 동시에 TTL을 낮춰도, 이미 옛 사본을 들고 있는 쪽에는 아무 효과가 없습니다. 그들은 옛 기간만큼 그 값을 유지한 뒤에야 새 레코드와 새 TTL을 함께 보게 됩니다.

보이지 않는 캐시는 어디에 있나

조회 한 번이 네다섯 개의 독립된 캐시를 지날 수 있고, 각각이 저마다의 시점에 오래된 값을 들고 있을 수 있습니다.

• 애플리케이션. 많은 런타임이 해석된 주소를 프로세스가 살아 있는 동안 캐시하며, 일부 JVM 설정은 영구히 캐시합니다. 프로세스를 재시작하는 것이 유일한 해결책일 때도 있습니다.
• 운영체제. Windows, macOS, 대부분의 리눅스 환경이 로컬 스텁 캐시를 둡니다.
• 공유기나 사내 리졸버. 가정용 공유기와 회사 리졸버는 공격적으로 캐시하며, 때로는 TTL을 아예 무시합니다.
• 재귀 리졸버. 통신사 리졸버나 1.1.1.1, 8.8.8.8 같은 공개 리졸버입니다. 사람들이 "전파"라고 말할 때 가리키는 대상이자, 내가 어찌할 수 없는 대상입니다.
• 사이트 앞단의 CDN이나 프록시. 이쪽도 자기 주기로 원본 이름을 해석하고 있을 수 있습니다.

앞의 세 개는 내 기기에서 비울 수 있습니다. 네 번째는 다른 사람을 대신해 비워 줄 수 없습니다. "전파를 강제한다"고 주장하는 도구가 있다면 자기 화면만 새로 고치는 것입니다.

전환 작업 계획하기

TTL을 이해해야 하는 이유는 간단합니다. 계획된 변경은 사실상 중단 없이 끝나지만, 계획 없는 변경은 TTL 하나를 통째로 잃습니다. 순서는 이렇습니다.

1. 변경보다 충분히 앞서(최소한 현재 TTL 한 번, 가급적 하루 전) 바꿀 레코드의 TTL을 300초로, 전환 시간이 빠듯하다면 60초로 낮춥니다.
2. 이전 TTL이 지나가기를 기다립니다. 많은 사람이 건너뛰는 단계입니다. 길었던 이전 TTL이 모든 곳에서 만료되기 전까지는 "한 시간 캐시하라"고 적힌 사본을 든 리졸버가 남아 있습니다.
3. 리졸버가 실제로 낮은 TTL을 내주고 있는지 확인합니다. 업체 관리 화면의 표시가 아니라 실제 응답을 봐야 합니다. 변경 전에 여러 리졸버를 비교하세요.
4. 변경을 적용합니다. 이제 최악의 경우가 길었던 옛 TTL이 아니라 짧은 새 TTL입니다.
5. 이전 대상 서버를 최소 TTL 한 번 더 살려 둡니다. 어딘가에는 아직 옛 주소를 든 클라이언트가 있고, 그들에게 오류를 보여 줄 이유가 없습니다.
6. 안정되면 TTL을 원래대로 올립니다. 불필요한 조회 비용을 계속 치를 이유가 없습니다.

캐시가 남은 것인지, 레코드가 잘못된 것인지

브라우저에서 보면 둘은 똑같아 보이지만 해결 방법은 전혀 다릅니다. 구분 기준은 리졸버들이 서로 다른 답을 하는지입니다.

• 일부는 새 값을, 일부는 옛 값을 보여 준다. 캐시 문제입니다. 시간이 지나면 저절로 해결되며, 남은 대기 시간은 이전 TTL을 넘지 않습니다.
• 모든 리졸버가 옛 값을 보여 주고, 이전 TTL도 한참 지났다. 캐시 문제가 아닙니다. 변경이 반영되지 않은 것이니, 실제로 위임된 영역을 편집했는지(등록기관의 NS 레코드가 어느 업체를 권한 서버로 정하는지) 확인하고, 다른 서브도메인의 레코드를 건드리지 않았는지 확인하세요.
• 모든 리졸버는 새 값을 주는데 내 브라우저만 아니다. 오래된 캐시가 로컬에 있습니다. 브라우저를 재시작하고 OS 캐시를 비우고, 애플리케이션이 자체적으로 해석 결과를 캐시하는지 확인하세요.
• 리졸버들이 계속 서로 다른 답을 한다. 권한 서버들이 같은 영역을 서비스하지 않고 있을 수 있습니다. 각 서버의 SOA 시리얼을 비교해 보세요. 값이 다르면 보조 서버가 전송을 받아 가지 못한 것입니다.

여기서 가장 쓸모 있는 신호는 SOA 시리얼입니다. 영역의 버전 번호라서, 최신 버전을 가진 권한 서버라면 모두 같은 값을 보고합니다.

부정 캐시: 오타 뒤에 찾아오는 함정

대부분은 당해 보기 전까지 모르는 두 번째 타이머가 있습니다. 이름이 존재하지 않는다는 답도 캐시되는데, 그 지속 시간은 방금 만든 레코드의 TTL이 아니라 그 영역 SOA 레코드의 minimum 필드에서 옵니다.

그래서 호스트명을 만들기 전에 먼저 조회해 버리면 NXDOMAIN이 캐시되고, 레코드를 만들어도 바로 해결되지 않습니다. SOA minimum이 지나기를 기다려야 하는데, 흔히 3600초이고 훨씬 긴 경우도 있습니다.

실용적인 규칙은 이것입니다. 레코드를 먼저 만들고 그다음에 조회하세요. 이미 부정 캐시를 만들었다면, 감으로 기다리지 말고 그 영역의 SOA minimum을 확인해 정확히 얼마나 기다려야 하는지 파악하세요. 같은 리졸버에 계속 다시 물어봐야 시간이 줄지는 않습니다.

이 가이드에서 잘못된 내용을 발견하셨나요? 다음 주소로 알려 주세요: [email protected] — 확인해서 고치고, 위의 수정일도 함께 갱신합니다.