DNS (Domain Name System)
DNS는 사람이 읽을 수 있는 도메인 이름(예: google.com)을 컴퓨터가 이해하는 IP 주소(예: 142.250.196.110)로 변환하는 시스템이다. 인터넷의 전화번호부 역할을 한다.
왜 필요한가?
- 사람은
142.250.196.110보다google.com을 기억하기 쉬움 - 서버 IP가 바뀌어도 도메인은 그대로 유지 가능
- 하나의 도메인에 여러 IP를 연결하여 로드밸런싱, 장애 대응 가능
DNS 계층 구조
DNS는 트리 구조로 되어 있고, 오른쪽부터 왼쪽으로 읽는다.
www.example.com.
│ │ │ └── Root (.)
│ │ └───── TLD (.com)
│ └──────────── SLD (example)
└───────────────── Subdomain (www)| 계층 | 설명 | 예시 |
|---|---|---|
| Root | 최상위, 전 세계 13개 루트 서버 | . |
| TLD (Top-Level Domain) | 최상위 도메인 | .com, .kr, .io |
| SLD (Second-Level Domain) | 실제 등록하는 도메인 | example, google |
| Subdomain | SLD 하위에 자유롭게 생성 | www, api, mail |
DNS 레코드 종류
| 레코드 | 설명 | 예시 |
|---|---|---|
| A | 도메인 → IPv4 주소 | example.com → 93.184.216.34 |
| AAAA | 도메인 → IPv6 주소 | example.com → 2606:2800:... |
| CNAME | 도메인 → 다른 도메인 (별칭) | www.example.com → example.com |
| NS | 해당 도메인의 네임서버 지정 | example.com → ns1.dns.com |
| MX | 메일 서버 지정 | example.com → mail.example.com |
| TXT | 텍스트 정보 (인증, SPF 등) | v=spf1 include:_spf.google.com |
| SOA | 도메인의 권한 정보 (시리얼, TTL 등) | 존(zone)의 메타 정보 |
A vs CNAME
A 레코드:
api.example.com → 10.0.0.1 (IP 직접 지정)
CNAME 레코드:
www.example.com → example.com → 10.0.0.1 (다른 도메인을 거쳐서 IP 확인)- A는 IP가 바뀌면 직접 수정해야 함
- CNAME은 원본 도메인의 IP가 바뀌면 자동 반영
- 루트 도메인(
example.com)에는 CNAME을 쓸 수 없음 → A 레코드 또는 ALIAS 사용
DNS 질의 과정 (Resolution)
브라우저에서 www.example.com을 입력했을 때:
1. 브라우저 캐시 확인 → 있으면 바로 사용
2. OS 캐시 확인 (/etc/hosts, OS DNS 캐시)
3. Local DNS 서버(리졸버)에 질의
└── 캐시에 있으면 바로 응답
4. Root 네임서버에 질의
└── ".com 은 이 TLD 서버에 물어봐" 응답
5. TLD 네임서버(.com)에 질의
└── "example.com 은 이 네임서버에 물어봐" 응답
6. Authoritative 네임서버에 질의
└── "www.example.com 의 IP는 93.184.216.34야" 응답
7. Local DNS 서버가 결과를 캐싱 후 클라이언트에 반환질의 방식
| 방식 | 설명 |
|---|---|
| 재귀적 질의 (Recursive) | 클라이언트 → 리졸버에게 "최종 답을 알려줘". 리졸버가 대신 전부 질의 |
| 반복적 질의 (Iterative) | 리졸버가 각 네임서버에 순서대로 질의. "나는 모르지만 여기에 물어봐" 응답을 따라감 |
일반적으로 클라이언트 → 리졸버는 재귀적, 리졸버 → 각 네임서버는 반복적으로 동작한다.
TTL (Time To Live)
DNS 레코드가 캐시에 유지되는 시간(초)이다.
example.com. 300 IN A 93.184.216.34
└── TTL: 300초 (5분)| TTL | 장점 | 단점 |
|---|---|---|
| 짧게 (60~300초) | IP 변경 시 빠르게 반영 | DNS 질의 빈도 증가 |
| 길게 (3600초~) | DNS 부하 감소, 응답 빠름 | IP 변경 시 반영이 느림 |
실무 팁
- 평소에는 TTL을 길게 설정 (예: 3600초)
- 서버 마이그레이션 전에 TTL을 짧게 낮춰두고 (예: 60초)
- 마이그레이션 완료 후 다시 TTL을 원래대로 올림
DNS 기반 로드밸런싱
하나의 도메인에 여러 IP를 등록하여 트래픽을 분산한다.
example.com → 10.0.0.1
example.com → 10.0.0.2
example.com → 10.0.0.3DNS 라운드로빈
질의할 때마다 다른 순서로 IP를 반환하여 분산한다.
DNS vs VIP 로드밸런싱
| 비교 | DNS | VIP (로드밸런서) |
|---|---|---|
| 전환 속도 | 느림 (TTL 만료 대기) | 즉시 |
| 헬스체크 | 기본 미지원 | LB가 직접 수행 |
| 세밀한 분산 | 불가 (클라이언트 캐싱 영향) | 가능 (가중치, 세션 등) |
| 적합한 상황 | 글로벌 분산, CDN | 실시간 트래픽 분산 |
→ 실무에서는 DNS(글로벌) + VIP(리전 내) 조합을 많이 사용한다.
AWS에서의 DNS
Route 53
AWS의 관리형 DNS 서비스이다.
| 라우팅 정책 | 설명 |
|---|---|
| 단순 라우팅 | 하나의 리소스로 트래픽 전달 |
| 가중치 기반 | 비율로 트래픽 분산 (예: 80:20) |
| 지연 시간 기반 | 가장 응답이 빠른 리전으로 라우팅 |
| 지리적 위치 기반 | 클라이언트 위치에 따라 라우팅 |
| 장애 조치 | 헬스체크 실패 시 백업 리소스로 전환 |
ALIAS 레코드
Route 53 전용 레코드로, 루트 도메인에서도 CNAME처럼 다른 AWS 리소스(ALB, CloudFront 등)를 가리킬 수 있다.
일반 DNS: example.com → CNAME → 불가능 (루트 도메인)
Route 53: example.com → ALIAS → ALB/CloudFront (가능)보안: DNS 관련 공격과 방어
DNS Spoofing (Cache Poisoning)
공격자가 DNS 캐시에 위조된 IP를 주입하여 사용자를 악성 사이트로 유도한다.
정상: example.com → 93.184.216.34
공격: example.com → 악성 서버 IP (캐시에 위조 응답 주입)방어
- DNSSEC: DNS 응답에 디지털 서명을 추가하여 위변조 방지
- DoH (DNS over HTTPS): DNS 질의를 HTTPS로 암호화
- DoT (DNS over TLS): DNS 질의를 TLS로 암호화