DNS(Domain Name System)는 우리가 외우기 쉬운 **웹사이트 이름(도메인 이름)**을 컴퓨터가 실제로 통신할 때 사용하는 **숫자 주소(IP 주소)**로 변환해주는 시스템입니다. 이를 **이름 해석(Name Resolution)**이라고 부릅니다.
가장 쉽게 비유하자면, DNS는 전화번호부와 같은 역할을 합니다. 우리는 친구의 이름을 기억하지 번호를 외우지 않듯, 웹에서도 도메인 이름(예: google.com)을 기억하고 실제 전화번호에 해당하는 IP 주소는 DNS가 찾아주는 것이죠.
1. DNS가 서버 주소를 찾는 4단계 과정
사용자가 브라우저에 도메인 이름(예: blog.naver.com)을 입력했을 때, DNS가 IP 주소를 찾아주는 과정은 보통 네 종류의 서버가 협력하여 다음과 같은 4단계로 진행됩니다.
| 역할 | 비유 |
| Recursor | 도서관 사서 (요청을 받고 결과를 돌려줌) |
| Root DNS | 도서관 색인 카드 (최상위 목록) |
| TLD DNS | 분야별 책임자 (예: .com, .net 담당) |
| Authoritative DNS | 실제 책의 소유자 (최종 IP 주소를 알고 있음) |
단계별 상세 설명
- Recursor에게 요청 (도서관 사서):사용자의 컴퓨터(브라우저)는 가장 먼저 DNS Recursor라는 서버(보통 인터넷 서비스 제공업체, ISP가 운영)에 “나 blog.naver.com의 IP 주소를 알고 싶어”라고 요청합니다.
- Root 서버에게 질문 (최상위 목록 확인):Recursor는 자신이 주소를 모르므로, 최상위 서버인 Root DNS 서버에게 질문합니다. Root 서버는 모든 도메인의 시작점입니다. Root 서버는 Recursor에게 “나는 전체 주소는 모르지만, .com을 담당하는 TLD 서버 주소는 알려줄게”라고 응답합니다.
- TLD 서버에게 질문 (분야별 책임자):Recursor는 Root 서버에게 받은 주소를 바탕으로, .com을 담당하는 TLD(Top-Level Domain) 서버에게 다시 질문합니다. TLD 서버는 Recursor에게 “나는 blog.naver.com의 최종 정보를 가지고 있는 Authoritative 서버 주소를 알려줄게”라고 응답합니다.
- Authoritative 서버에게 최종 질문 (실제 책의 소유자):Recursor는 마지막으로 blog.naver.com의 정보를 실제로 관리하는 Authoritative DNS 서버에 질문합니다. 이 서버가 드디어 “blog.naver.com의 IP 주소는 125.209.231.121 이야”라고 응답합니다.
2. 마지막 단계: IP 주소 전달 및 캐싱
Recursor는 최종적으로 얻은 IP 주소를 **사용자의 컴퓨터(브라우저)**에게 전달합니다. 브라우저는 이 IP 주소를 통해 서버와 연결(TCP Handshake)하고 웹페이지를 요청하게 됩니다.
이 과정이 매번 발생하면 시간이 오래 걸리기 때문에, Recursor 서버와 사용자의 컴퓨터는 이 정보를 **일정 시간 동안 저장(캐싱)**해 둡니다. 다음에 같은 도메인에 접속할 때는 위 4단계를 다시 거치지 않고 캐싱된 정보를 바로 사용하기 때문에 훨씬 빠르게 접속할 수 있습니다.
혹시 웹 서버에 요청을 보낸 후 어떤 일이 일어나는 HTTP 통신 과정에 대해서도 궁금하신가요?
