DNS의 구조와 동작
브라우저 주소창에 www.google.com을 입력하면 구글의 웹 페이지가 나타납니다. 하지만 패킷을 보내려면 IP 주소가 필요합니다. 사람이 쓰는 도메인 이름을 컴퓨터가 쓰는 IP 주소로 바꿔주는 시스템이 DNS(Domain Name System)입니다.
DNS는 전화번호부에 비유되곤 하지만, 실제로는 전 세계에 분산된 거대한 계층적 데이터베이스입니다.
DNS가 없는 세계
브라우저에 93.184.216.34 입력 → 구글
브라우저에 104.16.132.229 입력 → 네이버
브라우저에 13.107.42.14 입력 → 마이크로소프트
문제
1. 사람이 IP 주소를 기억할 수 없음
2. 서버 IP가 바뀌면 전 세계에 알려야 함
3. 한 서비스가 여러 IP를 가질 수 있음 (CDN)
4. 중앙 집중 관리 불가 (수십억 개의 도메인)
DNS가 있는 세계
브라우저에 google.com 입력 → DNS 자동 해석 → 142.250.196.110
서버 이전해도 DNS 레코드만 변경하면 끝!도메인 이름 체계
도메인 이름은 오른쪽에서 왼쪽으로 계층 구조를 가집니다.
www.example.com.
│ │ │ │
│ │ │ └── 루트 (Root) - 보이지 않는 최상위
│ │ └───── TLD (Top-Level Domain)
│ └───────────── SLD (Second-Level Domain)
└────────────────── 서브도메인 (Subdomain)
계층 트리
. (Root)
│
┌───────────┼───────────┐
com org kr
│ │ │
┌───┼───┐ ┌──┼──┐ ┌───┼───┐
google example wiki ... co go
│ │ │ │
www www,api naver ...
mail-
루트(Root): 도메인의 최상위입니다. 보통 표기하지 않지만, 정확히는
www.example.com.처럼 마지막에 점이 하나 더 있습니다. 이 마지막 점이 루트를 의미합니다. -
TLD(Top-Level Domain):
com,org,net,kr등 최상위 도메인입니다..com은 일반 TLD(gTLD),.kr은 국가 코드 TLD(ccTLD)입니다. -
SLD(Second-Level Domain):
example처럼 일반적으로 조직이나 서비스를 식별하는 부분입니다. 도메인을 구매할 때 실제로 등록하는 것이 이 레벨입니다. -
서브도메인(Subdomain):
www,api,mail등 도메인 소유자가 자유롭게 설정하는 부분입니다.
| TLD 유형 | 예시 | 설명 |
|---|---|---|
| gTLD (일반) | .com, .org, .net | 전 세계 공용 |
| ccTLD (국가) | .kr, .jp, .uk | 국가/지역 코드 |
| 신규 gTLD | .dev, .app, .io | 2012년 이후 추가 |
| sTLD (후원) | .edu, .gov, .mil | 특정 기관 전용 |
| 인프라 | .arpa | 역방향 DNS 등 인프라용 |
이 계층 구조는 DNS 서버의 구조와 직접 대응됩니다.
DNS 서버 종류
DNS 질의를 처리하는 서버는 네 가지 유형으로 나뉩니다.
클라이언트 (브라우저)
│
│ 재귀 질의 (답 찾아와!)
▼
┌──────────────┐
│ DNS 리졸버 │ ISP 또는 8.8.8.8, 1.1.1.1
│ (Recursive) │ 역할: 대리인, 캐시 보유
└──────┬───────┘
│ 반복 질의 (아는 것만 알려줘)
▼
┌──────────────┐
│ 루트 서버 │ 전 세계 13개 그룹 (A~M)
│ (Root) │ 역할: TLD 서버 위치 안내
└──────┬───────┘
│
▼
┌──────────────┐
│ TLD 서버 │ .com, .org, .kr 등 담당
│ │ 역할: 권한 서버 위치 안내
└──────┬───────┘
│
▼
┌───────────────┐
│ 권한 서버 │ 실제 레코드 보유
│(Authoritative)│ 역할: 최종 답변 제공
└───────────────┘DNS 리졸버(Recursive Resolver): 클라이언트(브라우저)의 질의를 받아, 답을 찾을 때까지 다른 DNS 서버들을 순차적으로 질의하는 서버입니다. ISP가 운영하거나, 8.8.8.8(Google), 1.1.1.1(Cloudflare) 같은 공개 리졸버를 사용할 수 있습니다. "대리인" 역할입니다.
루트 DNS 서버(Root Name Server): 도메인 계층의 최상위를 담당합니다. .com이면 어디로, .kr이면 어디로 가야 하는지를 알려줍니다. 전 세계에 13개의 루트 서버 그룹(A~M)이 있으며, 애니캐스트를 사용하여 물리적으로는 수백 대가 분산 운영됩니다.
| 루트 서버 | 운영 기관 | 비고 |
|---|---|---|
| A | Verisign | 최초 루트 서버 |
| B | USC-ISI | 대학 연구소 |
| F | ISC | BIND 개발 기관 |
| J | Verisign | 전 세계 200+ 노드 |
| K | RIPE NCC | 유럽 인터넷 레지스트리 |
| L | ICANN | 인터넷 거버넌스 |
| M | WIDE Project | 일본 (아시아 대표) |
TLD DNS 서버: .com, .org, .kr 같은 최상위 도메인을 담당합니다. example.com에 대한 질의를 받으면, example.com을 관리하는 권한 DNS 서버의 주소를 알려줍니다.
권한 DNS 서버(Authoritative Name Server): 특정 도메인의 실제 레코드를 가지고 있는 서버입니다. example.com의 IP 주소가 무엇인지, 메일 서버는 어디인지 등의 최종 답변을 제공합니다. 도메인 소유자가 직접 레코드를 관리합니다.
재귀 질의 vs 반복 질의
브라우저가 www.example.com의 IP 주소를 알아내는 전체 과정을 따라가 보겠습니다.
브라우저 리졸버 루트 서버 .com TLD 권한 서버
│ │ │ │ │
│─① "www.example.com?"──→│ │ │ │
│ (재귀 질의) │ │ │ │
│ │─② "example.com?"──→│ │ │
│ │ (반복 질의) │ │ │
│ │←── ".com TLD는 │ │ │
│ │ 192.5.6.30" ────│ │ │
│ │ │ │ │
│ │─③ "example.com?" ─────────────────→│ │
│ │ │ │
│ │←── "권한서버는 ──────────────────│ │
│ │ ns1.example.com" │ │
│ │ │ │
│ │─④ "www.example.com?" ────────────────────────────→│
│ │ │
│ │←── "93.184.216.34" ────────────────────────────────│
│ │ │
│←⑤ "93.184.216.34" ─────│ (캐시에 저장) │
│ │ │1단계: 브라우저가 DNS 리졸버에게 재귀 질의(Recursive Query)를 보냅니다. "완전한 답을 달라"는 요청이므로, 리졸버는 반드시 최종 답변(IP 주소 또는 "없음")을 클라이언트에게 돌려주어야 합니다.
2단계: 리졸버의 캐시에 답이 없으면, 루트 DNS 서버에 반복 질의(Iterative Query)를 보냅니다. 루트 서버는 "나는 모르지만, .com TLD 서버의 주소는 이것이다"라고 응답합니다.
3단계: 리졸버가 .com TLD 서버에 같은 질문을 합니다. TLD 서버는 "example.com의 권한 DNS 서버 주소는 이것이다"라고 응답합니다.
4단계: 리졸버가 example.com의 권한 DNS 서버에 질의합니다. 권한 서버가 "www.example.com의 IP 주소는 93.184.216.34입니다"라고 최종 답변을 제공합니다.
5단계: 리졸버가 이 답을 캐시에 저장하고, 클라이언트에게 전달합니다. 이후 같은 도메인에 대한 질의는 캐시에서 즉시 응답합니다.
재귀 질의 (Recursive)
클라이언트 → 리졸버: "답 찾아와!"
리졸버는 반드시 최종 답을 가져와야 함
클라이언트는 편하고, 리졸버가 수고
반복 질의 (Iterative)
리졸버 → 루트/TLD/권한: "아는 것만 알려줘"
각 서버는 다음 서버 위치만 알려줌
리졸버가 직접 다음 서버에 질의
왜 이렇게 구분할까?
→ 루트 서버에 재귀 질의를 허용하면
전 세계의 모든 DNS 질의 부담이 루트에 집중!
→ 반복 질의로 부담을 리졸버에게 분산DNS 캐시 계층
실제로는 매번 루트 서버부터 질의하지 않습니다. 여러 단계의 캐시가 있어서, 대부분의 질의는 캐시에서 즉시 해결됩니다.
1. 브라우저 캐시
Chrome: chrome://net-internals/#dns
↓ 없으면
2. OS DNS 캐시
Windows: ipconfig /displaydns
Linux: systemd-resolve --statistics
macOS: dns-sd 또는 dscacheutil
↓ 없으면
3. 로컬 hosts 파일
Windows: C:\Windows\System32\drivers\etc\hosts
Linux/Mac: /etc/hosts
↓ 없으면
4. 리졸버 캐시 (ISP 또는 8.8.8.8)
최근 질의 결과를 TTL 동안 보관
↓ 없으면
5. 실제 DNS 해석
루트 → TLD → 권한 서버 순서# Windows: OS DNS 캐시 확인
ipconfig /displaydns | findstr "Record Name"
# Windows: OS DNS 캐시 초기화
ipconfig /flushdns
# Linux: systemd-resolved 캐시 통계
resolvectl statistics
# macOS: DNS 캐시 초기화
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
# hosts 파일 확인 (로컬 DNS 오버라이드)
# Windows: type C:\Windows\System32\drivers\etc\hosts
# Linux/Mac: cat /etc/hostsimport socket
def resolve_domain(domain):
"""도메인 이름을 IP 주소로 해석"""
try:
# getaddrinfo: IPv4 + IPv6 모두 조회
results = socket.getaddrinfo(domain, None)
seen = set()
for family, _, _, _, sockaddr in results:
ip = sockaddr[0]
if ip not in seen:
seen.add(ip)
version = "IPv4" if family == socket.AF_INET else "IPv6"
print(f" {version}: {ip}")
# gethostbyname: IPv4만 (간단한 조회)
ipv4 = socket.gethostbyname(domain)
print(f"\n 기본 IPv4: {ipv4}")
except socket.gaierror as e:
print(f" 해석 실패: {e}")
# 여러 도메인 조회
domains = ["google.com", "naver.com", "github.com"]
for domain in domains:
print(f"\n{domain}:")
resolve_domain(domain)이 과정에서 리졸버가 대리인으로서 여러 서버를 돌아다니며 답을 찾아오기 때문에, 클라이언트는 복잡한 과정을 전혀 모르고 하나의 질문만 던지면 됩니다.
DNS 면접 포인트
| 질문 | 핵심 답변 |
|---|---|
| DNS란? | 도메인 이름 → IP 주소 변환 시스템, 분산 계층 데이터베이스 |
| 재귀 vs 반복 질의? | 재귀는 답 찾아와, 반복은 아는 것만 알려줘 |
| 루트 서버가 13개인 이유? | DNS 패킷이 512바이트(UDP) 안에 들어가야 하므로 |
| DNS 캐시 순서? | 브라우저 → OS → hosts → 리졸버 → 실제 해석 |
| 권한 서버 vs 리졸버? | 권한은 실제 레코드 보유, 리졸버는 대리 조회 + 캐시 |
다음 절에서는 DNS 서버가 저장하는 구체적인 레코드 유형과 실습 도구를 살펴보겠습니다.