① DNS 조회 — 도메인을 IP로 바꾸는 과정
브라우저가 example.com을 입력받으면 가장 먼저 하는 일이 "이 도메인의 IP가 뭐지?"를 알아내는 것이에요.
전화번호부에서 이름으로 번호를 찾는 것과 같아요.
핵심은 캐시를 단계적으로 확인하고, 없으면 점점 더 높은 서버에 물어보는 구조예요.

핵심 포인트 3가지:
캐시는 단계별로 확인돼요.
브라우저 캐시 → OS 캐시 → ISP 리졸버 캐시 순서로, 어느 단계에서든 찾으면 거기서 바로 끝나요.
그래서 자주 방문하는 사이트는 빠른 거예요.
리졸버가 대신 발품을 팔아요. 브라우저는 직접 루트 서버에 묻지 않고, ISP의 리졸버한테 "알아서 찾아줘"라고 위임해요.
리졸버가 루트 → TLD → 권한 서버 순서로 쫓아가며 IP를 찾아옵니다.
TTL이 캐시 수명을 결정해요. IP 반환 시 TTL(초 단위)도 같이 오는데, 이 시간 동안은 다시 조회 없이 캐시를 써요.
example.com은 TTL이 보통 86400초(1일)예요.
브라우저 DNS 캐시 확인하는 법
크롬 기준으로 주소창에 이렇게 입력하면 돼요:
chrome://net-internals/#dns
현재 캐시된 도메인 목록과 각각의 IP, 만료 시간이 나와요. "Clear host cache" 버튼으로 캐시를 직접 지울 수도 있어요.
TTL이란?
TTL(Time To Live)은 "이 DNS 응답을 얼마 동안 캐시해도 돼?"를 초 단위로 알려주는 값이에요.
예를 들어 example.com의 TTL이 3600이면, 한 번 조회한 결과를 1시간 동안 캐시에 저장해두고 재사용해요.
1시간이 지나면 캐시가 만료되고, 다음 요청 시 DNS 조회를 다시 해요.
# 터미널에서 TTL 직접 확인하기
dig example.com
# 결과 예시
example.com. 3600 IN A 93.184.216.34
# ^^^^
# TTL (초)
TTL을 짧게 설정하면 —
DNS 변경사항이 빠르게 반영돼요.
서버 이전이나 IP 변경 시 유용해요.
대신 DNS 조회가 자주 발생해요.
TTL을 길게 설정하면 —
캐시를 오래 쓰니까 DNS 조회 횟수가 줄고 응답이 빨라요.
대신 IP를 바꿔도 TTL이 만료되기 전까지는 이전 IP로 요청이 가요.
그래서 서버 이전 계획이 있을 때 미리 TTL을 짧게 줄여두는 게 실무 관행이에요.
루트 네임서버
루트 네임서버는 전 세계에 논리적으로 13개예요.
a.root-servers.net ~ m.root-servers.net까지 알파벳 순서로 이름이 붙어 있어요.
근데 물리적으로는 훨씬 많아요. 13개의 IP 주소 뒤에 애니캐스트(Anycast) 기술을 써서 전 세계 1,000개 이상의 서버가 분산되어 있어요. 요청하면 가장 가까운 서버가 응답하는 구조예요.
a.root-servers.net → 198.41.0.4 (Verisign 운영)
b.root-servers.net → 199.9.14.201 (USC-ISI 운영)
c.root-servers.net → 192.33.4.12 (Cogent 운영)
...
m.root-servers.net → 202.12.27.33 (WIDE Project 운영)
루트 네임서버의 역할
루트 네임서버는 IP를 직접 알려주지 않아요. 대신 "그 도메인은 이 TLD 서버한테 물어봐"라고 방향만 알려줘요.
예를 들어 example.com을 조회하면:
리졸버 → 루트 서버: "example.com의 IP가 뭐예요?"
루트 서버 → 리졸버: "모르지만, .com은 a.gtld-servers.net한테 물어봐요"
리졸버 → TLD 서버: "example.com의 IP가 뭐예요?"
TLD 서버 → 리졸버: "모르지만, ns1.example.com한테 물어봐요"
리졸버 → 권한 서버: "example.com의 IP가 뭐예요?"
권한 서버 → 리졸버: "93.184.216.34 이에요"
루트 서버가 담당하는 건 딱 하나 — .com, .net, .kr 같은 TLD(최상위 도메인) 서버의 주소를 알고 있는 것이에요.
인터넷의 모든 DNS 조회는 결국 루트 서버에서 시작돼요.
그래서 루트 서버는 인터넷 인프라의 핵심 중 핵심인데, 실제로 DDoS 공격 대상이 되기도 해요.
2002년, 2007년에 대규모 공격이 있었지만 애니캐스트 덕분에 큰 장애 없이 버텼어요.
'Front-End > 네트워크(브라우저)' 카테고리의 다른 글
| 4. HTTP 요청 — 실제 데이터를 주고받는 규칙 (0) | 2026.03.31 |
|---|---|
| 3-1. TLS 1.2, TLS1.3 차이 (0) | 2026.03.31 |
| 3. TLS handshake — HTTPS 암호화 연결 (0) | 2026.03.31 |
| 2. TCP 연결 — 3-way handshake (0) | 2026.03.31 |
| 0. 브라우저에서 URL 입력했을 때 무슨 일이 일어나는가? (0) | 2026.03.31 |