1. 개요
DNS 는 매일 쓰면서도 “그냥 도메인을 IP 로 바꿔주는 것” 정도로만 알고 넘어가는 경우가 많다. 그런데 장애가 나면 꼭 DNS 캐시, TTL, 네임서버 같은 단어가 튀어나온다. 이번 편에서는 브라우저에 도메인을 치는 순간부터 실제 IP 를 받기까지 조회가 어떤 순서로 일어나는지, 그리고 그 과정에 있는 캐시들이 왜 TTL 을 갖는지 정리한다.
2. 핵심 내용
2-1. 조회는 캐시부터 확인한다
example.com 을 주소창에 치면 곧바로 인터넷에 물어보러 가지 않는다. 순서대로 이렇게 확인한다.
- 브라우저 캐시: 브라우저가 최근에 같은 도메인을 조회한 적이 있으면 그 결과를 그대로 쓴다.
- OS 캐시: 브라우저에 없으면 운영체제의 DNS 리졸버 캐시를 본다(맥이면
dscacheutil, 리눅스면systemd-resolved등). - 로컬 네트워크의 리졸버: 그래도 없으면 보통 공유기나 회사망에 설정된 DNS 서버, 혹은 1.1.1.1 이나 8.8.8.8 같은 퍼블릭 리졸버에 물어본다. 이 리졸버를 재귀적 리졸버(recursive resolver) 라고 부른다. “재귀적” 이라는 이름은 이 서버가 답을 모르면 대신 여기저기 물어보러 다니기 때문이다.
2-2. 재귀적 리졸버가 물어보는 순서
재귀적 리졸버도 캐시가 비어 있으면 처음부터 조회를 시작한다.
- 루트 네임서버: “
.com은 누가 담당하냐” 고 묻는다. 루트는 도메인을 몰라도.comTLD 네임서버 주소는 안다. - TLD 네임서버: “
example.com은 누가 담당하냐” 고 묻는다. TLD 네임서버는example.com의 권한 있는 네임서버(authoritative nameserver) 주소를 알려준다. - 권한 있는 네임서버: 여기가 진짜 답을 갖고 있는 곳이다. 도메인 등록 시 Cloudflare 나 Route53 같은 데 설정해둔 그 네임서버가 이거다.
example.com의 A/AAAA 레코드를 여기서 받는다.
이 세 단계를 매번 거치면 느리기 때문에, 각 단계 결과가 캐시된다. 그래서 웬만한 조회는 2단계, 3단계까지 안 가고 재귀적 리졸버 캐시에서 끝난다.
2-3. TTL: 캐시가 언제까지 유효한지
각 레코드에는 TTL(Time To Live) 이 초 단위로 붙어 있다. 재귀적 리졸버는 이 시간이 지나기 전까지는 다시 물어보지 않고 캐시된 값을 그대로 돌려준다. TTL 이 존재하는 이유는 명확하다.
- TTL 이 없으면 매 요청마다 권한 네임서버까지 왕복해야 해서 느리고, 권한 네임서버에 부하가 몰린다.
- 그렇다고 TTL 을 너무 길게 잡으면, 서버 IP 를 바꿨을 때 전 세계 리졸버들이 옛날 IP 를 한참 들고 있게 된다.
그래서 IP 를 바꿀 계획이 있으면 미리 TTL 을 짧게(예: 300초) 낮춰두고, 전환이 끝난 뒤 다시 늘리는 식으로 운영한다. 장애 대응 중 DNS 를 바꿨는데도 반영이 안 되는 것처럼 보이는 경우, 대부분 원인은 서버가 아니라 어딘가에 남아 있는 캐시의 TTL 이다.
2-4. 자주 헷갈리는 것: 캐시 무효화는 강제로 못 한다
TTL 을 0으로 줄여도, 이미 캐시해간 리졸버들에게 “지금 당장 지워라” 라고 강제할 방법은 없다. DNS 는 풀(pull) 방식이라 리졸버가 알아서 다시 물어볼 때까지 기다려야 한다. 그래서 도메인 이전이나 마이그레이션 작업은 보통 TTL 을 미리 낮춰두고 하루 이상 기다린 다음에 실제 전환을 진행한다.
3. 마무리
요약
- 조회는 브라우저 캐시 → OS 캐시 → 재귀적 리졸버 순으로 확인하고, 재귀적 리졸버는 루트 → TLD → 권한 있는 네임서버 순으로 물어본다.
- TTL 은 “매번 권한 네임서버까지 왕복하는 비용” 과 “옛날 값을 오래 들고 있는 위험” 사이의 절충이다.
- DNS 는 풀 방식이라 캐시를 강제로 지울 수 없다. IP 를 바꾸기 전엔 TTL 을 미리 낮춰야 한다.
다음은 4편: HTTP 1.1에서 HTTP 3까지, 무엇이 왜 바뀌었나 다.