DNS의 원리 (3) - DNS 보안과 현대적 발전 - soo:bak
작성일 :
신뢰의 문제
DNS의 원리 (2)에서 DNS 질의 과정을 살펴보았습니다.
하지만 한 가지 의문이 있습니다.
응답을 어떻게 신뢰할 수 있는가?
1983년 DNS가 설계될 때, 인터넷은 작고 신뢰할 수 있는 연구 네트워크였습니다.
모든 참여자가 선의를 가졌다고 가정했습니다.
오늘날 인터넷은 그렇지 않습니다.
악의적인 공격자가 DNS 응답을 조작할 수 있습니다.
DNS의 보안 취약점
DNS Spoofing
공격자가 가짜 DNS 응답을 보내는 공격입니다.
1
2
3
4
5
6
7
8
9
10
11
정상적인 경우:
사용자 ──질의──▶ DNS 서버 ──응답──▶ 사용자
(정상 IP)
DNS Spoofing:
사용자 ──질의──▶ DNS 서버
◀─────── 공격자 (가짜 응답, 공격자 IP)
◀─────── DNS 서버 (정상 응답, 무시됨)
공격자가 정상 서버보다 먼저 응답하면 성공합니다.
사용자는 공격자의 서버로 연결됩니다.
왜 가능한가?
DNS 프로토콜의 구조적 문제입니다.
1. UDP 사용
UDP는 연결 상태가 없습니다.
누구든 응답 패킷을 보낼 수 있습니다.
2. 약한 트랜잭션 ID
질의와 응답을 매칭하는 ID가 16비트입니다.
65,536개의 가능한 값 중 하나를 맞추면 됩니다.
3. 인증 없음
응답에 서명이 없습니다.
누가 보냈는지 확인할 방법이 없습니다.
Cache Poisoning
Recursive Resolver의 캐시를 오염시키는 공격입니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
공격 시나리오:
1. 공격자가 Resolver에 질의 유도
"evil.example.com의 IP는?"
2. 공격자가 가짜 응답 전송
"evil.example.com의 IP는 1.2.3.4"
"추가 정보: www.example.com의 IP는 6.6.6.6" ← 악성
3. Resolver가 캐시에 저장
www.example.com → 6.6.6.6 (오염됨)
4. 다른 사용자들도 오염된 캐시 사용
Additional 섹션의 추가 정보를 이용한 공격입니다.
Bailiwick checking으로 일부 완화됩니다. (관련 없는 도메인 정보 거부)
Kaminsky Attack (2008)
Dan Kaminsky가 발표한 강력한 Cache Poisoning 기법입니다.
기존 공격의 한계:
- 캐시에 이미 정상 레코드가 있으면 공격 불가
- TTL이 만료될 때까지 기다려야 함
Kaminsky의 아이디어:
- 존재하지 않는 서브도메인을 계속 질의
random1.example.com,random2.example.com, …- 매번 새로운 질의이므로 캐시가 없음
- Authority 섹션에 가짜 NS 레코드 삽입
1
2
3
4
5
6
7
8
공격 과정:
1. 공격자: "abc123.example.com의 IP?"
2. Resolver: 캐시 없음, example.com NS에 질의
3. 공격자: 대량의 가짜 응답 전송
- 트랜잭션 ID 추측 (65536개 중 하나)
- Authority: "example.com NS = evil.attacker.com"
4. 성공하면 example.com 전체가 공격자 통제
위험성: 하위 도메인 하나가 아닌 전체 도메인 탈취
대응책 (2008년 이후):
- Source Port Randomization: 포트도 랜덤화 (추측해야 할 값 증가)
- 0x20 인코딩: 대소문자 변형을 추가 엔트로피로 사용
- DNSSEC: 근본적 해결책
DNSSEC
디지털 서명으로 해결
DNSSEC(DNS Security Extensions)는 DNS 응답에 디지털 서명을 추가합니다.
네트워크 보안의 원리 (1)에서 설명한 비대칭 암호화를 사용합니다.
핵심 아이디어:
- 각 Zone이 개인키/공개키 쌍을 가짐
- 레코드에 서명 추가
- 검증자가 공개키로 서명 확인
- 위조된 응답은 서명 검증 실패
DNSSEC 레코드 타입
DNSKEY
Zone의 공개키를 담습니다.
1
2
3
4
5
example.com. IN DNSKEY 257 3 13 (
mdsswUyr3DPW132mOi8V9xESWE8jTo0d
xCjjnopKl+GqJxpVXckHAeF+KkxLbxIL
fDLUT0rAK9iUzy1L53eKGQ==
)
257: KSK(Key Signing Key) 플래그
256: ZSK(Zone Signing Key) 플래그
13: 알고리즘 (ECDSA P-256)
RRSIG (Resource Record Signature)
레코드의 서명입니다.
1
2
3
4
5
6
example.com. IN A 93.184.216.34
example.com. IN RRSIG A 13 2 3600 (
20260301000000 20260201000000 12345 example.com.
oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip
8WTrPYGv07h108dUKGMeDPKijVCHX3DD
Kdfb+v6oB9wfuh3DTJXUAfI= )
서명 만료일, 서명 시작일, 키 태그, 서명값을 포함합니다.
DS (Delegation Signer)
자식 Zone의 키를 부모 Zone에서 인증합니다.
1
2
3
4
; .com Zone에서
example.com. IN DS 12345 13 2 (
49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE
)
자식의 DNSKEY 해시입니다.
신뢰 체인을 형성합니다.
NSEC/NSEC3
“이 레코드는 존재하지 않음”을 증명합니다.
1
2
; alpha.example.com 다음은 beta.example.com
alpha.example.com. IN NSEC beta.example.com. A RRSIG NSEC
신뢰 체인 (Chain of Trust)
DNSSEC의 핵심은 루트로부터의 신뢰 체인입니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Trust Anchor
│
┌────▼────┐
│ Root │ DNSKEY (루트 키)
│ . │ DS (com의 키 해시)
└────┬────┘
│ DS가 DNSKEY를 인증
┌────▼────┐
│ .com │ DNSKEY
│ TLD │ DS (example.com의 키 해시)
└────┬────┘
│ DS가 DNSKEY를 인증
┌────▼────┐
│ example │ DNSKEY
│ .com │ RRSIG (각 레코드 서명)
└─────────┘
Trust Anchor: 루트의 공개키
운영체제나 리졸버에 미리 설정되어 있습니다.
IANA가 관리하며, 드물게 변경됩니다 (2018년 키 롤오버).
DNSSEC 검증 과정
www.example.com A 레코드 검증:
- 응답 수신: A 레코드 + RRSIG
example.comDNSKEY로 RRSIG 검증example.comDNSKEY가 진짜인지 확인.com의 DS 레코드 확인 (example.com DNSKEY 해시).comDNSKEY로 DS의 RRSIG 검증- 루트까지 반복
- Trust Anchor(루트 키)로 최종 검증
모든 단계가 성공해야 신뢰
하나라도 실패하면 SERVFAIL 반환
DNSSEC의 한계
복잡성
- 키 관리가 어려움
- 키 롤오버 절차 복잡
- 설정 오류 시 도메인 접속 불가
응답 크기 증가
- 서명이 추가되어 패킷 커짐
- UDP 512바이트 초과 가능
- EDNS0 또는 TCP 필요
프라이버시 없음
- 응답 무결성만 보장
- 질의/응답 내용은 여전히 평문
- 누가 어떤 도메인을 조회하는지 노출
암호화된 DNS
프라이버시 문제
전통적인 DNS는 평문으로 전송됩니다.
1
2
3
4
5
6
7
8
9
10
11
12
네트워크 경로상의 누구든 볼 수 있음:
┌──────────┐ ┌──────────┐
│ 사용자 │ ──"bank.com의 IP는?"──────▶ │ DNS │
│ │ ◀─────────────────────────── │ 서버 │
└──────────┘ (평문, 노출됨) └──────────┘
│
│ 관찰 가능한 위치:
│ - 로컬 네트워크 관리자
│ - ISP
│ - 정부 감시 기관
│ - 공용 Wi-Fi 공격자
어떤 웹사이트를 방문하는지 DNS 질의로 알 수 있습니다.
HTTPS로 콘텐츠를 암호화해도 DNS는 노출됩니다.
DoT (DNS over TLS)
DNS 질의를 TLS로 암호화합니다.
네트워크 보안의 원리 (2)에서 설명한 TLS를 DNS에 적용합니다.
포트: 853
장점: 표준 TLS 사용, 구현 간단
단점: 별도 포트 사용으로 차단 가능
1
2
3
4
5
6
7
8
9
10
11
12
13
14
일반 DNS (포트 53):
┌──────────┐ UDP/53 ┌──────────┐
│ Resolver │ ────────────────────▶ │ DNS │
│ │ ◀─────────────────── │ 서버 │
└──────────┘ (평문) └──────────┘
DoT (포트 853):
┌──────────┐ TLS 핸드셰이크 ┌──────────┐
│ Resolver │ ◀──────────────────▶ │ DNS │
│ │ │ 서버 │
│ │ 암호화된 DNS │ │
│ │ ◀──────────────────▶ │ │
└──────────┘ (TLS over TCP/853) └──────────┘
DoH (DNS over HTTPS)
DNS 질의를 HTTPS로 전송합니다.
포트: 443 (일반 HTTPS와 같음)
장점: 일반 웹 트래픽과 구분 불가, 차단 어려움
단점: 약간의 오버헤드, CDN/프록시가 복잡해짐
1
2
3
4
5
6
7
8
9
10
11
12
DoH 요청 예시:
GET /dns-query?dns=AAABAAAB... HTTP/2
Host: dns.google
Accept: application/dns-message
POST /dns-query HTTP/2
Host: cloudflare-dns.com
Content-Type: application/dns-message
(이진 DNS 메시지)
주요 DoH 서버:
| 제공자 | URL |
|---|---|
| https://dns.google/dns-query | |
| Cloudflare | https://cloudflare-dns.com/dns-query |
| Quad9 | https://dns.quad9.net/dns-query |
DoH vs DoT
| 특성 | DoT | DoH |
|---|---|---|
| 포트 | 853 | 443 |
| 프로토콜 | TLS | HTTPS |
| 차단 가능성 | 포트 차단 쉬움 | 차단 어려움 |
| 네트워크 관리 | 식별 가능 | 식별 어려움 |
| 중앙화 우려 | 낮음 | 높음 (브라우저 내장) |
중앙화 논쟁:
브라우저가 특정 DoH 서버를 기본값으로 설정하면, 소수의 기업이 DNS 트래픽 대부분을 보게 됩니다.
ISP의 감시를 피하지만, 다른 기업의 감시 가능성이 생깁니다.
ODoH (Oblivious DoH)
DoH에 익명성을 추가한 프로토콜입니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
일반 DoH:
사용자 ──────▶ DoH 서버
│
└── 질의 내용 + IP 주소 둘 다 앎
ODoH (프록시 사용):
사용자 ──▶ 프록시 ──▶ DoH 서버
│ │
│ └── 질의 내용은 알지만
│ IP 주소 모름 (암호화됨)
│
└── IP 주소는 알지만
질의 내용 모름 (암호화됨)
프록시와 서버를 분리하여 어느 쪽도 전체 정보를 갖지 못합니다.
현대 DNS 인프라
Anycast DNS
동일한 IP 주소가 여러 위치에 존재합니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
사용자 (서울)
│
│ 8.8.8.8로 질의
▼
BGP가 가장 가까운 서버로 라우팅
│
┌─────────────┴─────────────┐
│ │
┌─────▼─────┐ ┌─────▼─────┐
│ 도쿄 PoP │ │ LA PoP │
│ 8.8.8.8 │ │ 8.8.8.8 │
└───────────┘ └───────────┘
↑
선택됨 (더 가까움)
PoP (Point of Presence): 물리적 서버 위치
라우팅과 인터넷 구조 (3)에서 설명한 BGP를 활용합니다.
같은 IP를 여러 위치에서 광고하면, BGP가 가장 가까운 곳으로 라우팅합니다.
장점:
- 지연 시간 감소 (가까운 서버 응답)
- DDoS 공격 분산
- 자동 장애 복구
루트 서버의 Anycast:
13개의 루트 서버 클러스터가 있지만, 실제로는 수백 개의 인스턴스가 전 세계에 분산되어 있습니다.
글로벌 로드 밸런싱
DNS를 이용한 트래픽 분산입니다.
1
2
3
4
$ dig www.example.com
;; ANSWER SECTION:
www.example.com. 60 IN A 93.184.216.34 ← 지역에 따라 다른 IP
지리 기반 응답 (GeoDNS):
- 질의자의 위치 추정 (IP 지오로케이션)
- 가까운 데이터센터의 IP 반환
헬스체크 연동:
- 서버 상태 모니터링
- 장애 서버 IP 제거
- TTL을 짧게 설정하여 빠른 전환
CDN과 DNS
CDN(Content Delivery Network)은 DNS를 핵심 기술로 사용합니다.
1
2
3
4
5
6
www.example.com 조회 흐름:
1. www.example.com → CNAME → cdn.provider.net
2. cdn.provider.net 조회
3. CDN의 권한 서버가 질의자 위치 기반으로 응답
4. 가장 가까운 에지 서버 IP 반환
CNAME Flattening / ALIAS 레코드:
Zone apex(example.com 자체)에는 CNAME을 사용할 수 없습니다.
일부 DNS 제공자는 ALIAS 또는 ANAME 레코드로 이를 우회합니다.
DNS 기반 서비스 디스커버리
마이크로서비스 환경에서 서비스 위치를 찾는 데 DNS를 활용합니다.
1
2
3
4
5
6
Kubernetes 내부 DNS:
service-name.namespace.svc.cluster.local
예: redis.production.svc.cluster.local
→ 클러스터 내부 Redis 서비스 IP
SRV 레코드로 포트 정보까지 제공합니다.
1
2
_http._tcp.web.example.com. IN SRV 10 0 80 server1.example.com.
IN SRV 10 0 80 server2.example.com.
DNS의 미래
DNS over QUIC (DoQ)
HTTP의 진화 (2)에서 설명한 QUIC을 DNS에 적용합니다.
장점:
- TLS 1.3 내장
- 연결 설정 빠름 (0-RTT 가능)
- Head-of-line blocking 없음
포트: 853 (DoT와 같지만 UDP)
HTTPS/SVCB 레코드
서비스 바인딩 정보를 DNS에서 제공합니다.
1
example.com. IN HTTPS 1 . alpn="h3,h2" ipv4hint=93.184.216.34
첫 연결 시 HTTP/3 지원 여부, IP 힌트 등을 미리 알 수 있습니다.
연결 설정 왕복을 줄입니다.
Encrypted Client Hello (ECH)
TLS 핸드셰이크의 SNI(Server Name Indication)도 암호화합니다.
DNS에서 ECH 설정을 배포합니다.
1
example.com. IN HTTPS 1 . ech="..." alpn="h3,h2"
DNS + TLS + HTTP를 결합하여 완전한 프라이버시를 목표로 합니다.
마무리: 40년의 진화
DNS는 1983년 단순한 이름-주소 매핑에서 시작했습니다.
1
2
3
4
5
6
7
8
1983: RFC 882/883 - DNS 탄생
1987: RFC 1034/1035 - 현재 표준
1999: RFC 2535 - DNSSEC 초기
2005: RFC 4033-4035 - DNSSEC 현재
2008: Kaminsky Attack 공개
2016: RFC 7858 - DNS over TLS
2018: RFC 8484 - DNS over HTTPS
2022: RFC 9230 - DNS over QUIC
보안: 평문에서 서명과 암호화로
성능: 중앙 집중에서 전 세계 분산으로
프라이버시: 노출에서 암호화로
인터넷의 가장 기본적인 서비스가 계속 진화하고 있습니다.
시리즈 네비게이션
- DNS의 원리 (1) - DNS의 탄생과 계층 구조
- DNS의 원리 (2) - DNS 질의와 해석 과정
- 현재 글: DNS의 원리 (3) - DNS 보안과 현대적 발전
관련 시리즈