DNS의 원리 (2) - DNS 질의와 해석 과정 - soo:bak

작성일 :

이름에서 주소까지

DNS의 원리 (1)에서 DNS의 계층 구조와 레코드 타입을 살펴보았습니다.

이제 실제로 이름이 어떻게 IP 주소로 변환되는지 알아봅니다.


브라우저에 www.example.com을 입력하면 무슨 일이 일어날까요?

단순해 보이지만, 여러 서버와 복잡한 과정을 거칩니다.

DNS 질의의 참여자

Stub Resolver

사용자의 컴퓨터에서 동작하는 가장 단순한 리졸버입니다.

운영체제에 내장되어 있습니다.


Stub Resolver의 역할은 단순합니다.

  1. 애플리케이션으로부터 DNS 질의 요청을 받음
  2. 설정된 DNS 서버(Recursive Resolver)에 질의 전송
  3. 응답을 애플리케이션에 전달


직접 계층을 탐색하지 않습니다.

“무거운 작업”은 Recursive Resolver에게 맡깁니다.


1
2
3
4
5
6
7
8
9
10
11

┌─────────────────────────────────────────────────────┐
│  사용자 컴퓨터                                       │
│  ┌──────────┐      ┌──────────────┐                 │
│  │  브라우저 │ ───▶ │ Stub Resolver │                │
│  └──────────┘      └──────┬───────┘                 │
│                           │                         │
└───────────────────────────│─────────────────────────┘
                            │
                            ▼
                   Recursive Resolver
                   (ISP 또는 공용 DNS)

Recursive Resolver

Recursive Resolver(재귀 리졸버)는 실제 조회 작업을 수행합니다.

“Full-service Resolver” 또는 “Caching Resolver”라고도 합니다.


이 서버는 클라이언트를 대신해 전체 조회를 수행합니다.

루트 서버부터 시작해 최종 답을 찾을 때까지 질의합니다.


일반적인 Recursive Resolver:

유형 예시
ISP 제공 인터넷 서비스 제공업체의 DNS
공용 DNS Google DNS (8.8.8.8), Cloudflare (1.1.1.1)
사내 DNS 기업 내부 DNS 서버


Recursive Resolver의 핵심 기능 두 가지:

  1. 재귀적 조회: 클라이언트 대신 전체 조회 수행
  2. 캐싱: 결과를 저장하여 반복 질의 감소

Authoritative Server

DNS의 원리 (1)에서 설명한 권한 있는 서버입니다.

특정 Zone의 공식 데이터를 가지고 있습니다.


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

                    참여자 관계도

┌─────────┐  질의   ┌─────────────────┐   반복   ┌─────────────┐
│  Stub   │ ──────▶ │   Recursive     │ ──────▶  │ Authoritative│
│ Resolver│ ◀────── │   Resolver      │ ◀──────  │   Server    │
└─────────┘  응답   └─────────────────┘   응답   └─────────────┘
                           │
                           │ 캐시 조회/저장
                           ▼
                    ┌─────────────┐
                    │    캐시     │
                    └─────────────┘

재귀적 질의 vs 반복적 질의

재귀적 질의(Recursive Query)

클라이언트가 “최종 답을 달라”고 요청하는 방식입니다.


Stub Resolver → Recursive Resolver 간에 사용됩니다.

“내가 원하는 건 www.example.com의 IP야. 어떻게 찾든 상관없어, 답만 줘.”


1
2
3
4
5
6
7
8
9
10
11

Stub Resolver                    Recursive Resolver
     │                                  │
     │ "www.example.com의 IP 주소는?"    │
     │ ────────────────────────────────▶│
     │                                  │
     │         (Resolver가 알아서       │
     │          조회 과정 수행)         │
     │                                  │
     │ "IP는 93.184.216.34야"           │
     │◀──────────────────────────────── │
     │                                  │


재귀적 질의를 받은 서버는 최종 답을 반환할 책임이 있습니다.

캐시에 있으면 바로 응답, 없으면 다른 서버에 질의해서라도 답을 찾습니다.

반복적 질의(Iterative Query)

서버가 “내가 아는 최선의 정보”를 알려주는 방식입니다.


Recursive Resolver → Authoritative Server 간에 사용됩니다.


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

Recursive Resolver               Root Server
     │                              │
     │ "www.example.com의 IP는?"    │
     │ ───────────────────────────▶ │
     │                              │
     │ "모르지만, .com은 이 서버가   │
     │  관리해: ns.com-registry"    │
     │◀─────────────────────────────│
     │                              │


Recursive Resolver               .com TLD Server
     │                              │
     │ "www.example.com의 IP는?"    │
     │ ───────────────────────────▶ │
     │                              │
     │ "모르지만, example.com은      │
     │  ns1.example.com이 관리해"   │
     │◀─────────────────────────────│
     │                              │


반복적 질의에서 서버는 최종 답을 찾아주지 않습니다.

“내가 아는 건 이것뿐이야. 더 알고 싶으면 저기에 물어봐”라고 알려줍니다.

실제 조회 과정

www.example.com의 A 레코드 조회 과정입니다.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

┌──────────┐
│ 브라우저  │
└────┬─────┘
     │ ① www.example.com?
     ▼
┌──────────┐         ┌──────────┐
│  Stub    │         │ Recursive│
│ Resolver │ ──②──▶  │ Resolver │
└──────────┘         └────┬─────┘
                          │
       ┌──────────────────┼──────────────────┐
       │                  │                  │
       │ ③ .com은 어디?   │                  │
       ▼                  │                  │
┌──────────┐              │                  │
│  Root    │              │                  │
│  Server  │              │                  │
└────┬─────┘              │                  │
     │ ④ .com NS 반환     │                  │
     ▼                    │                  │
       │ ⑤ example.com은? │                  │
       ▼                  │                  │
┌──────────┐              │                  │
│ .com TLD │              │                  │
│  Server  │              │                  │
└────┬─────┘              │                  │
     │ ⑥ example.com NS   │                  │
     ▼                    │                  │
       │ ⑦ www.example.com?                  │
       ▼                                     │
┌──────────────┐                             │
│ example.com  │                             │
│ Authoritative│                             │
└────┬─────────┘                             │
     │ ⑧ A 93.184.216.34                     │
     │                                       │
     └───────────────────────────────────────┘
                          │
                          │ ⑨ 최종 응답
                          ▼
                   ┌──────────┐
                   │  Stub    │
                   │ Resolver │
                   └────┬─────┘
                        │ ⑩
                        ▼
                   ┌──────────┐
                   │ 브라우저  │
                   └──────────┘


단계별 설명:

  1. 브라우저가 www.example.com의 IP 필요
  2. Stub Resolver가 Recursive Resolver에 재귀적 질의
  3. Recursive Resolver가 Root Server에 반복적 질의
  4. Root Server가 .com TLD 서버 주소 반환
  5. .com TLD 서버에 질의
  6. TLD 서버가 example.com 네임서버 주소 반환
  7. example.com 권한 서버에 질의
  8. 최종 IP 주소 반환
  9. Recursive Resolver가 Stub Resolver에 응답
  10. 브라우저가 IP로 HTTP 연결 시작


이 과정에서 캐시가 없다면 최대 4번의 왕복이 필요합니다.

실제로는 캐싱 덕분에 대부분 1-2번의 왕복으로 끝납니다.

캐싱과 TTL

캐싱의 필요성

매번 루트 서버부터 조회하면 비효율적입니다.


  • 루트 서버에 과부하
  • 응답 지연
  • 네트워크 트래픽 낭비


캐싱은 이 문제를 해결합니다.

한 번 조회한 결과를 저장하고, 같은 질의에 재사용합니다.

TTL (Time To Live)

모든 DNS 레코드에는 TTL이 있습니다.

“이 정보를 얼마나 오래 캐시해도 되는가”를 나타냅니다.


1
2
3

example.com.    3600    IN    A    93.184.216.34
                 │
                 └── TTL: 3600초 (1시간)


TTL이 3600이면:

  • 이 레코드를 1시간 동안 캐시 가능
  • 1시간 후에는 다시 조회해야 함


TTL 설정의 트레이드오프:

TTL 장점 단점
짧음 (60초) 변경이 빠르게 전파 질의 증가, 서버 부하
긺 (86400초) 캐시 효율 높음 변경 전파에 오래 걸림


일반적인 권장값:

  • 자주 변경되지 않는 레코드: 1-24시간
  • 변경 가능성 있는 레코드: 5-15분
  • 마이그레이션 직전: 60초로 낮춤

캐시 계층

캐싱은 여러 단계에서 일어납니다.


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

┌─────────────────────────────────────────────────────────┐
│ 브라우저 캐시                                            │
│ (Chrome: chrome://net-internals/#dns)                  │
│ TTL 또는 브라우저 정책에 따름                            │
└────────────────────────┬────────────────────────────────┘
                         │ 캐시 미스
                         ▼
┌─────────────────────────────────────────────────────────┐
│ OS 캐시 (Stub Resolver)                                 │
│ Windows: ipconfig /displaydns                          │
│ macOS: dscacheutil -cachedump                          │
└────────────────────────┬────────────────────────────────┘
                         │ 캐시 미스
                         ▼
┌─────────────────────────────────────────────────────────┐
│ Recursive Resolver 캐시                                 │
│ ISP DNS, Google DNS, Cloudflare 등                     │
│ 대규모 캐시, 많은 사용자 공유                            │
└────────────────────────┬────────────────────────────────┘
                         │ 캐시 미스
                         ▼
               Authoritative Server 조회


Recursive Resolver의 캐시가 가장 효과적입니다.

수많은 사용자가 공유하므로 적중률이 높습니다.

네거티브 캐싱

“없음”도 캐싱됩니다.


존재하지 않는 도메인 asdfgh123.example.com을 조회하면?

권한 서버가 “없음(NXDOMAIN)”을 응답합니다.


이 응답도 캐싱됩니다.

같은 질의가 반복되면 캐시에서 “없음”을 반환합니다.


네거티브 캐시 TTL은 SOA 레코드의 마지막 필드입니다.

1
2
3
4
5
6

example.com.  IN  SOA  ns1.example.com. admin.example.com. (
                    2024010101  ; Serial
                    7200        ; Refresh
                    3600        ; Retry
                    1209600     ; Expire
                    3600 )      ; Negative TTL ← 이것


RFC 2308은 네거티브 캐시 TTL을 최대 3시간으로 제한합니다.

DNS 메시지 구조

프로토콜 기본

DNS는 기본적으로 UDP 포트 53을 사용합니다.


왜 UDP인가?

  • 질의와 응답이 단순 (연결 설정 불필요)
  • 빠른 응답이 중요
  • 하나의 패킷에 담길 정도로 작음


소켓과 전송 계층 (1)에서 설명했듯이, UDP는 연결 상태를 유지하지 않습니다.

DNS 질의 하나에 패킷 왕복 한 번이면 충분합니다.


TCP를 사용하는 경우:

  • 응답이 512바이트를 초과할 때 (Zone Transfer 등)
  • DNSSEC으로 응답이 커질 때
  • TCP 53 포트도 열어두어야 함

메시지 형식

DNS 메시지는 질의와 응답이 같은 형식입니다.


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

┌─────────────────────────────────────────────┐
│                   Header                    │
│  (ID, Flags, 각 섹션의 레코드 수)            │
├─────────────────────────────────────────────┤
│                  Question                   │
│  (질의할 이름, 타입, 클래스)                 │
├─────────────────────────────────────────────┤
│                   Answer                    │
│  (응답 레코드들)                             │
├─────────────────────────────────────────────┤
│                  Authority                  │
│  (권한 정보 - NS 레코드 등)                  │
├─────────────────────────────────────────────┤
│                  Additional                 │
│  (추가 정보 - NS의 A 레코드 등)              │
└─────────────────────────────────────────────┘

Header 섹션

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

                                1  1  1  1  1  1
  0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                      ID                       |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE   |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    QDCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ANCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    NSCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ARCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+


주요 필드:

필드 설명
ID 16비트 식별자. 질의와 응답 매칭
QR 0=질의, 1=응답
AA Authoritative Answer
TC Truncated. 응답이 잘림 (TCP 재시도 필요)
RD Recursion Desired. 재귀 요청
RA Recursion Available. 서버가 재귀 지원
RCODE 응답 코드 (0=성공, 3=NXDOMAIN 등)


RCODE 값:

값 이름 의미
0 NOERROR 성공
1 FORMERR 형식 오류
2 SERVFAIL 서버 실패
3 NXDOMAIN 도메인 없음
5 REFUSED 거부됨

Question 섹션

1
2
3
4
5
6
7
8
9

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                                               |
/                     QNAME                     /
/                                               /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                     QTYPE                     |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                     QCLASS                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+


QNAME은 레이블 형식으로 인코딩됩니다.

1
2
3
4
5
6
7

www.example.com

인코딩:
03 77 77 77   → 3 w w w
07 65 78 61 6D 70 6C 65   → 7 e x a m p l e
03 63 6F 6D   → 3 c o m
00            → 종료


각 레이블 앞에 길이 바이트가 붙습니다.

마지막은 0으로 끝납니다.

Answer, Authority, Additional 섹션

세 섹션 모두 같은 Resource Record(RR) 형식입니다.


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

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                                               |
/                     NAME                      /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                     TYPE                      |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                     CLASS                     |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                      TTL                      |
|                                               |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                   RDLENGTH                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/                     RDATA                     /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+


NAME: 도메인 이름 (압축 가능)

TYPE: A(1), AAAA(28), CNAME(5), MX(15), NS(2) 등

CLASS: 거의 항상 IN(Internet) = 1

TTL: 32비트, 초 단위

RDLENGTH: RDATA 길이

RDATA: 타입에 따른 실제 데이터 (A면 4바이트 IPv4 주소)

메시지 압축

같은 도메인 이름이 반복되면 공간 낭비입니다.

DNS는 이름 압축(Name Compression)을 사용합니다.


1
2
3
4
5
6
7
8
9

첫 번째 등장:
offset 12: 03 77 77 77 07 65 78 61 6D 70 6C 65 03 63 6F 6D 00
           (www.example.com)

두 번째 등장 (같은 이름 참조):
C0 0C
│  │
│  └── offset 12를 가리킴
└───── 상위 2비트가 11이면 포인터


상위 2비트가 11(이진)이면 나머지 14비트는 오프셋입니다.

이전에 나온 이름을 가리킵니다.

Glue Record

위임의 순환 문제

example.com의 네임서버가 ns1.example.com이라면?


1

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


example.com을 조회하려면 ns1.example.com의 IP가 필요합니다.

ns1.example.com의 IP를 조회하려면 example.com의 네임서버가 필요합니다.

순환 참조입니다.

Glue Record로 해결

상위 도메인(.com)이 Glue Record를 함께 제공합니다.


1
2
3

; .com Zone에서
example.com.      IN  NS    ns1.example.com.
ns1.example.com.  IN  A     93.184.216.1    ← Glue Record


.com 서버가 example.com의 NS를 응답할 때, Additional 섹션에 ns1.example.com의 A 레코드를 포함합니다.


1
2
3
4
5
6
7

;; AUTHORITY SECTION:
example.com.        172800  IN  NS  ns1.example.com.
example.com.        172800  IN  NS  ns2.example.com.

;; ADDITIONAL SECTION:
ns1.example.com.    172800  IN  A   93.184.216.1
ns2.example.com.    172800  IN  A   93.184.216.2


순환 참조가 해결됩니다.

로컬 DNS 설정

/etc/resolv.conf

Linux/macOS에서 DNS 설정 파일입니다.


1
2
3
4

# /etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4
search example.com


nameserver: 사용할 Recursive Resolver

search: 짧은 이름에 자동으로 붙일 도메인


server만 입력하면 server.example.com으로 조회합니다.

/etc/hosts

HOSTS.TXT의 현대판입니다.

DNS보다 먼저 확인됩니다.


1
2
3

# /etc/hosts
127.0.0.1       localhost
192.168.1.100   myserver.local


개발 환경에서 도메인을 로컬 IP로 매핑할 때 유용합니다.

마무리: 질의의 여정

DNS 질의는 단순해 보이지만 복잡한 과정입니다.


1
2
3
4
5
6
7

요약: www.example.com 조회

1. 브라우저/OS 캐시 확인
2. Stub Resolver → Recursive Resolver (재귀적)
3. Recursive Resolver → Root → TLD → Authoritative (반복적)
4. 결과 캐싱
5. 응답 전달


캐싱이 없다면 매번 전 세계를 돌아다녀야 합니다.

TTL과 계층적 캐싱이 시스템을 효율적으로 만듭니다.


다음 편에서는 DNS의 보안 문제와 DNSSEC, DoH/DoT 같은 현대적 발전을 살펴봅니다.

시리즈 네비게이션

관련 시리즈

Tags: DNS, 네트워크, 캐싱, 프로토콜

Categories: ,

관련 문제