www.google.com을 입력하면 일어나는 일
(DNS 쿼리 추적 실습)
우리가 매일같이 브라우저 주소창에 www.google.com 같은 도메인 이름을 입력하면, 어떻게 컴퓨터는 구글 서버를 찾아가는 걸까요? 이 과정의 첫 단추는 바로 DNS(Domain Name System)를 통한 '이름 풀이'입니다. DNS는 인터넷의 거대한 전화번호부처럼, 사람이 기억하기 쉬운 도메인 이름을 컴퓨터가 이해하는 IP 주소로 바꿔주는 핵심적인 시스템입니다.
이론으로만 들으면 막연하게 느껴지는 이 과정을, 『도커로 구축한 랩에서 혼자 실습하며 배우는 네트워크 프로토콜 입문』 도서의 실습 환경을 통해 직접 추적하며 파헤쳐 보겠습니다. 내 PC 안에서 벌어지는 DNS의 여정을 함께 따라가 보시죠.
DNS 이름 풀이의 주인공들
DNS의 동작을 이해하기 위해 먼저 세 명의 핵심 플레이어를 알아야 합니다. 책에서는 이들을 각각의 역할을 가진 컨테이너로 구현하여 직접 관찰할 수 있습니다.
DNS 클라이언트 (cl1): "IP 주소 알려주세요!"라고 가장 먼저 질문을 던지는 우리의 PC입니다.
캐시 서버 (ns1): 클라이언트의 요청을 받아 IP 주소를 찾아다니는 부지런한 중개인입니다. 한 번 찾아온 정보는 일정 시간 기억(캐싱)해두었다가 빠르게 응답해 줍니다.
권한 서버 (lb1): 도메인의 실제 IP 주소 정보를 가지고 있는, 이름 그대로 '권한'을 가진 최종 정보원입니다. 인터넷에는 루트 서버, TLD(.com) 서버 등 계층 구조로 존재합니다.
DNS 쿼리 추적 실습: 단계별 여정
이제 『도커로 구축한 랩에서 혼자 실습하며 배우는 네트워크 프로토콜 입문』의 실습 환경에서 cl1이 www.example.com의 IP 주소를 찾아가는 과정을 단계별로 따라가 보겠습니다.
1단계: 클라이언트의 첫 질문 (재귀 쿼리)
모든 것은 cl1에서 시작됩니다. cl1은 www.example.com에 접속하라는 명령을 받으면, 먼저 자신의 DNS 설정에 등록된 DNS 서버에게 IP 주소를 물어봅니다. 책의 실습 환경에서는 가정 내 공유기 역할을 하는 rt1이 DNS 서버로 설정되어 있습니다.
Bash
# cl1에서 이름 풀이를 요청하는 명령어
root@cl1:/# dig www.example.com
이때 cl1이 rt1에게 보내는 질문을 '재귀 쿼리(Recursive Query)'라고 합니다. "내가 원하는 최종 답변을 찾아서 알려줘!"라는 의미입니다.
rt1은 이 요청을 받아 인터넷상의 DNS 캐시 서버인 ns1에게 그대로 전달하는 'DNS 포워더' 역할을 수행합니다.
2단계: 캐시 서버의 여정 시작 (반복 쿼리)
재귀 쿼리를 받은 캐시 서버 ns1은 이제 바빠집니다. ns1은 답을 알 때까지 각 계층의 권한 서버에게 직접 물어보는 '반복 쿼리(Iterative Query)'를 시작합니다.
첫 번째 목적지는 인터넷 계층 구조의 최상위인 루트 서버입니다. ns1은 루트 서버에게 묻습니다.
".com 도메인은 어느 서버가 관리하나요?"
3단계: .com 서버에게 물어보기
루트 서버는 www.example.com의 전체 주소를 알지 못합니다. 대신 하위 도메인을 관리하는 서버의 정보만 알려줍니다.
루트 서버의 응답: "나는 모르지만, .com 도메인은 10.1.3.52 IP 주소를 가진 TLD(최상위 도메인) 서버가 관리하니 그쪽에 물어보세요."
ns1은 이 정보를 받아 이제 .com 서버에게 다시 질문합니다.
" example.com 도메인은 어느 서버가 관리하나요?"
4단계: 최종 목적지, example.com 서버
.com 서버 역시 www.example.com의 주소를 직접 알지는 못합니다. 대신 그 하위 도메인 관리자 정보를 알려줍니다.
.com 서버의 응답: "나는 모르지만, example.com 도메인은 10.1.3.53 IP 주소를 가진 권한 서버가 관리하니 그쪽에 물어보세요."
드디어 ns1은 최종 목적지에 도달했습니다. ns1은 example.com의 권한 서버(lb1)에게 마지막 질문을 던집니다.
" www.example.com의 IP 주소는 무엇인가요?"
5단계: 정답 확인과 캐싱
example.com의 권한 서버는 자신이 관리하는 정보가 담긴 '존 파일(zone file)'을 뒤져 최종 답변을 찾아냅니다.
example.com 서버의 응답: "www.example.com의 IP 주소(A 레코드)는 10.1.3.12입니다."
ns1은 이 소중한 답변을 받아 cl1에게 전달하기 전에, 자신의 캐시에 저장해 둡니다. 다음에 똑같은 질문이 들어오면 이 복잡한 과정을 반복하지 않고 즉시 캐시에서 답변을 꺼내주기 위함입니다. 책에서는 아래 명령어로 캐시된 내용을 직접 확인할 수 있습니다.
Bash
# ns1에서 캐시된 DNS 정보 확인
root@ns1:/# unbound-control dump_cache
...
;rrset 183 1 0 8 2
www.example.com. 183 IN A 10.1.3.12
...
ns1은 최종적으로 rt1을 거쳐 cl1에게 " www.example.com의 IP 주소는 10.1.3.12입니다."라는 응답을 전달하며 긴 여정을 마칩니다.
결론: 눈에 보이지 않는 인터넷의 길잡이
사용자가 도메인 이름을 입력하는 단 한 번의 행동 뒤에는 이처럼 여러 서버들이 계층적으로 협력하며 올바른 길을 찾아주는 정교한 과정이 숨어 있습니다. 이 과정은 수십 밀리초(ms) 안에 일어나기에 우리는 그 존재조차 느끼지 못합니다.
『도커로 구축한 랩에서 혼자 실습하며 배우는 네트워크 프로토콜 입문』은 바로 이 눈에 보이지 않는 과정을 독자의 PC 안에서 직접 재현하고, 패킷 하나하나를 뜯어보며 추적할 수 있는 독보적인 경험을 제공합니다. 네트워크가 실제로 어떻게 움직이는지 궁금하다면, 이 책과 함께 여러분만의 작은 인터넷을 탐험해 보시는 건 어떨까요?
https://wikibook.co.kr/network-protocols/
이 책은 단순히 지식을 읽고 배우는 것이 아니라, 설정부터 패킷 분석까지 전 과정을 실제로 체험할 수 있는 네트워크 기술서입니다. 한 대의 PC 안에 스위치, 라우터, 방화벽, 로드 밸런서를 갖춘 가상 네트워크 환경을 구축하고, 각 장비에 로그인해 VLAN, 라우팅, 방화벽의 통신 제어, HTTPS 암호화, 로드 밸런싱 등을 모두 실제로 설정하고 동작을 확인할 수 있습니다. 이 책을 통해 네트워크 장비를 설정하고 패킷을 분석하면서 네트워크 검증 환경을 구축하다 보면 실제 구축 현장이나 운영 현장과 유사한 경험을 자연스럽게 쌓고 체험할 수 있을 것입니다.
