DNS Hierarchy

· 4분 읽기

“google.com 을 브라우저에 입력하면 어떤 일이 일어나나요?” 같은 질문은 소프트웨어 엔지니어 면접에서 자주 등장하는 고전적인 질문이다.

보고자 하는 깊이가 지원자의 연차에 따라 달라질 수 있지만, 최소한 이 질문에 제대로 대답하기 위해서는 DNS 계층 구조를 이해해야 한다.

DNS 는 사람이 읽을 수 있는 도메인 이름(e.g. google.com)을 컴퓨터가 이해할 수 있는 IP 주소로 변환하는 시스템이다.

이 변환 과정은 실제로는 여러 계층의 DNS 서버들이 협력하는 분산 시스템이라는 것을 이해해야 한다.

DNS Hierarchy Diagram

A Crash Course in DNS - ByteByteGo Newsletter

DNS 시스템은 트리 구조로 되어 있으며, 루트에서 시작해 점점 구체적인 정보로 내려간다.

Root DNS Server

Root DNS 서버는 DNS 계층 구조의 최상위에 위치한 서버이다. DNS 조회의 첫 번째 단계이며, 모든 도메인 해석의 시작점이다.

Root DNS 서버는 전 세계에 13개의 논리적 클러스터(A to M)로 구성된다. 당연히 물리적으로 13개만 있다는 뜻은 아니다.

Why Only 13 root DNS | TechieMaster.in

Root DNS 서버가 개별 도메인의 IP 주소를 저장하지 않는다는 점이 중요하다.

대신, 각 최상위 도메인, TLD(Top-Level Domain) DNS 서버의 주소를 알려준다.

예를 들어:

  1. .com 을 조회하면 → Verisign 의 .com TLD DNS 서버 주소를 반환

  2. .org 를 조회하면 → PIR 의 .org TLD DNS 서버 주소를 반환

Root 서버는 책갈피와 같다. 직접 답을 주지는 않지만, 어디에서 답을 찾을 수 있는지 알려준다.

TLD DNS Server

TLD DNS 서버는 특정 최상위 도메인(.com, .org, .net 등)의 모든 Second-Level 도메인 정보를 관리하는 서버이다.

TLD DNS 서버는 Zone file 이라는 것을 관리한다. 이 파일에는 해당 TLD 하위의 모든 활성 Second-Level 도메인과 그 도메인의 Authoritative DNS 서버 IP 주소 매핑 정보가 저장되어 있다.

예를 들어, .com TLD 서버의 존 파일에는 다음과 같은 정보가 저장되어 있을 것이다:

google.com      IN  NS  ns1.google.com
google.com      IN  NS  ns2.google.com
google.com      IN  NS  ns3.google.com
google.com      IN  NS  ns4.google.com

amazon.com      IN  NS  ns1.p31.dynect.net
amazon.com      IN  NS  ns2.p31.dynect.net
...

즉, “google.com 의 정확한 정보는 ns1.google.com ~ ns4.google.com 에 물어보세요” 라는 뜻이다.

Authoritative DNS Server

Authoritative DNS 서버라는 이 발음도 어려운 녀석은 특정 도메인에 대한 공식적인 DNS 레코드를 보유한 서버이다.

한 마디로 정답을 쥐고 있는 서버이며, DNS 조회의 최종 목적지이다. 이 녀석은 실제 IP 주소나 기타 DNS 레코드를 제공해준다.

Authoritative DNS 서버는 Primary Server 와 Secondary Servers 로 구성되어 있다.

  • Primary Server: Master, 읽기-쓰기가 가능한 원본 복사본을 보유한다. DNS 레코드 변경은 여기서만 가능하다.

  • Secondary Server: Slave, 읽기 전용 복사본을 보유한다. Primary 서버로부터 주기적으로 동기화 (이를 zone transfer 라고 함) 하여 데이터를 최신 상태로 유지한다.

전체 DNS 조회 흐름

사용자가 “google.com” 방문했을 때:

  1. Local Cache 확인, 브라우저 캐시 → OS 캐시 → hosts 파일 순서로 확인

    1. Cache hit → 바로 연결

    2. Cache miss → 2단계로

  2. Recursive Resolver 쿼리

    1. ISP DNS (예: KT xxx.xxx.xx.x) 또는 Public DNS (e.g. Google 8.8.8.8) 쿼리

  3. Root DNS 서버 쿼리

    1. Query: “google.com” → Response: “.com TLD Server”

  4. TLD DNS 서버 쿼리

    1. Query: “google.com” → Response: “google.com 의 Authoritative 서버”

  5. Authoritative DNS 서버 쿼리

    1. Query: “google.com” → Response: “xxx.xxx.xxx.xxx”

    2. 실제 IP 주소를 반환

  6. Recursive Resolve 에서 캐싱하고, TTL 동안 결과 저장

  7. 클라이언트가 받은 IP 로 HTTP / HTTPS 연결

ISP 는 Internet Service Provider 의 약자로, 대한민국의 경우 KT, SKT 같은 곳을 말한다.
Recursive Resolver 단계에서 기본적으로 ISP DNS 를 조회하지만, OS 네트워크 설정에 DNS 서버를 Public DNS 서버로 바꿔둔 경우에는 그렇지 않다.
또한 2단계에서 Cache hit 한 경우에는 Root DNS 서버로 쿼리하지 않는다(당연히)

References