컴퓨터 네트워크/응용계층

계층적 네임 서버

iOS Developer 2025. 1. 4. 14:49

계층적 네임 서버 (Hierarchical Name Servers)

네트워크 환경에서 도메인 이름을 IP 주소로 변환하는 DNS(Domain Name System)의 계층 구조와 동작 방식을 상세히 살펴봅시다. DNS는 전 세계적으로 분산된 네임 서버들을 기반으로, 사용자가 쉽고 직관적인 도메인 이름을 통해 인터넷 서비스에 접근할 수 있도록 돕습니다.

DNS 기본 개념

DNS는 사용자가 기억하기 쉽도록 만든 도메인 이름을 숫자로 구성된 IP 주소에 대응시키는 체계입니다. 아래와 같은 특징이 있습니다.

  • 분산 구조: 전 세계에 분산된 여러 네임 서버가 도메인 이름 정보를 관리
  • 위임(Delegation): 루트 서버는 TLD 서버에, TLD 서버는 하위 도메인을 관리하는 서버에 권한을 위임
  • 계층형 구조: 루트(“.”) → TLD(“.com”, “.net” 등) → 서브 도메인 → 호스트(“www”) 순으로 이름이 구성

결과적으로 DNS를 통해 사용자는 “http://www.example.com”처럼 알기 쉬운 주소로 원하는 호스트에 연결할 수 있습니다.

계층적 DNS 구조

DNS는 크게 아래 네 종류의 네임 서버로 구성되며, 각 계층별 네임 서버는 서로 다른 역할을 담당합니다.

image

로컬 네임 서버

  • 클라이언트와 가장 가까운 네임 서버입니다.
  • 사용자의 컴퓨터나 스마트폰에서 도메인을 입력하면, 가장 먼저 질의를 받는 서버가 로컬 네임 서버입니다.
  • 일반적으로 ISP(Internet Service Provider)가 자동으로 로컬 DNS 서버 주소를 할당하지만, 공개 DNS 서버(예: 구글 8.8.8.8 / 8.8.4.4, 클라우드플레어 1.1.1.1)를 수동으로 설정할 수도 있습니다.

 

루트 네임 서버

  • 전 세계에 13개의 루트 서버 군(“.”)이 존재하며, 가장 상위의 루트 도메인을 관리합니다.
  • 로컬 네임 서버가 질의했을 때 해당 도메인을 직접 모르지만, 어느 TLD 서버가 이 도메인을 관리하는지 TLD 네임 서버의 주소를 알려줍니다.

image

 

TLD 네임 서버

  • .com, .net, .org, .kr 등 최상위 도메인(Top-Level Domain)에 대한 정보를 관리합니다.
  • 루트 네임 서버로부터 질의를 넘겨받아, 하위 도메인(.example.com 등)을 실제로 관리하는 서버(책임 네임 서버)의 위치 정보를 반환합니다.
  • TLD 서버에도 여러 종류가 있으며, 일반 gTLD(.com, .net), 국가별 ccTLD(.kr, .jp, .uk) 등으로 구분됩니다.

image

 

책임 네임 서버

  • Authoritative Name Server라고도 불리며, 실제로 특정 도메인 영역(Zone)을 담당합니다.
  • 자신이 관리하는 도메인 영역에 대한 질의에는, 다른 서버로 넘기지 않고 최종 IP 주소를 직접 반환합니다.
  • 로컬 네임 서버가 마지막으로 질의하게 되는 서버이기도 합니다.

image

DNS 질의(Resolution) 방식

클라이언트(사용자)가 http://www.example.com과 같은 도메인 이름을 입력하면, 내부적으로 아래 두 가지 방식(재귀 또는 반복)을 통해 IP 주소를 찾아냅니다.

image

재귀적 질의

  • 클라이언트가 로컬 네임 서버에 “http://www.example.com의 IP 주소를 알려주세요”라고 질의합니다.
  • 로컬 네임 서버가 대신 루트 서버 → TLD 서버 → 책임 서버 순으로 “재귀적으로” 요청을 보내며, 모든 과정을 담당합니다.
  • 최종 응답(IP 주소)을 찾으면, 역방향으로 결과를 클라이언트에게 전달합니다.

image

 

반복적 질의

  • 클라이언트가 로컬 네임 서버에 질의하면, 로컬 네임 서버가 루트 서버에 “이 도메인을 누가 관리하나요?”라고 묻고, TLD 서버 주소를 안내받습니다.
  • 로컬 네임 서버가 받은 정보를 바탕으로 TLD 서버에 재차 질의하고, 다시 하위 책임 서버 주소를 안내받는 과정을 “반복”합니다.
  • 최종 IP 주소를 얻어낸 다음, 로컬 네임 서버가 클라이언트에 응답합니다.

image

DNS 캐시(DNS Cache)

DNS 질의 시 매번 루트 네임 서버부터 책임 서버까지 모든 단계를 거치면, 네트워크 트래픽과 응답 시간이 증가할 수 있습니다. 이를 방지하고 속도를 높이기 위해 DNS 캐시를 사용합니다.

  • DNS 캐시: 이전에 받은 도메인-IP 매핑 정보를 임시 저장해두고, 동일 질의가 들어오면 즉시 응답
  • TTL(Time To Live): 캐시에 저장된 레코드의 유효 기간. 기간이 지나면 캐시에서 제거
  • 캐시를 통해 루트 네임 서버 등 상위 서버의 과부하를 감소시키며, 사용자에게 빠른 응답을 제공합니다.

DNS 기록(Records)

책임 네임 서버가 보유하고 있는 DNS 존(Zone)에는 여러 유형의 DNS 레코드가 있습니다.

  • A 레코드: IPv4 주소와 도메인 매핑
  • AAAA 레코드: IPv6 주소와 도메인 매핑
  • CNAME 레코드: 별칭(Alias) 설정. 예) www를 다른 호스트 이름에 매핑
  • MX 레코드: 메일 서버 주소 정보
  • NS 레코드: 해당 도메인을 관리하는 네임 서버 정보
  • PTR 레코드: IP 주소를 도메인으로 역매핑(Reverse DNS)

이러한 레코드들이 쌓여 전체 DNS 시스템이 유기적으로 작동하게 됩니다.

DNS의 동작 예시

아래는 http://www.example.com을 예로 들었을 때, 실제 도메인 리졸빙 과정에서 일어날 수 있는 일련의 단계입니다.

  1. 클라이언트가 로컬 네임 서버에 http://www.example.com을 질의
  2. 로컬 서버가 DNS 캐시에 해당 결과가 없으면 → 루트 서버에 질의
  3. 루트 서버가 “.com TLD 서버” 정보를 알려줌
  4. 로컬 서버가 .com TLD 서버에 example.com 질의
  5. .com TLD 서버가 “책임 네임 서버” 주소 알려줌
  6. 로컬 서버가 최종 책임 서버에 http://www.example.com을 질의
  7. 책임 서버가 실제 IP 주소를 로컬 서버에 전달
  8. 로컬 서버가 결과를 캐시에 저장하고 클라이언트에게 응답

실제 시스템에서는 여러 보조 DNS, 포워딩 DNS 등 다양한 요소가 추가될 수 있지만, 기본적인 계층 구조와 질의 흐름은 위와 같습니다.

참고 및 출처