DNS · IP · 도메인 — 이름을 주소로 바꾸는 여정
jit.co.kr → 1.2.3.4로의 조회 경로 (resolver→root→TLD→authoritative), TTL과 전파 지연.
"배포했는데 도메인이 연결 안 돼요" 사고 95%는 DNS 전파 대기. 이 메커니즘을 알면 기다릴지, 레코드를 고칠지 판단할 수 있다.
컴퓨터는 IP로만 통신한다(예: `172.217.161.14`). 사람은 이 숫자를 못 외운다. DNS는 전 세계 전화번호부 — `google.com` → `172.217.161.14` 변환을 담당한다.
브라우저가 jit-learning.com을 연다:
1) 브라우저 캐시 확인 → 없음
2) OS 캐시(/etc/hosts, DNS client) → 없음
3) ISP Resolver (보통 ISP나 1.1.1.1/8.8.8.8)
↓ 이것도 없으면:
4) Root DNS 서버 (.) → "co.kr 담당은 여기로"
5) TLD 서버 (.co.kr) → "jit-learning.co.kr 담당은 여기로"
6) Authoritative 서버 → "1.2.3.4 입니다"
(Cloudflare, AWS Route 53 등)
7) 각 단계 결과를 TTL만큼 캐시
→ 결과가 브라우저에 도착, TCP+TLS+HTTP 시작한 번 질의되면 TTL(보통 300~86400초)만큼 캐시됨. 그래서 레코드 변경이 즉시 반영 안 된다.
| 레코드 | 뜻 | 예시 |
|---|---|---|
| A | 도메인 → IPv4 | `jit.co.kr → 1.2.3.4` |
| AAAA | 도메인 → IPv6 | `jit.co.kr → 2606:...` |
| CNAME | 별칭 → 다른 도메인 | `www → jit.co.kr` |
| MX | 메일 서버 지정 | `@ → mail.jit.co.kr` |
| TXT | 자유 문자열 | SPF·도메인 소유 증명 |
| NS | 이 도메인의 권한 서버 | `cloudflare.com의 네임서버` |
# DNS 조회 도구 4총사
dig jit-learning.com # 상세 응답 (Mac/Linux)
dig jit-learning.com +short # IP만
nslookup jit-learning.com # 모든 OS 공통
host jit-learning.com # 간결
Resolve-DnsName jit-learning.com # Windows PowerShell
# 특정 DNS 서버에 직접 질의 (ISP 캐시 우회)
dig @8.8.8.8 jit-learning.com
dig @1.1.1.1 jit-learning.com
# TTL 확인 — "몇 초 뒤 바뀐 레코드가 보일까"
dig jit-learning.com | grep -E "ANSWER|IN\s+A"
# 로컬 DNS 캐시 비우기
# macOS: sudo dscacheutil -flushcache
# Linux: sudo systemd-resolve --flush-caches
# Windows: ipconfig /flushdns배포 후 도메인이 안 붙을 때 먼저 `dig @8.8.8.8 도메인` → IP가 제대로 보이면 DNS는 OK, 내 ISP 캐시 문제. IP가 틀리면 레코드 자체가 문제.
TTL 전파 딜레이. 기존 TTL이 86400(1일)이었다면, 레코드 바꿔도 최대 하루까지 기존 IP가 캐시에 남음. 배포 전에 TTL을 300 등으로 낮춰둬야 교체가 빠르다.
CNAME 체인 주의. `www.jit.co.kr` CNAME → `jit.vercel.app` CNAME → `cname.vercel-dns.com` A. 브라우저는 단계마다 DNS 쿼리를 또 보낸다. 길수록 느려짐. 루트(`jit.co.kr`)는 CNAME 금지라서 보통 A 또는 ALIAS 레코드를 쓴다.
도메인을 IPv4 주소로 매핑하는 DNS 레코드 타입은?
DNS 결과를 일정 시간 캐시하는 기간을 지정하는 필드 이름은?