Network Fundamentals - 08. DNS

이름을 물으면 주소가 나오는 전화번호부 — DNS

브라우저에 example.com을 친다. 컴퓨터는 example.com이라는 이름을 모른다 — IP 주소(93.184.216.34)만 안다. 이름과 주소 사이의 이 간극을 메우는 것이 DNS(Domain Name System) 이다. 전 세계의 도메인 이름과 IP 주소를 연결하는 분산 데이터베이스. 인터넷의 전화번호부. DNS가 없으면 — 사용자가 93.184.216.34를 외워서 쳐야 한다. DNS 덕분에 사람은 이름을 기억하고, 컴퓨터는 주소로 통신한다.

이 글은 DNS를 다룬다. 도메인 이름이 어떻게 IP 주소로 변환되는가(resolution), 재귀 서버와 권한 서버의 역할, DNS 레코드 종류(A·AAAA·CNAME·MX·TXT·NS), TTL이 왜 중요한가, DNSSEC과 DoH(DNS over HTTPS)가 왜 만들어졌는지. foundations 03에서 본 "DNS는 SPOF의 흔한 원인"이라는 말이 — DNS가 인터넷의 핵심 의존성이기 때문임을 이해할 것이다.

DNS 해석 — 이름에서 주소로 가는 여정

example.com을 브라우저에 치면 — DNS 해석(resolution)이라는 과정이 시작된다. 이 과정은 여러 서버를 거친다.

sequenceDiagram
    participant U as 사용자 PC
    participant R as 재귀 서버<br/>(리졸버)
    participant Root as 루트 서버
    participant TLD as .com TLD 서버
    participant Auth as example.com<br/>권한 서버

    U->>R: example.com의 IP?
    R->>Root: .com 네임서버가 어디야?
    Root-->>R: .com TLD 서버 주소들
    R->>TLD: example.com 네임서버가 어디야?
    TLD-->>R: example.com 권한 서버 주소들
    R->>Auth: example.com의 IP가 뭐야?
    Auth-->>R: 93.184.216.34 (A 레코드)
    R-->>U: 93.184.216.34
    Note over R: 캐시에 저장 (TTL 동안)

각 단계를 보자.

1. 재귀 서버(resolver)에게 물음 — PC는 먼저 자기가 설정한 재귀 서버(recursive resolver) 에게 example.com의 IP를 물어본다. 재귀 서버는 보통 ISP의 DNS 서버(예: 8.8.8.8 Google DNS, 1.1.1.1 Cloudflare DNS)다. PC의 /etc/resolv.conf에 설정돼 있다.

2. 루트 서버 — 재귀 서버가 example.com의 IP를 모르면 — 루트 서버(root server) 에게 ".com" TLD(Top-Level Domain) 네임서버의 주소를 물어본다. 루트 서버는 전 세계에 13개의 IP(물리적으로는 수백 개 인스턴스로 분산)가 있고, 인터넷 DNS의 최상위다. 루트 서버는 IP를 직접 주지 않고 — ".com을 담당하는 TLD 서버 주소를 줄게"라고 방향만 알려준다.

3. TLD 서버 — 재귀 서버가 .com TLD 서버에게 "example.com"의 권한 서버(authoritative server) 주소를 물어본다. TLD 서버는 "example.com은 ns1.example.com이 담당해"라고 알려준다.

4. 권한 서버(authoritative server) — 재귀 서버가 example.com의 권한 서버에게 "example.com의 IP가 뭐야?"라고 물어보면 — 드디어 IP(93.184.216.34)를 받는다.

5. 캐시 — 재귀 서버는 이 IP를 TTL(Time To Live) 동안 캐시에 저장한다. 다음에 같은 질의가 오면 — 캐시에서 즉시 답한다. 위의 4단계를 다시 안 거친다. TTL이 중요한 이유가 여기 있다 — TTL이 길면 캐시가 오래 유지돼 빠르지만, IP를 바꿨을 때 캐시가 갱신되기까지 오래 걸린다. TTL이 짧으면 갱신은 빠르지만 — 매번 위의 과정을 거쳐야 해서 지연이 발생한다.

재귀 서버 vs 권한 서버

DNS 서버는 두 종류로 나뉜다. 이 구분이 DNS의 핵심이다.

재귀 서버(recursive resolver, 리졸버) — 사용자를 대신해 여러 서버를 돌아다니며 답을 찾는 서버. "재귀적(recursive)"이라는 말은 — 질문을 받으면 답을 찾을 때까지 스스로 여러 서버에 물어본다는 뜻. 찾은 답을 캐시에 저장하고 사용자에게 돌려준다. Google DNS(8.8.8.8)·Cloudflare DNS(1.1.1.1)·ISP DNS가 여기 속한다. 비유하자면 — 도서관 사서. "이 책 어디 있어요?"라고 물으면, 사서가 알아서 서가를 뒤져서 찾아준다.

권한 서버(authoritative server, 네임서버) — 특정 도메인에 대해 최종 권위를 가진 서버. "example.com의 IP는? 내가 example.com의 권한 서버니까 답할게 — 93.184.216.34야." 권한 서버는 다른 서버에 물어보지 않는다. 자기가 답한다. Route 53·Cloudflare DNS(Authoritative)·BIND(자체 호스팅)가 여기 속한다. 비유하자면 — 책의 저자. 저자에게 "이 책의 결말이 뭐야?"라고 물으면, 저자가 직접 답한다.

특성	재귀 서버 (resolver)	권한 서버 (authoritative)
역할	사용자 대신 답 찾기	특정 도메인의 최종 답 제공
캐시	있음 (TTL 기반)	없음 (항상 같은 답)
사용자	일반 사용자가 직접 사용	재귀 서버만 질의
전형 사례	8.8.8.8, 1.1.1.1, ISP DNS	Route 53, Cloudflare, BIND
비유	도서관 사서	책의 저자

DNS 레코드 — 도메인에 어떤 정보가 저장되나

DNS에는 IP 주소만 저장되는 게 아니다. 도메인에 대한 다양한 정보가 레코드(record) 형태로 저장된다.

레코드 타입	이름	내용	예
A	Address	도메인 → IPv4 주소	example.com. A 93.184.216.34
AAAA	IPv6 Address	도메인 → IPv6 주소	example.com. AAAA 2606:2800:220:1::
CNAME	Canonical Name	도메인 → 다른 도메인 (별칭)	www.example.com. CNAME example.com.
MX	Mail Exchange	이메일 서버 지정	example.com. MX 10 mail.example.com.
TXT	Text	임의 텍스트 (SPF, DKIM, 인증)	example.com. TXT "v=spf1 ..."
NS	Name Server	이 도메인의 권한 서버	example.com. NS ns1.example.com.
SOA	Start of Authority	도메인 메타데이터	serial, refresh, retry, expire
PTR	Pointer	IP → 도메인 (역방향)	34.216.184.93.in-addr.arpa. PTR example.com.
SRV	Service	특정 서비스의 호스트·포트	_sip._tcp.example.com. SRV ...
CAA	Certification Authority Authorization	인증서 발급 기관 제한	example.com. CAA 0 issue "letsencrypt.org"

초심자가 자주 보는 것은 — A(IPv4), AAAA(IPv6), CNAME(별칭), MX(이메일). TXT는 이메일 인증(SPF·DKIM·DMARC)과 도메인 소유권 인증에 자주 쓰인다.

CNAME과 A의 차이 — A는 도메인이 직접 IP를 가리키고, CNAME은 다른 도메인을 가리킨다. www.example.com CNAME example.com이면 — www.example.com을 찾을 때 example.com의 A 레코드를 따라간다. CDN(Cloudflare·CloudFront)을 쓸 때 CNAME이 흔하다 — www.example.com CNAME example.cdn.net으로 CDN의 도메인을 가리키는 것이다.

TTL — 캐시 수명

TTL(Time To Live) 은 DNS 레코드의 캐시 수명(초 단위)이다. 재귀 서버가 권한 서버에서 답을 받으면 — TTL 동안 캐시에 저장하고, TTL이 지나면 폐기한다. 다음 질의는 다시 권한 서버까지 가야 한다.

TTL 설정	효과	전형 사례
60초 (낮음)	IP 변경이 빠르게 전파, 하지만 질의 빈도 높음	장애 조치(failover), 카나리 배포
3600초 (1시간)	균형 — 보통 설정	일반 웹 서비스
86400초 (1일)	캐시 효율 높음, 하지만 IP 변경 전파 느림	거의 안 바뀌는 서비스

IP를 바꿀 계획이 있으면 — 미리 TTL을 낮춰둔다(예: 1주일 전에 3600초 → 60초로). 그래야 기존 캐시가 빨리 만료되고, 새 IP가 전파된다. 그렇지 않으면 — TTL이 긴 캐시가 남아서 일부 사용자가 옛날 IP로 계속 접속한다.

DNS 캐싱 계층 — 여러 층에서 이름을 기억한다

DNS 해석은 — 매번 루트 서버부터 권한 서버까지 여행하면 느리다. 그래서 여러 층에서 캐시(cache) 한다. DNS 해석의 실제 여행은 — 대부분 캐시에서 끝난다.

flowchart TD
    APP["1. 브라우저 캐시<br/>(Chrome, Firefox)"] -->|"miss"| OS["2. OS 캐시<br/>(nscd/systemd-resolved)"]
    OS -->|"miss"| RESOLVER["3. 재귀 서버 캐시<br/>(ISP/Google/Cloudflare)"]
    RESOLVER -->|"miss"| AUTH["4. 권한 서버<br/>(Route 53/Cloudflare)"]
    AUTH -.->|"TTL 동안 캐시"| RESOLVER
    RESOLVER -.->|"TTL 동안 캐시"| OS
    OS -.->|"짧은 캐시"| APP

1. 브라우저 캐시 — Chrome·Firefox가 자체적으로 DNS 캐시를 갖는다. 같은 사이트를 다시 방문하면 — 브라우저가 즉시 IP를 반환(0ms). 캐시 시간은 보통 60초 ~ 수 분.
2. OS 캐시 — Linux의 nscd(Name Service Cache Daemon) 또는 systemd-resolved가 OS 수준에서 캐시. 같은 머신의 모든 앱이 공유한다.
3. 재귀 서버 캐시 — ISP나 Google(8.8.8.8)·Cloudflare(1.1.1.1)의 재귀 서버가 TTL 동안 캐시. 같은 ISP를 쓰는 다른 사용자가 이미 example.com을 해석했으면 — 재귀 서버가 즉시 답한다(1 ~ 5ms). 대부분의 DNS 질의는 여기서 끝난다.
4. 권한 서버 — 캐시가 모두 실패(miss)하면 — 재귀 서버가 루트 → TLD → 권한 서버까지 거슬러 올라간다(20 ~ 100ms). 이 과정은 — 캐시가 만료된 첫 질의에만 발생한다.

캐싱 덕분에 — DNS 해석의 평균 지연은 수 ms 이하다. 캐시가 없으면 매번 50 ~ 200ms가 걸린다.

Split-horizon DNS — 내부와 외부에 다른 답

Split-horizon DNS(스플릿 호라이즌 DNS) 는 — 같은 도메인 이름에 대해 질문자의 위치에 따라 다른 답을 주는 기술이다. 예를 들어 — intranet.company.com을 사내 네트워크에서 물으면 사내 IP(10.0.0.5)를 주고, 인터넷에서 물으면 "없는 도메인"이라고 답한다. 또는 — www.example.com을 한국에서 물으면 한국 서버 IP를, 미국에서 물으면 미국 서버 IP를 준다(GeoDNS, 지리적 DNS).

이게 가능하려면 — 재귀 서버(또는 권한 서버)가 질문자의 위치를 알아야 한다. DNS 질의의 출발지 IP(재귀 서버의 IP)로 지역을 추정한다. AWS Route 53의 "지연 기반 라우팅(latency-based routing)"·Cloudflare의 Geo Steering이 이 원리다.

DNS 유형	동작	전형 사례
일반 DNS	모두에게 같은 답	대부분의 공개 웹사이트
Split-horizon	내부/외부 다른 답	사내 인트라넷, 개발/운영 환경 분리
GeoDNS	지역별 다른 서버 IP	글로벌 CDN, 지역 서비스
라운드 로빈 DNS	여러 IP를 번갈아 반환	기본적인 부하 분산

DNS 라운드 로빈 — 가장 단순한 부하 분산

DNS 라운드 로빈(round-robin DNS) 은 — 하나의 도메인에 여러 A 레코드를 등록하고, 질의가 올 때마다 순서를 바꿔서 반환하는 기술이다.

example.com.  300  IN  A  192.0.2.10
example.com.  300  IN  A  192.0.2.11
example.com.  300  IN  A  192.0.2.12

첫 질의에는 .10, .11, .12 순서로, 다음 질의에는 .11, .12, .10 순서로 반환. 클라이언트는 보통 첫 번째 IP로 접속하니 — 트래픽이 세 서버에 분산된다.

한계 — DNS 라운드 로빈은 로드 밸런서가 아니다. 서버가 죽어도 DNS에서 제거하지 않는 한 — 죽은 서버의 IP가 계속 반환된다(헬스체크 없음). 또한 — DNS 캐싱 때문에 분배가 정확하지 않다(한 재귀 서버가 캐시한 IP를 수만 명의 사용자가 공유). 실제 부하 분산에는 — 로드 밸런서(이 영역의 마지막 글에서 다룸)를 쓰는 게 정답이다. DNS 라운드 로빈은 보조적 분산 수단이다.

DNSSEC — DNS 응답의 진위 보장

DNS는 원래 보안이 없었다. 누구나 DNS 질의를 가로채서(False 응답을 보낼 수 있다(DNS spoofing·DNS poisoning). example.com의 IP를 물었는데 공격자가 가짜 IP를 주면 — 사용자가 악성 사이트로 간다.

DNSSEC(DNS Security Extensions, RFC 4033~4035) 은 — DNS 응답에 디지털 서명을 붙여서, 응답이 진짜 권한 서버에서 왔음을 보장한다. 공격자가 가짜 응답을 보내도 — 서명이 없거나 틀리면 재귀 서버가 거부한다. DNSSEC은 2026년 기준으로 주요 TLD(.com·.net·.org·.kr)에서 지원되지만, 개별 도메인의 활성화율은 여전히 낮다(약 30%).

DoH/DoT — DNS 질의 암호화

일반 DNS 질의는 평문(UDP 53번 포트)으로 전송된다. 네트워크 중간자(ISP·카페 Wi-Fi)가 — 누가 어떤 사이트에 접속하려 하는지를 DNS 질의에서 볼 수 있다.

• DoT(DNS over TLS, RFC 7858) — DNS 질의를 TLS로 암호화. 포트 853. ISP가 내용을 못 본다.
• DoH(DNS over HTTPS, RFC 8484) — DNS 질의를 HTTPS로 암호화. 포트 443(일반 HTTPS와 같음). 방화벽이 DNS를 차단해도 HTTPS는 뚫기 어려우니 — 검열 우회에 쓰인다.

Firefox·Chrome이 기본적으로 DoH를 지원한다(Cloudflare 1.1.1.1 또는 Google 8.8.8.8로 전송).

DNS 문제 해결 — 흔한 장애와 진단

DNS 문제는 — "사이트가 안 열린다"는 보고의 흔한 원인이다. 체계적 진단 순서:

1. 로컬 해석 확인 — dig example.com이 작동하는가? 안 되면 — /etc/resolv.conf의 nameserver 확인. DNS 서버가 죽었을 수 있음.
2. 재귀 서버 확인 — dig @8.8.8.8 example.com으로 다른 재귀 서버를 지정. ISP DNS가 문제면 — Google DNS로 바꾸면 됨.
3. 권한 서버 확인 — dig +trace example.com으로 루트부터 추적. 어디서 끊기는지 보임.
4. TTL 만료 확인 — 도메인을 방금 바꿨는데 안 되면 — TTL이 긴 캐시 때문. dig example.com의 TTL이 아직 높으면 — 기존 캐시가 남아있는 것.

증상	원인	해결
모든 사이트가 안 열림	DNS 서버 장애	재귀 서버 변경 (8.8.8.8)
특정 사이트만 안 열림	해당 도메인 DNS 장애	권한 서버 확인, TTL 대기
IP를 바꿨는데 일부 사용자가 옛날 사이트	TTL 캐시	TTL 낮추고 대기
이메일이 안 감	MX 레코드 문제	dig domain MX 확인
DNS 응답이 느림	재귀 서버 성능	가까운 DNS 서버(지리적) 사용

실습 — DNS 직접 확인

1. 단순 질의

# 도메인의 IP (A 레코드)
dig example.com +short
# 또는
nslookup example.com

확인할 것: A 레코드(IPv4)가 나온다. 빈 결과면 — 도메인이 없거나 DNS가 안 됨.

2. 전체 해석 경로 추적

# 루트 → TLD → 권한 서버까지의 경로
dig +trace example.com

확인할 것: +trace가 루트 서버부터 시작해 각 단계의 답을 보여준다. 루트 서버 → .com TLD → example.com 권한 서버 → A 레코드의 순서가 보인다.

3. 특정 레코드 조회

# MX (이메일 서버)
dig example.com MX +short
# TXT (SPF 등)
dig example.com TXT +short
# NS (권한 서버)
dig example.com NS +short
# AAAA (IPv6)
dig example.com AAAA +short

확인할 것: 레코드 타입을 지정하면 해당 레코드만 나온다. MX가 비어 있으면 — 이 도메인은 이메일을 안 받는 것.

4. TTL 확인

# TTL 포함 상세 출력
dig example.com
# ANSWER SECTION의 마지막 숫자가 TTL (초)

확인할 것: ;; ANSWER SECTION:에서 example.com. 3600 IN A 93.184.216.34의 3600이 TTL. 캐시 수명이 1시간이라는 뜻.

5. 사용 중인 DNS 서버 확인

# /etc/resolv.conf — 시스템의 재귀 서버
cat /etc/resolv.conf
# systemd-resolved 상태
resolvectl status 2>/dev/null | head -10

확인할 것: nameserver 행이 시스템이 사용하는 재귀 서버. 8.8.8.8이면 Google DNS, 1.1.1.1이면 Cloudflare, 168.126.63.1이면 KT DNS.

미검증: dig는 별도 설치 필요(apt install dnsutils). resolvectl은 systemd-resolved를 사용하는 시스템에서만 동작. 클라우드 VM은 VPC의 DNS 서버(AWS: 두 번째 IP의 .2)를 사용.

DNS는 인터넷의 "이름 계층"이다

DNS를 이해하면 — "왜 도메인이 안 풀리면 사이트가 안 열리나?"(DNS 장애), "왜 IP를 바꿨는데 일부 사용자가 옛날 사이트를 보나?"(TTL이 긴 캐시), "왜 ISP가 어떤 사이트를 차단할 수 있나?"(DNS 차단)에 답할 수 있다. DNS는 인터넷의 이름 계층이고 — foundations 03에서 본 SPOF의 흔한 원인이다. DNS가 죽으면 IP를 못 찾고, IP를 못 찾으면 통신 자체가 안 된다.

다음 글에서는 HTTP와 TLS를 다룬다 — 이름으로 찾은 IP로 데이터를 안전하게 주고받는 방법. HTTP/1.1에서 HTTP/3까지, TLS 핸드셰이크와 인증서가 어떻게 보안을 만드는지를 본다.

DNS는 — 이름과 주소를 연결하는 인터넷의 전화번호부이자 — foundations 03에서 본 SPOF의 흔한 원인이다. DNS가 죽으면 IP를 못 찾고, IP를 못 찾으면 통신 자체가 안 된다. 이 영역에서 가장 많이 장애가 나는 서비스 중 하나다.
DNS는 — 인터넷의 이름 계층이자, foundations 03에서 본 SPOF의 흔한 원인이다. DNS가 죽으면 IP를 못 찾고, IP를 못 찾으면 통신 자체가 안 된다. DNS를 이해하는 것은 — 인터넷의 의존성 구조를 이해하는 것이다.

DNS의 핵심 — 재귀 서버가 "대신 찾아주고" 캐시에 저장하며, 권한 서버가 "최종 답을 준다". TTL이 캐시 수명을 결정하고, DNSSEC이 응답의 진위를 보장하며, DoH/DoT가 질의를 암호화한다. 인터넷의 이름 계층이자, 동시에 가장 흔한 장애 원인 — DNS를 이해하는 것이 인프라 엔지니어의 기본이다.
DNS는 이름과 주소를 연결하는 인터넷의 전화번호부다. 재귀 서버가 대신 찾아주고 캐시하며, 권한 서버가 최종 답을 준다. TTL이 캐시 수명을, DNSSEC이 진위를, DoH/DoT가 암호화를 담당한다. 다음 글에서는 HTTP와 TLS를 다룬다 — DNS로 찾은 IP로 데이터를 안전하게 주고받는 방법.이해 없이 DNS를 쓰면 — 장애의 원인과 해결을 모른다.DNS를 이해하는 것은 인터넷의 의존성 구조를 이해하는 것이다. DNS가 죽으면 — 통신 자체가 안 된다. 재귀 서버, 권한 서버, TTL, DNSSEC, DoH/DoT가 DNS의 핵심 요소다.
DNS는 인터넷의 이름 계층이며,
가장 흔한 장애 원인이기도 하다.
이해하면 — 장애의 원인과 해결이 보인다.

---

참고

• RFC 1035, Mockapetris, P. "Domain Names — Implementation and Specification", 1987, Internet Standard — DNS 핵심 표준. 접근 2026-07-21
• RFC 4033, Arends, R. et al. "DNS Security Introduction and Requirements", 2005 — DNSSEC. 접근 2026-07-21
• RFC 7858, Hu, Z. et al. "Specification for DNS over Transport Layer Security (TLS)", 2016 — DoT. 접근 2026-07-21
• RFC 8484, Hoffman, P., McManus, P. "DNS Queries over HTTPS (DoH)", 2018 — DoH. 접근 2026-07-21
• Liu, C., Albitz, P. 5th ed, O'Reilly, 2006 — DNS 실무 정론. 접근 2026-07-21
• Kurose, J. F., Ross, K. W. 8th ed, 2021, Ch.2 — DNS. 접근 2026-07-21