DNS 캐싱: 작동 원리

웹사이트를 방문할 때마다 기기는 하나의 질문을 던집니다. "이 도메인의 IP 주소가 뭐지?" 캐싱이 없다면, 같은 페이지를 1초 뒤에 새로고침할 때도 매번 이 질문을 새로 해야 합니다. DNS 캐싱은 시스템이 "저번에 답을 기억해 뒀어"라고 말하는 방식입니다.

그런데 기억에는 함정이 있습니다. 캐시된 답변은 모두 "마지막으로 물어봤을 때부터 세상이 바뀌지 않았다"는 도박입니다.

도박

캐싱은 DNS를 빠르게 만듭니다. 새로운 조회는 50~200밀리초가 걸립니다—요청이 인터넷을 가로질러 권위 서버까지 갔다가 돌아옵니다. 캐시 조회는 1밀리초도 안 걸립니다. 모든 웹 요청 전에 일어나는 일치고는 그 차이가 엄청납니다.

하지만 속도에는 대가가 따릅니다. 답을 캐시하면 그 답이 여전히 맞다고 신뢰하는 것입니다. 대부분은 맞습니다. 가끔은 틀립니다. 그리고 어느 쪽인지 알 방법이 없습니다.

네 겹의 기억

DNS 쿼리는 각자의 기억을 가진 네 개의 캐시를 통과합니다.

브라우저는 약 60초 동안 기억합니다. 가장 빠른 캐시이자 가장 짧은 기억입니다. 브라우저를 닫으면 모든 것을 잊습니다.

운영 체제는 더 오래—몇 분에서 몇 시간까지—기억합니다. 이 기억은 브라우저를 재시작해도 살아남습니다. Windows에서는 ipconfig /displaydns 명령으로 시스템이 기억하는 내용을 볼 수 있습니다. (macOS는 DNS 캐시 내용을 직접 노출하지 않지만, 필요할 때 초기화할 수 있습니다.)

리졸버 (보통 ISP, 또는 Cloudflare나 Google 같은 서비스)는 수백만 명의 사용자를 대신해 기억합니다. 같은 도시 누군가가 인기 도메인을 조회하면, 모두가 그 기억의 혜택을 받습니다. 이것이 가장 영향력 있는 캐시입니다—현재 브라우저 세션에서 한 번도 방문하지 않았어도 google.com이 즉시 조회되는 이유입니다.

CDN 엣지 서버는 관리하는 도메인에 또 다른 계층을 추가합니다. 표준 계층 구조의 일부는 아니지만, 같은 방식으로 작동합니다. 답을 기억하고, 빠르게 제공합니다.

각 계층은 위 계층에 묻기 전에 자신의 기억을 먼저 확인합니다. 인기 있는 도메인은 거의 항상 캐시에서 답이 나옵니다. 잘 안 알려진 도메인은 질문이 권위 서버까지 전달되었다가—다음번을 위해 기억됩니다.

TTL: 얼마나 오래 기억할까

모든 DNS 레코드에는 숫자가 붙어 있습니다. 초 단위로 측정되는 TTL(Time to Live)입니다. 권위 서버가 "이 답을 이만큼 신뢰해도 돼"라고 말하는 방식입니다.

TTL이 3600이면 "한 시간 동안 기억해"라는 뜻입니다. TTL이 300이면 "5분 후에 잊어"라는 뜻입니다. 도메인 소유자는 인프라의 안정성에 따라 TTL을 결정합니다.

• 긴 TTL (시간~일 단위): DNS 쿼리가 줄고 성능이 좋아지지만, 변경 사항이 전파되는 데 오래 걸립니다
• 짧은 TTL (분 단위): 변경 사항이 빨리 적용되지만, DNS 시스템에 더 많은 부하를 줍니다

안정적인 프로덕션 웹사이트는 24시간 TTL을 쓸 수 있습니다. 호스팅 업체를 바꾸려는 사이트는 일시적으로 60초로 낮췄다가, 이전이 완료되면 다시 높입니다.

전파 문제

DNS 캐싱이 진짜 묘한 이유가 여기 있습니다. "잊어버려" 버튼이 없습니다.

DNS 레코드를 변경할 때, 인터넷의 모든 캐시에 "이전 답을 믿지 마"라는 메시지를 보낼 수 없습니다. 그냥 기다려야 합니다. TTL이 만료될 때까지 모든 캐시는 이전 답을 계속 제공합니다. 한 시간 전에 3600초 TTL로 도메인을 조회했다면, 그 사람은 당신이 무슨 일을 해도 한 시간 더 이전 답을 받게 됩니다.

이것이 전파 지연입니다. 버그가 아니라 시스템의 작동 방식입니다. DNS는 한번 말한 것을 취소할 방법이 없습니다. 모두가 이전 답을 믿는 것을 멈출 때까지 기다릴 뿐입니다.

영리한 관리자는 변경에 미리 대비합니다. 내일 서버를 바꿀 계획인가요? 오늘 TTL을 300초로 낮추세요. 그러면 변경을 적용할 때 모든 캐시가 몇 시간이 아닌 5분 안에 만료됩니다.

도박이 맞아떨어질 때

대부분의 경우, 캐싱은 순수한 이득입니다. 안정적인 웹사이트에서는 DNS가 잠재적인 병목에서 눈에 띄지 않는 무언가로 탈바꿈합니다. 수백만 명의 사용자가 같은 도메인을 방문해도 권위 서버에 과부하를 주지 않습니다—리졸버가 요청의 90% 이상을 캐시에서 처리합니다.

DNS 캐싱이 없다면 인터넷은 사용 불가능해질 것입니다. 클릭할 때마다 새로운 조회를 기다려야 합니다. DNS 서버는 부하를 감당하지 못하고 무너질 것입니다.

도박이 빗나갈 때

비상 상황에서—DDoS 공격, 서버 장애, 긴급 마이그레이션—캐싱은 당신의 적이 됩니다. 트래픽을 지금 당장 이동시켜야 하는데, 캐시는 여전히 이전 답을 내보냅니다. 사용자들은 캐시가 그것을 기억하고 있기 때문에 죽은 서버에 계속 연결하려 합니다.

이것이 긴급 장애 조치가 종종 DNS를 완전히 우회하는 이유입니다. 분 단위로 중요할 때, 캐시 만료를 기다리는 것은 받아들일 수 없습니다. 팀은 IP 기반 솔루션이나 미리 배치된 인프라를 사용합니다.

일부 브라우저는 지정된 TTL을 넘어서까지 캐시를 유지해 상황을 악화시킵니다—기술적으로 잘못된 동작이지만 실제로 일어납니다. "DNS 캐시를 지워라"가 문제 해결 조언으로 나오는 이유가 그 때문입니다. 대부분의 사용자는 그게 무슨 뜻인지도 모르지만요.

트레이드오프

DNS 캐싱은 핵심적인 긴장 관계를 담고 있습니다. 속도와 신선함, 둘 다 완전히 가질 수는 없습니다.

긴 TTL은 민첩성을 희생하고 속도를 얻습니다. 짧은 TTL은 속도(와 더 높은 DNS 부하)를 희생하고 민첩성을 얻습니다. 공짜 점심은 없습니다—지금 무엇이 더 중요한지에 따라 조절할 수 있는 다이얼이 있을 뿐입니다.

대부분의 도메인에서 대부분의 시간에는 더 긴 TTL을 택하세요. 인프라가 시간마다 바뀌지는 않을 테니까요. 캐시가 제 역할을 하게 두세요. 변경이 예정되어 있다면 미리 계획하세요. TTL을 낮추고, 변경하고, 다시 높이세요.

인터넷은 캐시된 답변 위에서 돌아갑니다. 그 답변들이 도박이라는 것을—보통은 맞고, 가끔은 틀리고, 항상 임시적인—이해하면, 시스템과 싸우는 대신 함께 일할 수 있게 됩니다.

DNS 캐싱에 대해 자주 묻는 질문

DNS 캐시를 어떻게 지우나요?

어느 계층을 지우느냐에 따라 다릅니다. 브라우저는 닫았다가 다시 열면 보통 됩니다 (또는 브라우저 내장 캐시 지우기 기능을 사용하세요). 운영 체제의 경우: macOS에서는 sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder를 실행하세요. Windows에서는 명령 프롬프트에서 ipconfig /flushdns를 실행하세요. ISP 리졸버 캐시는 지울 수 없습니다—TTL이 만료될 때까지 기다려야 합니다.

DNS 변경이 전파되는 데 왜 그렇게 오래 걸리나요?

캐시에게 잊으라고 말할 방법이 없기 때문입니다. DNS 레코드를 변경하면, 이미 이전 답을 가진 모든 캐시는 TTL이 만료될 때까지 계속 그것을 제공합니다. TTL이 24시간이었다면, 완전한 전파에 그만큼 걸립니다. 변경 전에 TTL을 낮추면 이 과정을 빠르게 할 수 있습니다.

어떤 TTL을 사용해야 하나요?

안정적인 인프라의 경우, 3600초(1시간)에서 86400초(24시간)가 일반적입니다. 자주 변경되는 도메인이나 계획된 마이그레이션 중에는 60~300초를 사용하세요. 트레이드오프는 항상 같습니다. 긴 TTL은 더 나은 성능을 주지만 업데이트가 느리고, 짧은 TTL은 더 빠른 업데이트를 주지만 DNS 쿼리가 많아집니다.

DNS 변경을 즉시 적용할 수 있나요?

아니요. 변경 전에 미리 TTL을 낮춰 두면 캐시가 빨리 만료됩니다. 하지만 인터넷 전체의 기존 캐시 항목을 무효화할 수는 없습니다. 이것은 DNS가 작동하는 방식의 근본적인 한계입니다.