Skip to content

DNS 설정 TTL(Time To Live)

GPT 5.4 Thinking

DNS 설정의 TTL(Time To Live)

DNS 조회 결과를 얼마 동안 캐시에 저장해 둘지 정하는 시간이야.

예를 들어: • TTL = 300 이면 300초(5분) 동안 • 인터넷 제공업체 DNS, 회사 DNS, 브라우저, OS 등이 해당 도메인의 IP 정보를 다시 묻지 않고 캐시해서 씀

쉽게 말하면

도메인 example.com 이 1.2.3.4 를 가리킨다고 할 때,

TTL이 길면:
• 조회가 덜 일어나서 안정적
• 대신 IP 바꿨을 때 반영이 늦을 수 있음

TTL이 짧으면:
• 변경 반영이 비교적 빠름
• 대신 DNS 조회가 더 자주 일어남

자주 쓰는 값

• 300초: 변경 가능성이 있거나 운영 중 자주 바꿀 때
• 3600초(1시간): 일반적인 기본값
• 86400초(24시간): 거의 안 바뀌는 레코드

실무에서 중요한 점

서버 이전이나 IP 변경 예정이면,
미리 TTL을 300 같은 짧은 값으로 낮춰놓고
변경 작업한 뒤 안정화되면 다시 늘리는 식으로 많이 해.

주의

TTL이 300이라고 해서 무조건 5분 안에 전 세계가 완전히 반영되는 건 아니야.
중간 캐시 DNS 정책 때문에 조금 더 늦을 수도 있어.

A 레코드, CNAME, MX 기준으로 TTL을 얼마로 두면 좋은지 상황별로 추천

A 레코드

서버 IP를 직접 가리키는 레코드라서, 변경 가능성이 있으면 짧게 두는 편이 좋아.
• 자주 바뀔 수 있음 / 이전 예정 있음: 300초
• 일반 운영: 600 ~ 3600초
• 거의 안 바뀌는 고정 인프라: 3600 ~ 86400초

보통은 A 레코드는 300 또는 600초로 많이 시작해.
특히 네처럼 서버, 미니PC, NAS, 포워딩, 이전 작업 가능성이 있으면 300초가 편하다.

CNAME

다른 도메인 이름을 가리키는 용도라서, 대상이 CDN이나 외부 서비스면 너무 길게 잡지 않는 게 안전하다.
• 외부 서비스 연결, CDN, SaaS: 300 ~ 600초
• 내부적으로 거의 안 바뀌는 별칭: 1800 ~ 3600초

보통 CNAME은 300초가 가장 무난하다.
특히 www, api, img 같은 서브도메인은 300으로 두면 운영이 편하다.

MX

메일 서버 레코드는 자주 안 바뀌니까 일반적으로 좀 길게 둬도 된다.
• 일반 운영: 3600 ~ 14400초
• 메일 이전 작업 직전/직후: 300 ~ 600초로 잠시 낮춤
• 안정화 후: 다시 3600 이상으로 올림

보통 MX는 3600초(1시간) 정도면 충분히 좋다.
메일은 너무 자주 바뀌는 항목이 아니라서 A/CNAME보다 길게 잡는 편이다.

실전 추천값

네가 개인 서버나 홈서버, API, 이미지 서버 운영하는 느낌이면 이렇게 추천해.
• A 레코드: 300
• CNAME: 300
• MX: 3600

예외

• 서버 이전 예정이면 하루 전쯤 TTL을 300으로 낮춤
• 이전 완료 후 문제 없으면 다시 3600 이상으로 올림
• 정말 거의 안 바뀌는 도메인만 길게 둠

네 상황 기준으로 한 줄 추천하면
웹/API용 A, CNAME은 300 / 메일 MX는 3600 이 제일 무난해.