요약: 기존 DNS는 모든 "example.com의 IP가 뭐야?" 쿼리를 평문 UDP로 전송하므로 네트워크 경로상의 누구나 읽거나 수정할 수 있습니다. DoH는 이 쿼리를 HTTPS로 감싸기 때문에 네트워크 관찰자는 더 이상 도메인 이름을 볼 수 없고 가짜 응답을 주입할 수도 없습니다. 이는 세 가지 실질적인 문제(ISP의 DNS 엿보기, 카페 WiFi의 DNS 주입, 일부 국가 수준의 DNS 검열)를 해결하는 동시에 두 가지 새로운 문제를 만들어냅니다(자녀 보호 기능과 기업 보안이 작동을 멈추고, 선택한 DoH 공급자에게 방문하는 모든 도메인을 알려주게 됩니다). DoH는 "더 사적"이거나 "덜 사적"인 것이 아닙니다 — 다르게 사적인 것이며, 어떤 트레이드오프가 자신의 위협 모델에 맞는지가 관건입니다.
DoH가 실제로 무엇인지 (그리고 무엇을 대체하는지)
기존 DNS는 아직도 운용 중인 가장 오래된 프로토콜 중 하나입니다. 1983년에 만들어졌고 HTTPS가 보편화되기 이전의 것으로, "네트워크상의 모든 사람은 대략 신뢰할 수 있다"는 가정이 합리적이었던 시절에 설계되었습니다. 작동 방식: 기기가 설정된 DNS 리졸버(보통 ISP 것이거나, 변경했다면 8.8.8.8 / 1.1.1.1)의 포트 53으로 UDP 패킷을 보냅니다. 패킷 본문에는 평문으로 "example.com의 A 레코드를 주세요"라고 적혀 있습니다. 리졸버는 IP를 평문으로 응답합니다. 세 가지 속성을 짚어볼 만합니다:
- 네트워크 경로상의 누구나 쿼리를 읽을 수 있습니다. ISP, 카페 WiFi, 로컬 네트워크에서 tcpdump를 실행 중인 누구든 — 조회하는 모든 도메인 이름이 노출됩니다.
- 네트워크 경로상의 누구나 응답을 위조할 수 있습니다. 정상 리졸버보다 먼저 기기에 가짜 응답을 보내면 트래픽이 다른 곳으로 유도됩니다. 일부 캡티브 포털과 검열 체계가 이 방식으로 작동합니다.
- 설정된 리졸버는 모든 쿼리를 봅니다. DNS를 운영하는 주체는 방문하는 모든 도메인을 순서와 시간까지 파악합니다.
DoH(RFC 8484, 2018년)는 #1과 #2를 바꿉니다: 쿼리가 리졸버까지 TLS 암호화된 HTTPS 연결 안에서 이동합니다. 경로상의 관찰자는 HTTPS 바이트만 보고 도메인 이름은 알 수 없습니다. 위조는 HTTPS 응답을 위조하는 것만큼 어려워집니다(즉, 리졸버의 TLS 인증서 없이는 사실상 불가능합니다). #3은 바뀌지 않습니다 — 리졸버는 여전히 쿼리를 보는데, 쿼리가 리졸버에게 보내지기 때문입니다. DoH는 신뢰 경계를 이동시킬 뿐 제거하지 않습니다.
DoT(DNS-over-TLS, RFC 7858)는 HTTPS 포트 443을 타는 대신 전용 포트(853)에서 동일한 작업을 합니다. 기능적으로는 동등한 프라이버시 속성을 가지지만 운영상 다릅니다. DoH는 임의의 HTTPS를 차단하면 인터넷 전체가 끊기기 때문에 네트워크 수준에서 차단하기가 더 어렵습니다. DoT는 네트워크 운영자가 선택적으로 강제하거나 차단하기가 더 쉽습니다. DoH가 배포 경쟁에서 이긴 주된 이유는 Mozilla와 Google이 브라우저에 기본값으로 내장했기 때문입니다.
DoH가 실제로 해결하는 세 가지
1. ISP의 DNS 엿보기
미국에서는 2017년부터 ISP가 명시적 동의 없이 브라우징 데이터를 판매하는 것이 법적으로 허용되어 있으며, DNS 쿼리 로그도 수집 대상에 포함됩니다. 다른 나라에서는 법적 체계가 다양하며, 일부는 의무적 데이터 보존에 DNS가 이름으로 포함됩니다. 어느 쪽이든: ISP의 리졸버를 사용하고 있다면 ISP는 타임스탬프까지 포함된 방문 사이트의 완전한 로그를 보유합니다.
비(非)ISP 리졸버로의 DoH(Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9, NextDNS, AdGuard DNS, Mullvad의 DNS, VPN 내부의 리졸버)는 ISP 관점에서 이를 완전히 차단합니다. ISP는 여전히 특정 IP 주소로의 TLS 연결을 볼 수 있고, 그 IP들(그리고 아래에서 설명하는 TLS 핸드셰이크의 SNI)로부터 호스트명을 추론할 수 있는 경우도 많습니다 — 하지만 더 이상 깔끔하게 검색 가능한 DNS 로그는 갖지 못합니다. 신뢰는 ISP에서 DoH 리졸버를 운영하는 주체로 이동합니다.
2. 카페 WiFi의 DNS 주입
공용 WiFi의 캡티브 포털은 DNS 쿼리(와 HTTP 요청)를 가로채서 네트워크 약관에 동의할 때까지 포털 페이지로 리다이렉트하는 방식으로 작동합니다. 그 메커니즘 — DNS를 가로채는 것 — 은 악의적인 DNS 주입과 같은 구조입니다. 적대적인 네트워크는 DNS 응답을 재작성하여 피싱 페이지나 광고 주입 프록시로 유도할 수 있습니다. 평문 DNS는 쉬운 공격 표면을 제공하지만, DoH는 이를 차단합니다.
이것은 DoH와 VPN 터널이 겹치는 경우 중 하나입니다. VPN은 DNS를 포함한 모든 것을 암호화된 바이트를 통해 터널링하고, DoH만 사용하면 DNS 쿼리만 터널링됩니다. 적대적인 네트워크에서는 두 가지 개입 모두 DNS 주입 유형의 공격을 막지만, 다른 레이어를 처리합니다. 위협 환경은 2026년 공용 WiFi 공격에서 다루었습니다.
3. 일부 국가 수준의 DNS 검열
여러 검열 체계가 DNS 수준 차단을 구현합니다: "blocked-site.com의 IP가 뭐야?"라고 물으면 국가 지정 리졸버가 NXDOMAIN을 반환하거나 "이 사이트는 차단됩니다" 페이지로 리다이렉트합니다. 검열 관할 밖의 리졸버로의 DoH는 이 특정 메커니즘을 무력화합니다. 검열 네트워크는 DoH 리졸버로의 HTTPS만 보고 내부의 쿼리는 보지 못하기 때문입니다.
단서: 이는 검열 측이 확대하기 전까지만 작동합니다. 정교한 검열 체계(중국, 이란)는 DoH 리졸버를 IP로 직접 차단하거나, 국가 발급 루트 CA를 통해 HTTPS 가로채기를 강제하거나, SNI 기반 차단을 사용합니다(다음 섹션 참조). DoH는 단순한 DNS 검열을 무력화하지만, 작심한 국가 수준의 검열은 막지 못합니다.
DoH가 도움이 되지 않는 세 가지
1. TLS 핸드셰이크의 SNI 누출
이것은 대부분의 글이 건너뛰는 함정입니다. HTTPS로 "example.com"에 접속할 때 브라우저는 TLS 핸드셰이크 중에 호스트명을 평문으로 보냅니다 — 구체적으로는 SNI(Server Name Indication) 확장에서입니다. 이유: 하나의 IP가 TLS 종료를 통해 여러 도메인을 서비스하는 경우가 많으므로, 암호화된 세션이 시작되기 전에 서버가 어떤 인증서를 제시할지 알아야 합니다. SNI는 설계상 평문입니다.
실질적 영향: DoH를 사용하더라도 네트워크상의 관찰자는 SNI를 통해 어떤 호스트명에 접속하는지 볼 수 있습니다. DNS 엿보기 수정은 부분적입니다. 완화책은 ECH(Encrypted Client Hello)입니다 — SNI를 암호화하는 비교적 새로운 TLS 확장입니다. Cloudflare는 2023년에 자사 네트워크 뒤의 사이트에 ECH를 켰고 Firefox와 Chrome도 지원을 추가했지만, Cloudflare 외에서의 도입은 아직 산발적입니다. ECH가 보편화될 때까지 DoH는 "누가 내 방문 사이트를 볼 수 있나" 질문의 절반만 해결합니다.
2. 목적지의 IP 기반 식별
DoH와 ECH를 함께 사용하더라도 TLS 연결은 여전히 특정 목적지 IP로 향합니다. 전용 인프라를 가진 사이트(은행, 틈새 서비스)의 경우, DNS나 SNI 없이도 목적지 IP가 사이트의 거의 완벽한 식별자가 됩니다. 주요 CDN(Cloudflare, Fastly, AWS CloudFront) 뒤의 사이트는 수백만 개의 사이트가 몇 개의 IP를 공유하므로 IP 기반 식별이 더 모호합니다 — 하지만 가장 큰 사이트들은 여전히 고유한 인프라나 특징적인 트래픽 패턴을 가집니다.
DoH는 이 문제를 해결하지 못하며, 해결할 수도 없습니다. 어떤 사이트를 방문하는지 진짜로 알고 싶은 네트워크 관찰자는 IP-도메인 매핑 테이블을 만들어 트래픽 목적지를 조회할 수 있습니다. 완화책은 VPN 터널로, 목적지 IP 가시성을 로컬 네트워크에서 VPN 공급자로 이동시킵니다. 신뢰는 어딘가에 두어야만 합니다; DoH만으로는 네트워크 소유자에게 남겨집니다.
3. DoH 공급자가 ISP에 누출되던 모든 것을 봅니다
이것은 DoH 마케팅이 보통 슬쩍 넘어가는 트레이드오프입니다: DoH는 DNS 쿼리를 비공개로 만들지 않습니다; 가시성을 ISP에서 선택한 DoH 리졸버로 이동시킵니다. Cloudflare(1.1.1.1), Google(8.8.8.8), Quad9, NextDNS, AdGuard 및 다른 DoH 공급자들은 이전에 ISP가 그랬던 것과 정확히 같은 방식으로 모든 쿼리를 봅니다. 일부는 엄격한 무로그 정책을 발표하고, 일부는 집계 전용 로깅을 발표하며, 일부는 집계 데이터를 "연구 파트너"에게 판매합니다. DoH 공급자를 둘러싼 법적 체계는 ISP를 둘러싼 것만큼 중요합니다.
Cloudflare의 1.1.1.1은 24시간 후 로그를 삭제하고 DNS 데이터를 판매하지 않는다는 감사 보고서를 발표합니다. Google의 8.8.8.8은 명시된 보존 정책에 따라 (익명화를 통해) 무기한 쿼리를 로깅합니다. NextDNS는 "없음"부터 "내 계정, 내 선택"까지 자체 로그 보존을 설정할 수 있게 해줍니다. DoH 공급자 선택은 중요합니다; 어떤 신뢰 관계가 더 편안한지가 관건입니다 — 자국 법률 하의 ISP인지, 해당 공급자 국가 법률 하의 DoH 공급자인지.
DoH가 합법적으로 망가뜨리는 두 가지
1. 자녀 보호 기능과 가족 네트워크 필터링
대부분의 소비자용 자녀 보호 시스템은 라우터에서 DNS를 검사하거나 설정된 패밀리 필터 DNS 리졸버(OpenDNS Family Shield, Cleanbrowsing Family, NextDNS 패밀리 프로필)를 통해 작동합니다. 자녀의 기기가 이 리졸버를 사용하면 성인 콘텐츠, 도박 등의 조회가 NXDOMAIN을 반환합니다. 이 시스템은 기기가 애초에 자녀 보호 DNS 리졸버에 물어보는 것에 의존합니다.
브라우저 수준의 DoH(Firefox는 2019년에 미국 사용자에게 기본값으로 DoH를 활성화했고, Chrome과 Edge는 설정된 경우 DoH와 함께 OS 리졸버를 사용합니다)는 이 시스템을 자동으로 우회합니다. 브라우저는 Cloudflare나 Google에 직접 물어보고, 패밀리 필터 리졸버는 쿼리를 전혀 보지 못하며, 아이는 원하던 사이트에 접속합니다. 이것은 Mozilla 관점에서는 설계에 의한 것이고("네트워크가 검열하도록 내버려둬서는 안 된다"), 부모 관점에서는 우연한 결과입니다("돈 내고 산 필터가 그냥 멈췄다").
완화책은 존재하지만 번거롭습니다: OS 수준(브라우저가 아닌)에서 NextDNS 패밀리 프로필이나 OpenDNS Family Shield 같은 패밀리 인식 리졸버로 DoH를 설정한 다음, OS 선택을 통과할 수 있도록 브라우저 수준의 DoH를 비활성화합니다. Apple의 구성 프로필과 Windows 그룹 정책 모두 이를 지원합니다. 대부분의 가정에서는 실제로 마찰이 될 만큼 복잡합니다.
2. 기업 보안과 네트워크 수준 악성코드 차단
대부분의 기업 네트워크는 DNS 기반 보안을 구현합니다: 싱크홀 DNS 서버가 알려진 악성 도메인을 아무것도 아닌 것으로(또는 내부 경고 페이지로) 확인하여 악성코드 명령&제어, 피싱 리다이렉트, 알려진 엔드포인트로의 데이터 유출을 차단합니다. 기업 네트워크의 모든 기기가 기업 DNS를 사용하기 때문에 모든 조회가 필터링됩니다.
브라우저 수준의 DoH는 이를 자동으로 우회합니다. C2 서버에 접근이 차단되어야 할 감염된 브라우저가 Cloudflare를 통해 C2 호스트명을 DoH로 확인하고, 실제 IP를 얻어 직접 연결할 수 있습니다. 기업 IT 팀은 다음 중 하나로 대응했습니다: (a) 브라우저 정책으로 DoH 비활성화, (b) 보안 스택이 DoH 트래픽을 포함한 HTTPS 내부를 볼 수 있도록 완전한 TLS 검사 배포, (c) 방화벽에서 알려진 DoH 리졸버 IP 차단. 어느 것도 쉽지 않습니다 — 옵션 (a)는 집에서도 사용자가 평문 DNS를 쓰게 만들고, 옵션 (b)는 모든 기기에 루트 CA를 설치해야 하며, 옵션 (c)는 새로운 DoH 엔드포인트가 나타날 때마다 무너집니다.
각 플랫폼의 DoH — 실제 설정은?
iOS 14+ / iPadOS 14+: 설정 → 일반 → VPN 및 기기 관리 → DNS — 하지만 설치된 구성 프로필을 통해서만 가능합니다. iOS는 표준 설정 UI에서 DoH를 노출하지 않습니다; .mobileconfig 파일을 설치합니다(Cloudflare, Quad9, NextDNS, AdGuard, Mullvad 모두 제공합니다). 설치 후 기기의 모든 앱이 해당 리졸버로 DoH를 사용합니다. 이것은 설계에 의한 것으로 — iOS는 DoH를 앱별이 아닌 OS 수준 설정으로 취급합니다.
Android 9+: 설정 → 네트워크 및 인터넷 → 고급 → 프라이빗 DNS — 하지만 이것은 실제로 DoH가 아닌 DoT입니다. Android는 DoH(HTTPS)가 아닌 DoT(포트 853)를 사용하여 "프라이빗 DNS"를 구현했습니다. 기능적으로는 동등한 프라이버시 속성이지만 프로토콜이 다릅니다. DoT 리졸버의 호스트명을 입력하면(Cloudflare는 one.one.one.one, Google은 dns.google, AdGuard는 dns.adguard.com) Android가 시스템 전체 DNS 쿼리를 암호화합니다.
macOS 11+: iOS와 동일한 구성 프로필 메커니즘입니다. Apple은 자체 DoH 지원을 제공하지만 시스템 설정에서는 노출하지 않습니다; 프로필을 설치합니다.
Windows 11: 설정 → 네트워크 및 인터넷 → 어댑터 속성 → DNS 서버 할당 → "암호화만(HTTPS를 통한 DNS)" — Windows는 Cloudflare, Google, Quad9를 기본으로 알고 있으며 해당 IP를 설정하면 DoH를 자동 구성합니다. Windows 10도 DoH 지원이 있지만 찾기가 더 어렵습니다.
브라우저 수준 DoH: Firefox는 미국 사용자에게 기본값으로 DoH를 활성화합니다(설정 → 개인 정보 보호 및 보안 → HTTPS를 통한 DNS). Chrome은 "보안 DNS"라고 부릅니다(설정 → 개인 정보 보호 및 보안 → 보안). Safari는 브라우저별 설정이 아닌 macOS 수준 설정을 사용합니다. Edge는 Windows 수준을 사용합니다. 브라우저 DoH는 활성화하기 빠르지만 위의 자녀 보호/기업 우회 문제를 만들어냅니다; OS 수준 DoH는 결정을 관리할 수 있는 한 곳에 둡니다.
DoH 리졸버 선택 — 솔직한 비교
DoH 리졸버를 선택하는 것이 DoH가 내려주는 실제 프라이버시 결정입니다. 주요 옵션들:
- Cloudflare 1.1.1.1: 빠름(애니캐스트, 대부분의 도시에서 15ms 이내), 24시간 로그 보존, 매년 감사. 성인 콘텐츠를 차단하는 "패밀리" 변형(1.1.1.3)이 있습니다. Cloudflare는 DoH와 Cloudflare 네트워크로의 터널을 결합한 VPN-라이트 서비스인 WARP도 제공합니다.
- Google 8.8.8.8: 빠르고 어디서나 사용 가능하며, Google 정책에 따라 무기한 로그 보존. Google 기준으로는 합리적인 프라이버시지만, "또 다른 데이터 스트림을 Google에 신뢰하는 것"이 걸린다면 다른 것을 찾아보세요.
- Quad9 9.9.9.9: 스위스 비영리 재단, 기본 동작으로 알려진 악성 도메인 차단, 무로그 정책 명시, 대부분보다 데이터에 보수적.
- NextDNS: 프로필별 설정 가능(차단 목록, 패밀리 필터, 로그 보존) — 파워 유저를 위한 선택. 자세한 내용은 우리의 비교를 참조하세요.
- AdGuard DNS: DNS 레이어에서 공격적으로 광고/트래커를 차단하며, DoH와 DoT를 모두 지원합니다.
- Mullvad DNS: 단독으로 사용 가능(VPN 구독 불필요), 스웨덴, 설정 가능한 콘텐츠 차단, DoH와 DoT를 통해 접근 가능.
- VPN 공급자의 리졸버: Casper's Cloak, ProtonVPN(NetShield), Mullvad — VPN 터널 내부에서 처리되는 DNS로 별도 설정이 필요 없습니다. 편리하지만, 두 레이어 모두를 VPN 공급자에게 신뢰해야 한다는 것을 의미합니다. 어차피 VPN을 사용한다면 불가피합니다.
솔직한 정리: "최고의" DoH 리졸버는 없습니다; 자신의 위협 모델에 맞는 최고가 있을 뿐입니다. 어떤 사람에게는 속도가, 다른 사람에게는 차단 목록이, 다른 사람에게는 무로그 정책이, 다른 사람에게는 관할권이 중요합니다. 하나를 선택하고, 모든 앱에 일관되게 적용되도록 OS 수준(브라우저 수준만이 아닌)에서 설정하고, 우선순위나 어떤 리졸버의 투명성 보고서가 변경될 때 재검토하세요.
DoH가 VPN 및 광고 차단과 어떻게 맞는가 — 통합된 그림
각각 다른 공격 표면을 차단하는 세 가지 독립적인 프라이버시 레이어:
- VPN 터널: 로컬 네트워크에서의 목적지 IP 가시성을 암호화하고 VPN 공급자로 이동시킵니다. "카페/ISP가 접속하는 IP를 볼 수 있다"를 차단합니다.
- DoH / DoT: 로컬 네트워크와 ISP로부터 DNS 쿼리를 암호화하고 DNS 가시성을 DoH 리졸버로 이동시킵니다. "ISP에 파일로 저장된 DNS 로그"와 "네트워크 수준에서의 DNS 주입"을 차단합니다.
- DNS 수준 콘텐츠 필터링(Pi-hole, NextDNS, AdGuard DNS): 광고, 트래커, 악성코드, 피싱에 대한 조회를 리졸버에서 차단합니다. "기기의 모든 앱이 DNS 레이어에서 차단할 수 있는 엔드포인트를 가진 트래커 SDK를 로드하고 있다"를 차단합니다.
DoH만으로는 하나의 레이어입니다. 실질적인 프라이버시 자세는 세 가지 모두를 쌓습니다. Casper's Cloak은 이 스택을 단일 앱으로 제공하도록 만들어졌습니다: VPN 터널 + Pi-hole DNS 필터링(사용자별 Pi-hole 인스턴스를 리졸버로 운영) + 정적 차단 목록 위에 ML 기반 제로데이 피싱 탐지. DoH는 그 연결 방식에 내재되어 있습니다 — 기기와 리졸버 사이의 DNS 쿼리가 암호화됩니다. 솔직한 정리는 이것이 하나의 유효한 아키텍처라는 것입니다; 다른 방법은 "OS 수준에서 NextDNS로 DoH를 설정하고, 자체 VPN을 레이어하여 동일한 최종 상태를 더 많은 제어 옵션과 함께 얻는 것"입니다. 둘 다 작동합니다; 트레이드오프는 편의성 대 설정 가능성입니다. DNS 필터링 관점에서 같은 내용을 DNS 수준 필터링이 실제로 작동하는 방식에서 다루었습니다.
결론
DoH는 마케팅 문구에는 없는 주의 사항이 있지만, 실제로 유용한 프라이버시 개선입니다. ISP DNS 엿보기, 카페 DNS 주입, 단순한 검열을 차단합니다 — 실제 사용자의 실제 문제 세 가지입니다. SNI 누출, IP 기반 목적지 식별, 또는 선택한 리졸버에 대한 신뢰는 해결하지 못합니다. 그리고 신중하게 설정하지 않으면 정당한 사용 사례에서 자녀 보호 기능 + 기업 보안을 망가뜨립니다.
DoH에서 가장 중요한 단 하나의 결정은 어떤 리졸버를 선택하느냐이며, 모든 앱이 일관되게 적용받도록 OS 수준에서 설정해야 합니다. 두 번째로 중요한 결정은 DoH를 VPN 터널(목적지 IP 가시성을 차단)과 DNS 수준 콘텐츠 필터링(광고/트래커/악성 도메인 조회를 차단)과 함께 레이어할지 여부입니다. DoH만으로는 하나의 레이어를 해결하고, 통합 스택은 전체 공격 표면을 해결합니다.
관련 글: DNS 수준 필터링이 실제로 작동하는 방식은 DoH만으로는 포함하지 않는 필터링 레이어를 다루고, 2026년 공용 WiFi 공격은 DoH가 도움이 되는 네트워크 적대성 위협 모델을 다루며, 2026년 무료 VPN 대 유료 VPN은 VPN 터널 레이어를 다룹니다. NextDNS 비교와 Pi-hole 비교는 설정 가능한 DNS 리졸버 선택을 자세히 다룹니다.