인터넷 주소는 어떻게 IP를 찾아갈까?

브라우저가 shop.example.com 같은 주소로 연결을 시작하면, 그 도메인 이름의 IP를 DNS로 찾는 조회가 먼저 일어납니다. 결론부터 말하면, 도메인→IP는 재귀 리졸버의 캐시와 여러 DNS 서버를 거치는 조회이고, 한 번 찾으면 TTL 동안 캐시에서 바로 답합니다.

조회 경로

처음 찾는 주소라면 조회는 이렇게 내려갑니다.

• 브라우저/앱 → OS 스텁 리졸버: 요청을 DNS 조회 서버(재귀 리졸버)로 전달만 합니다.
• 재귀 리졸버: 캐시에 없으면, 대신 끝까지 물어봅니다.
• 루트 → TLD: 루트와 TLD 서버는 답을 주지 않고 다음 서버를 알려주는 위임만 합니다.
• 권한 서버: 마지막으로 최종 IP(A 레코드)를 응답합니다.

즉 루트·TLD는 "캐시 미스"가 아니라 길을 안내하는 단계이고, 실제 답은 권한 서버가 줍니다.

캐시와 TTL

재귀 리졸버는 받은 답을 TTL(Time To Live) 동안 캐시해 둡니다. TTL은 "이 답을 몇 초 동안 믿어도 되는가"입니다. 그래서 같은 주소를 다시 조회하면 루트까지 갈 필요 없이 즉답합니다.

한 가지 더 있습니다. 리졸버는 최종 IP뿐 아니라 권한 서버의 위치(NS 위임) 도 따로, 대개 더 길게 캐시합니다. 그래서 짧은 IP 캐시(A)가 만료돼도 위임 캐시가 살아 있으면, 루트·TLD를 건너뛰고 권한 서버로 바로 다시 물어봅니다.

데모 사용법

첫 화면은 콜드 조회 한 건이 채워진 상태입니다.

• 조회: 캐시 상태에 따라 1단계(IP 캐시 히트) · 2단계(권한 직행) · 4단계(완전 콜드)로 갈립니다.
• IP 주소 캐시 시간(A TTL): 짧게 두면 카운트다운이 0이 되는 걸 보고, A만 만료된 상태를 만들 수 있습니다.
• 전체 캐시 비우기: A와 위임을 모두 지워 완전 콜드로 되돌립니다.

카드 아래 다음 → 안내를 따라가면, "느린 전체 조회 → 빠른 캐시 히트 → 권한 직행"을 순서대로 볼 수 있습니다.

결과 해석

• 1단계(IP 주소 캐시 히트): 가장 빠름. 리졸버 캐시가 바로 답했습니다.
• 2단계(권한 서버 위치 캐시 히트): A는 만료됐지만 위임이 살아 권한 서버로 직행.
• 4단계(완전 콜드): 캐시가 비어 루트부터 전체 경로.

같은 결과라도 캐시 상태에 따라 걸리는 단계가 다르다는 것 — 이게 DNS 캐시와 TTL의 핵심입니다.

실제 조회와 비교하기

데모는 정해진 장면을 보여주지만 실제 컴퓨터에서는 dig로 응답과 TTL을 볼 수 있습니다.

# 현재 설정된 재귀 리졸버에 A 레코드 조회
dig example.com A

# 루트부터 위임 경로를 따라가며 조회
dig +trace example.com A

첫 명령의 ANSWER SECTION에는 받은 IP와 남은 TTL이 표시됩니다. 바로 다시 실행하면 같은 리졸버 캐시에서 TTL이 줄어든 답을 볼 수 있습니다. +trace는 로컬 리졸버의 일반 재귀 조회를 그대로 재현하는 명령이 아니라, 도구가 루트부터 권한 서버까지 직접 따라가며 위임을 관찰하는 방식입니다. 둘의 시간이 다르다는 사실만으로 평소 DNS가 느리다고 판단하면 안 됩니다.

존재하지 않는 이름의 결과도 일정 시간 캐시할 수 있습니다. 이를 부정 캐싱이라고 하며, 오타 난 이름을 반복해서 루트부터 조회하지 않게 합니다. 데모는 처음 배우는 흐름을 짧게 유지하려고 성공한 A 레코드와 NS 위임만 보여줍니다.

이 데모는 원리를 보여주기 위한 단순화한 시뮬레이션이며 실제 조회나 지연이 아닙니다. 예시 도메인은 문서용 예약 도메인(example.com/example.net), IP는 문서용 대역(192.0.2.0/24)만 씁니다. 재귀 리졸버 캐시 한 곳만 모델링하며 DNSSEC·부정 캐싱·복수 IP 등은 생략했습니다.

참고: RFC 1034 · RFC 1035 · RFC 2308(부정 캐싱) · RFC 9499(DNS 용어), Google Public DNS