DNS TTL이란? 적절한 값 정하기

TTL은 Time To Live의 약자입니다. 모든 DNS 레코드에 붙는 초 단위의 숫자이며, 리졸버가 다시 묻기 전까지 이 응답을 얼마나 재사용해도 되는지에 답합니다.

DNS 설정 중에서 가장 덜 고려되는 항목입니다. 대부분은 제공업체가 정한 기본값을 그대로 받아들이고, 긴급한 마이그레이션 중에야 그 존재를 알게 되지만 그때는 의미 있게 바꾸기에 너무 늦습니다.

트레이드오프

실제 TTL은 어떻게 보이나요

example.com.    3600    IN    A     93.184.216.34
example.com.   86400    IN    NS    ns1.example.com.

dig로 질의하면 설정된 값이 아니라 남은 TTL이 표시됩니다. 같은 질의를 몇 초 간격으로 두 번 실행해 숫자가 줄어드는 것을 확인해 보세요. 리졸버 캐시가 카운트다운되는 모습을 실시간으로 보는 것입니다.

dig +noall +answer example.com
# wait 10 seconds, then
dig +noall +answer example.com

레코드 유형별 권장 값

마이그레이션 패턴

외워 둘 만한 유일한 TTL 워크플로입니다. 하루 동안 이어질 수 있는 장애 위험을 5분으로 줄여 주기 때문입니다.

1. 1

   변경하기 최소 이전 TTL 한 주기 전에 TTL 낮추기

   현재 TTL이 3600이라면 300으로 변경하고 최소 1시간 기다리세요. 다른 것은 바꾸지 마세요.

2. 2

   짧은 TTL이 제공되는지 확인

   레코드를 질의해 TTL이 300에서부터 카운트다운되는지 확인하세요. 이제 여러분의 레코드를 보관 중인 모든 캐시가 5분 타이머로 동작합니다.

3. 3

   실제 변경 수행

   주소를 수정합니다. 이제 누구든 최대 대기 시간은 5분입니다.

4. 4

   검증한 뒤 TTL 복원

   트래픽이 새 서버로 옮겨 갔다면 TTL을 3600으로 되돌려 질의 비용 부담을 멈추세요.

TTL과 복원력

거의 언급되지 않는 높은 TTL의 장점이 있습니다. DNS 제공업체에 장애가 생겨도 레코드를 아직 캐시하고 있는 리졸버는 계속 응답한다는 점입니다. 24시간 TTL이라면 몇 시간 동안 이어지는 DNS 장애도 대부분 눈에 띄지 않고 넘길 수 있습니다. 60초 TTL이라면 거의 즉시 서비스가 끊깁니다.

안정적인 레코드에서는 TTL을 넉넉하게 높게 유지하고, 낮은 TTL은 기본 방침이 아니라 일시적인 마이그레이션 도구로 다루어야 한다는 실질적인 근거입니다. 레코드가 바뀔 때 무엇을 기다리는 것인지는 DNS 전파에서 다룹니다.