학습 목표
DNS(Domain Name System) 가 호스트명 → IP 주소 로 사람이 읽기 쉬운 이름을 기계 주소로 바꾸는 이유를 설명할 수 있다.
주요 레코드 타입(A, AAAA, CNAME, MX, NS, TXT)의 용도를 구분할 수 있다.
재귀 질의와 반복 질의의 역할 차이를 설명할 수 있다.
dig, nslookup으로 질의·응답을 확인할 수 있다.
문제 상황
curl https://api.example.com은 되는데 코드에는 IP가 없다- 언제 도메인이 IP로 바뀌는지, HTTP/TLS 전인지 후인지 모른다
api.example.com과www.example.com이 다른 IP를 가리킨다- CNAME·A 레코드 차이를 모르면 CDN·로드밸런서 설정이 꼬인다
- 메일이
@example.com으로 안 간다- MX 레코드가 없거나 우선순위가 잘못됐을 수 있다
- DNS만 바꿨는데 몇 분~몇 시간 뒤에야 반영된다
- TTL·캐시 때문에 “이미 바꿨는데” 현상이 생긴다
HTTPS·인증서까지 봤다. connect() 전에 이름 해석이 먼저다 — DNS가 그 역할을 한다.
1. DNS가 하는 일
인터넷 호스트는 IP 주소로 식별되지만, 사람과 설정 파일은 도메인 이름을 쓴다. DNS는 분산 데이터베이스로 이름을 IP(및 기타 정보)에 매핑한다.
| 역할 | 설명 |
|---|---|
| 이름 해석 | host.example.com → 93.184.216.34 (A 레코드) |
| 별칭 | www → cdn.example.net (CNAME) |
| 메일 라우팅 | 도메인 → 메일 서버 호스트 (MX) |
| 위임 | 서브도메인을 다른 DNS 서버에 위임 (NS) |
- UDP 53 포트가 기본 (대용량 응답·DNSSEC 등은 TCP도 사용)
- 계층적 이름 공간:
www.google.com.→.(루트) →com→google→www - 애플리케이션(브라우저)은 보통 스텁 리졸버만 호출하고, OS가 재귀 리졸버에 질의
2. 이름 해석 흐름
클라이언트가 www.example.com IP를 알고 싶을 때, 로컬 DNS(재귀 리졸버) 가 루트·TLD·권한 서버를 거쳐 답을 모은다.
Client app Local resolver Root TLD (.com) Authoritative
| | | | |
|-- query A www.example.com ----------->| | |
| |-- .com NS -------------------->| |
| |<-- referral -------------------| |
| |-- example.com NS ---------------------------->|
| |<-- A 93.184.216.34 -------------------------|
|<-- answer -----------------------------------------| |- 루트 서버 — TLD NS 알려줌 (
.com,.kr등) - TLD 서버 — 해당 도메인 권한 NS 알려줌
- 권한(authoritative) 서버 — 실제 A/AAAA 등 레코드 보유
- 결과는 리졸버·OS·앱에 캐시 — TTL 동안 재질의 생략
dig +trace www.example.com
# 루트 → TLD → authoritative 순 referral 추적3. 재귀 vs 반복 질의
| 재귀(recursive) | 반복(iterative) | |
|---|---|---|
| 누가 | 클라이언트 → 로컬 리졸버 | 리졸버 → 루트/TLD/권한 서버 |
| 동작 | “답 전부 구해줘” | “모르면 다음 물어볼 서버 알려줘” |
| 응답 | 최종 IP(또는 NXDOMAIN) | Referral (NS·A 글루) 또는 최종 답 |
- 스텁 리졸버(호스트 OS)는 보통 재귀 요청만 보냄 — 8.8.8.8, 1.1.1.1, 사내 DNS
- 로컬 리졸버가 인터넷 쪽에는 반복 질의로 체인을 따라감
RD(Recursion Desired) 플래그 — 클라이언트가 재귀를 원함을 표시
dig @8.8.8.8 www.example.com A
dig @a.root-servers.net www.example.com A # 반복만 (referral)4. 레코드 타입
DNS 응답은 RR(Resource Record) 집합이다. 타입별로 의미가 다르다.
| 타입 | 용도 | 예 |
|---|---|---|
| A | IPv4 주소 | www IN A 93.184.216.34 |
| AAAA | IPv6 주소 | www IN AAAA 2606:2800:... |
| CNAME | 별칭 (다른 이름으로 위임) | www IN CNAME cdn.example.net |
| MX | 메일 서버 (우선순위) | 10 mail.example.com |
| NS | 해당 존의 권한 DNS | example.com NS ns1.example.com |
| TXT | 임의 텍스트 (SPF, DKIM, 검증) | v=spf1 include:... |
| SOA | 존 권한·직렬·TTL 등 메타 | primary NS, refresh 등 |
- CNAME 대상에는 보통 다른 CNAME 체인 가능, CNAME과 A 동시 같은 이름에 불가(규칙 주의)
- TTL(Time To Live) — 캐시 수명(초). 짧으면 변경 반영 빠름, 질의 부하 증가
- PTR — 역방향(IP→이름),
in-addr.arpa— 메일·로그 분석에서 가끔 사용
dig example.com A +short
dig example.com MX +short
dig example.com TXT +short
dig -x 93.184.216.34 # PTR (응답 없을 수 있음)5. 캐시와 /etc/hosts
| 계층 | 예 | 비고 |
|---|---|---|
| 브라우저 | Chrome DNS cache | 짧은 TTL |
| OS | systemd-resolved, macOS mDNSResponder | 스텁 → upstream |
| 로컬 파일 | /etc/hosts |
최우선 (개발·고정) |
| 재귀 리졸버 | ISP, 8.8.8.8 | TTL 존중 |
# /etc/hosts — DNS보다 먼저 (일반 OS)
127.0.0.1 localhost
192.168.1.10 dev.api.local- Negative cache — “없음(NXDOMAIN)”도 잠시 캐시
- DNS 변경 미반영 — TTL, 중간 리졸버 캐시, 앱 재시작·
sudo dscacheutil -flushcache등 확인 - Private DNS — K8s
CoreDNS, AWS Route 53, Cloudflare — 같은 프로토콜, 다른 권한·백엔드
6. HTTP·TLS와의 관계
- 앱이
https://api.example.com접속 - DNS → A/AAAA IP 획득 (또는 캐시 hit)
- TCP
connect(IP, 443) - TLS SNI에 호스트명 (
api.example.com) — IP만으로는 부족 (VirtualHost·인증서) - HTTP 요청
- DNS 실패 →
Could not resolve host,NXDOMAIN— TCP/TLS까지 가지 못함 - DNS spoofing/poisoning — 잘못된 IP → 피싱·중간자 (DNSSEC·DoH/DoT는 심화)
- CDN은 often CNAME → 엣지 IP — 지역별 다른 A 응답(GeoDNS)
7. 정리
- DNS는 분산 DB로 도메인을 IP·메일·텍스트 등으로 매핑한다
- 재귀 리졸버가 반복 질의로 루트→TLD→권한 체인을 따라간다
- A/AAAA/CNAME/MX/NS/TXT 를 구분해야 인프라·메일·인증 설정을 읽을 수 있다
- TTL·캐시 때문에 변경 전파 지연이 생긴다 —
dig로 실제 응답을 확인한다
다음에 다룰 것
- 전송 계층 역할
- 프로세스 간 통신, 포트, 멀티플렉싱
해당 내용은 Computer Networking: A Top-Down Approach, 8/E (James Kurose, Keith Ross) 의 내용을 기반으로 합니다.