Domain IP Lookup

실무에서 TTL 정하기

60-300s마이그레이션 중: 빠른 전파, 쿼리 증가
3,600s대부분의 일반 레코드에 적합한 기본값
86,400sMX, NS처럼 거의 바뀌지 않는 레코드
DNS 기초

DNS 캐시 비우는 방법 (OS와 브라우저별)

읽는 시간 4분

컴퓨터는 요청할 때마다 다시 질의하지 않도록 DNS 응답을 저장해 둡니다. 레코드가 바뀌었는데도 계속 이전 목적지가 보이는 이유가 바로 이렇게 저장된 사본 때문입니다. 캐시를 비우면 그 사본을 버리고 새로 조회하도록 강제합니다.

다만 무언가를 비우기 전에, 오래된 캐시가 정말 문제의 원인인지 확인하는 데 30초만 들여 볼 가치가 있습니다. 대부분의 경우 원인이 아니기 때문입니다.

먼저 캐시가 문제인지 확인하세요

나와 원본 사이의 모든 캐시를 우회해서 권한 네임서버에 직접 질의합니다.

캐시가 아니라 원본에 물어보기
dig +short example.com @ns1.example.com
  • 권한 서버는 새 값을 보여 주는데 내 쪽에서는 이전 값이 보인다 — 캐시가 문제입니다. 캐시를 비우면 도움이 될 수 있습니다.
  • 권한 서버도 이전 값을 보여 준다 — 캐시를 비워도 달라지는 것이 없습니다. 레코드가 저장되지 않았거나, 도메인이 위임되지 않은 제공업체에서 레코드를 수정한 것입니다.

핵심 요약

캐시 비우기는 내가 관리하는 컴퓨터의 캐시만 지웁니다. ISP의 리졸버나 다른 사람의 리졸버는 건드릴 수 없으며, 그런 캐시는 레코드의 TTL에 따라 각자의 일정대로 만료됩니다.

Windows

명령 프롬프트 또는 PowerShell을 관리자 권한으로 열고 다음을 실행하세요.

명령 프롬프트 (관리자)
ipconfig /flushdns

Successfully flushed the DNS Resolver Cache(한국어 Windows에서는 “DNS 확인자 캐시를 플러시했습니다.”)라는 메시지가 표시됩니다. 관리자 권한이 없으면 권한 오류와 함께 실패합니다.

비우기 전에 캐시 내용 확인
ipconfig /displaydns

macOS

Big Sur 이후의 모든 버전에서 명령 하나면 됩니다. 비밀번호를 입력하라는 메시지가 나타납니다.

터미널
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

성공해도 출력이 없습니다. 조용하다면 제대로 동작한 것입니다. 두 부분 모두 중요합니다. 앞의 명령은 디렉터리 서비스 캐시를 비우고, 뒤의 명령은 나머지를 보관하는 리졸버 데몬을 재시작합니다.

Linux

Linux는 사용하는 리졸버 데몬이 서로 다르기 때문에 배포판마다 방법이 다릅니다. 먼저 어떤 것을 쓰는지 확인하세요.

사용 중인 리졸버 확인
systemctl is-active systemd-resolved
systemctl is-active nscd
systemctl is-active dnsmasq
systemd-resolved (Ubuntu 18.04+, Fedora, 대부분의 최신 배포판)
sudo resolvectl flush-caches

# Confirm it worked:
resolvectl statistics
nscd
sudo systemctl restart nscd
dnsmasq
sudo systemctl restart dnsmasq

브라우저

브라우저는 운영 체제와 별개로 자체 DNS 캐시를 유지합니다. OS 캐시를 비워도 이 캐시는 지워지지 않습니다. 그래서 dig는 이미 새 주소를 보여 주는데 Chrome에서는 사이트가 계속 이전 주소로 로드되는 일이 생깁니다.

브라우저지우는 방법
Chrome / Edge / Bravechrome://net-internals/#dns에 접속해 Clear host cache를 클릭
Firefoxabout:networking#dns에 접속해 Clear DNS Cache를 클릭
SafarimacOS 캐시를 사용하므로 OS 수준에서 비우기

공유기

가정용 공유기는 집 전체의 DNS를 캐시하는 경우가 많아서, 모든 기기를 하나씩 비워도 여전히 실패하는 일이 있습니다. 공유기를 재시작하면 캐시가 지워집니다. 투박하지만 효과적인 방법입니다. 일부 펌웨어는 관리 화면에서 DNS 캐시 삭제 기능도 제공합니다.

네거티브 캐싱: 새 레코드가 없는 것처럼 보이는 이유

일반적인 곳을 아무리 비워도 해결되지 않아 사람들을 당황하게 하는 경우가 있습니다. 완전히 새로운 서브도메인을 만들고 바로 조회했더니 “존재하지 않음”이라는 응답이 나오고, 레코드가 분명히 적용되어 있는데도 한동안 계속 같은 응답이 나오는 경우입니다.

이것이 네거티브 캐싱입니다. 리졸버는 이름이 존재하지 않는다는 응답을 받으면, 실제 응답을 캐시하는 것과 똑같이 그 부재도 캐시합니다. 다시 질의해도 캐시된 부정 응답에 걸릴 뿐입니다.

그 지속 시간은 방금 만든 레코드가 아니라 존의 SOA 레코드 마지막 필드인 최소 TTL에서 정해집니다. 보통 300초에서 3600초 사이의 값이므로, 새로 만든 이름이 최대 한 시간 동안 없는 것처럼 보일 수 있습니다.

로컬 캐시를 비우는 것은 이 경우에도 도움이 됩니다. 부정 응답도 다른 응답처럼 모든 계층에 저장되기 때문입니다. 그러나 ISP의 리졸버는 자체 사본을 보유하고 있으며, 그것은 만료되기를 기다리는 수밖에 없습니다. 그 지속 시간이 어디서 오는지는 TTL을 참고하세요.

캐시가 존재하는 이유

습관적으로 비우고 싶은 충동을 참을 만한 이유가 있습니다. DNS 캐싱은 실제로 중요한 일을 하고 있습니다. 일반적인 페이지 로드에서는 사이트 자체, 글꼴, 분석 도구, 이미지의 이름을 확인합니다. 캐싱이 없다면 이 모든 것이 단 한 바이트를 가져오기 전에 새로운 왕복 통신을 뜻하게 됩니다.

캐싱은 사용자를 보호하기도 합니다. DNS 제공업체에 장애가 발생해도 만료되지 않은 레코드 사본을 가진 리졸버는 계속 응답을 제공하므로 방문자는 아무것도 눈치채지 못합니다. 캐시를 공격적으로 비우면 이 완충 장치가 사라집니다. 특정한 오래된 응답을 추적할 때 비우세요. 일상적인 위생 관리처럼 비우지는 마세요.

전체 순서, 차례대로

  1. 권한 레코드 확인

    새 값이 원본에서 실제로 적용되어 있는지 확인하세요. 그렇지 않다면 여기서 멈추세요. 캐시 문제가 아닙니다.

  2. 브라우저 캐시 비우기

    가장 흔한 원인이자 가장 쉽게 지울 수 있는 캐시입니다. 시크릿 창에서 테스트해 보아도 됩니다.

  3. OS 캐시 비우기

    위에 나온 플랫폼별 명령을 사용하세요.

  4. 공유기 재시작

    같은 네트워크의 다른 기기에서도 이전 값이 보인다면 공유되는 계층일 가능성이 높습니다.

  5. 다른 네트워크에서 테스트

    모바일 데이터는 완전히 별개의 리졸버 체인을 사용합니다. 거기서 정상 동작한다면 남아 있는 오래된 캐시는 ISP의 것이며, 시간이 지나야만 해결됩니다.

모든 것을 비웠는데도 이전 응답이 보인다면, 내가 제어할 수 없는 캐시를 기다리고 있는 것입니다. DNS 전파는 그 대기 시간을 결정하는 요소를 설명하고, TTL은 다음에 그 시간을 줄이는 방법을 설명합니다.

도메인의 공개 DNS 주소를 확인해야 하나요? Domain IP Lookup 도구를 사용해 보세요.

자주 묻는 질문

관련 글

“전파”란 사실 캐시 만료일 뿐

0분

변경 사항 저장

0-5분

DNS 호스트가 업데이트

TTL까지

이전 응답이 아직 캐시됨

TTL 이후

모두 새 응답을 확인

어디로도 푸시되지 않으며, 각 캐시가 사본 재사용을 멈출 뿐입니다

DNS 기초

DNS 전파, 변경이 오래 걸리는 진짜 이유

실제로 전파되는 것은 없습니다. 기다리는 동안 무슨 일이 일어나는지 이해하면 얼마나 걸릴지, 어떻게 줄일지 정확히 알 수 있습니다.

읽는 시간 3분

실무에서 TTL 정하기

60-300s마이그레이션 중: 빠른 전파, 쿼리 증가
3,600s대부분의 일반 레코드에 적합한 기본값
86,400sMX, NS처럼 거의 바뀌지 않는 레코드
DNS 기초

DNS TTL이란? 적절한 값 정하기

숫자 하나가 변경 사항이 반영되는 속도와 DNS 트래픽의 양을 좌우합니다. 의도적으로 값을 정하는 방법을 소개합니다.

읽는 시간 2분

재귀 DNS 조회, 단계별로 살펴보기

브라우저

example.com 요청

리졸버

내 ISP / 1.1.1.1

루트 + TLD

.com 운영 주체는?

권한 네임서버

실제 응답

체인의 각 단계도 DNS 조회이며 이후 캐시됩니다

DNS 기초

DNS의 작동 원리: 도메인 이름에서 IP 주소까지

인터넷의 전화번호부를 처음부터 끝까지 추적합니다. 도메인을 입력한 뒤 첫 패킷이 서버에 닿기까지 몇 밀리초 동안 무슨 일이 일어날까요?

읽는 시간 3분