개요

DNS TTL은 레코드가 캐시로 유지되는 시간의 기준값으로 초 단위 설정값임. 권한 네임서버가 응답에 TTL을 포함하고, 재귀 리졸버와 클라이언트가 이 시간 동안 결과를 기억함. TTL이 만료되면 다시 질의가 발생함

핵심 개념

  • TTL Time To Live
  • DNS 응답을 브라우저나 재귀 DNS 서버가 얼마 동안 캐시할지 정하는 값
  • 예 TTL이 300이면 해당 레코드는 5분간 캐시 유지, 이후 재질의 발생
  • 부존재 응답 NXDOMAIN 역시 SOA 설정에 따라 일정 시간 캐시됨

왜 중요한가

  • TTL이 짧으면 변경 사항이 빠르게 반영됨
    • 트래픽 변화 대응 용이
    • 대신 DNS 요청 수 증가로 지연과 비용 증가 가능
  • TTL이 길면 질의 수가 줄어 효율적이고 안정적임
    • 캐시 적중률 상승
    • 대신 변경 반영이 느림

권장 TTL 값 가이드

  • 일반 웹사이트 300600 510분
  • 트래픽 변화가 잦은 API 60~300
  • 안정적이고 변경이 드문 서비스 360086400 1시간하루
  • 레코드 변경 직전 예 이관 60 이하로 낮춰 사전 준비

참고 사항

  • 일부 리졸버와 캐시 계층은 최소 또는 최대 TTL 정책을 적용할 수 있어 설정값과 실제 캐시 시간이 다를 수 있음
  • 브라우저는 보통 OS 리졸버 캐시를 따르며, CDN 또는 로드밸런서는 자체 캐시 정책을 가질 수 있음

예시

A Record
Name app.example.com
Value 13.125.12.34
TTL 300

이 설정이면 클라이언트는 5분 동안 app.example.com → 13.125.12.34 매핑을 캐시하고 만료 후 재질의함

베스트 프랙티스와 주의점

  • 변경이 예정되어 있다면 충분한 시간 전에 TTL을 낮추고, 변경 완료 후 다시 정상값으로 복원
  • MX, NS, CNAME 등 모든 레코드에 TTL 존재. CNAME 체인이 길면 전체 해석에 관여하는 각 레코드의 TTL 영향 합성됨
  • TTL을 과도하게 짧게 두면 재귀 리졸버 캐시 적중률이 떨어져 지연이 늘 수 있음. 응답 시간과 변경 민감도 간 균형 필요
  • 장애 대응 목적이라면 애플리케이션 계층의 롤링 배포, 헬스체크 기반 라우팅 등과 조합. TTL만으로 즉시 전환을 보장하기 어려움

결론 요약

  • TTL은 DNS 정보의 유효 시간
  • 짧으면 반영이 빠르나 요청 증가와 지연 가능성 존재
  • 길면 효율적이나 변경 반영 지연
  • 일반적으로 300 5분이 실무에서 균형점으로 자주 사용됨

참고자료