도메인을 샀다, 그래서 DNS를 공부했다

드디어 개인 도메인을 샀다

개발자라면 한 번쯤 "내 도메인 하나 있으면 좋겠다"는 생각을 한다. 나도 그랬고, 드디어 iamian.app를 구매했다. 결제 버튼을 누르는 순간의 그 짜릿함이란.

그런데 도메인을 사고 나니 궁금한 게 생겼다. 브라우저에 iamian.app를 치면 어떻게 내 서버까지 찾아가는 걸까? 네임서버를 변경하라는데, 네임서버가 뭐지? A 레코드? CNAME? 이 용어들이 뭔지 대충은 알겠는데, 제대로 설명하라면 자신이 없었다.

그래서 이 기회에 DNS를 처음부터 끝까지 정리해보기로 했다.

1. DNS 기초

DNS란?

DNS(Domain Name System)는 인터넷의 전화번호부다. 사람이 읽을 수 있는 도메인 이름(iamian.app)을 컴퓨터가 이해하는 IP 주소(76.76.21.21)로 변환해주는 시스템이다.

전화번호부 없이 모든 전화번호를 외워야 한다면 얼마나 불편할까. DNS가 없다면 우리는 웹사이트에 접속할 때마다 IP 주소를 직접 입력해야 한다. 142.250.196.110을 외우는 것보다 google.com이 훨씬 낫다.

도메인 구조

URL은 여러 파트로 구성되어 있다. 아래 시각화에서 직접 확인해보자.

도메인은 오른쪽부터 읽는다. .app이 TLD(최상위 도메인), iamian이 SLD(2차 도메인), blog가 서브도메인이다. 이 계층 구조가 DNS 조회의 핵심이 된다.

TLD의 종류:

• gTLD (Generic): .com, .net, .org, .io 등
• ccTLD (Country Code): .kr, .jp, .uk 등
• New gTLD: .dev, .app, .blog 등

DNS 레코드 타입

도메인에는 다양한 레코드를 설정할 수 있다. 각 레코드가 어떤 역할을 하는지 탭을 눌러 확인해보자.

;; ANSWER SECTION:
iamian.app.        300    IN    A    76.76.21.21

실무에서 가장 많이 쓰는 건 A, CNAME, MX, TXT 레코드다. Vercel에 도메인을 연결할 때도 A 레코드나 CNAME을 설정하게 된다.

2. DNS 조회 과정

DNS 서버 계층 구조

DNS 조회를 이해하려면 먼저 DNS 서버의 계층 구조를 알아야 한다. 각 카드를 눌러 자세한 설명을 확인해보자.

핵심은 위임(delegation) 이다. Root는 TLD 서버를, TLD는 Authoritative 서버를 안내할 뿐, 직접 IP를 알려주지 않는다.

브라우저에 URL을 입력하면?

브라우저에 iamian.app를 입력하고 Enter를 누르면, IP 주소를 얻기 위해 여러 단계의 DNS 조회가 일어난다. 아래에서 전체 과정을 단계별로 따라가보자.

요약하면 이런 흐름이다:

1. 로컬 캐시 확인 (브라우저 → OS → /etc/hosts)
2. ISP DNS 서버에 질의 (재귀적 리졸버)
3. ISP DNS가 Root → TLD → Authoritative 순서로 반복 질의
4. 최종적으로 IP 주소를 받아 브라우저로 전달

중요: 위 과정은 모든 단계를 항상 거치는 것이 아니다. 각 단계에서 캐시에 답이 있으면 거기서 즉시 반환된다. 브라우저 캐시에 있으면 OS까지 안 가고, ISP DNS 캐시에 있으면 Root 서버까지 갈 필요가 없다. 실제로 대부분의 DNS 조회는 캐시 덕분에 1~2단계 만에 끝난다.

재귀(Recursive) vs 반복(Iterative) 쿼리

• 재귀 쿼리: 클라이언트가 ISP DNS에 "이 도메인의 IP 알려줘"라고 요청하면, ISP DNS가 알아서 전체 체인을 돌아 최종 답을 가져다준다. 클라이언트 입장에서는 한 번 요청으로 끝.
• 반복 쿼리: ISP DNS가 루트, TLD, Authoritative 서버에 각각 질의하는 과정. "나는 모르겠고, 저쪽에 물어봐"라는 응답(referral)을 받아가며 답을 찾아간다.

일반적으로 클라이언트 → ISP DNS는 재귀, ISP DNS → 각 네임서버는 반복 방식으로 동작한다.

TTL과 캐싱

DNS 응답에는 TTL(Time To Live) 값이 포함된다. "이 결과를 N초 동안 캐시해도 돼"라는 의미다. TTL이 짧으면 변경사항이 빠르게 반영되지만, DNS 조회가 자주 발생한다. TTL이 길면 캐시 효율은 좋지만, 레코드 변경 시 전파가 느려진다.

일반적인 TTL 설정:

• A/AAAA 레코드: 300초 (5분) ~ 3600초 (1시간)
• MX 레코드: 3600초 (1시간) ~ 86400초 (24시간)
• NS 레코드: 86400초 (24시간) 이상

도메인 마이그레이션 전에는 TTL을 미리 낮춰두는 것이 좋다. 기존 TTL이 24시간이면, 마이그레이션 24시간 전에 TTL을 5분으로 변경해두면 전환이 훨씬 부드럽다.

3. 실전: 도메인 연결하기

네임서버 변경

도메인을 구매하면 기본적으로 등록 기관(registrar)의 네임서버가 설정되어 있다. Vercel이나 Cloudflare 같은 서비스를 사용하려면 네임서버를 변경해야 한다.

# 도메인 등록 기관 관리 페이지에서 변경
기존: ns1.registrar-default.com
변경: ns1.vercel-dns.com, ns2.vercel-dns.com

네임서버를 변경하면, 해당 도메인의 모든 DNS 레코드 관리 권한이 새 네임서버로 넘어간다. 이후 Vercel 대시보드에서 A, CNAME 등 레코드를 설정할 수 있다.

SSL/HTTPS 연동

요즘 대부분의 호스팅 서비스는 Let's Encrypt를 통해 자동으로 SSL 인증서를 발급해준다. 도메인을 연결하면 자동으로 HTTPS가 활성화된다.

ACME(Automatic Certificate Management Environment) 프로토콜이 이 과정을 자동화한다:

1. 서버가 Let's Encrypt에 인증서 발급 요청
2. Let's Encrypt가 도메인 소유권 검증 (DNS TXT 레코드 또는 HTTP 챌린지)
3. 검증 통과 시 인증서 발급
4. 만료 전 자동 갱신 (보통 90일)

DNS 전파 (Propagation)

네임서버에서 레코드를 변경하면 전 세계에 즉시 반영될까? 아니다.

"전파"라는 이름이 마치 서버가 능동적으로 변경사항을 밀어내는(push) 것처럼 들리지만, 실제 동작은 캐시 만료 후 재조회다. Authoritative 서버에는 즉시 반영되지만, 전 세계 Recursive Resolver들은 이전 값을 TTL만큼 캐시하고 있다. 각 리졸버의 캐시가 개별적으로 만료될 때, 그때서야 Authoritative에 다시 질의해서 새 값을 받아간다.

그래서 물리적으로 가까운 서버가 먼저 업데이트된다는 보장이 없다. 서울의 ISP DNS가 5분 전에 캐시했다면 금방 만료되지만, 바로 옆 도쿄의 DNS가 20시간 전에 캐시했다면 아직 한참 남아 있다. 전파 속도는 거리가 아니라 각 리졸버의 캐시 잔여 TTL이 결정한다.

아래 시뮬레이션에서 확인해보자 — 네임서버 바로 옆의 유럽 서부보다 한국이 먼저 업데이트되는 것을 볼 수 있다.

전파 확인 방법

dig이나 nslookup 명령어로 DNS 레코드를 직접 확인할 수 있다.

# dig 명령어 (macOS, Linux)
dig iamian.app A +short
# 출력: 76.76.21.21

# 상세 조회
dig iamian.app A
# ;; ANSWER SECTION:
# iamian.app.    300    IN    A    76.76.21.21

# 특정 DNS 서버로 직접 질의
dig @8.8.8.8 iamian.app A +short
# Google DNS를 통해 조회

# nslookup (Windows, macOS, Linux)
nslookup iamian.app
# Server:  168.126.63.1
# Address: 168.126.63.1#53
# Non-authoritative answer:
# Name:    iamian.app
# Address: 76.76.21.21

# 네임서버 확인
dig iamian.app NS +short
# ns1.vercel-dns.com.
# ns2.vercel-dns.com.

온라인 도구로는 whatsmydns.net이 전 세계 DNS 전파 상태를 한눈에 보여준다.

4. 심화: DNS 보안과 인프라

DNSSEC (DNS Security Extensions)

왜 필요한가?

기본 DNS는 UDP 기반이라 응답 패킷을 위조하기 쉽다. DNS Cache Poisoning 공격이 대표적이다:

1. 공격자가 리졸버에게 가짜 DNS 응답을 보냄
2. 리졸버가 이를 진짜로 착각하고 캐시
3. 이후 해당 도메인을 조회하는 모든 사용자가 가짜 IP로 연결
4. 피싱 사이트로 유도 → 비밀번호, 카드 정보 탈취

HTTPS가 있으니 괜찮다고 생각할 수 있지만, DNS 단계에서 이미 잘못된 서버로 갔다면 HSTS가 없는 사이트는 취약하다.

핵심 아이디어: 서명과 신뢰 체인

DNSSEC은 모든 DNS 응답에 디지털 서명을 추가한다. 존(Zone)마다 공개키/비밀키 쌍을 가지고, 비밀키로 레코드를 서명하고, 리졸버가 공개키로 검증한다. "이 응답이 정말 Authoritative 서버에서 온 것인가?"를 확인할 수 있는 것이다.

키가 두 종류인 이유가 있다:

• ZSK (Zone Signing Key): 실제 DNS 레코드(A, MX 등)를 서명. 자주 교체됨 (1~3개월).
• KSK (Key Signing Key): ZSK를 포함한 DNSKEY 레코드 세트를 서명. 드물게 교체 (1~2년). 상위 존의 DS 레코드에 등록됨.

ZSK를 교체할 때마다 상위 존(예: .app TLD)에 알려야 한다면 운영이 번거롭다. KSK가 ZSK를 보증하고, 상위 존은 KSK만 알면 되므로 ZSK 교체가 자유롭다.

Root Zone부터 TLD, Authoritative까지 이어지는 신뢰 체인(Chain of Trust) 으로 각 레벨의 서명을 검증한다. 아래에서 전체 과정을 단계별로 따라가보자.

DNSSEC은 응답의 무결성과 출처를 검증할 뿐, 쿼리/응답 내용을 암호화하지 않는다. 네트워크 감청을 통해 어떤 도메인을 조회하는지는 여전히 볼 수 있다. 암호화는 아래에서 설명할 DoH/DoT의 역할이다.

DNS over HTTPS (DoH) / DNS over TLS (DoT)

기본 DNS 쿼리는 평문 UDP로 전송된다. 즉, 네트워크를 감청하면 사용자가 어떤 사이트에 접속하는지 볼 수 있다.

• DoH (DNS over HTTPS): DNS 쿼리를 HTTPS로 암호화. 포트 443 사용. 일반 HTTPS 트래픽과 구분이 어렵다.
• DoT (DNS over TLS): DNS 쿼리를 TLS로 암호화. 전용 포트 853 사용.

# 기본 DNS
[클라이언트] --UDP:53--> [DNS 서버]  (평문, 누구나 볼 수 있음)

# DoH
[클라이언트] --HTTPS:443--> [DNS 서버]  (암호화, 웹 트래픽에 섞임)

# DoT
[클라이언트] --TLS:853--> [DNS 서버]  (암호화, 전용 포트)

Chrome, Firefox, Safari 등 주요 브라우저는 이미 DoH를 지원한다. Cloudflare(1.1.1.1), Google(8.8.8.8) 등의 공개 DNS도 DoH/DoT을 제공한다.

CDN과 DNS의 관계

CDN(Content Delivery Network)은 DNS를 활용해 사용자를 가장 가까운 서버로 연결한다.

1. 사용자가 cdn.example.com 요청
2. DNS가 사용자의 **위치(IP 기반 Geo)**를 파악
3. 가장 가까운 엣지 서버의 IP를 응답
4. 사용자는 지리적으로 가까운 서버에서 콘텐츠를 받음

이것이 가능한 이유는 CDN의 DNS가 동일한 도메인에 대해 요청자 위치에 따라 다른 IP를 응답하기 때문이다. 이를 GeoDNS 또는 지리적 라우팅이라 한다.

Anycast DNS

Anycast는 하나의 IP 주소를 여러 서버가 공유하는 네트워크 기술이다.

사용자 A (서울) ──→ 서버 1 (도쿄)  ← 같은 IP: 1.1.1.1
사용자 B (런던) ──→ 서버 2 (파리)  ← 같은 IP: 1.1.1.1
사용자 C (뉴욕) ──→ 서버 3 (시카고) ← 같은 IP: 1.1.1.1

BGP 라우팅이 자동으로 가장 가까운 서버로 트래픽을 보낸다. Cloudflare의 1.1.1.1이 대표적인 Anycast DNS다. 장점은:

• 낮은 지연시간: 물리적으로 가까운 서버 응답
• DDoS 방어: 공격 트래픽이 여러 서버로 분산
• 높은 가용성: 한 서버가 다운되면 다른 서버가 자동으로 처리

마무리

이 글에서 다룬 내용을 정리하면:

1. DNS 기초: 도메인 구조, 레코드 타입 (A, CNAME, MX, TXT, NS)
2. 조회 과정: 브라우저 → 캐시 → ISP → Root → TLD → Authoritative
3. 실전: 네임서버 변경, SSL 자동 발급, 전파 확인
4. 심화: DNSSEC 신뢰 체인, DoH/DoT 암호화, CDN과 Anycast

다음에 dig 명령어를 칠 때는 조금 다른 눈으로 보게 될 것 같다.