DNS TTL 계산기 · 변환기

TTL 계산기 사용법

입력란은 세 개, 계정은 필요 없고, 계산은 전부 이 자리에서 일어납니다. 넣은 값은 어디로도 전송되지 않습니다.

1. 지금 걸린 TTL을 넣습니다. 앞으로 바꿀 레코드에 설정된 TTL을 초나 1h 같은 표기로 넣습니다. 읽을 수 있는 시간으로의 환산과, 그것이 전환용·균형·안정 중 어디에 해당하는지가 나옵니다.
2. 변경 순서를 읽습니다. 작업 중에 쓸 낮은 TTL, 그것을 몇 시간 전에 내보내야 하는지, 전환 뒤 캐시가 따라오기까지 걸리는 시간, 그리고 끝난 뒤 되돌릴 값이 차례로 나옵니다.
3. NXDOMAIN이 나오고 있다면 SOA 숫자도 넣습니다. dig SOA example.kr 를 실행해 minimum 필드와 SOA 레코드 자신의 TTL을 넣으면, RFC 2308 네거티브 캐시 시간 — 고친 뒤 몇 분·몇 시간 동안 그 부정이 남는지 — 이 나옵니다.

네임서버 변경: 언제 낮추고 언제 전환하는가

순서 자체는 짧습니다. 어려운 부분은 얼마나 앞서 낮추느냐이고, 그 답은 지금 걸려 있는 TTL이 정합니다.

1. 먼저 TTL을 낮춥니다. 옮길 레코드의 TTL을 300초로 바꿉니다. 아직 아무것도 옮기지 않습니다.
2. 기존 TTL만큼 기다립니다. 이미 3600으로 캐시해 간 리졸버는 그 한 시간이 끝나야 새 값을 다시 물어봅니다. 안전하게 가려면 두 배를 기다립니다.
3. 그다음에 전환합니다. 이 시점에서 모두가 300초짜리를 들고 있으므로, 실제 전환은 5분 안에 따라옵니다.
4. 안정되면 되돌립니다. 3600이나 14400으로 올려 둡니다. 300을 그대로 두면 질의만 늘어납니다.

여기서 자주 나오는 오해가 하나 있습니다. TTL을 낮추는 것은 전환을 빠르게 만들지 않습니다. 낮추는 시점이 전환보다 충분히 앞서야만 빨라집니다. 전환 당일 아침에 낮추면, 캐시는 여전히 어제의 긴 TTL로 돌아갑니다.

「DNS 반영 시간」을 그만두고 실제로 보는 두 숫자

한국어로 이 문제를 검색하면 거의 항상 「DNS 반영 시간」이라는 한 단어가 나옵니다. 그런데 그 한 단어가 길이가 전혀 다른 두 개의 지연을 덮고 있습니다. 둘을 갈라 놓으면 기다려야 할 시간이 정확해집니다.

아래 숫자는 2026년 9월 5일에 .kr 권위 서버에 직접 물어서 읽은 값입니다. 관리 화면에 적혀 있는 안내가 아니라 실제 응답입니다.

직접 다시 계산해 볼 수 있습니다.

$ dig @c.dns.kr NS naver.kr +noall +authority +answer
naver.kr.  86400  IN  NS  ns1.naver.com.

$ dig @c.dns.kr A zzz-nx-test.kr
kr.  900  IN  SOA  g.dns.kr. ... 3600 900 604800 900

읽는 법은 이렇습니다. 첫 번째 응답의 86400은 네임서버를 바꿨을 때 걸리는 시간입니다. 리졸버가 「이 도메인의 네임서버는 누구인가」를 이미 캐시해 갔다면, 그 답은 24시간 동안 유효합니다. 내 쪽에서 아무리 TTL을 낮춰도 이 구간은 줄지 않습니다 — 애초에 리졸버가 내 네임서버에 물어보지도 않으니까요.

두 번째 응답 마지막 줄의 두 숫자가 네거티브 캐시입니다. SOA 레코드 자신의 TTL이 900, minimum 필드도 900이므로 RFC 2308에 따라 작은 쪽인 900초가 적용됩니다. 도메인이 존재하지 않는다는 답을 받아 간 리졸버는, 위임을 고친 뒤에도 15분 동안 그 부정을 그대로 돌려줍니다.

96배 차이입니다. 「반영 시간」이라는 한 단어로 24시간과 15분을 동시에 가리키고 있었던 것입니다. 네임서버를 바꿨다면 최대 하루를 봐야 하고, 위임이 잠깐 깨졌다가 복구된 것이라면 15분이면 끝납니다. 어느 쪽인지는 dig 한 번으로 갈립니다.

국내 호스팅 업체가 자기 존에서 실제로 돌려주는 값

2026년 9월 5일, 각 업체의 권위 서버에 직접 물어 자사 도메인의 A 레코드 TTL을 읽은 값입니다. 관리 화면의 기본값과는 다른 것이니 주의하세요 — 이건 그들이 실제로 내보내고 있는 숫자입니다.

다섯 곳 모두 자기 사이트에는 짧은 TTL을 씁니다. 언제든 옮길 수 있게 해 두는 것이죠. 고객 존의 기본값이 이것과 같다는 뜻은 아니니, 내 도메인 값은 직접 확인하세요.

네거티브 캐시 계산: 고친 순간에 낫지 않는 이유

도메인이 잠깐이라도 존재하지 않는 상태가 되면 — 위임이 깨졌거나, 레코드를 지웠거나, 이전 중 공백이 생겼거나 — 그 사이에 물어본 리졸버는 「없음」이라는 답을 캐시합니다. 그리고 그 캐시의 수명은 내 레코드의 TTL이 아니라 SOA가 정합니다.

RFC 2308의 규칙은 min(SOA의 minimum 필드, SOA 레코드 자신의 TTL)입니다. minimum만 읽으면 틀립니다 — 두 값이 다른 존이 실제로 많고, 그때는 작은 쪽이 이깁니다.

$ dig SOA example.kr +noall +authority

이것이 장애가 복구보다 늦게 끝나는 이유입니다. 위임을 고쳤는데도 일부 사용자에게는 여전히 안 보인다면, 대개 고장이 아니라 네거티브 캐시가 남아 있는 것입니다. .kr이라면 15분입니다.

자주 보는 TTL 값과 각각의 용도

마지막 줄이 중요합니다. 인터넷에 널리 퍼져 있는 「DNS 변경은 24~48시간」이라는 말은 .com의 172800에서 나온 숫자이지 .kr의 숫자가 아닙니다. .kr은 그 절반인 86400입니다.

$ npm i -g @clize/clize && clize install
$ clize domain check example.kr