DNS: 인터넷 전화번호부와 0.1초의 여정 (완전정복)

1. 프롤로그 - "223.130.195.200 치고 접속하세요"

회사 첫 날이었다. 시니어가 말했다.

"테스트 서버 접속해봐요. IP는 192.168.45.237이에요."

나는 멍하니 메모장을 켰다. 숫자를 적었다. 다음날 또 물어봤다. 또 적었다. 일주일이 지나자 나는 깨달았다.

인간은 숫자를 기억하도록 설계되지 않았다.

그런데 우리는 매일 수십 개의 웹사이트에 접속한다. www.google.com, www.youtube.com, www.github.com. 이 이름들은 기억하지만, 그 뒤에 숨어있는 IP 주소 142.250.207.174, 172.217.174.206을 외우는 사람은 없다.

컴퓨터는 숫자(IP)만 이해하고, 인간은 이름(도메인)만 기억한다. 이 둘을 연결해주는 시스템이 바로 DNS(Domain Name System)다.

처음엔 "그냥 주소록 아니야?"라고 생각했다. 하지만 파고들수록 이건 단순한 변환기가 아니었다. 이건 0.1초 만에 전 세계 계층 구조를 순회하는 분산 데이터베이스였다. Root 서버, TLD 서버, Authoritative 서버. 캐싱, TTL, Anycast.

내가 주소창에 도메인을 입력하고 엔터를 치는 순간, 내 뒤에서 일어나는 일들을 정리해본다.

2. 과거의 투쟁 - HOSTS.TXT의 시대

DNS를 이해하려면, DNS가 왜 생겨났는지 알아야 했다.

1970년대 - 하나의 파일로 관리하던 인터넷

1970년대 ARPANET 시절, 인터넷에 연결된 컴퓨터는 고작 몇 백 대였다. 당시엔 HOSTS.TXT라는 단 하나의 텍스트 파일에 모든 컴퓨터의 이름과 주소를 적어서 관리했다.

# HOSTS.TXT (1975년 어느 날)
10.0.0.51  SRI-ARC
10.0.0.52  MIT-AI
10.0.0.73  BBN-TENEX
...

스탠퍼드 연구소(SRI)가 이 파일을 중앙에서 관리했고, 사람들은 FTP로 주기적으로 이 파일을 다운로드받아야 했다.

문제는 네트워크가 커지면서 시작됐다.

매일 새로운 컴퓨터가 추가됐다.
파일 크기가 기하급수로 커졌다.
동기화 지연이 발생했다. (내가 가진 파일은 3일 전 버전인데, 상대방은 오늘 추가됐다면?)
단일 실패 지점(Single Point of Failure): SRI 서버가 다운되면 전체 인터넷이 마비됐다.

1983: 폴 모카페트리스의 발명

폴 모카페트리스(Paul Mockapetris)는 이 문제를 해결하기 위해 계층적 분산 데이터베이스 시스템을 제안했다. 이게 바로 DNS였다.

핵심 아이디어는 간단했다.

"한 곳에서 모든 정보를 관리하지 말고, 책임을 나눠서 가지자."

.com 도메인은 .com TLD 서버가 관리한다.
google.com은 구글이 직접 관리한다.
Root 서버는 TLD 서버들의 주소만 알려준다.

이 구조가 지금까지 40년 넘게 인터넷의 근간으로 작동하고 있다는 사실이 와닿았다.

3. 아하 모먼트 - "DNS는 전화 교환원이 아니라 우편 체계다"

처음엔 DNS를 "전화번호부"라는 비유로 이해했다. 이름을 찾으면 번호가 나온다. 간단하다.

하지만 실제로 DNS 쿼리를 추적해보니, 이건 전화번호부가 아니었다.

DNS는 우편 체계에 가깝다.

편지를 보낼 때 우리는 "서울시 강남구 테헤란로 123"이라고 쓴다. 우체국은 이걸 한 번에 찾지 않는다.

먼저 서울시 우체국으로 보낸다.
서울시 우체국은 강남구 우체국으로 넘긴다.
강남구 우체국은 테헤란로 담당자에게 전달한다.
최종적으로 123번지 우편함에 도착한다.

DNS도 똑같다. www.google.com을 찾을 때:

Root 서버(.)가 ".com은 쟤가 관리해"라고 알려준다.
.com TLD 서버가 "google.com은 쟤가 관리해"라고 알려준다.
Google Authoritative 서버가 "www는 142.250.76.100이야"라고 최종 답을 준다.

결국 이거였다. DNS는 계층적 위임(Hierarchical Delegation) 시스템이다.

4. 심층 분석 - DNS Recursive Query의 6단계

브라우저에 www.naver.com을 입력했을 때, 정확히 무슨 일이 일어나는지 정리해본다.

Step 1: 브라우저 캐시

브라우저는 최근 방문 기록을 메모리에 저장한다.

# Chrome의 내부 DNS 캐시 (chrome://net-internals/#dns)
www.naver.com -> 223.130.195.200 (TTL: 300초 남음)

캐시 히트 → DNS 조회 스킵. 가장 빠른 경로다.

Step 2: OS 캐시

브라우저 캐시에 없으면 운영체제에 물어본다.

# macOS/Linux
$ dscacheutil -cachedump -entries Host

# Windows
$ ipconfig /displaydns

여기도 없으면 진짜 DNS 서버에 물어봐야 한다.

Step 3: Recursive Resolver (ISP DNS)

이제 ISP(통신사) DNS 서버에게 물어본다. 이 서버를 Recursive Resolver라고 부른다.

내 컴퓨터 -> KT DNS (168.126.63.1)
"www.naver.com IP 주세요!"

여기서 중요한 건, Recursive Resolver는 나를 대신해서 전 세계를 돌아다니며 답을 찾아온다는 점이다. 나는 단 한 번만 요청하면 된다.

Step 4: Root DNS 서버 (.)

ISP DNS는 가장 먼저 Root 서버에게 물어본다.

KT DNS -> Root 서버 (198.41.0.4)
"www.naver.com 어디 있어요?"

Root: "난 몰라. 하지만 .com을 관리하는 TLD 서버는 알아.
       a.gtld-servers.net (192.5.6.30) 한테 가봐."

전 세계에 Root 서버는 13개의 원본 서버(a.root-servers.net ~ m.root-servers.net)가 있다. 하지만 실제론 Anycast 기술로 수백 곳에 복제되어 있다.

Step 5: TLD 서버 (.com)

ISP DNS는 이제 .com TLD 서버에게 간다.

KT DNS -> .com TLD 서버 (192.5.6.30)
"naver.com 어디 있어요?"

TLD: "난 몰라. 하지만 naver.com을 관리하는 네임서버는 알아.
      ns1.naver.com (125.209.248.6) 한테 가봐."

TLD는 Top-Level Domain의 약자다. .com, .org, .kr, .io 같은 최상위 도메인을 관리한다.

Step 6: Authoritative Name Server (네이버)

마지막으로 네이버의 Authoritative 서버에게 물어본다.

KT DNS -> ns1.naver.com (125.209.248.6)
"www.naver.com IP 주세요!"

Naver DNS: "223.130.195.200이야. 이게 최종 답이야."

Authoritative는 "권위 있는"이란 뜻이다. 이 서버가 최종 정답을 가지고 있다.

Step 7: 응답 및 캐싱

ISP DNS는 이 IP를 받아서:

나에게 전달한다.
자기 자신도 캐싱해둔다. (다음 사람이 같은 걸 물어보면 바로 답해주기 위해)

KT DNS 캐시:
www.naver.com -> 223.130.195.200 (TTL: 300초)

이 모든 과정이 0.1초 안에 끝난다.

5. DNS 레코드 타입 - 도메인의 신분증

DNS는 단순히 IP만 저장하지 않는다. 다양한 레코드 타입이 있고, 각각 다른 역할을 한다.

레코드 타입	역할	예시	활용
A	도메인 → IPv4 주소	`example.com` → `93.184.216.34`	가장 기본적인 레코드. 웹사이트 호스팅의 핵심
AAAA	도메인 → IPv6 주소	`example.com` → `2606:2800:220:1::`	IPv6 지원. 차세대 주소 체계
CNAME	도메인 별칭 (Alias)	`www.example.com` → `example.com`	IP 변경 시 한 곳만 수정하면 됨
MX	메일 서버 지정	`example.com` → `mail.google.com` (우선순위: 10)	이메일 수신용. 우선순위 낮을수록 먼저 시도
NS	네임서버 지정	`example.com` → `ns1.aws.com`	"이 도메인 관리는 AWS Route53이 해"
TXT	텍스트 정보	`example.com` → `"v=spf1 include:_spf.google.com ~all"`	SPF 인증, 구글 서치 콘솔 인증 등
SOA	권한 시작 (Start of Authority)	-	도메인 관리 정보 (관리자 이메일, 갱신 주기, 시리얼 번호)
PTR	IP → 도메인 (역방향)	`34.216.184.93.in-addr.arpa` → `example.com`	스팸 필터링에 사용. 메일 서버가 진짜인지 확인
SRV	서비스 위치 지정	`_minecraft._tcp.example.com` → `server.example.com:25565`	게임 서버, VoIP 등 포트 정보 포함
CAA	인증서 발급 기관 제한	`example.com` → `letsencrypt.org`	Let's Encrypt만 SSL 인증서 발급 가능

실제 예시 - CNAME의 힘

blog.company.com으로 블로그를 운영한다고 해보자. 처음엔 A 레코드로 설정했다.

# 초기 설정
blog.company.com  A  52.123.45.67

나중에 서버를 AWS에서 Vercel로 옮겼다. IP가 바뀌었다. A 레코드를 수정해야 했다.

# 서버 이전 후
blog.company.com  A  76.223.47.193  # 변경됨!

CNAME을 쓰면 이런 문제가 없다.

# CNAME 설정
blog.company.com  CNAME  company.vercel.app

# Vercel이 IP를 바꿔도 CNAME은 그대로
company.vercel.app  A  76.223.47.193  # Vercel이 관리

IP가 바뀌어도 CNAME 레코드는 건드릴 필요가 없다. 이게 별칭의 힘이다.

6. TTL: 캐시의 수명을 결정하는 숫자

DNS 설정에서 가장 헷갈렸던 게 TTL(Time To Live)이었다.

TTL이란?

TTL은 "이 정보를 몇 초 동안 믿어도 되는지"를 나타낸다.

www.example.com  300  A  93.184.216.34
                 ↑
              TTL (초 단위)

이 레코드는 "300초(5분) 동안은 내 캐시를 믿고, 그 이후엔 다시 물어봐"라는 뜻이다.

TTL 길면 vs 짧으면

TTL	장점	단점	언제 쓰나
긴 TTL (86400초 = 24시간)	DNS 서버 부하 감소, 응답 속도 빠름	IP 변경 시 반영이 느림 (최대 24시간 소요)	안정적인 프로덕션 서버
짧은 TTL (60초 = 1분)	IP 변경 즉시 반영	DNS 조회 트래픽 증가, 약간의 속도 저하	서버 이전, A/B 테스트, 긴급 점검

팁 - 서버 이전 전에 TTL 줄이기

클라우드 마이그레이션 시에는 TTL 관리가 핵심이다. 예를 들어 AWS에서 GCP로 이전하는 경우를 생각해보자.

D-Day에 IP를 바꿨는데 TTL이 86400초(24시간)였다면, 일부 사용자가 24시간 동안 접속 오류를 겪을 수 있다. ISP DNS들이 구 IP를 하루 동안 캐싱하기 때문이다.

올바른 절차는 이렇다.

D-7일: TTL을 300초(5분)로 줄인다.
D-1일: TTL이 전파될 때까지 대기. (기존 TTL인 24시간 후)
D-Day: IP를 변경한다.
D+1일: TTL을 다시 86400초로 복구한다.

서버 이전 일주일 전부터 TTL을 줄여놔야 한다. 이게 DNS 관리의 핵심이었다.

7. 실제 Lab - `dig`와 `nslookup`으로 DNS 추적하기

이론만으론 부족했다. 직접 DNS 경로를 추적해봤다.

Lab 1: `dig +trace`로 계층 구조 보기

$ dig +trace www.google.com

; <<>> DiG 9.10.6 <<>> +trace www.google.com
;; global options: +cmd
.                       518400  IN  NS  a.root-servers.net.
.                       518400  IN  NS  b.root-servers.net.
.                       518400  IN  NS  c.root-servers.net.
;; Received 239 bytes from 192.168.1.1#53(로컬 DNS) in 12 ms

com.                    172800  IN  NS  a.gtld-servers.net.
com.                    172800  IN  NS  b.gtld-servers.net.
;; Received 1176 bytes from 198.41.0.4#53(a.root-servers.net) in 23 ms

google.com.             172800  IN  NS  ns1.google.com.
google.com.             172800  IN  NS  ns2.google.com.
;; Received 384 bytes from 192.5.6.30#53(a.gtld-servers.net) in 89 ms

www.google.com.         300     IN  A   142.250.76.100
;; Received 59 bytes from 216.239.32.10#53(ns1.google.com) in 21 ms

Root(.) → TLD(.com) → Authoritative(ns1.google.com) 순으로 찾아가는 걸 직접 볼 수 있다.

Lab 2: `nslookup`으로 특정 레코드 조회

# A 레코드 조회
$ nslookup www.github.com
Server:    168.126.63.1
Address:   168.126.63.1#53

Non-authoritative answer:
Name:   www.github.com
Address: 140.82.121.4

# MX 레코드 조회 (메일 서버)
$ nslookup -type=MX google.com
Server:    168.126.63.1
Address:   168.126.63.1#53

google.com  mail exchanger = 10 smtp.google.com.

Lab 3: `dig`로 TTL 확인

$ dig www.naver.com

;; ANSWER SECTION:
www.naver.com.      268   IN  A   223.130.195.200
                    ↑
                  TTL (268초 남음)

같은 명령어를 1분 후에 다시 치면 TTL이 줄어든 걸 볼 수 있다.

$ dig www.naver.com

www.naver.com.      208   IN  A   223.130.195.200
                    ↑
                  60초 감소

Lab 4: 특정 DNS 서버에 직접 질의

# 구글 DNS(8.8.8.8)에 직접 물어보기
$ dig @8.8.8.8 www.github.com

# Cloudflare DNS(1.1.1.1)에 물어보기
$ dig @1.1.1.1 www.github.com

ISP DNS를 거치지 않고 특정 Public DNS에 직접 질의할 수 있다.

8. 보안 - DNS의 취약점과 방어

DNS는 1983년에 설계됐다. 당시엔 보안이 고려되지 않았다.

문제 1 - DNS Cache Poisoning (캐시 오염)

공격자가 가짜 DNS 응답을 ISP DNS 서버에 주입한다.

공격자 -> ISP DNS
"bank.com의 IP는 6.6.6.6이야" (피싱 사이트 IP)

ISP DNS는 이걸 믿고 캐싱
사용자 -> ISP DNS
"bank.com IP 주세요?"

ISP DNS: "6.6.6.6이야" (피싱 사이트로 유도됨)

해결책: DNSSEC (DNS Security Extensions)

DNSSEC는 DNS 응답에 디지털 서명을 추가한다.

Root 서버의 공개키
  ↓ 서명 검증
.com TLD 서버의 공개키
  ↓ 서명 검증
bank.com Authoritative 서버의 응답
  ↓ 서명 검증
최종 IP

Chain of Trust를 통해 각 단계의 응답이 진짜인지 검증한다.

문제 2 - DNS 스파이 (도청)

전통적인 DNS는 UDP/53 포트로 평문 전송된다. ISP는 내가 어떤 사이트를 방문하는지 전부 볼 수 있다.

내 컴퓨터 -> ISP DNS (평문)
"www.wikileaks.org IP 주세요?"

ISP: "아하, 이 사람 wikileaks 보네?" (로그 저장)

해결책 1: DoH (DNS over HTTPS)

DNS 쿼리를 HTTPS(443 포트)로 암호화한다.

내 컴퓨터 -> Cloudflare DoH 서버 (1.1.1.1)
HTTPS로 암호화된 DNS 쿼리

ISP: "뭔가 HTTPS 통신하는데... 내용은 모르겠네"

Chrome, Firefox는 기본적으로 DoH를 사용한다.

해결책 2: DoT (DNS over TLS)

DNS 전용 암호화 채널(853 포트)을 사용한다.

내 컴퓨터 -> DNS 서버 (853 포트, TLS 암호화)

DoH와 차이점:

DoH: 일반 웹 트래픽처럼 보임. ISP가 차단하기 어려움.
DoT: 전용 포트. 네트워크 관리자가 모니터링/차단 가능.

9. Anycast: 8.8.8.8이 빠른 이유

구글 Public DNS(8.8.8.8)를 쓰면 전 세계 어디서든 빠르다. 어떻게 가능할까?

Anycast 라우팅 덕분이다.

Unicast vs Anycast

Unicast (일반적인 방식)

1.2.3.4 IP → 서울에 있는 단 하나의 서버
미국에서 접속 → 서울까지 왕복 (200ms 지연)

Anycast (8.8.8.8 방식)

8.8.8.8 IP → 전 세계 수백 개 서버가 동시에 광고 (BGP)

서울에서 접속 → 가장 가까운 서버(서울 데이터센터)로 자동 라우팅
미국에서 접속 → 가장 가까운 서버(LA 데이터센터)로 자동 라우팅

네트워크 라우팅 프로토콜(BGP)이 자동으로 가장 가까운 서버를 찾아준다.

Anycast의 장점

낮은 지연시간: 물리적으로 가까운 서버로 연결
고가용성: 한 데이터센터가 죽어도 자동으로 다음 서버로 전환
DDoS 방어: 공격 트래픽이 수백 대의 서버로 분산됨

이제 나는 이해했다. 8.8.8.8은 "한 대의 서버"가 아니라 전 세계에 퍼져있는 서버 군단이었다.

10. 실제로 마주친 DNS 문제들

Case 1: "도메인 샀는데 안 돼요"

동료가 도메인을 새로 샀다. DNS 설정도 다 했다. 근데 접속이 안 됐다.

이유: DNS 전파 시간 (Propagation Delay)

전 세계 ISP DNS들이 캐시를 갱신하는 데 시간이 걸린다. 예전엔 24~48시간이 걸렸는데, 요즘은 보통 1시간 내로 끝난다.

# 전파 상태 확인
$ dig @8.8.8.8 new-domain.com  # 구글 DNS에선 보임
$ dig @168.126.63.1 new-domain.com  # KT DNS에선 안 보임 (아직 전파 안 됨)

해결책: 기다리거나, /etc/hosts로 로컬 테스트

$ sudo vi /etc/hosts

93.184.216.34  new-domain.com

Case 2: 로컬 개발 서버에 도메인 붙이기

개발 중인 서버(localhost:3000)에 dev.myapp.com이라는 도메인을 붙이고 싶었다.

방법 1: /etc/hosts 수정

$ sudo vi /etc/hosts

127.0.0.1  dev.myapp.com

이제 브라우저에서 http://dev.myapp.com:3000 접속 가능.

방법 2: dnsmasq (팀 전체 공유)

팀원들도 같은 도메인을 써야 한다면, 내부 DNS 서버를 띄운다.

# dnsmasq 설정
$ echo "address=/dev.myapp.com/192.168.1.100" >> /etc/dnsmasq.conf
$ sudo systemctl restart dnsmasq

Case 3: 구글 DNS vs 통신사 DNS

친구가 물었다. "8.8.8.8이 더 빨라?"

일반적으론 맞다. 구글 DNS는:

빠르고 안정적
검열이 적음 (특정 사이트 차단 안 함)
DoH/DoT 지원

하지만 예외가 있다.

한국 사이트(네이버, 카카오)는 통신사 DNS가 더 빠를 수 있다. 이유는 CDN 최적화 때문이다.

KT DNS 사용:
naver.com → 223.130.195.200 (KT 네트워크 내 CDN)

8.8.8.8 사용:
naver.com → 223.130.195.95 (일반 서버)

통신사 DNS는 CDN 서버 위치를 고려해서 가장 가까운 IP를 준다.

결론: 국내 사이트 위주면 통신사 DNS, 해외 사이트/프라이버시 중요하면 8.8.8.8 또는 1.1.1.1

11. 용어 사전 (Glossary)

DNS (Domain Name System): 도메인 이름을 IP 주소로 변환하는 계층적 분산 데이터베이스 시스템.
Recursive Query: 클라이언트를 대신해 최종 정답을 찾을 때까지 계속 질문을 던지는 방식. ISP DNS가 담당.
Iterative Query: "난 모르니까 쟤한테 물어봐"라고 다음 서버 주소만 알려주는 방식. Root/TLD 서버가 사용.
Root Name Server: DNS 계층의 최상위(.) 서버. 전 세계 13개 (a~m.root-servers.net). TLD 서버 정보를 제공.
TLD (Top Level Domain): .com, .net, .kr 같은 최상위 도메인. ICANN이 관리.
Authoritative Name Server: 특정 도메인의 실제 IP 정보를 가지고 있는 최종 권한 서버.
Resolver: 사용자의 요청을 받아 DNS 조회를 대행해주는 서버. 주로 ISP DNS나 Public DNS(8.8.8.8).
TTL (Time To Live): DNS 레코드가 캐시에 저장되어 유효한 시간 (초 단위).
A Record: 도메인을 IPv4 주소로 매핑하는 레코드.
AAAA Record: 도메인을 IPv6 주소로 매핑하는 레코드.
CNAME Record: 도메인 별칭(Alias) 레코드. 다른 도메인을 가리킴.
MX Record: 메일 수신 서버를 지정하는 레코드. 우선순위 포함.
NS Record: 특정 도메인을 관리하는 네임서버를 지정하는 레코드.
TXT Record: 텍스트 정보를 저장. SPF, DKIM, 도메인 인증 등에 사용.
SOA Record: Start of Authority. 도메인 관리 정보(관리자 이메일, 시리얼 번호, 갱신 주기).
PTR Record: IP 주소를 도메인으로 역변환. 스팸 필터링에 사용.
Anycast: 하나의 IP 주소를 여러 물리적 위치의 서버가 공유. 가장 가까운 서버로 자동 라우팅.
Hosts File: DNS 이전 시대의 로컬 주소 매핑 파일. /etc/hosts (Linux/Mac), C:\Windows\System32\drivers\etc\hosts (Windows). DNS보다 우선순위 높음.
DNS Cache Poisoning: 해커가 DNS 캐시에 가짜 IP를 주입해 피싱 사이트로 유도하는 공격.
DNSSEC (DNS Security Extensions): DNS 응답에 디지털 서명을 추가해 위변조를 방지하는 보안 확장.
DoH (DNS over HTTPS): DNS 쿼리를 HTTPS(443 포트)로 암호화. 평문 도청 방지.
DoT (DNS over TLS): DNS 쿼리를 TLS(853 포트)로 암호화. DoH와 비슷하지만 전용 포트 사용.
Zone File: 도메인의 DNS 레코드들을 모아놓은 텍스트 파일. Authoritative 서버가 관리.
DNS Propagation: 전 세계 DNS 서버들이 변경된 레코드를 캐시에 반영하는 데 걸리는 시간.
Split-Horizon DNS: 질의자의 위치나 네트워크에 따라 다른 IP를 응답. 내부 직원엔 사설 IP, 외부 사용자엔 공인 IP.

12. FAQ

Q1: 도메인을 샀는데 접속이 안 돼요.

A: DNS 전파 시간(Propagation Delay) 때문일 수 있습니다.

레지스트라(GoDaddy, Cloudflare 등)에서 DNS 설정을 바꾸면, 전 세계 ISP DNS들이 이 정보를 받아서 캐시를 갱신해야 합니다. 예전엔 24~48시간 걸렸지만, 요즘은 보통 1시간 이내에 완료됩니다.

확인 방법:

# 구글 DNS에선 보이는지 확인
$ dig @8.8.8.8 yourdomain.com

# 통신사 DNS에선 보이는지 확인
$ dig @168.126.63.1 yourdomain.com  # KT
$ dig @210.220.163.82 yourdomain.com  # SK

둘 다 응답이 오면 전파 완료입니다.

Q2: /etc/hosts 파일은 언제 쓰나요?

A: 두 가지 경우에 씁니다.

1. 로컬 개발 테스트

$ sudo vi /etc/hosts

127.0.0.1  dev.myapp.com
192.168.1.50  staging.company.com

브라우저에서 dev.myapp.com을 입력하면 DNS 조회 없이 바로 127.0.0.1로 연결됩니다.

2. 특정 사이트 차단

127.0.0.1  facebook.com
127.0.0.1  twitter.com

이러면 해당 사이트가 localhost로 연결돼서 접속이 안 됩니다. (생산성 도구로 쓰는 사람도 있습니다)

주의: hosts 파일은 DNS보다 우선순위가 높습니다. 실수로 잘못 설정하면 정상 사이트도 안 열릴 수 있습니다.

Q3: 구글 DNS(8.8.8.8)가 통신사 DNS보다 좋은가요?

A: 상황에 따라 다릅니다. 구글 DNS(8.8.8.8) 또는 Cloudflare(1.1.1.1)의 장점:

빠르고 안정적
검열이 적음 (특정 사이트 차단 안 함)
DoH/DoT 지원 (프라이버시 보호)
전 세계 Anycast 네트워크

통신사 DNS(KT, SK, LG)의 장점:

국내 사이트 CDN 최적화: 네이버, 카카오 같은 한국 서비스는 통신사 DNS가 가장 가까운 CDN IP를 줌
망내 트래픽으로 처리되어 약간 더 빠를 수 있음

실측 비교 (서울 기준):

# KT DNS
$ dig @168.126.63.1 www.naver.com | grep "Query time"
Query time: 12 msec

# 구글 DNS
$ dig @8.8.8.8 www.naver.com | grep "Query time"
Query time: 18 msec

결론: 국내 사이트 위주로 쓰면 통신사 DNS, 해외 사이트 많이 쓰거나 프라이버시 중요하면 8.8.8.8 또는 1.1.1.1 추천.

Q4: CNAME과 A 레코드의 차이는?

A: 둘 다 도메인을 연결하지만, 가리키는 대상이 다릅니다.

A 레코드: 도메인 → IP 주소

example.com  A  93.184.216.34

CNAME 레코드: 도메인 → 다른 도메인

www.example.com  CNAME  example.com

언제 CNAME을 쓰나?

서버 IP가 자주 바뀌는 경우. 예를 들어 Vercel, Netlify 같은 호스팅 서비스는 IP를 예고 없이 바꿉니다.

# A 레코드 사용 시 (나쁨)
blog.mysite.com  A  76.223.47.193  # Vercel IP

# Vercel이 IP 바꾸면 → 수동으로 A 레코드 수정 필요

# CNAME 사용 시 (좋음)
blog.mysite.com  CNAME  mysite.vercel.app

# Vercel이 IP 바꿔도 → 내 CNAME은 그대로 유지

주의: 루트 도메인(example.com)에는 CNAME을 쓸 수 없습니다. (DNS 표준 제약) 대신 ALIAS 레코드를 지원하는 DNS 제공자(Cloudflare, Route53)를 쓰면 가능합니다.

Q5: DNS는 UDP인가요, TCP인가요?

A: 기본은 UDP, 조건부로 TCP입니다.

UDP/53 (일반적인 경우)

DNS 쿼리는 보통 작아서(512 bytes 이하) UDP로 충분
빠르고 오버헤드가 적음
응답이 안 오면 재전송

TCP/53 (특수한 경우)

응답이 512 bytes를 초과할 때 (많은 레코드를 반환하는 경우)
Zone Transfer (마스터 DNS → 슬레이브 DNS 동기화)
DoT (DNS over TLS)

테스트:

# UDP로 질의 (기본)
$ dig @8.8.8.8 google.com

# TCP로 강제 질의
$ dig @8.8.8.8 +tcp google.com

Q6: 서브도메인마다 다른 서버로 연결할 수 있나요?

A: 가능합니다. 각 서브도메인에 별도의 레코드를 설정하면 됩니다.

# Zone File 예시
example.com           A      93.184.216.34   # 메인 사이트
www.example.com       A      93.184.216.34   # 메인 사이트
blog.example.com      A      52.123.45.67    # 블로그 서버 (다른 IP)
api.example.com       A      13.209.84.123   # API 서버 (AWS)
cdn.example.com       CNAME  d111111abcdef8.cloudfront.net  # CDN

실제로 많은 회사가 이렇게 운영합니다.

www.company.com: 메인 웹사이트
blog.company.com: 블로그 (Notion, WordPress)
api.company.com: API 서버
admin.company.com: 관리자 대시보드

13. 정리 - 내가 받아들인 것들

DNS를 공부하면서 이해했던 것들을 정리해본다.

1. DNS는 단순한 전화번호부가 아니다

처음엔 "이름 → 숫자 변환"으로만 생각했다. 하지만 파고들수록 계층적 분산 시스템, 캐싱 전략, 보안, Anycast 라우팅까지 엮여있는 복잡한 인프라였다.

결국 이거였다: DNS는 인터넷의 신경계다. 이게 멈추면 전 세계 웹사이트가 전부 IP 주소로만 접속 가능한 세상이 된다.

2. TTL은 "캐시의 신뢰 기간"이다

TTL을 처음 봤을 때 "이게 왜 필요하지?"라고 생각했다. 하지만 서버 이전을 겪으면서 와닿았다.

TTL이 길면: 안정적이고 빠르지만, IP 변경이 느리다. TTL이 짧으면: IP 변경이 빠르지만, DNS 조회가 잦아진다.

팁: 평소엔 TTL 86400초(24시간). 서버 이전 일주일 전부터 300초(5분)로 줄인다. 이전 완료 후 다시 복구.

3. Anycast가 8.8.8.8을 빠르게 만든다

8.8.8.8은 하나의 서버가 아니라 전 세계 수백 대의 서버 군단이다. 네트워크 라우팅(BGP)이 자동으로 가장 가까운 서버로 연결해준다.

이게 바로 확장성의 핵심이다. 사용자가 늘어나도 서버를 추가하면 되고, DDoS 공격도 분산시킬 수 있다.

4. 보안은 나중에 추가됐다

DNS는 1983년에 만들어졌다. 당시엔 인터넷이 학술용이었기 때문에 보안이 고려되지 않았다.

평문 전송 → DoH/DoT로 해결
위변조 가능 → DNSSEC로 해결

이걸 통해 배운 교훈: 초기 설계에서 보안을 고려하지 않으면, 나중에 패치하기가 훨씬 어렵다.

5. 실제 디버깅 도구

DNS 문제를 만났을 때:

# 1. 기본 조회
dig example.com

# 2. 계층 구조 추적
dig +trace example.com

# 3. 특정 DNS 서버 질의
dig @8.8.8.8 example.com

# 4. 특정 레코드 타입 조회
dig -t MX example.com

# 5. TTL 확인 (캐시 만료 시간)
dig example.com | grep -A1 "ANSWER SECTION"

이 명령어들을 익히고 나니, DNS 문제를 10분 안에 해결할 수 있게 됐다.

마지막으로

DNS는 "보이지 않지만 항상 작동하는 시스템"이다. 우리가 주소창에 도메인을 입력할 때마다, 0.1초 만에 전 세계 계층 구조를 순회하고, 캐싱 전략을 적용하고, 가장 가까운 서버로 라우팅한다.

나는 이제 알았다. 인터넷의 편리함 뒤에는 40년 된 분산 시스템이 숨어있다는 걸.

DNS: When I Realized the Internet Runs on a 40-Year-Old Phonebook

1. Prologue: "Just Type 223.130.195.200 to Connect"

My first day at work. A senior engineer said:

"Connect to the test server. The IP is 192.168.45.237."

I stared blankly. Opened a notepad. Wrote down the numbers. The next day, I asked again. Wrote it down again. After a week, I had an epiphany.

Humans aren't designed to memorize numbers.

Yet every day, we visit dozens of websites. www.google.com, www.youtube.com, www.github.com. We remember these names, but nobody memorizes the IPs behind them: 142.250.207.174, 172.217.174.206.

Computers only understand numbers (IPs). Humans only remember names (domains). The system bridging this gap is DNS (Domain Name System).

At first, I thought, "Isn't this just an address book?" But the deeper I dug, the more I realized: this isn't a simple translator. It's a distributed database that traverses a global hierarchy in 0.1 seconds. Root servers, TLD servers, Authoritative servers. Caching, TTL, Anycast.

When I type a domain into my browser and hit Enter, here's what happens behind the scenes.

2. The Struggle: The Era of HOSTS.TXT

To understand DNS, I had to learn why it was invented.

1970s: Managing the Internet with a Single File

In the 1970s ARPANET era, the internet had only a few hundred connected computers. Back then, a single text file called HOSTS.TXT stored every computer's name and address.

# HOSTS.TXT (circa 1975)
10.0.0.51  SRI-ARC
10.0.0.52  MIT-AI
10.0.0.73  BBN-TENEX
...

Stanford Research Institute (SRI) managed this file centrally. People periodically downloaded it via FTP.

The problem started as the network grew.

New computers were added daily.
File size exploded.
Synchronization delays occurred. (My file is 3 days old, but you were added today?)
Single point of failure: If SRI's server went down, the entire internet froze.

1983: Paul Mockapetris's Invention

Paul Mockapetris proposed a hierarchical distributed database system to solve this. That was DNS.

The core idea was simple.

"Don't manage all information in one place. Distribute responsibility."

.com domains are managed by .com TLD servers.
google.com is managed directly by Google.
Root servers only provide TLD server addresses.

This architecture has been the backbone of the internet for over 40 years.

3. Aha Moment: "DNS Isn't a Phonebook, It's a Postal System"

Initially, I understood DNS through the "phonebook" metaphor. You look up a name, you get a number. Simple.

But when I actually traced a DNS query, I realized: this isn't a phonebook.

DNS is more like a postal system.

When you mail a letter, you write "123 Teheran-ro, Gangnam-gu, Seoul." The post office doesn't find it in one step.

First, it goes to the Seoul City post office.
The Seoul office forwards it to the Gangnam-gu branch.
The Gangnam branch hands it to the Teheran-ro carrier.
Finally, it arrives at mailbox 123.

DNS works the same way. When you look up www.google.com:

Root server (.) says ".com is managed by that guy".
.com TLD server says "google.com is managed by that guy".
Google Authoritative server says "www is 142.250.76.100".

This was it. DNS is a hierarchical delegation system.

4. Deep Dive: The 6 Steps of a DNS Recursive Query

When you type www.naver.com into your browser, here's exactly what happens.

Step 1: Browser Cache

Your browser stores recent visit records in memory.

# Chrome's internal DNS cache (chrome://net-internals/#dns)
www.naver.com -> 223.130.195.200 (TTL: 300 seconds remaining)

Cache hit → Skip DNS lookup. This is the fastest path.

Step 2: OS Cache

If the browser cache misses, it asks the operating system.

# macOS/Linux
$ dscacheutil -cachedump -entries Host

# Windows
$ ipconfig /displaydns

If it's not there either, we need to query a real DNS server.

Step 3: Recursive Resolver (ISP DNS)

Now we ask the ISP (Internet Service Provider) DNS server. This server is called a Recursive Resolver.

My computer -> KT DNS (168.126.63.1)
"Give me the IP for www.naver.com!"

Here's the key: The Recursive Resolver travels the world on your behalf to find the answer. You only need to ask once.

Step 4: Root DNS Server (.)

The ISP DNS first asks the Root server.

KT DNS -> Root server (198.41.0.4)
"Where's www.naver.com?"

Root: "I don't know. But I know the TLD server that manages .com:
       a.gtld-servers.net (192.5.6.30). Try them."

There are 13 original Root servers worldwide (a.root-servers.net ~ m.root-servers.net). But in reality, they're replicated to hundreds of locations via Anycast technology.

Step 5: TLD Server (.com)

The ISP DNS now goes to the .com TLD server.

KT DNS -> .com TLD server (192.5.6.30)
"Where's naver.com?"

TLD: "I don't know. But I know the nameserver managing naver.com:
      ns1.naver.com (125.209.248.6). Try them."

TLD stands for Top-Level Domain. It manages domains like .com, .org, .kr, .io.

Step 6: Authoritative Name Server (Naver)

Finally, we ask Naver's Authoritative server.

KT DNS -> ns1.naver.com (125.209.248.6)
"Give me the IP for www.naver.com!"

Naver DNS: "223.130.195.200. That's the final answer."

Authoritative means "having authority". This server holds the final truth.

Step 7: Response and Caching

The ISP DNS receives this IP and:

Sends it to me.
Caches it for itself. (So it can answer instantly next time someone asks)

KT DNS cache:
www.naver.com -> 223.130.195.200 (TTL: 300 seconds)

All of this happens in 0.1 seconds.

5. DNS Record Types: The Domain's Identity Card

DNS doesn't just store IPs. There are various record types, each serving a different purpose.

Record Type	Purpose	Example	Real-World Use
A	Domain → IPv4 address	`example.com` → `93.184.216.34`	The most basic record. Core of web hosting
AAAA	Domain → IPv6 address	`example.com` → `2606:2800:220:1::`	IPv6 support. Next-generation addressing
CNAME	Domain alias	`www.example.com` → `example.com`	Change IP in one place, update everywhere
MX	Mail server designation	`example.com` → `mail.google.com` (priority: 10)	Email receiving. Lower priority = tried first
NS	Nameserver designation	`example.com` → `ns1.aws.com`	"AWS Route53 manages this domain"
TXT	Text information	`example.com` → `"v=spf1 include:_spf.google.com ~all"`	SPF auth, Google Search Console verification
SOA	Start of Authority	-	Domain management info (admin email, refresh rate, serial number)
PTR	IP → Domain (reverse)	`34.216.184.93.in-addr.arpa` → `example.com`	Spam filtering. Verify mail server authenticity
SRV	Service location	`_minecraft._tcp.example.com` → `server.example.com:25565`	Game servers, VoIP with port info
CAA	Certificate authority restriction	`example.com` → `letsencrypt.org`	Only Let's Encrypt can issue SSL certificates

Real Example: The Power of CNAME

Say you run a blog at blog.company.com. Initially, you set up an A record.

# Initial setup
blog.company.com  A  52.123.45.67

Later, you move servers from AWS to Vercel. The IP changes. The A record needs updating.

# After server migration
blog.company.com  A  76.223.47.193  # Changed!

With CNAME, this problem disappears.

# CNAME setup
blog.company.com  CNAME  company.vercel.app

# Even if Vercel changes IPs, CNAME stays the same
company.vercel.app  A  76.223.47.193  # Vercel manages this

Even when the IP changes, the CNAME record needs no touching. That's the power of aliasing.

6. TTL: The Number That Determines Cache Lifespan

The most confusing part of DNS configuration was TTL (Time To Live).

What is TTL?

TTL indicates "how many seconds can you trust this information?"

www.example.com  300  A  93.184.216.34
                 ↑
              TTL (in seconds)

This record means "trust my cache for 300 seconds (5 minutes), then ask again afterward."

Long TTL vs Short TTL

TTL	Pros	Cons	When to Use
Long TTL (86400s = 24h)	Reduced DNS server load, fast responses	IP changes take up to 24h to propagate	Stable production servers
Short TTL (60s = 1m)	IP changes reflected immediately	Increased DNS query traffic, slight speed penalty	Server migrations, A/B testing, emergency maintenance

Practical Tip: Lower TTL Before Server Migration

When migrating between cloud providers, TTL management is critical. Take an AWS to GCP migration as an example.

If the IP is changed on D-Day while TTL is 86400 seconds (24 hours), some users will experience connection errors for up to 24 hours. ISP DNS servers keep caching the old IP for the full TTL duration.

The correct procedure:

D-7 days: Lower TTL to 300 seconds (5 minutes).
D-1 day: Wait for propagation. (After the old TTL of 24 hours expires)
D-Day: Change the IP.
D+1 day: Restore TTL to 86400 seconds.

You must lower TTL a week before server migration. This was the core of DNS management.

7. Hands-On Lab: Tracing DNS with `dig` and `nslookup`

Theory wasn't enough. I traced DNS paths myself.

Lab 1: Seeing the Hierarchy with `dig +trace`

$ dig +trace www.google.com

; <<>> DiG 9.10.6 <<>> +trace www.google.com
;; global options: +cmd
.                       518400  IN  NS  a.root-servers.net.
.                       518400  IN  NS  b.root-servers.net.
.                       518400  IN  NS  c.root-servers.net.
;; Received 239 bytes from 192.168.1.1#53(Local DNS) in 12 ms

com.                    172800  IN  NS  a.gtld-servers.net.
com.                    172800  IN  NS  b.gtld-servers.net.
;; Received 1176 bytes from 198.41.0.4#53(a.root-servers.net) in 23 ms

google.com.             172800  IN  NS  ns1.google.com.
google.com.             172800  IN  NS  ns2.google.com.
;; Received 384 bytes from 192.5.6.30#53(a.gtld-servers.net) in 89 ms

www.google.com.         300     IN  A   142.250.76.100
;; Received 59 bytes from 216.239.32.10#53(ns1.google.com) in 21 ms

You can directly see the journey: Root(.) → TLD(.com) → Authoritative(ns1.google.com).

Lab 2: Querying Specific Records with `nslookup`

# A record lookup
$ nslookup www.github.com
Server:    168.126.63.1
Address:   168.126.63.1#53

Non-authoritative answer:
Name:   www.github.com
Address: 140.82.121.4

# MX record lookup (mail server)
$ nslookup -type=MX google.com
Server:    168.126.63.1
Address:   168.126.63.1#53

google.com  mail exchanger = 10 smtp.google.com.

Lab 3: Checking TTL with `dig`

$ dig www.naver.com

;; ANSWER SECTION:
www.naver.com.      268   IN  A   223.130.195.200
                    ↑
                  TTL (268 seconds remaining)

Run the same command 1 minute later, and you'll see the TTL decrease.

$ dig www.naver.com

www.naver.com.      208   IN  A   223.130.195.200
                    ↑
                  60 seconds decreased

Lab 4: Querying Specific DNS Servers Directly

# Query Google DNS (8.8.8.8) directly
$ dig @8.8.8.8 www.github.com

# Query Cloudflare DNS (1.1.1.1)
$ dig @1.1.1.1 www.github.com

You can query specific Public DNS servers directly without going through your ISP DNS.

8. Security: DNS Vulnerabilities and Defenses

DNS was designed in 1983. Back then, security wasn't considered.

Problem 1: DNS Cache Poisoning

An attacker injects fake DNS responses into ISP DNS servers.

Attacker -> ISP DNS
"bank.com's IP is 6.6.6.6" (phishing site IP)

ISP DNS believes it and caches
User -> ISP DNS
"Give me bank.com's IP?"

ISP DNS: "6.6.6.6" (user redirected to phishing site)

Solution: DNSSEC (DNS Security Extensions)

DNSSEC adds digital signatures to DNS responses.

Root server's public key
  ↓ verify signature
.com TLD server's public key
  ↓ verify signature
bank.com Authoritative server's response
  ↓ verify signature
Final IP

Through a Chain of Trust, each step's response is verified as genuine.

Problem 2: DNS Spying (Eavesdropping)

Traditional DNS uses UDP port 53 in plaintext. ISPs can see every site you visit.

My computer -> ISP DNS (plaintext)
"Give me the IP for www.wikileaks.org?"

ISP: "Aha, this person is viewing wikileaks" (logs saved)

Solution 1: DoH (DNS over HTTPS)

Encrypt DNS queries via HTTPS (port 443).

My computer -> Cloudflare DoH server (1.1.1.1)
DNS query encrypted via HTTPS

ISP: "Some HTTPS traffic... but I can't read the content"

Chrome and Firefox use DoH by default.

Solution 2: DoT (DNS over TLS)

Use a dedicated encrypted channel for DNS (port 853).

My computer -> DNS server (port 853, TLS encrypted)

DoH vs DoT:

DoH: Looks like normal web traffic. Hard for ISPs to block.
DoT: Dedicated port. Network admins can monitor/block it.

9. Anycast: Why 8.8.8.8 is Fast

Google Public DNS (8.8.8.8) is fast anywhere in the world. How is this possible?

Anycast routing makes it happen.

Unicast vs Anycast

Unicast (normal approach)

IP 1.2.3.4 → one single server in Seoul
Access from USA → round trip to Seoul (200ms latency)

Anycast (8.8.8.8 approach)

IP 8.8.8.8 → hundreds of servers worldwide advertising simultaneously (BGP)

Access from Seoul → auto-routed to closest server (Seoul datacenter)
Access from USA → auto-routed to closest server (LA datacenter)

Network routing protocol (BGP) automatically finds the nearest server.

Benefits of Anycast

Low latency: Connect to physically nearest server
High availability: If one datacenter dies, automatically switch to next
DDoS defense: Attack traffic distributed across hundreds of servers

I finally understood. 8.8.8.8 isn't "one server"—it's a legion of servers spread across the globe.

10. Real-World DNS Issues I Faced

Case 1: "I Bought a Domain But It Doesn't Work"

A colleague bought a new domain. Set up DNS. But it wouldn't connect.

Reason: DNS Propagation Delay

ISP DNS servers worldwide need time to refresh their caches. It used to take 24-48 hours, but nowadays it usually finishes within 1 hour.

# Check propagation status
$ dig @8.8.8.8 new-domain.com  # Shows up on Google DNS
$ dig @168.126.63.1 new-domain.com  # Doesn't show on KT DNS (not propagated yet)

Solution: Wait, or test locally via /etc/hosts

$ sudo vi /etc/hosts

93.184.216.34  new-domain.com

Case 2: Attaching a Domain to Local Dev Server

I wanted to attach dev.myapp.com to my development server (localhost:3000).

Method 1: Edit /etc/hosts

$ sudo vi /etc/hosts

127.0.0.1  dev.myapp.com

Now I can access http://dev.myapp.com:3000 in the browser.

Method 2: dnsmasq (team-wide sharing)

If team members need the same domain, spin up an internal DNS server.

# dnsmasq configuration
$ echo "address=/dev.myapp.com/192.168.1.100" >> /etc/dnsmasq.conf
$ sudo systemctl restart dnsmasq

Case 3: Google DNS vs ISP DNS

A friend asked: "Is 8.8.8.8 faster?"

Generally, yes. Google DNS is:

Fast and stable
Less censorship (doesn't block specific sites)
Supports DoH/DoT

But there are exceptions.

For Korean sites (Naver, Kakao), ISP DNS might be faster. The reason: CDN optimization.

Using KT DNS:
naver.com → 223.130.195.200 (CDN within KT network)

Using 8.8.8.8:
naver.com → 223.130.195.95 (general server)

ISP DNS considers CDN server locations and gives you the closest IP.

Conclusion: For mostly Korean sites, use ISP DNS. For international sites or privacy concerns, use 8.8.8.8 or 1.1.1.1.

11. Glossary

DNS (Domain Name System): A hierarchical distributed database system that translates domain names into IP addresses.
Recursive Query: A query method where the server finds the final answer on behalf of the client. Handled by ISP DNS.
Iterative Query: A query method where the server says "I don't know, ask that guy" and only provides the next server's address. Used by Root/TLD servers.
Root Name Server: The top-level (.) servers in the DNS hierarchy. 13 worldwide (a~m.root-servers.net). Provides TLD server information.
TLD (Top Level Domain): Top-level domains like .com, .net, .kr. Managed by ICANN.
Authoritative Name Server: The final authority server that holds the actual IP information for a specific domain.
Resolver: A server that performs DNS lookups on behalf of users. Usually ISP DNS or Public DNS (8.8.8.8).
TTL (Time To Live): The duration (in seconds) a DNS record remains valid in cache.
A Record: A record mapping a domain to an IPv4 address.
AAAA Record: A record mapping a domain to an IPv6 address.
CNAME Record: A domain alias record pointing to another domain.
MX Record: A record designating mail servers with priority.
NS Record: A record specifying nameservers managing a domain.
TXT Record: A record storing text information. Used for SPF, DKIM, domain verification.
SOA Record: Start of Authority. Domain management info (admin email, serial number, refresh rate).
PTR Record: Reverse mapping from IP address to domain. Used in spam filtering.
Anycast: One IP address shared by multiple servers in different physical locations. Auto-routes to nearest server.
Hosts File: Pre-DNS era local address mapping file. /etc/hosts (Linux/Mac), C:\Windows\System32\drivers\etc\hosts (Windows). Higher priority than DNS.
DNS Cache Poisoning: An attack where hackers inject fake IPs into DNS cache to redirect users to phishing sites.
DNSSEC (DNS Security Extensions): A security extension adding digital signatures to DNS responses to prevent tampering.
DoH (DNS over HTTPS): Encrypting DNS queries via HTTPS (port 443). Prevents plaintext eavesdropping.
DoT (DNS over TLS): Encrypting DNS queries via TLS (port 853). Similar to DoH but uses dedicated port.
Zone File: A text file collecting DNS records for a domain. Managed by Authoritative servers.

12. FAQ

Q1: I bought a domain but can't connect to it.

A: It's likely due to DNS Propagation Delay.

When you change DNS settings at a registrar (GoDaddy, Cloudflare, etc.), ISP DNS servers worldwide need to receive this information and refresh their caches. It used to take 24-48 hours, but nowadays it usually completes within 1 hour.

How to check:

# Check if Google DNS sees it
$ dig @8.8.8.8 yourdomain.com

# Check if ISP DNS sees it
$ dig @168.126.63.1 yourdomain.com  # KT
$ dig @210.220.163.82 yourdomain.com  # SK

If both respond, propagation is complete.

Q2: When do I use the /etc/hosts file?

A: Two main cases.

1. Local development testing

$ sudo vi /etc/hosts

127.0.0.1  dev.myapp.com
192.168.1.50  staging.company.com

When you type dev.myapp.com in your browser, it connects to 127.0.0.1 without DNS lookup.

2. Blocking specific sites

127.0.0.1  facebook.com
127.0.0.1  twitter.com

This redirects those sites to localhost, making them inaccessible. (Some people use this as a productivity tool)

Warning: The hosts file has higher priority than DNS. If you misconfigure it, even normal sites won't open.

Q3: Is Google DNS (8.8.8.8) better than ISP DNS?

A: It depends on your situation. Google DNS (8.8.8.8) or Cloudflare (1.1.1.1) advantages:

Fast and stable
Less censorship (doesn't block specific sites)
DoH/DoT support (privacy protection)
Worldwide Anycast network

ISP DNS (KT, SK, LG) advantages:

Korean site CDN optimization: Korean services like Naver and Kakao give the closest CDN IP via ISP DNS
Processed as intra-network traffic, potentially slightly faster

Measured comparison (Seoul basis):

# KT DNS
$ dig @168.126.63.1 www.naver.com | grep "Query time"
Query time: 12 msec

# Google DNS
$ dig @8.8.8.8 www.naver.com | grep "Query time"
Query time: 18 msec

Conclusion: If you mostly use Korean sites, use ISP DNS. If you use many international sites or privacy is important, use 8.8.8.8 or 1.1.1.1.

Q4: What's the difference between CNAME and A records?

A: Both connect domains, but what they point to differs.

A record: Domain → IP address

example.com  A  93.184.216.34

CNAME record: Domain → Another domain

www.example.com  CNAME  example.com

When to use CNAME?

When server IPs change frequently. For example, hosting services like Vercel and Netlify change IPs without notice.

# Using A record (bad)
blog.mysite.com  A  76.223.47.193  # Vercel IP

# If Vercel changes IP → must manually update A record

# Using CNAME (good)
blog.mysite.com  CNAME  mysite.vercel.app

# If Vercel changes IP → your CNAME stays unchanged

Warning: You cannot use CNAME on the root domain (example.com). (DNS standard constraint) Instead, use ALIAS records if your DNS provider supports it (Cloudflare, Route53).

Q5: Does DNS use UDP or TCP?

A: Default is UDP, conditionally TCP. UDP/53 (typical case)

DNS queries are usually small (under 512 bytes), so UDP suffices
Fast and low overhead
Retransmits if no response

TCP/53 (special cases)

When responses exceed 512 bytes (returning many records)
Zone Transfer (master DNS → slave DNS synchronization)
DoT (DNS over TLS)

Test:

# Query via UDP (default)
$ dig @8.8.8.8 google.com

# Force query via TCP
$ dig @8.8.8.8 +tcp google.com

Q6: Can I connect each subdomain to a different server?

A: Yes. Set separate records for each subdomain.

# Zone File example
example.com           A      93.184.216.34   # Main site
www.example.com       A      93.184.216.34   # Main site
blog.example.com      A      52.123.45.67    # Blog server (different IP)
api.example.com       A      13.209.84.123   # API server (AWS)
cdn.example.com       CNAME  d111111abcdef8.cloudfront.net  # CDN

Many companies actually operate this way.

www.company.com: Main website
blog.company.com: Blog (Notion, WordPress)
api.company.com: API server
admin.company.com: Admin dashboard

DNS: 인터넷 전화번호부와 0.1초의 여정 (완전정복)

관련 포스트

메모리 관리: 연속 할당과 분산 할당

BFS와 DFS: 그래프 탐색의 두 축

브라우저 저장소 완벽 가이드: Cookie, LocalStorage, IndexedDB

퀵 정렬(Quick Sort): 분할 정복의 대표

1. 프롤로그 - "223.130.195.200 치고 접속하세요"

2. 과거의 투쟁 - HOSTS.TXT의 시대

1970년대 - 하나의 파일로 관리하던 인터넷

1983: 폴 모카페트리스의 발명

3. 아하 모먼트 - "DNS는 전화 교환원이 아니라 우편 체계다"

4. 심층 분석 - DNS Recursive Query의 6단계

Step 1: 브라우저 캐시

Step 2: OS 캐시

Step 3: Recursive Resolver (ISP DNS)

Step 4: Root DNS 서버 (.)

Step 5: TLD 서버 (.com)

Step 6: Authoritative Name Server (네이버)

Step 7: 응답 및 캐싱

5. DNS 레코드 타입 - 도메인의 신분증

실제 예시 - CNAME의 힘

6. TTL: 캐시의 수명을 결정하는 숫자

TTL이란?

TTL 길면 vs 짧으면

팁 - 서버 이전 전에 TTL 줄이기

7. 실제 Lab - dig와 nslookup으로 DNS 추적하기

Lab 1: dig +trace로 계층 구조 보기

Lab 2: nslookup으로 특정 레코드 조회

Lab 3: dig로 TTL 확인

Lab 4: 특정 DNS 서버에 직접 질의

8. 보안 - DNS의 취약점과 방어

문제 1 - DNS Cache Poisoning (캐시 오염)

문제 2 - DNS 스파이 (도청)

9. Anycast: 8.8.8.8이 빠른 이유

Unicast vs Anycast

Anycast의 장점

10. 실제로 마주친 DNS 문제들

Case 1: "도메인 샀는데 안 돼요"

Case 2: 로컬 개발 서버에 도메인 붙이기

Case 3: 구글 DNS vs 통신사 DNS

11. 용어 사전 (Glossary)

12. FAQ

Q1: 도메인을 샀는데 접속이 안 돼요.

Q2: /etc/hosts 파일은 언제 쓰나요?

Q3: 구글 DNS(8.8.8.8)가 통신사 DNS보다 좋은가요?

Q4: CNAME과 A 레코드의 차이는?

Q5: DNS는 UDP인가요, TCP인가요?

Q6: 서브도메인마다 다른 서버로 연결할 수 있나요?

13. 정리 - 내가 받아들인 것들

1. DNS는 단순한 전화번호부가 아니다

2. TTL은 "캐시의 신뢰 기간"이다

3. Anycast가 8.8.8.8을 빠르게 만든다

4. 보안은 나중에 추가됐다

5. 실제 디버깅 도구

마지막으로

DNS: When I Realized the Internet Runs on a 40-Year-Old Phonebook

1. Prologue: "Just Type 223.130.195.200 to Connect"

2. The Struggle: The Era of HOSTS.TXT

1970s: Managing the Internet with a Single File

1983: Paul Mockapetris's Invention

3. Aha Moment: "DNS Isn't a Phonebook, It's a Postal System"

4. Deep Dive: The 6 Steps of a DNS Recursive Query

Step 1: Browser Cache

Step 2: OS Cache

Step 3: Recursive Resolver (ISP DNS)

Step 4: Root DNS Server (.)

Step 5: TLD Server (.com)

Step 6: Authoritative Name Server (Naver)

Step 7: Response and Caching

5. DNS Record Types: The Domain's Identity Card

Real Example: The Power of CNAME

6. TTL: The Number That Determines Cache Lifespan

What is TTL?

Long TTL vs Short TTL

Practical Tip: Lower TTL Before Server Migration

7. Hands-On Lab: Tracing DNS with dig and nslookup

Lab 1: Seeing the Hierarchy with dig +trace

Lab 2: Querying Specific Records with nslookup

Lab 3: Checking TTL with dig

Lab 4: Querying Specific DNS Servers Directly

7. 실제 Lab - `dig`와 `nslookup`으로 DNS 추적하기

Lab 1: `dig +trace`로 계층 구조 보기

Lab 2: `nslookup`으로 특정 레코드 조회

Lab 3: `dig`로 TTL 확인

7. Hands-On Lab: Tracing DNS with `dig` and `nslookup`

Lab 1: Seeing the Hierarchy with `dig +trace`

Lab 2: Querying Specific Records with `nslookup`

Lab 3: Checking TTL with `dig`