DNS 조회의 전체 여정 — linux.io를 치면

브라우저 캐시부터 권한 서버까지 여섯 곳을 도는 첫 조회와, 캐시 덕에 0왕복으로 끝나는 두 번째 조회를 나란히 실행한다.

1 / 10주소창에 linux.io를 치고 Enter. 브라우저는 IP 주소를 몰라서, 답을 아는 누군가를 차례로 찾아갑니다.

브라우저 캐시캐시 없음

OS 캐시캐시 없음

재귀 리졸버캐시 없음

루트 서버캐시 없음

.io TLD캐시 없음

권한 서버캐시 없음

첫 조회 — 방문한 곳 0 / 6

단계 목록 · 키보드 ←/→ 이동, Space 재생

DNS는 '한 서버가 답을 아는' 시스템이 아니라, 루트→TLD→권한 서버로 위임을 따라가고 그 결과를 계층마다 캐시하는 분산 전화번호부다.

왜 헷갈리는가

"DNS 바꿨는데 왜 반영이 안 돼요?"와 "어느 서버가 진짜 답을 갖고 있어요?"가 단골 질문이다. 답을 갖는 곳(권한 서버)과 답을 물어봐 주는 곳(재귀 리졸버), 답을 기억하는 곳(캐시 계층)이 다르기 때문이다.

첫 조회는 여섯 곳을 순서대로 거친다. 브라우저 캐시와 OS 캐시는 비어 있고, 재귀 리졸버가 대신 루트에 묻는다. 루트는 답이 아니라 방향(.io는 저쪽)을 주고, TLD도 방향(권한 서버는 저쪽)을 준다. 답은 오직 권한 서버만 갖고 있다.

답이 돌아오는 길에 리졸버·OS·브라우저가 전부 TTL만큼 기억한다. 그래서 두 번째 조회는 네트워크에 나가지도 않는다 — 방문 수 6 대 1이 화면의 요점이다.

장애와 삽질의 대부분은 캐시 계층과 위임 구조에서 나온다.

레코드를 바꿔도 즉시 반영되지 않는 이유: 전 세계 리졸버가 이전 값을 TTL만큼 들고 있다. 이전(migration) 전에 TTL을 미리 300초쯤으로 줄여 두는 것이 표준 절차다.
dig +trace는 이 애니메이션 그대로를 실행한다 — 루트부터 위임을 직접 따라가므로 캐시를 배제한 진짜 상태를 본다.
8.8.8.8(구글)·1.1.1.1(클라우드플레어)은 재귀 리졸버다. 권한 서버(Route 53, Cloud DNS의 NS)와 역할이 다르다 — 장애 원인 분석 시 어느 쪽이 아픈지부터 갈라야 한다.
negative 캐시: '없다'는 답(NXDOMAIN)도 캐시된다. 오타 도메인을 잘못 만들었다 지우면 한동안 계속 없다고 나온다.

루트 서버가 모든 도메인의 답을 갖는 설계였다면 초당 수조 건을 받아야 한다. 위임(계층)이 쓰기 권한을 나누고, 캐시(TTL)가 읽기 부하를 흡수한다 — 인터넷 규모에서 살아남는 거의 모든 시스템이 이 두 수를 쓴다.