DNS TTL 이해하기: 변경이 반영되는 데 시간이 걸리는 이유

모든 DNS 레코드에는 초 단위로 표시되는 TTL(time to live, 생존 시간)이 있습니다. 도메인의 권한 네임서버가 레코드를 가져가는 모든 리졸버에게 보내는 지시입니다. "이 응답은 다시 묻기 전까지 이 시간 동안 재사용해도 좋습니다." TTL이 300초라면 방금 도메인을 조회한 리졸버는 그 사이에 레코드가 바뀌더라도 5분 동안은 다시 묻지 않습니다.

TTL이 균형을 잡는 트레이드오프

TTL이 길면 DNS 질의가 줄고, 더 많은 요청이 캐시에서 처리되므로 평균 조회가 빨라지며, 권한 네임서버의 부하도 줄어듭니다. TTL이 짧으면 레코드 변경이 더 빨리 전파되지만 질의가 더 자주 발생합니다. 모든 경우에 올바른 값은 없으며, 레코드가 얼마나 자주 바뀔 것으로 예상되는지와 오래된 응답을 얼마나 허용할 수 있는 상황인지에 따라 달라집니다.

변경 중에 실제로 일어나는 일

DNS 레코드를 갱신한다고 해서 변경이 인터넷의 모든 리졸버에 밀려 나가지는 않습니다. 권한 네임서버가 다음에 질의받을 때 하는 대답이 바뀔 뿐입니다. 이전 응답을 이미 캐시한 리졸버는 캐시된 사본의 TTL이 만료될 때까지 그것을 계속 제공하므로, 어떤 리졸버와 어떤 캐시가 응답하느냐에 따라 같은 도메인이 잠시 서로 다른 주소로 확인될 수 있습니다.

• 계획된 마이그레이션 전에 하루나 이틀 앞서 TTL을 낮춰 두면 실제 전환이 더 빨리 전파되는데, 흔히 쓰는 실용적인 방법입니다.
• 마이그레이션이 끝나면 TTL은 보통 원래 값으로 다시 올립니다.
• 최근 변경이 없고 TTL이 긴 레코드는 일단 변경되고 나면 전 세계 캐시에서 완전히 사라지는 데 그 TTL 전체 구간이 걸릴 수 있습니다.

실무에서 TTL 고르기

부정 응답도 캐시된다는 점은 간과하기 쉽습니다. 도메인이 존재하지 않을 때 NXDOMAIN 응답 자체가 캐시되며, 이는 별도의 값(애초에 없었던 레코드의 TTL이 아니라 SOA 레코드의 최소 TTL)이 좌우합니다. 새로 등록한 도메인이 등록이 완료되기 전에 리졸버가 이미 NXDOMAIN을 캐시해 두었다는 이유만으로 그 직후 잠시 동안 확인되지 않는 것처럼 보일 수 있습니다.

TTL은 요청일 뿐 보장이 아닙니다

TTL은 권고 사항이며 어떤 외부 기관이 강제하는 것이 아니라는 점을 알아 둘 만합니다. 리졸버는 기술적으로 명시된 TTL보다 오래 응답을 캐시하거나(일부는 질의량을 줄이려고 과부하 상태에서 그렇게 합니다) 더 일찍 제거할 수 있습니다(메모리가 부족한 리졸버는 캐시 항목을 일찍 버릴 수 있습니다). 압도적인 다수의 경우 잘 운영되는 공개 리졸버와 ISP 리졸버는 TTL을 정확하고 예측 가능하게 지킵니다. 하지만 그렇기 때문에 TTL을 바탕으로 한 전파 시간 추정은 계약상의 확고한 보장이 아니라 강력한 경험칙에 해당합니다. 이전 TTL 구간이 지난 뒤에도 변경이 제대로 나타나지 않는다면, 유난히 공격적인 중간 캐시는 드물지만 실제로 있을 수 있는 원인 중 하나이므로 염두에 둘 만합니다.

DNS 변경이 반영되었는지 확인하는 경우, 한 번의 조회는 리졸버 하나가 현재 캐시하고 있는 내용만 알려 줍니다. 몇 분 간격으로 조회를 다시 실행하거나 반복 점검을 예약하면, 오래된 캐시 응답을 한 번 잡고서 그것이 최종이라고 가정하는 것보다 변경이 실제로 전파되었는지 훨씬 믿을 만하게 확인할 수 있습니다.