- Published on
DNS 프로바이더 & 프라이버시 DNS 2026 — Cloudflare 1.1.1.1 · Route 53 · Quad9 · NextDNS · ControlD · Mullvad · Pi-hole · AdGuard Home 심층 분석
- Authors

- Name
- Youngju Kim
- @fjvbn20031
프롤로그 — "DNS는 50ms짜리 인프라"라는 거짓말
"DNS는 그냥 도메인을 IP로 바꿔주는 거잖아요"라는 말은 2026년에 들으면 한쪽 눈썹이 올라간다. 진실은 이렇다. 당신이 어떤 사이트에 접속할 때 가장 먼저 정보를 흘리는 곳이 DNS다. 브라우저가 TLS를 걸기도 전에, VPN을 켜기 전에, 광고 차단기가 동작하기 전에, DNS 쿼리는 평문으로 ISP 리졸버에 도착해 있다. 그리고 ISP는 그걸 본다. 보지 않는 척하지만, 본다.
2026년의 DNS는 세 개의 전선이 동시에 움직이고 있다. (1) 프라이버시 — DoH/DoT/DoQ로 쿼리를 암호화하고, ODoH로 클라이언트 IP까지 분리한다. (2) 보안 — DNSSEC, DNS firewall, malware-blocking 리졸버로 악성 도메인을 거른다. (3) 성능과 비용 — Anycast로 전 세계 P50 10ms 이하를 노리고, HTTPS/SVCB 레코드(RFC 9460)로 첫 핸드셰이크를 한 번에 줄인다.
이 글은 그 전체 지형을 한 번에 정리한다. 공용 리졸버 9개(Cloudflare, Quad9, Google, OpenDNS, AdGuard, NextDNS, ControlD, Mullvad, dns0.eu), 권한 DNS 7개(Cloudflare DNS, Route 53, Cloud DNS, Azure DNS, NS1, DNS Made Easy, 레지스트라 DNS), 자체 호스팅 6개(PowerDNS, BIND9, CoreDNS, Knot, Unbound, dnsmasq), 그리고 홈 프라이버시 DNS 5개(Pi-hole 6, AdGuard Home, Technitium, Unbound+Stubby, Blocky). 마지막에는 한국·일본 통신사 DNS와 공격 시나리오, 그리고 의사결정 체크리스트.
DNS는 50ms짜리 인프라가 아니다. 인터넷 전체의 신뢰 평면이다.
1장 · DNS 기초 — 계층, 레코드, 재귀 vs 권한
먼저 용어부터. DNS는 트리 구조다. 루트(.) → TLD(com., kr.) → 권한 네임서버(example.com.) → 호스트(www.example.com.). 각 단계는 위임(delegation)으로 연결되고, 각 단계의 권한 서버가 그 zone의 진실의 원천이다.
| 역할 | 의미 | 대표 |
|---|---|---|
| Recursive resolver (재귀 리졸버) | 클라이언트 대신 루트→TLD→권한을 따라가서 답을 찾고 캐시 | Cloudflare 1.1.1.1, Quad9 9.9.9.9, ISP DNS, Unbound |
| Authoritative server (권한 서버) | 자기가 가진 zone의 진실을 응답 | Cloudflare DNS, Route 53, BIND9, PowerDNS |
| Stub resolver | OS 안의 가장 얕은 클라이언트, 보통 리졸버 한 곳에 위임 | systemd-resolved, Windows DNS Client |
| Forwarder | 자기는 캐시만 하고 실제 재귀는 상위에 위임 | dnsmasq, Pi-hole, 가정용 라우터 |
자주 만나는 레코드 타입은 정해져 있다.
| 타입 | 의미 | 예 |
|---|---|---|
| A | IPv4 주소 | example.com. 300 IN A 93.184.216.34 |
| AAAA | IPv6 주소 | example.com. 300 IN AAAA 2606:2800:220:1::1 |
| CNAME | 별칭 | www.example.com. 300 IN CNAME example.com. |
| MX | 메일 서버 | example.com. 300 IN MX 10 mail.example.com. |
| TXT | 임의 텍스트 (SPF, DKIM, 검증) | example.com. 300 IN TXT "v=spf1 -all" |
| SRV | 서비스 디스커버리 | _sip._tcp.example.com. 300 IN SRV 0 5 5060 sip.example.com. |
| CAA | 인증서 발급 권한 제어 | example.com. 300 IN CAA 0 issue "letsencrypt.org" |
| HTTPS / SVCB | 서비스 바인딩 (RFC 9460) | example.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint=... |
| DNSKEY / RRSIG / DS | DNSSEC 키, 서명, 위임 서명 | DNSSEC 활성 zone |
TTL(Time To Live)은 리졸버가 답을 캐시해도 되는 초 단위 시간이다. 너무 길면 변경이 늦게 퍼지고, 너무 짧으면 권한 서버에 부하가 간다. 일반 웹은 300~3600초, 게임/CDN은 60초 이하가 흔하다.
2장 · DNS over HTTPS (DoH, RFC 8484)
DoH는 DNS 쿼리를 HTTPS POST/GET으로 감싸 443 포트로 보낸다. 2018년 RFC 8484로 표준화됐고, Firefox는 2020년부터 미국 사용자에 대해 기본 활성화, Chrome은 2020년 "DNS Secure" 기능으로 OS DNS가 DoH를 지원하면 자동 업그레이드한다.
장점은 명확하다. 443 포트라 차단이 어렵고, ISP가 평문으로 보던 쿼리를 못 본다. 단점도 있다. 캡티브 포털과 충돌하고, 회사 네트워크의 split DNS와도 자주 싸운다.
Cloudflare 1.1.1.1의 DoH 엔드포인트.
https://cloudflare-dns.com/dns-query
https://1.1.1.1/dns-query
https://1.0.0.1/dns-query
curl로 직접 쿼리 — Content-Type만 맞추면 된다.
# DoH JSON API (Cloudflare 확장)
curl -s -H 'accept: application/dns-json' \
'https://1.1.1.1/dns-query?name=example.com&type=A' | jq .
# DoH wire format (RFC 8484 표준)
echo -n 'AAABAAABAAAAAAAAB2V4YW1wbGUDY29tAAABAAE' | \
curl -s -H 'accept: application/dns-message' \
-H 'content-type: application/dns-message' \
--data-binary @- \
https://cloudflare-dns.com/dns-query | xxd
브라우저 외에 OS 차원 DoH도 가능. Windows 11은 설정 → 네트워크 → DNS 서버 할당에서 DoH 템플릿을 선택, macOS는 .mobileconfig 프로파일로 DoH를 강제할 수 있다.
3장 · DNS over TLS (DoT, RFC 7858)
DoT는 853 포트 위에서 TLS로 DNS를 감싼다. RFC 7858(2016)로 더 먼저 표준화됐고, 모바일 기기에서 친숙한 방식이다. Android 9 Pie부터 "Private DNS" 항목으로 OS 차원 DoT를 지원한다.
DoH와 DoT의 차이는 포트와 가시성.
| 항목 | DoH (RFC 8484) | DoT (RFC 7858) |
|---|---|---|
| 포트 | 443 (HTTPS와 동일) | 853 |
| 식별 가능성 | HTTPS 트래픽과 섞임, 사실상 차단 불가 | 853 포트 차단으로 막을 수 있음 |
| 클라이언트 지원 | Firefox/Chrome 기본, OS 일부 | Android 9+, systemd-resolved, Unbound, Stubby |
| 오버헤드 | HTTP/2/3 헤더 | TLS만, 더 가벼움 |
systemd-resolved로 DoT 활성화 — /etc/systemd/resolved.conf에 한 줄.
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com
DNSOverTLS=yes
DNSSEC=yes
Android에서는 설정 → 네트워크 및 인터넷 → 비공개 DNS → "비공개 DNS 제공업체 호스트명"에 1dot1dot1dot1.cloudflare-dns.com 또는 dns.quad9.net을 입력하면 즉시 DoT.
4장 · DNS over QUIC (DoQ, RFC 9250)
DoQ는 2022년 RFC 9250으로 표준화된 가장 새로운 전송이다. QUIC(UDP 기반 0-RTT) 위에 DNS를 올린다. 853 포트(DoT와 동일하지만 UDP). 모바일에서 연결 마이그레이션이 매끄럽고, 초기 RTT가 짧다.
| 전송 | RFC | 포트 | 핸드셰이크 RTT | 비고 |
|---|---|---|---|---|
| Do53 (평문) | RFC 1035 | 53 UDP/TCP | 0 | 평문, 가장 빠르지만 가장 위험 |
| DoT | RFC 7858 | 853 TCP | 1~2 | 모바일에서 인기 |
| DoH | RFC 8484 | 443 TCP | 1~2 | 차단 회피에 강함 |
| DoQ | RFC 9250 | 853 UDP | 0~1 (0-RTT 재시작) | 가장 최신, 모바일 친화 |
AdGuard DNS, NextDNS, ControlD, Cloudflare는 모두 DoQ를 지원한다. 클라이언트는 dnsproxy, AdGuard Home(6.x), Stubby 패치 버전 등.
dnsproxy로 DoQ 사용.
dnsproxy --upstream='quic://dns.adguard-dns.com' \
--listen=127.0.0.1 --port=53
5장 · Oblivious DoH (ODoH) — IP까지 가린다
DoH/DoT/DoQ가 푸는 문제는 "ISP가 내 쿼리를 못 보게 하기"다. 그러나 리졸버 자체(Cloudflare, Quad9)는 여전히 내 IP와 내 쿼리를 둘 다 본다. ODoH(2020년 Cloudflare + Apple + Fastly 공동 제안, RFC 9230, 2022년)는 이 결합을 깬다.
구조는 단순하다. 클라이언트 → Oblivious Proxy → Oblivious Target(리졸버).
- Proxy는 클라이언트 IP를 보지만 쿼리는 못 본다(쿼리는 Target 공개키로 암호화).
- Target은 쿼리를 보지만 클라이언트 IP는 모른다(Proxy가 가렸음).
Cloudflare의 1.1.1.1 ODoH 엔드포인트, 그리고 외부 Proxy(Surfshark, ISP-independent)와 함께 쓰는 구성이 대표적. iOS 17부터 시스템 레벨 ODoH 지원이 비공식적으로 가능하고, dnscrypt-proxy 2.1+는 정식 지원한다.
dnscrypt-proxy로 ODoH 설정.
# /etc/dnscrypt-proxy/dnscrypt-proxy.toml
server_names = ['odoh-cloudflare']
[sources.'odoh-servers']
urls = ['https://download.dnscrypt.info/resolvers-list/v3/odoh-servers.md']
cache_file = '/var/cache/dnscrypt-proxy/odoh-servers.md'
minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
[sources.'odoh-relays']
urls = ['https://download.dnscrypt.info/resolvers-list/v3/odoh-relays.md']
cache_file = '/var/cache/dnscrypt-proxy/odoh-relays.md'
minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
ODoH는 채택률이 낮지만, VPN 없이 IP-쿼리 분리가 가능한 거의 유일한 표준이다.
6장 · DNSSEC — 서명된 DNS, 그러나 느린 확산
DNSSEC은 권한 서버가 응답에 서명을 붙이고, 리졸버가 그 서명 체인(루트 KSK → TLD ZSK → zone)을 검증한다. 캐시 포이즈닝, 위조 응답을 거른다. 표준은 RFC 4033/4034/4035(2005).
문제는 도입률. 2026년 기준 글로벌 zone 중 DNSSEC 활성 비율은 약 30%대, .kr zone은 그보다 낮고, .com은 위임 가능하지만 등록자 대부분이 꺼둔 상태다.
DNSSEC 검증 확인.
# +dnssec 플래그로 RRSIG 확인
dig +dnssec example.com A
# AD 비트 = Authenticated Data (리졸버가 검증 통과)
dig @1.1.1.1 +dnssec icann.org SOA | grep -E 'flags|RRSIG'
DNSSEC의 실용적 평가는 갈린다. 옹호자는 "캐시 포이즈닝의 마지막 방어선", 회의론자는 "DoT/DoH가 있으면 채널이 이미 검증되니 zone 서명은 운영 부담만 늘린다". 2026년 현실: 권한 zone은 켜는 게 권장, 클라이언트 검증은 리졸버가 알아서 한다.
7장 · DNS firewall — 악성 도메인을 거른다
DNS firewall은 알려진 악성/피싱/멀웨어 도메인을 리졸버 레벨에서 NXDOMAIN으로 떨어뜨린다. RPZ(Response Policy Zone, BIND9에서 시작), Cloudflare Gateway, Quad9 기본 정책, Cisco Umbrella(전 OpenDNS) 등이 이 카테고리.
| 제공자 | 차단 카테고리 | 가격 |
|---|---|---|
| Cloudflare Gateway | 멀웨어, 피싱, C2, 카테고리 필터링 | Zero Trust 50 사용자 무료 |
| Quad9 9.9.9.9 | 멀웨어, 봇넷 (Swiss, 무로깅) | 무료 |
| Cisco Umbrella | 멀웨어, 피싱, 신뢰 평판, DLP | 사용자/월 과금 |
| AdGuard DNS Family | 멀웨어 + 성인 + 광고 | 무료/유료 |
| NextDNS | 모든 카테고리 커스텀 | 무료 30만 쿼리/월 + 유료 |
RPZ는 zone 파일 형식으로 정책을 표현. example.com을 차단하려면.
$TTL 60
@ SOA rpz.local. admin.local. (1 1h 15m 30d 2h)
NS rpz.local.
; example.com 및 모든 서브도메인을 NXDOMAIN으로
example.com CNAME .
*.example.com CNAME .
; some-malware.example.org를 walled-garden IP로
some-malware.example.org CNAME walled-garden.local.
BIND9에서 named.conf로 RPZ를 활성화한 뒤, dig @localhost example.com은 NXDOMAIN을 받는다.
8장 · Cloudflare 1.1.1.1 — 가장 인용되는 공용 리졸버
Cloudflare 1.1.1.1은 2018년 4월 1일 출시(만우절이지만 진짜 서비스). APNIC과 협력해 1.1.1.0/24를 받았고, "no logging of queries, no selling"을 KPMG 감사로 매년 증명한다.
엔드포인트가 세 종류로 갈린다.
| IP | 정책 | 용도 |
|---|---|---|
| 1.1.1.1 / 1.0.0.1 | 무필터 (순수 리졸버) | 일반 |
| 1.1.1.2 / 1.0.0.2 | 멀웨어 차단 | 보안 강화 |
| 1.1.1.3 / 1.0.0.3 | 멀웨어 + 성인 콘텐츠 차단 | 가정/학교 |
IPv6도 2606:4700:4700::1111, ::1001, ::1112, ::1113로 동일 정책 매핑.
DoH/DoT/DoQ 모두 지원하며, 1.1.1.1 자체가 Anycast로 300개 이상 PoP에 떠 있어 평균 P50이 한 자릿수 ms. 한국 사용자의 경우 인천/오사카/싱가포르 PoP가 잡힌다.
가장 큰 비판은 "중앙집중". 전 세계 DNS 쿼리의 상당 부분이 Cloudflare를 통한다는 사실 자체가 일종의 단일 실패점/관측점이다. 그래서 옹호자도 "Cloudflare 단독보다 Quad9, dns0.eu와 분산하라"고 권한다.
9장 · Quad9 9.9.9.9 — 스위스, 무로깅, 멀웨어 차단
Quad9는 2017년 IBM Security X-Force, PCH(Packet Clearing House), GCA(Global Cyber Alliance)가 공동 출범한 비영리 리졸버다. 스위스 비영리 재단으로 운영(2021년 이전), GDPR과 스위스 데이터 보호법의 보호를 받는다.
엔드포인트.
| IP | 정책 |
|---|---|
| 9.9.9.9 / 149.112.112.112 | 보안 차단(멀웨어 RPZ) + DNSSEC 검증 + 무로깅 |
| 9.9.9.10 / 149.112.112.10 | 보안 차단 없음, 가장 빠름 |
| 9.9.9.11 / 149.112.112.11 | 보안 차단 + ECS(EDNS Client Subnet, CDN에 위치 힌트) |
IPv6: 2620:fe::fe, 2620:fe::9.
Quad9의 차별점은 두 가지. (1) 무로깅 정책의 법적 보호 — 스위스 사법 관할은 미국/영국보다 NSL이나 비밀 영장에 강하다. (2) 17개 멀웨어 인텔리전스 피드 통합 — IBM, Anomali, Domain Tools, Proofpoint 등의 피드를 실시간 머지해 차단 리스트로 만든다.
성능은 Cloudflare보다 조금 느리다(P50 15~20ms 한국). 그러나 보안 차단을 켠 상태로 거의 0 false positive가 강점. 기업/학교에서 가장 자주 권장된다.
10장 · Google 8.8.8.8 — 빠르지만 로그한다
Google Public DNS(2009 출시)는 가장 오래된 공용 리졸버 중 하나. 8.8.8.8과 8.8.4.4 두 IP는 거의 모든 네트워크 엔지니어가 외운다.
장점: 압도적인 글로벌 카바리지, DNS64 지원(IPv6 only 네트워크에서 IPv4 호환), DoH/DoT 지원.
단점: 로깅한다. Google은 일시적 로그(24~48시간 IP 포함)와 영구 로그(IP 익명화 후)로 나누어 보관한다고 명시한다. 광고에 직접 쓰지는 않는다고 하지만, Cloudflare/Quad9의 "무로깅" 정책과는 명확히 다르다.
2026년의 현실: 빠르고 안정적이지만, 프라이버시가 필요하면 1순위는 아니다. ISP 기본 DNS가 너무 느릴 때의 fallback으로 많이 쓰인다.
11장 · AdGuard DNS — 광고 차단이 기본
AdGuard DNS는 키프로스 기반 AdGuard Software가 운영하며, 광고 차단을 DNS 레벨에서 한다. 광고 도메인을 NXDOMAIN으로 떨어뜨리니, 브라우저 광고 차단기 없이도 모든 앱에서 광고가 사라진다.
엔드포인트.
| IP | 정책 |
|---|---|
| 94.140.14.14 / 94.140.15.15 | 광고 + 추적 차단(기본) |
| 94.140.14.15 / 94.140.15.16 | 가족 모드(광고 + 추적 + 성인) |
| 94.140.14.140 / 94.140.15.141 | 무필터 |
DoH https://dns.adguard-dns.com/dns-query, DoT dns.adguard-dns.com, DoQ quic://dns.adguard-dns.com.
광고 차단 DNS의 한계도 분명하다. 퍼스트 파티 광고(서비스 자체 도메인에서 서빙)는 못 막고, DOM 레벨 추적 스크립트도 못 막는다. 그래서 AdGuard도 별도 브라우저 확장과의 조합을 권장한다.
12장 · NextDNS — 커스터마이즈 + 분석
NextDNS는 2019년 출시된 프랑스 스타트업이 만든 공용 리졸버다. 차별점은 프로파일 단위 커스터마이즈.
가입 후 발급받는 ID(예: abcdef)를 엔드포인트로 사용.
https://dns.nextdns.io/abcdef
abcdef.dns.nextdns.io (DoT/DoQ)
대시보드에서 100개+ 차단 리스트(EasyList, OISD, StevenBlack, Hagezi 등), 카테고리 차단(소셜미디어, 도박, 성인, 멀웨어), 로그 보관 기간(0/24h/3개월/이상), 위치별 보관(EU/US/스위스) 모두 선택 가능.
가격: 30만 쿼리/월까지 무료, 그 이상은 19.90/년(가족, 무제한 디바이스).
NextDNS의 진짜 가치는 분석 대시보드. 어떤 디바이스가, 어떤 도메인을, 몇 번 쿼리했는지가 한눈에 보인다. 가족 모드에서 자녀 디바이스가 새로 학습한 추적 도메인을 추적할 수 있다.
13장 · ControlD — 빠르고 라우팅 가능한 리졸버
ControlD는 캐나다 Windscribe VPN 팀이 만든 리졸버. NextDNS와 비슷한 컨셉이지만 속도와 트래픽 라우팅에 더 무게.
차별점:
- Free Resolvers:
76.76.2.0시리즈로 다양한 사전 정의 프로파일(p0/p1/p2/...). - Custom Profiles: 프록시 라우팅 — "Netflix는 미국 IP로", "BBC는 영국 IP로" 같은 식으로 도메인별 SOCKS5 라우팅을 DNS 응답으로 조작.
- POP: 100+ 글로벌, 평균 P50 한 자릿수 ms.
DoH 엔드포인트: https://dns.controld.com/p2 (멀웨어 + 광고 + 추적 + 소셜미디어), 무료.
ControlD의 약점은 신생. 2020년 시작이라 NextDNS 만큼 커뮤니티 리스트 라이브러리가 풍부하지는 않다. 그러나 속도와 라우팅의 조합은 독특하다.
14장 · Mullvad DNS — VPN 회사의 DNS
Mullvad는 스웨덴 VPN 회사. 2022년 11월 공용 DNS를 별도 출시했고, "계정 없이 익명으로 쓸 수 있는 가장 강한 프라이버시 DNS"를 표방한다.
엔드포인트와 정책.
| 호스트네임 | 정책 |
|---|---|
dns.mullvad.net | 무필터 |
adblock.dns.mullvad.net | 광고 차단 |
base.dns.mullvad.net | 광고 + 추적 |
extended.dns.mullvad.net | 광고 + 추적 + 소셜미디어 |
family.dns.mullvad.net | 광고 + 추적 + 성인 |
all.dns.mullvad.net | 모두 차단 |
DoH/DoT/DoQ 모두 지원. IP는 변동될 수 있으니 호스트네임으로 설정하는 것이 권장.
Mullvad의 강점은 법적/기술적 무로깅. 스웨덴은 EU지만 데이터 보존법이 약하고, Mullvad는 2020년 스웨덴 경찰 압수 사건에서 "서버에 보관된 데이터가 없어 응할 게 없다"를 실증했다.
15장 · dns0.eu — EU 공동 리졸버 (무료)
dns0.eu는 2023년 출시된 비영리 EU 기반 리졸버. 본부는 프랑스 파리, GDPR 강성 적용, EU 자금/스폰서.
엔드포인트.
| IP | 정책 |
|---|---|
| 193.110.81.0 / 185.253.5.0 | 무필터 |
https://zero.dns0.eu | 보안 차단 (멀웨어/피싱/맥주광고) |
https://kids.dns0.eu | 가족 모드 |
DoH/DoT/DoQ 지원. PoP는 유럽 위주.
dns0.eu는 유럽 디지털 주권 흐름의 일부다. Cloudflare/Google에 의존하지 않는 EU-내부 리졸버를 목표한다. 한국/일본 사용자에게는 PoP가 적어 느릴 수 있지만, 선택의 다양성 차원에서 의미가 크다.
16장 · Authoritative DNS — Cloudflare DNS vs Route 53 vs Cloud DNS vs Azure DNS vs NS1
권한 DNS(우리 zone을 서빙하는 곳)는 시장이 갈린다.
| 제공자 | 가격 모델 | 강점 | 약점 |
|---|---|---|---|
| Cloudflare DNS | 도메인 무료(웹사이트는 기본 플랜에 포함) | Anycast 300+ PoP, 빠른 전파, 직관 UI | 고급 트래픽 정책은 Enterprise 한정 |
| AWS Route 53 | 0.40/100만 쿼리 | AWS 통합(alias, weighted, latency, geo), health check | UI 답답함, 가격이 트래픽에 비례 |
| GCP Cloud DNS | 0.40/100만 쿼리 | GCP 통합, peering DNS | AWS만큼 풍부하지 않음 |
| Azure DNS | $0.50/zone/월 + 비슷한 쿼리 가격 | Azure 통합, Private DNS는 별도 SKU | UX 평이 갈림 |
| NS1 (IBM) | 엔터프라이즈 | Pulsar(실시간 RUM 기반 라우팅), Filter Chain | 가격, 학습 곡선 |
| DNS Made Easy | $30/년~ | 짧은 TTL에 강함, 100% uptime SLA | 부가 기능 적음 |
대부분의 스타트업은 Cloudflare DNS(웹), 클라우드 라이프 사이클이 깊은 팀은 자기 클라우드의 DNS(Route 53, Cloud DNS, Azure DNS). geo routing이나 weighted routing이 정말 필요한 팀(글로벌 SaaS, 게임)은 NS1.
Cloudflare DNS는 무료지만 권한 DNS로서 정말 빠르다. 2026년 dnsperf 글로벌 권한 DNS 응답 시간에서 Cloudflare는 보통 P50 10~12ms로 1위 또는 2위(NS1과 경쟁).
17장 · Route 53 — AWS 통합의 끝판왕
Route 53은 AWS의 권한 DNS + 도메인 등록 + health check + traffic policy를 하나로 묶은 서비스. 출시 2010년.
가격 — zone 단위(0.40/100만).
라우팅 정책이 풍부하다.
| 정책 | 의미 |
|---|---|
| Simple | 단일 응답 |
| Weighted | 가중치 비율로 분기(A/B, 카나리) |
| Latency-based | AWS 리전 기준 최저 지연 라우팅 |
| Failover | primary/secondary, health check 기반 |
| Geolocation | 클라이언트 위치 기반(국가/대륙) |
| Geoproximity | Traffic Flow, bias로 거리 조정 |
| Multivalue answer | 최대 8개 IP, health check 통과한 것만 |
| IP-based | 클라이언트 CIDR 기준 |
Terraform으로 다중 정책 zone.
resource "aws_route53_zone" "main" {
name = "example.com"
}
resource "aws_route53_record" "api" {
zone_id = aws_route53_zone.main.zone_id
name = "api.example.com"
type = "A"
set_identifier = "us-east-1"
latency_routing_policy {
region = "us-east-1"
}
alias {
name = aws_lb.us_east.dns_name
zone_id = aws_lb.us_east.zone_id
evaluate_target_health = true
}
}
Route 53의 약점은 UI의 답답함과 가격의 누적. zone이 수십 개로 늘면 월 수십 달러는 그냥 나간다. 그래도 AWS 락인 팀에는 거의 디폴트.
18장 · Self-hosted DNS — PowerDNS · BIND9 · CoreDNS · Knot · Unbound · dnsmasq
권한이든 재귀든 자체 호스팅 옵션은 풍부하다.
| 도구 | 종류 | 언어 | 특징 |
|---|---|---|---|
| BIND9 | 권한 + 재귀 | C | 클래식, ISC 관리, RPZ 원조 |
| PowerDNS Authoritative | 권한 | C++ | DB 백엔드(MySQL/PostgreSQL), API 풍부, GeoIP 모듈 |
| PowerDNS Recursor | 재귀 | C++ | Lua 스크립팅, 빠름 |
| CoreDNS | 권한 + 재귀 | Go | 플러그인 체인 구조, K8s 클러스터 DNS 기본 |
| Knot DNS | 권한 | C | 체코 CZ.NIC, 매우 빠름, 대형 zone 최적 |
| Knot Resolver | 재귀 | C | 같은 팀의 재귀 리졸버, DNSSEC 강 |
| Unbound | 재귀 | C | NLnet Labs, DNSSEC 강, Stubby와 페어 |
| dnsmasq | 포워더/캐시 | C | 작고 가벼움, 라우터/소형 네트워크에 흔함 |
CoreDNS의 Corefile 예시 — K8s 내부 DNS 그대로.
.:53 {
errors
health {
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
prometheus :9153
forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}
dnsmasq는 holiday router/Pi-hole의 코어다. 100KB 바이너리로 DHCP + DNS forwarder + TFTP까지 한다.
19장 · Pi-hole 6 — 가정용 DNS 싱크홀
Pi-hole은 2015년 GitHub 프로젝트로 시작한 가정용 DNS 차단 서버. Raspberry Pi 위에 띄우는 것으로 유명해졌고, 2025년 출시된 Pi-hole 6(2024년 베타)는 PHP 웹 UI를 버리고 all-Go REST API + 새 웹 UI로 갈아엎었다.
원리는 단순. (1) dnsmasq 기반 forwarder로 동작, (2) 광고/추적/멀웨어 도메인을 NXDOMAIN으로 응답, (3) 그 외 쿼리는 상위 리졸버(Cloudflare, Quad9 등)에 위임, (4) 가족 단위 화이트리스트/블랙리스트 관리.
도커로 1분 설치.
docker run -d \
--name pihole \
-p 53:53/tcp -p 53:53/udp \
-p 80:80/tcp \
-e TZ=Asia/Seoul \
-e WEBPASSWORD=changeme \
-v $PWD/etc-pihole:/etc/pihole \
-v $PWD/etc-dnsmasq.d:/etc/dnsmasq.d \
--restart=unless-stopped \
pihole/pihole:latest
라우터 DHCP에서 DNS 서버를 Pi-hole IP로 변경하면 모든 가정 디바이스가 Pi-hole을 거친다. 광고 차단율 30~50%, 모바일 앱 광고까지 막힌다.
한계: HTTPS 페이지 내 광고 빈 자리는 차단되지만 페이지 레이아웃 깨짐이 가끔 발생. DoH로 도는 클라이언트(Firefox, Chrome 일부)는 Pi-hole을 우회한다 — 그래서 라우터에서 DoH 차단 또는 강제 redirect가 필요.
20장 · AdGuard Home — Pi-hole의 현대적 대안
AdGuard Home은 같은 영역의 Go 단일 바이너리. Pi-hole이 dnsmasq + PHP 조합인 데 비해 AdGuard Home은 한 바이너리에 다 들어있다.
차별점:
- DoH/DoT/DoQ 업스트림 내장 — Pi-hole에서 cloudflared 사이드카 없이도 된다.
- 암호화된 DNS 서버 모드 — 외부 클라이언트가 우리 AdGuard Home에 DoH/DoT로 접속하게도 만든다.
- 사용자별 정책 — 디바이스/IP별 다른 필터 리스트, 시간대별 차단(어린이 디바이스 22시 이후 SNS 차단 같은).
- DHCP 내장(선택).
Docker 설치.
docker run --name adguardhome \
--restart unless-stopped \
-v $PWD/work:/opt/adguardhome/work \
-v $PWD/conf:/opt/adguardhome/conf \
-p 53:53/tcp -p 53:53/udp \
-p 80:80/tcp -p 443:443/tcp -p 443:443/udp \
-p 3000:3000/tcp \
-p 853:853/tcp \
-p 784:784/udp \
-d adguard/adguardhome
Pi-hole vs AdGuard Home — 둘 다 검증됐다. Pi-hole이 커뮤니티/문서가 더 크고, AdGuard Home이 기능과 UX가 더 현대적. 2026년 신규 설치라면 AdGuard Home을 더 자주 본다.
21장 · Technitium · Unbound + Stubby · Blocky — 마이너 알찬 옵션
Pi-hole/AdGuard Home 이외의 옵션도 있다.
- Technitium DNS Server: .NET 기반, 풀 권한 + 재귀 + 차단 + 캐시 + DoH/DoT/DoQ 서버까지. UI가 매우 풍부, 자체 호스팅 권한 zone(예:
home.local)을 운영하면서 동시에 가정 차단 리졸버를 돌릴 때 강력. - Unbound + Stubby: NLnet Labs 정통. Unbound는 자체 재귀(외부 리졸버 안 거치고 루트부터 따라감), Stubby는 DoT 클라이언트 데몬. 둘을 묶으면 "외부 리졸버를 신뢰하지 않는 완전 자가 호스팅"이 가능하다.
- Blocky: Go 기반 작은 DNS 프록시. Pi-hole보다 가볍고, Prometheus/Grafana 메트릭이 우아. K8s에 띄워 사내 차단 리졸버로 쓰는 사례도 있다.
Unbound를 자체 재귀로 띄우는 최소 설정 — /etc/unbound/unbound.conf.
server:
interface: 127.0.0.1
interface: ::1
access-control: 127.0.0.0/8 allow
access-control: ::1 allow
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
hide-identity: yes
hide-version: yes
qname-minimisation: yes
harden-glue: yes
harden-dnssec-stripped: yes
use-caps-for-id: yes
prefetch: yes
이러면 1.1.1.1조차 안 거치고 클라이언트가 루트부터 직접 따라가 답을 받는다. 가장 분권적인 옵션.
22장 · 라우터의 프라이버시 DNS — OpenWRT · Mikrotik · UniFi
OS/디바이스가 아니라 라우터 단에서 DNS를 강제하면 모든 가정 트래픽이 한 번에 보호된다.
- OpenWRT + dnsmasq + https-dns-proxy: OpenWRT 기본 dnsmasq를 forwarder로 두고,
https-dns-proxy패키지로 DoH 업스트림(1.1.1.1, 9.9.9.9 등) 사용.luci-app-https-dns-proxyGUI로 클릭 설정. - Mikrotik RouterOS 7.x:
/ip dns기본 모드 외에/ip dns/set use-doh-server=https://...명령으로 RouterOS 7부터 정식 DoH 지원. - Ubiquiti UniFi: UDM/UDR Pro에서 Threat Management로 DNS 카테고리 차단, OS 3.x부터 DNS over HTTPS도 일부 지원.
OpenWRT에서 1.1.1.1 DoH 강제.
opkg update
opkg install https-dns-proxy luci-app-https-dns-proxy
uci set https-dns-proxy.@https-dns-proxy[0].bootstrap_dns='1.1.1.1,1.0.0.1'
uci set https-dns-proxy.@https-dns-proxy[0].resolver_url='https://cloudflare-dns.com/dns-query'
uci commit https-dns-proxy
service https-dns-proxy restart
라우터 차원의 강제는 모바일 DoH 우회를 줄인다. Firefox나 Chrome이 자체 DoH를 켜 있으면 라우터를 그냥 지나가는데, 일부 라우터는 알려진 DoH 호스트를 차단해 강제로 시스템 DNS로 돌린다.
23장 · 듀얼 스택 / IPv6 / HTTPS · SVCB 레코드 (RFC 9460)
2026년의 DNS는 레코드 타입도 진화 중. HTTPS 레코드(RFC 9460, 2023)는 도메인 하나 조회로 IP+ALPN+ECH+포트 힌트를 다 받는다.
example.com. 3600 IN HTTPS 1 . alpn="h3,h2" ipv4hint=93.184.216.34 ipv6hint=2606:2800:220:1::1
브라우저가 이 한 줄을 받으면 곧장 HTTP/3로 핸드셰이크 시작. A/AAAA를 별도로 또 안 물어도 된다. ECH(Encrypted Client Hello) 키도 이 레코드에 들어간다 — SNI 평문 노출까지 막는다.
Cloudflare DNS, Route 53 모두 HTTPS/SVCB 레코드 입력 지원. iOS 14+/Safari, Chrome 100+에서 자동 활용.
IPv6 측면 — 듀얼 스택 zone은 A + AAAA를 같이 가지고, 클라이언트는 happy eyeballs(RFC 8305)로 더 빠른 쪽을 선택한다. 2026년 대형 사이트의 IPv6 활성율은 50%대로 올라왔다.
24장 · 한국 / 일본 DNS — KT · SK · LG · IIJ · NTT · Naver · JPDNS
한국 통신사 DNS.
| 통신사 | DNS IP |
|---|---|
| KT | 168.126.63.1 / 168.126.63.2 |
| SK Broadband | 219.250.36.130 / 210.220.163.82 |
| LG U+ | 164.124.101.2 / 203.248.252.2 |
| Naver Public DNS | 다시 작동 (dns.naver.com 계열, 자체 정책) |
KT 168.126.63.1은 한국에서 가장 자주 외워지는 IP다. 그러나 DoH/DoT를 공식 제공하지 않고, **국가 차단(warning.or.kr)**을 강제로 SNI 검사/DNS 응답으로 우회/리다이렉트한다. 프라이버시가 필요하면 KT DNS를 그대로 쓰지 말고 1.1.1.1이나 9.9.9.9로 교체 권장.
일본 통신사 DNS.
| 통신사 | DNS IP |
|---|---|
| NTT 도코모 모바일 | 사용자 APN 자동 |
| KDDI / au | 사용자 APN 자동 |
| SoftBank | 사용자 APN 자동 |
| IIJ (Internet Initiative Japan) | 210.130.0.5 / 210.130.1.5 |
| JPNIC / JPDNS 공개 캐시 | 일부 IIJ/NTT 공유 |
일본은 한국보다 ISP DNS 의존도가 낮고, IIJ 같은 도매 ISP가 안정적인 공용 DNS를 제공한다. JPDNS(JPNIC 운영 .jp 권한)는 .jp TLD 답을 보장.
한·일 사용자 모두에게 권장: 1차 1.1.1.1 + 2차 9.9.9.9 조합으로 ISP DNS를 우회. 단, 일부 국가 차단/통신사 부가 서비스는 ISP DNS에 의존하니 차단/이슈가 있을 때 임시로 ISP DNS 복귀.
25장 · DNS 공격 — 캐시 포이즈닝, 터널링, DGA, 리바인딩
DNS는 공격 표면이 넓다. 대표적 4가지.
- 캐시 포이즈닝(Dan Kaminsky 2008): 재귀 리졸버 캐시에 가짜 응답을 채워 모든 클라이언트를 잘못된 IP로 보내기. 방어: 소스 포트 랜덤화, 0x20 인코딩, DNSSEC.
- DNS 터널링: 평문 DNS 위에 임의 데이터를 인코딩해 방화벽 우회. 멀웨어 C2(iodine, dnscat2)에서 흔함. 방어: DNS firewall, 쿼리 빈도/크기 이상 탐지.
- DGA (Domain Generation Algorithm): 멀웨어가 매일 수천 개 임의 도메인을 만들어 C2와 통신 시도, 일부만 진짜로 등록. 방어: ML 기반 DGA 도메인 탐지, RPZ.
- DNS 리바인딩: 짧은 TTL로 같은 도메인이 처음엔 공용 IP, 다음엔 사설 IP를 응답하게 만들어 SOP를 우회. 방어: 사설 IP 응답 거부(Pi-hole/dnsmasq의
--stop-dns-rebind).
DoH/DoT는 공격 표면을 줄이지만 없애지는 않는다. 캐시 포이즈닝은 평문 53 포트만 해당, 그러나 터널링과 DGA는 채널 암호화와 무관하다.
26장 · 의사결정 체크리스트 — 우리 팀 / 우리 집은 뭘 쓸까
개인/가정
- 모바일/노트북 단일 디바이스만 보호 → OS의 Private DNS(
1dot1dot1dot1.cloudflare-dns.com또는dns.quad9.net). - 가족 전체 + 광고 차단 → 라즈베리파이/리눅스 박스에 Pi-hole 6 또는 AdGuard Home, 라우터 DHCP에 그 IP를 DNS로.
- 외부 리졸버도 신뢰 안 함 → Unbound 자체 재귀, 옵션으로 Stubby의 DoT.
- 분석 대시보드 원함 → NextDNS 또는 ControlD.
스타트업/서비스 권한 DNS
- 정적 사이트/SaaS, 비용 0 우선 → Cloudflare DNS.
- AWS 락인 → Route 53, alias 레코드와 latency routing 활용.
- 멀티 클라우드/엣지 라우팅 → NS1 또는 Cloudflare DNS의 Load Balancing.
- 짧은 TTL의 health-check 기반 failover → Route 53 + health check, 또는 NS1 Filter Chain.
엔터프라이즈
- 사내 모든 디바이스의 DNS firewall → Cloudflare Gateway 또는 Cisco Umbrella.
- 자체 DC, 자체 캐시 운영 → PowerDNS + Unbound.
- K8s 클러스터 내부 DNS → CoreDNS(EKS/GKE/AKS 기본).
- 멀티 리전 권한 DNS, geo routing → NS1.
기본 룰: ISP 기본 DNS는 가능한 한 빨리 벗어나라. 1.1.1.1 + 9.9.9.9 듀얼만 해도 평균 사용자에게는 즉시 체감이 된다.
에필로그 — DNS는 인터넷의 신뢰 평면이다
2026년 DNS의 진짜 교훈은 "DNS는 인프라가 아니라 신뢰 평면" 이다. 누구를 신뢰해 이름을 IP로 바꿀 것인가, 그 신뢰가 어디서 기록되고 어디서 차단되며 어디서 위조되는가 — 이게 DNS 선택의 전부다.
도구는 단순하다. Cloudflare 1.1.1.1 한 줄을 OS DNS에 넣으면 ISP 평문 노출은 끝난다. Pi-hole/AdGuard Home을 가정 라우터 뒤에 놓으면 광고도 끝난다. 그러나 그 단순한 한 줄을 누구를 위해, 누구를 신뢰해서 적었는가는 본인이 안다.
다음 글 후보: Cloudflare Workers + DNS — Cloudflare를 끝까지 굴리기, DNSSEC을 진짜로 켜는 법 — .com/.io/.kr 위임 실전, HTTPS · SVCB 레코드와 ECH — 2026년 새 핸드셰이크의 모든 것.
"DNS를 고른다는 것은 '내가 어디에 처음 정보를 흘려도 괜찮은가'를 고르는 일이다."
— DNS 프로바이더 & 프라이버시 2026, 끝.
참고 / References
- RFC 8484 — DNS Queries over HTTPS (DoH)
- RFC 7858 — DNS over TLS (DoT)
- RFC 9250 — DNS over QUIC (DoQ)
- RFC 9230 — Oblivious DNS over HTTPS (ODoH)
- RFC 9460 — Service Binding and Parameter Specification (SVCB / HTTPS records)
- RFC 4033 — DNSSEC Introduction and Requirements
- Cloudflare 1.1.1.1
- Cloudflare 1.1.1.1 for Families
- Cloudflare Trust Hub — 1.1.1.1 audits
- Quad9
- Google Public DNS
- OpenDNS / Cisco Umbrella
- AdGuard DNS
- NextDNS
- ControlD
- Mullvad DNS
- dns0.eu
- AWS Route 53 Documentation
- Google Cloud DNS
- Azure DNS
- NS1 (IBM)
- PowerDNS
- BIND9 — ISC
- CoreDNS
- Knot DNS — CZ.NIC
- Unbound — NLnet Labs
- dnsmasq
- Pi-hole
- AdGuard Home
- Technitium DNS Server
- Blocky — DNS proxy
- Stubby — DoT client
- OpenWRT https-dns-proxy
- DNSperf — public DNS benchmarks
- APNIC — 1.1.1.1 history