DNS의 원리 (1) - DNS의 탄생과 계층 구조 - soo:bak

작성일 :

인터넷의 전화번호부

인터넷에서 통신하려면 IP 주소가 필요합니다.

IP 주소(IP Address)의 개념과 구조에서 살펴보았듯이, IPv4 주소는 192.0.2.1과 같은 32비트 숫자입니다.


하지만 사람은 숫자를 잘 기억하지 못합니다.

142.250.196.110보다 google.com이 기억하기 쉽습니다.


DNS(Domain Name System)는 사람이 읽을 수 있는 이름을 IP 주소로 변환하는 시스템입니다.

단순해 보이지만, 인터넷 전체를 아우르는 거대한 분산 데이터베이스입니다.

어떻게 이런 시스템이 만들어지게 되었을까요?

HOSTS.TXT 시대

초기 ARPANET

1970년대 ARPANET에는 수백 대의 컴퓨터만 연결되어 있었습니다.

각 컴퓨터의 이름과 주소는 하나의 파일에 저장되었습니다.


1
2
3
4

# HOSTS.TXT 예시 (SRI-NIC에서 관리)
101.0.0.1   SRI-NIC      # SRI International
10.0.0.73   MIT-AI       # MIT AI Lab
10.1.0.13   STANFORD     # Stanford


SRI-NIC(Stanford Research Institute - Network Information Center)가 이 파일을 관리했습니다.

새 호스트가 추가되면 관리자에게 이메일(혹은 전화)로 알렸습니다.

SRI-NIC가 파일을 업데이트하면, 각 사이트가 FTP로 다운로드했습니다.

확장성의 한계

네트워크가 성장하면서 문제가 발생했습니다.


이름 충돌

중앙 관리 없이는 같은 이름을 두 조직이 사용할 수 있었습니다.

MAILSERVER라는 이름을 MIT도, Stanford도 사용하고 싶다면?


업데이트 지연

새 호스트 등록에 며칠이 걸렸습니다.

등록되어도 모든 사이트가 새 파일을 받기까지 또 시간이 필요했습니다.


트래픽 폭증

1982년경 ARPANET에는 수백 개의 호스트가 있었습니다.

각 호스트가 주기적으로 HOSTS.TXT를 다운로드했습니다.

파일 크기도 커지고, 다운로드 빈도도 늘어났습니다.


단일 장애점

SRI-NIC가 다운되면 새 호스트를 등록할 수 없었습니다.


1
2
3
4
5
6
7
8
9
10
11

                HOSTS.TXT의 한계
  ┌─────────────────────────────────────────┐
  │                                         │
  │     호스트 수 증가 → 파일 크기 증가     │
  │            ↓                            │
  │     업데이트 빈도 증가                  │
  │            ↓                            │
  │     네트워크 트래픽 = O(N²)             │
  │     (N개 호스트 × N개 레코드)           │
  │                                         │
  └─────────────────────────────────────────┘


인터넷이 기하급수적으로 성장할 것이 예상되었습니다.

새로운 해결책이 필요했습니다.

DNS의 탄생

Paul Mockapetris와 RFC 882/883

1983년 11월, Paul Mockapetris는 RFC 882와 RFC 883을 발표했습니다.

DNS(Domain Name System)의 설계를 담은 문서입니다.


핵심 아이디어는 세 가지였습니다.


1. 계층적 네임스페이스(Hierarchical Namespace)

이름을 계층 구조로 조직하여 충돌을 방지합니다.

mit.edu와 stanford.edu는 다른 도메인이므로, 각각 mailserver.mit.edu와 mailserver.stanford.edu를 가질 수 있습니다.


2. 분산 데이터베이스(Distributed Database)

하나의 서버가 모든 정보를 갖지 않습니다.

각 조직이 자신의 도메인에 대한 정보를 관리합니다.


3. 캐싱(Caching)

한 번 조회한 정보를 일정 시간 저장합니다.

같은 질문을 반복하지 않아 트래픽을 줄입니다.


1984년, Berkeley의 학생들이 BIND(Berkeley Internet Name Domain)를 구현했습니다.

최초의 DNS 서버 소프트웨어입니다.

오늘날에도 BIND는 가장 널리 사용되는 DNS 서버 중 하나입니다.

RFC 1034/1035

1987년, RFC 1034와 RFC 1035가 발표되었습니다.

DNS의 현재 표준을 정의한 문서입니다.


RFC 1034는 개념과 기능을 설명합니다.

RFC 1035는 구현 세부 사항과 프로토콜을 정의합니다.


40년이 지난 지금도 이 문서들이 DNS의 기반입니다.

물론 수많은 확장(DNSSEC, EDNS 등)이 추가되었습니다.

계층적 네임스페이스

도메인 이름의 구조

도메인 이름은 점(.)으로 구분된 레이블의 연속입니다.


1
2
3
4
5
6

www.example.com.
│   │       │  │
│   │       │  └── 루트(보통 생략)
│   │       └───── 최상위 도메인(TLD)
│   └───────────── 2차 도메인
└──────────────── 3차 도메인(서브도메인)


오른쪽에서 왼쪽으로 읽습니다.

가장 오른쪽의 점은 루트(root)를 나타냅니다. (보통 생략)


각 레이블은 최대 63자, 전체 이름은 최대 253자입니다.

대소문자를 구분하지 않습니다. (Example.COM = example.com)

도메인 트리

DNS 네임스페이스는 트리 구조입니다.


1
2
3
4
5
6
7
8
9
10
11
12
13

                        . (root)
                        │
         ┌──────────────┼──────────────┐
         │              │              │
        com            org            kr
         │              │              │
    ┌────┴────┐        │         ┌────┴────┐
    │         │        │         │         │
  google   example  wikipedia   co       go
    │         │        │         │         │
   www       www      www      naver    korea
                                 │
                                www


루트(Root)

트리의 최상위입니다.

전 세계에 13개의 루트 서버 클러스터가 있습니다. (A-root ~ M-root)

실제로는 Anycast를 통해 수백 개의 서버가 분산되어 있습니다.


최상위 도메인(TLD, Top-Level Domain)

루트 바로 아래의 도메인입니다.


유형 예시 설명
gTLD com, org, net 일반 최상위 도메인
ccTLD kr, jp, uk 국가 코드 최상위 도메인
sTLD edu, gov, mil 후원 최상위 도메인
new gTLD blog, app, dev 2012년 이후 추가된 도메인


2차 도메인(Second-Level Domain)

TLD 바로 아래에서 조직이 등록하는 도메인입니다.

google.com에서 google이 2차 도메인입니다.


서브도메인(Subdomain)

2차 도메인 아래로 조직이 자유롭게 만들 수 있습니다.

mail.google.com, maps.google.com 등.

FQDN

FQDN(Fully Qualified Domain Name)은 루트까지 포함한 전체 이름입니다.


1
2
3

www.example.com.     ← FQDN (마지막 점이 루트)
www.example.com      ← 일반적인 표기 (루트 생략)
www                  ← 상대적 이름


DNS 설정 파일에서는 구분이 중요합니다.

마지막 점이 없으면 현재 도메인이 자동으로 붙기 때문입니다.

권한 위임(Delegation)

분산 관리의 핵심

DNS의 핵심 개념은 권한 위임(Delegation)입니다.

상위 도메인이 하위 도메인의 관리 권한을 위임합니다.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

권한 위임 체계

ICANN/IANA
    │
    │  "com의 관리를 Verisign에 위임"
    ▼
Verisign (.com 레지스트리)
    │
    │  "example.com의 관리를 Example Inc.에 위임"
    ▼
Example Inc. (example.com 소유자)
    │
    │  "api.example.com의 관리를 클라우드 팀에 위임"
    ▼
클라우드 팀 (api.example.com 관리)


각 단계에서 관리 책임이 넘어갑니다.

ICANN이 모든 도메인을 직접 관리하지 않습니다.

각 조직이 자신의 도메인을 관리합니다.

Zone과 Zone File

Zone(존)은 한 관리자가 책임지는 네임스페이스의 연속된 부분입니다.


1
2
3
4
5
6
7
8
9
10
11

example.com Zone
┌─────────────────────────────────────┐
│                                     │
│  example.com (SOA, NS, MX, A...)    │
│       │                             │
│  ┌────┴────┬────────┐               │
│  │         │        │               │
│  www      mail    api ──────────────│──→ 별도 Zone으로
│  (A)      (A)                       │     위임 가능
│                                     │
└─────────────────────────────────────┘


Zone은 도메인과 다릅니다.

하나의 도메인에 여러 Zone이 있을 수 있습니다. (서브도메인을 별도 Zone으로 위임한 경우)


Zone File은 Zone의 데이터를 담은 텍스트 파일입니다.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

; example.com Zone File
$TTL 3600
@   IN  SOA   ns1.example.com. admin.example.com. (
                2024010101  ; Serial
                7200        ; Refresh
                3600        ; Retry
                1209600     ; Expire
                3600 )      ; Negative TTL

    IN  NS    ns1.example.com.
    IN  NS    ns2.example.com.
    IN  MX    10 mail.example.com.
    IN  A     93.184.216.34

www IN  A     93.184.216.34
mail IN A     93.184.216.35

권한 있는 서버(Authoritative Server)

특정 Zone에 대한 공식 정보를 가진 서버입니다.


Zone을 직접 관리하며, 원본 데이터를 제공합니다.

캐시된 데이터가 아닌 실제 데이터입니다.


Primary(Master) 서버: Zone File의 원본을 가진 서버

Secondary(Slave) 서버: Primary로부터 Zone을 복제한 서버


1
2
3
4
5
6
7

┌──────────────┐      Zone Transfer      ┌──────────────┐
│   Primary    │ ─────────────────────▶  │  Secondary   │
│   (Master)   │        (AXFR/IXFR)      │   (Slave)    │
│              │                         │              │
│  Zone File   │                         │  Zone 복제본 │
│  (원본)       │                         │              │
└──────────────┘                         └──────────────┘


Secondary 서버는 중복성을 제공합니다.

Primary가 다운되어도 서비스가 계속됩니다.

DNS 레코드 타입

기본 레코드 타입

Zone File에는 다양한 레코드가 포함됩니다.

각 레코드는 특정 유형의 정보를 담습니다.


A (Address)

도메인을 IPv4 주소로 매핑합니다.

1

www.example.com.    IN  A     93.184.216.34


AAAA (IPv6 Address)

도메인을 IPv6 주소로 매핑합니다.

1

www.example.com.    IN  AAAA  2606:2800:220:1:248:1893:25c8:1946


CNAME (Canonical Name)

도메인을 다른 도메인의 별칭으로 지정합니다.

1

blog.example.com.   IN  CNAME www.example.com.

blog.example.com을 조회하면 www.example.com의 주소를 따라갑니다.


주의: CNAME은 다른 레코드와 공존할 수 없습니다.

Zone apex(example.com 자체)에는 CNAME을 사용할 수 없습니다.

(NS, SOA 레코드가 있어야 하므로)


MX (Mail Exchange)

메일 서버를 지정합니다.

1
2

example.com.        IN  MX    10 mail1.example.com.
example.com.        IN  MX    20 mail2.example.com.

숫자는 우선순위입니다. 낮을수록 높은 우선순위.

mail1이 응답하지 않으면 mail2로 시도합니다.


NS (Name Server)

도메인의 권한 있는 네임서버를 지정합니다.

1
2

example.com.        IN  NS    ns1.example.com.
example.com.        IN  NS    ns2.example.com.


TXT (Text)

임의의 텍스트 데이터를 저장합니다.

1

example.com.        IN  TXT   "v=spf1 include:_spf.google.com ~all"

SPF, DKIM, DMARC 등 이메일 인증에 널리 사용됩니다.

도메인 소유권 검증에도 사용됩니다.

인프라 레코드

SOA (Start of Authority)

Zone의 메타데이터를 담습니다.

모든 Zone에 반드시 하나 있어야 합니다.

1
2
3
4
5
6

example.com.  IN  SOA  ns1.example.com. admin.example.com. (
                    2024010101  ; Serial - Zone 버전
                    7200        ; Refresh - Secondary가 확인하는 주기
                    3600        ; Retry - 실패 시 재시도 간격
                    1209600     ; Expire - Primary 연결 불가 시 만료 시간
                    3600 )      ; Negative TTL - 부정 캐시 시간


Serial: Zone이 변경될 때마다 증가합니다. Secondary가 변경을 감지하는 기준.

Refresh: Secondary가 Primary의 변경을 확인하는 주기.

Retry: Refresh 실패 시 재시도 간격.

Expire: Primary와 연결 불가 시 Secondary가 응답을 중단하는 시간.

Negative TTL: “해당 레코드 없음” 응답의 캐시 시간.


PTR (Pointer)

IP 주소를 도메인으로 매핑합니다 (역방향 DNS).

1

34.216.184.93.in-addr.arpa.  IN  PTR  www.example.com.

이메일 서버 검증, 로그 분석에 사용됩니다.


SRV (Service)

특정 서비스의 위치를 지정합니다.

1

_sip._tcp.example.com.  IN  SRV  10 60 5060 sipserver.example.com.

형식: 우선순위, 가중치, 포트, 대상 호스트

현대적 레코드 타입

CAA (Certification Authority Authorization)

어떤 인증 기관(CA)이 인증서를 발급할 수 있는지 지정합니다.

1

example.com.        IN  CAA   0 issue "letsencrypt.org"


HTTPS/SVCB (Service Binding)

서비스 연결 정보를 제공합니다 (HTTP/3 지원 여부 등).

1

example.com.        IN  HTTPS 1 . alpn="h3,h2" ipv4hint=93.184.216.34

HTTP의 진화 (2)에서 설명한 HTTP/3 연결에 활용됩니다.

레코드 조회 예시

dig 명령어

dig는 DNS 조회 도구입니다.

실제 DNS 동작을 확인할 수 있습니다.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

$ dig example.com A

; <<>> DiG 9.18.1 <<>> example.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            3600    IN      A       93.184.216.34

;; Query time: 23 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Jan 20 10:00:00 KST 2026
;; MSG SIZE  rcvd: 56


QUESTION: 질의한 내용

ANSWER: 응답받은 레코드

3600: TTL (초 단위, 1시간)


1
2
3
4

$ dig example.com MX

;; ANSWER SECTION:
example.com.            3600    IN      MX      10 mail.example.com.



1
2
3
4
5

$ dig example.com NS

;; ANSWER SECTION:
example.com.            86400   IN      NS      ns1.example.com.
example.com.            86400   IN      NS      ns2.example.com.

권한 있는 서버 직접 조회

@서버 옵션으로 특정 서버에 직접 질의할 수 있습니다.


1
2
3

$ dig @ns1.example.com example.com A

;; flags: qr aa rd; QUERY: 1, ANSWER: 1, ...


aa 플래그는 Authoritative Answer를 의미합니다.

캐시가 아닌 권한 있는 서버에서 직접 받은 응답입니다.

마무리: 분산의 힘

DNS는 중앙 집중의 한계를 분산으로 해결했습니다.


계층적 네임스페이스: 이름 충돌 방지

권한 위임: 각 조직이 자신의 도메인 관리

분산 데이터베이스: 단일 장애점 제거

캐싱: 트래픽 감소


1
2
3
4
5
6
7

HOSTS.TXT                          DNS
    │                               │
    ▼                               ▼
중앙 집중                         분산 시스템
단일 파일                         계층적 구조
수동 업데이트                     자동 전파
확장 불가                         무한 확장


40년 전 설계된 시스템이 오늘날 수십억 개의 도메인을 처리합니다.

확장 가능한 설계의 중요성을 보여주는 사례입니다.


다음 편에서는 DNS 질의가 어떻게 처리되는지, 리졸버와 캐싱의 동작을 살펴봅니다.

시리즈 네비게이션

관련 시리즈

Tags: DNS, 네트워크, 분산시스템, 인터넷

Categories: ,

관련 문제