DNS TTL과 캐싱 — 'DNS 전파'의 진짜 정체

DNS TTL(Time To Live)은 도메인 레코드 하나를 얼마 동안 캐시해도 되는지를 초 단위로 알려주는 값이다. TTL이 300이면 리졸버는 그 응답을 5분간 재사용하고, 만료되면 다시 물어본다. 우리가 흔히 "DNS 전파(propagation)에 몇 시간 걸린다"고 말하는 지연의 정체가 바로 이 TTL에 걸린 캐시가 만료되기를 기다리는 시간이다.

도메인 IP를 바꿨는데 어떤 사람은 새 서버로, 어떤 사람은 여전히 옛 서버로 가는 경험, 다들 한 번쯤 해봤을 거다. 나는 이걸 "DNS가 원래 느린 거"라고 뭉뚱그려 이해했다가, TTL을 제대로 알고 나서 배포 사고를 여러 번 피했다.

캐시가 겹겹이 쌓이는 구조

DNS 응답은 한 곳이 아니라 여러 계층에 캐시된다. 그래서 내가 권한 있는 네임서버에서 레코드를 바꿔도, 그 변경이 사용자에게 닿기까지 여러 캐시가 만료돼야 한다.

즉 "전파"라는 건 실제로 정보가 퍼져 나가는 게 아니다. 각 리졸버가 낡은 캐시를 버리고 새로 물어보는 시점이 제각각이라 생기는 시차일 뿐이다. TTL이 짧을수록 이 시차가 줄어든다.

TTL 값 읽고 확인하기

dig로 현재 TTL을 실시간으로 볼 수 있다. 흥미로운 건, 같은 질의를 반복하면 캐시된 리졸버에서는 TTL이 남은 시간만큼 줄어든 채 온다는 점이다.

# A 레코드와 TTL 확인 (응답의 두 번째 컬럼이 남은 TTL)
dig example.com A
# 예시:
# example.com.  283  IN  A  93.184.216.34
#               ^^^ 남은 캐시 시간(초). 다시 조회하면 더 줄어듦
# 권한 네임서버에 직접 물어 원본 TTL 보기 (캐시 우회)
dig @ns1.example.com example.com A +noall +answer

배포 전에 이걸로 원본 TTL을 확인해두면, "이 변경이 최악의 경우 몇 분 뒤에 완전히 반영되는지"를 예측할 수 있다. 최대 지연은 대략 그 도메인 레코드의 TTL 값이다.

실전: 마이그레이션 전에 TTL을 낮춰라

서버 IP를 바꾸는 마이그레이션에서 내가 반드시 하는 절차가 있다. 갑자기 IP를 바꾸면 TTL만큼(예: 하루) 일부 사용자가 옛 서버로 가서, 그동안 양쪽으로 트래픽이 갈린다. 그래서 이렇게 한다.

• 며칠 전: 해당 레코드 TTL을 평소 3600에서 60~300초로 미리 낮춘다. 단, 기존 TTL이 만료돼야 이 낮은 값이 퍼지므로 여유를 둔다.
• 전환일: IP를 새 값으로 바꾼다. TTL이 짧으니 몇 분 내 대부분 리졸버가 새 IP를 받는다.
• 안정 후: 잦은 질의로 인한 부하를 줄이려 TTL을 다시 올린다.

낮은 TTL은 전환을 빠르게 하는 대신 질의 횟수를 늘려 네임서버 부하와 평균 조회 지연을 키운다. 그래서 평소엔 넉넉히(수십 분~시간), 변경 직전에만 짧게 가져가는 게 정석이다. 항상 낮게 두는 건 낭비다.

없는 레코드도 캐시된다: 네거티브 캐싱

의외로 놓치기 쉬운 지점이 하나 있다. "그런 레코드 없음(NXDOMAIN)"이라는 응답도 캐시된다는 사실이다. 이걸 네거티브 캐싱이라 하고, 지속 시간은 개별 레코드 TTL이 아니라 도메인의 SOA 레코드에 있는 minimum 값이 결정한다.

그래서 새 서브도메인을 만들었는데 "없다"고 나오면, 방금 전에 누군가(혹은 내가) 그 이름을 조회하는 바람에 없음이 캐시됐을 수 있다. 이땐 레코드 TTL을 아무리 만져도 소용없고, SOA minimum이 만료되기를 기다려야 한다. 새 도메인 세팅 후 안 풀릴 때 SOA를 확인하면 원인이 보이는 경우가 많다.

TTL로 안 되는 것

TTL을 0으로 둔다고 캐시가 완전히 사라지진 않는다. 많은 공용 리졸버가 자체적인 최소 TTL을 강제해, 너무 낮은 값은 무시하고 자기 하한(예: 30초)으로 올려 캐시한다. 또 브라우저와 앱은 DNS TTL과 무관하게 자기만의 짧은 캐시를 두기도 한다. 그러니 "TTL 0이면 즉시 반영"은 환상이다. TTL은 상한을 통제할 뿐, 하한까지 내 마음대로 되는 건 아니다.

자주 묻는 질문

DNS 전파가 24~48시간 걸린다는 말이 사실인가요?

과장된 통념입니다. 실제 최대 지연은 대체로 해당 레코드의 TTL 값에 가깝습니다. TTL이 300초면 5분 안팎이면 대부분 반영됩니다. 예전엔 TTL을 하루로 크게 잡는 경우가 많아 그런 통념이 생겼습니다.

TTL을 아주 짧게 하면 무슨 단점이 있나요?

캐시가 자주 만료돼 리졸버가 권한 네임서버에 더 자주 질의합니다. 그만큼 네임서버 부하와 사용자 조회 지연이 늘어납니다. 그래서 평소엔 넉넉하게 두고, IP 변경 직전에만 낮추는 방식을 권합니다.

레코드를 바꿨는데 여전히 옛 IP가 나와요.

어딘가에 이전 TTL이 만료되지 않은 캐시가 남아 있는 겁니다. dig로 남은 TTL을 확인하고, 로컬 OS·브라우저 DNS 캐시도 비워보세요. 권한 네임서버에 직접 질의해 원본이 바뀌었는지부터 확인하는 게 순서입니다.

TTL을 0으로 하면 캐시가 전혀 안 되나요?

이론상 캐시하지 말라는 뜻이지만, 많은 리졸버가 자체 최소 TTL을 강제해 그 값으로 올려 캐시합니다. 따라서 0으로 둬도 완전한 실시간 반영은 보장되지 않으며, 불필요한 질의만 늘 수 있습니다.