요약: 1987년부터 사용된 클래식 DNS는 UDP port 53을 통해 평문으로 쿼리를 전송합니다. 네트워크 경로상의 누구든 당신이 조회하는 모든 도메인을 읽거나, 응답을 변조하거나, 특정 쿼리를 차단할 수 있습니다. DoT(RFC 7858, 2016)는 DNS 쿼리를 port 853의 TLS로 감쌉니다. DoH(RFC 8484, 2018)는 port 443의 HTTPS 요청 내부에 DNS 쿼리를 넣습니다. 둘 다 평문 문제를 해결합니다. 하지만 누가 배포를 제어하는지, 누가 쿼리를 볼 수 있는지, 누가 차단할 수 있는지에서 갈립니다 — 그리고 이것이 바로 "어떤 것을 써야 할까?"라고 물을 때 대부분의 사람들이 실제로 묻는 질문입니다. 무엇으로부터 보호하려는지에 따라 다릅니다.
DNS 암호화가 해결하는 것 — 그리고 해결하지 못하는 것
두 프로토콜을 비교하기 전에, 각 프로토콜이 실제로 무엇을 보호하는지 명확히 짚어볼 필요가 있습니다. 클래식 DNS는 기기가 조회하는 모든 도메인 이름을 노출합니다. example.com에 접속하면, ISP — 또는 경로상의 모든 네트워크 운영자 — 는 브라우저가 첫 HTTPS 요청을 보내기도 전에 example.com에 대한 쿼리를 볼 수 있습니다. 그 HTTPS 요청의 실제 내용은 암호화되어 있지만, 그 앞에 있었던 DNS 조회는 그렇지 않습니다. 암호화된 DNS는 바로 이 특정 구멍을 막습니다.
해결하지 못하는 것: 연결하는 목적지 IP 주소는 여전히 보입니다. TLS Server Name Indication(SNI) 필드도 구버전 TLS에서는 핸드셰이크 중에 호스트명을 노출했습니다 — 다만 Encrypted Client Hello(ECH)가 TLS 1.3에서 이를 해결합니다. 암호화된 DNS와 ECH를 함께 쓰면 명백한 유출이 닫힙니다. ECH 없이 암호화된 DNS만 쓰면 하나의 구멍은 막히지만 SNI 유출은 열려 있어, TLS 핸드셰이크 중에 목적지 호스트명이 여전히 보입니다. 솔직하게 말하면: 암호화된 DNS는 필요하지만 충분하지 않습니다.
DoT의 작동 방식 — port 853의 전용 채널
DoT(DNS-over-TLS, RFC 7858에 정의됨)는 개념적으로 더 단순한 설계입니다. 기기가 port 853에서 DNS 서버로 TCP 연결을 엽니다. TLS 핸드셰이크를 수행하고 — HTTPS를 보호하는 것과 동일한 TLS입니다 — 그 후 암호화된 스트림 내에서 표준 DNS 쿼리를 전송합니다. DNS 서버는 마찬가지로 암호화된 스트림 안에서 표준 DNS 응답을 반환합니다. 네트워크 관점에서는 port 853으로의 TLS 연결만 보입니다.
port 853은 IANA가 DoT 전용으로 공식 할당한 포트이므로, 해당 포트의 모든 TCP 트래픽은 명백히 DoT입니다. 네트워크 운영자는 심층 패킷 검사(deep packet inspection) 없이도 목적지 포트만 보면 DoT를 간단히 식별할 수 있습니다. DoT를 차단하려면 port 853을 드롭하면 됩니다. 목적지 DNS 서버의 IP를 기록하면서 허용하는 것도 마찬가지로 간단합니다. DoT는 DNS임을 솔직하게 드러내는데, 이것이 어떤 사용 사례에서는 장점이 되고 다른 경우에는 약점이 됩니다.
DoH의 작동 방식 — 웹 트래픽 속에 숨겨진 DNS
DoH(DNS-over-HTTPS, RFC 8484에 정의됨)는 다른 접근 방식을 취합니다. 기기가 DNS 제공업체의 HTTPS 서버의 특정 URL로 DNS 쿼리를 HTTP POST 요청(또는 쿼리 파라미터를 포함한 GET 요청)으로 전송합니다. POST의 본문에는 바이너리 DNS 메시지가 담기고, 응답 본문에는 바이너리 DNS 응답이 담깁니다. 이 모든 것이 port 443의 일반 HTTPS 연결로 이루어집니다 — 브라우저가 웹 페이지를 불러올 때 사용하는 바로 그 포트입니다.
네트워크 관점에서, DoH 요청은 동일한 서버로의 일반 HTTPS 요청과 구분이 불가능합니다. 연결이 웹 트래픽처럼 보입니다. 패킷 크기도 웹 트래픽처럼 보입니다(초기 쿼리 이후 후속 쿼리는 동일한 HTTP/2 또는 HTTP/3 연결을 재사용합니다). 목적지 IP는 평범해 보이는 엔드포인트에 속합니다 — Cloudflare의 1.1.1.1이나 Google의 8.8.8.8은 동일한 IP에서 DoH와 다른 웹 트래픽을 모두 처리합니다. DoH를 특정하여 차단하려면 네트워크 운영자가 특정 엔드포인트를 식별하고 차단해야 하는데, 이는 포트를 차단하는 것보다 훨씬 어렵습니다.
네트워크 가시성 차이
전송 방식의 차이는 가시성 차이를 낳습니다. DoT를 쓰면 네트워크 운영자(기업 IT, ISP, 학교, 호텔)는 암호화된 DNS를 사용하고 있음을 알 수 있고, 어떤 DoT 서버를 쓰는지(목적지 IP로)도 볼 수 있으며, 그 서버를 차단하도록 선택할 수 있습니다. DoH를 쓰면 네트워크 운영자는 DNS 제공업체 IP로의 암호화된 HTTPS 트래픽은 볼 수 있지만, DoH 엔드포인트 차단 목록을 별도로 관리하지 않는 한 해당 제공업체로의 일반 HTTPS와 DoH를 구별할 수 없습니다.
이는 예측 가능한 결과로 이어집니다. 기업 IT 부서들은 오랫동안 DoT를 선호했습니다. 깔끔하게 차단할 수 있기 때문입니다. port 853을 드롭하면 DNS는 그들이 모니터링하고 필터링하는 조직의 리졸버로 폴백됩니다. 그들이 DoH를 싫어하는 이유도 마찬가지입니다 — DoH는 자신들의 가시성을 우회하기 때문입니다. 소비자 프라이버시 옹호자들은 같은 이유로 DoH를 선호합니다. 서로 다른 이해관계자들이 동일한 아키텍처 결정으로부터 서로 다른 결과를 원합니다.
네트워크가 차단할 수 있는 것
DoT는 차단하기 쉽습니다. port 853을 사용하는 것은 DoT뿐이므로, 방화벽 규칙으로 드롭하면 끝입니다. 많은 기업 네트워크가 이미 그렇게 합니다. 통제가 심한 지역의 필터링 방화벽들도 마찬가지입니다. DoT를 쓰도록 기기를 설정했는데 해당 네트워크가 port 853을 차단하면, OS나 앱이 평문 DNS로 폴백할 때까지 기기의 DNS 쿼리가 실패합니다 — 대부분은 조용히 폴백됩니다.
DoH는 차단하기 훨씬 어렵습니다. 차단하는 유일한 방법은 모든 DoH 엔드포인트를 식별하고 차단 목록에 올리는 것이기 때문입니다. Cloudflare의 1.1.1.1은 가장 잘 알려져 있어 보통 차단 목록에 있습니다. Google의 8.8.8.8도 보통 마찬가지입니다. 하지만 독립적으로 운영되는 DoH 엔드포인트는 계속 늘어납니다 — curl의 DoH 위키 같은 공개 목록에는 수백 개가 등록되어 있습니다. DoH를 전면 차단하려는 네트워크 운영자는 그 목록을 최신 상태로 유지해야 하고, 항상 새로운 엔드포인트보다 한 발 뒤처질 수밖에 없다는 것을 감수해야 합니다. 일부 통제적인 네트워크는 트래픽 패턴 분석으로 DoH를 탐지하려 시도하지만(DoH는 특징적인 요청 크기와 타이밍 특성을 가집니다), 이는 취약하고 오탐이 발생합니다.
Mozilla의 DoH 문서는 이 특성 — DoH가 네트워크가 차단하기 어렵다는 것 — 을 사고로 인한 결과가 아니라 의도적인 설계 목표로 명시하고 있습니다. 동일한 특성이 기업 환경에서는 논란을 일으키는데, 거기서는 네트워크 운영자가 DNS 가시성을 사용자 프라이버시 침해가 아닌 자신들의 보안 스택의 정당한 일부로 간주하기 때문입니다.
기업 환경 및 자녀 보호 기능에 미치는 영향
DNS 수준의 필터링(대부분의 자녀 보호 소프트웨어, 기업의 "안전한 브라우징" 필터링, 그리고 가장 단순한 형태의 악성 도메인 차단에 쓰이는 방식)은 DNS 쿼리를 가로채서 차단 도메인에 대한 쿼리를 드롭하거나 가짜 응답을 반환하는 방식으로 작동합니다. 그 메커니즘은 DNS 수준 필터링의 실제 작동 방식에 대한 글에서 다루었습니다.
암호화된 DNS는 이를 완전히 우회합니다 — DoT와 DoH 모두 로컬 네트워크의 리졸버가 아닌 다른 리졸버로 쿼리를 보내기 때문에, 로컬 리졸버에 적용된 모든 필터링이 무의미해집니다. 자녀 보호 소프트웨어 제공업체 입장에서는 이것이 문제입니다. 사용자 입장에서는 해당 필터링이 정당한지 아니면 침해적인지에 따라 완전히 달라집니다. 대부분의 기업 엔드포인트 관리 도구는 이제 정책으로 브라우저 DoH를 비활성화하고, 가시성을 유지하기 위해 OS 수준의 DNS 설정이나 전체 트래픽 검사에 의존합니다. Apple의 MDM 관리형 iOS 프로파일에는 바로 이를 위해 설계된 DoH/DoT 설정 메커니즘이 포함되어 있습니다. 기업은 자신들이 선택한 암호화된 DNS 리졸버를 지정하고 사용자가 변경하지 못하도록 할 수 있습니다.
가정에서는, 브라우저에서 DoH를 켜면 설정해 둔 라우터 기반 콘텐츠 필터링이 우회됩니다. 설정을 관리하는 쪽이 누구냐에 따라 이것이 기능일 수도 있고 버그일 수도 있습니다.
성능 특성
DoT는 일반적으로 DoH보다 쿼리당 오버헤드가 약간 낮습니다. 두 프로토콜 모두 TLS를 사용하지만, DoT는 각 DNS 메시지 주위에 훨씬 작은 래퍼를 씁니다 — HTTP 요청 라인, 헤더, Content-Length, HTTP 메서드가 없습니다. DNS 메시지가 TLS 스트림에 직접 들어갑니다. 반면 DoH는 각 DNS 쿼리를 HTTP POST 또는 GET으로 감싸므로 쿼리당 수십 바이트에서 수백 바이트의 오버헤드가 추가됩니다.
이 오버헤드는 연결 재사용으로 대부분 상쇄됩니다. DoT와 DoH 모두 여러 쿼리에 걸쳐 TLS 연결을 유지하므로, 핸드셰이크 비용은 한 번만 지불됩니다. HTTP/2의 DoH는 동일한 연결에서 쿼리를 다중화하고, HTTP/3(QUIC 기반)은 지연 시간을 더욱 줄입니다. 실제로 현대 네트워크에서는 두 프로토콜이 사용자 입장에서 구분할 수 없는 지연 시간을 보입니다 — 기껏해야 한 자릿수 밀리초 차이입니다. 성능을 이유로 하나를 선택하지 마세요. 선택 기준은 가시성, 제어, 그리고 위협 모델입니다.
DoT vs DoH 한눈에 보기
| 속성 | DNS-over-TLS (DoT) | DNS-over-HTTPS (DoH) |
|---|---|---|
| 포트 | 853 (전용) | 443 (HTTPS와 공유) |
| RFC | RFC 7858 (2016) | RFC 8484 (2018) |
| 전송 | TCP 위의 순수 TLS | HTTPS (HTTP/2 또는 HTTP/3) |
| 네트워크에서 식별 가능 여부 | 가능 — port 853은 DoT 전용 | 불가능 — 일반 HTTPS처럼 보임 |
| 네트워크 차단 용이성 | 쉬움 (port 853 드롭) | 어려움 (엔드포인트 차단 목록 필요) |
| 브라우저 지원 | 없음 (브라우저는 DoT를 구현하지 않음) | Firefox, Chrome, Edge, Safari 모두 지원 |
| OS 지원 | Android 9+, iOS 14+, macOS 11+, Linux (systemd-resolved) | Android 9+, iOS 14+, macOS 11+, Windows 11+ |
| 기업 가시성 | 포트로 식별 가능; 모니터링 또는 차단 용이 | 포트 기반 모니터링 우회; 엔드포인트 검사 필요 |
| 쿼리당 지연 오버헤드 | 낮음 (최소한의 래퍼) | 약간 높음 (HTTP 헤더); HTTP/2 다중화로 무시할 수준 |
| 검열 저항성 | 낮음 (포트 차단 가능) | 높음 (port 443은 현대 웹의 필수 요소) |
어떤 것을 써야 할까 — 세 가지 시나리오
"어떤 프로토콜이 더 나은가"는 완전히 무엇을 달성하려는지에 달려 있습니다. 구체적인 답변이 있는 세 가지 시나리오를 소개합니다:
시나리오 1: 적대적이거나 신뢰할 수 없는 네트워크의 개인 기기
카페, 호텔, 공항, 친구 집 Wi-Fi. 위협 모델은 로컬 네트워크 운영자가 DNS를 관찰하거나 변조하는 것입니다. 암호화 자체를 위해서는 두 프로토콜 모두 작동합니다. DoH가 선호되는 이유는 적대적인 네트워크가 차단하기 훨씬 어렵기 때문입니다. port 853을 드롭하는 네트워크에서 DoT를 사용하면 쿼리는 port 53의 평문으로 조용히 폴백되고(대부분의 OS 클라이언트는 이렇게 실패함), 보호하려 했던 모든 것이 노출됩니다. DoH는 거의 항상 엔드포인트에 도달합니다.
시나리오 2: 자녀 기기를 관리하는 가정 네트워크
자녀 기기가 필터링 DNS 리졸버(NextDNS, OpenDNS Family Shield, Cloudflare for Families)를 사용하도록 하고, 이를 우회하지 못하게 하고 싶은 경우입니다. 여기서는 DoT가 실제로 더 편리합니다 — 기기가 특정 DoT 리졸버를 사용하도록 설정하면, 아이가 브라우저에서 설정을 바꿔 다른 DNS를 사용하기 어렵습니다. 브라우저 DoH는 기업/MDM 정책이나 카나리아 도메인 설정으로 비활성화할 수 있습니다. DoT와 DoH 중 어떤 것을 선택하느냐보다, 개별 앱이 선택하도록 두는 것이 아니라 OS 계층에서 기기 수준 DNS를 설정하는 것이 더 중요합니다.
시나리오 3: 이미 VPN을 사용 중인 경우
VPN을 사용하고 있다면 어느 쪽이든 로컬 네트워크는 DNS 쿼리를 볼 수 없습니다 — VPN 터널이 DNS를 포함한 모든 것을 암호화하기 때문입니다. 관련된 질문은 VPN이 내부적으로 어떤 DNS 리졸버를 사용하는지, 그리고 그것이 업스트림 리졸버로 암호화된 DNS를 지원하는지가 됩니다. 대부분의 현대 VPN(Casper's Cloak 포함)은 내부적으로 암호화된 DNS를 사용하고, 터널을 통해 응답을 돌려보내기 전에 리졸버에서 위협 차단 필터링을 적용합니다. 이 구성에서 DoT vs DoH는 주로 구현 세부사항입니다. 중요한 것은 리졸버가 ISP가 아니고 쿼리를 기록하지 않는다는 것입니다.
두 프로토콜이 모두 회피하는 신뢰 문제
DoT와 DoH 모두 신뢰를 로컬 네트워크 운영자에서 선택한 암호화된 DNS 제공업체로 이동시킵니다. Cloudflare, Google, Quad9, NextDNS, ControlD — 이들 각 회사는 당신이 보내는 모든 DNS 쿼리를 봅니다. 그들에게 암호화되어 있다는 것이 그들로부터의 프라이버시를 의미하지는 않습니다. ISP가 DNS를 보면 안 된다는 것이 우려라면, 암호화된 DNS가 문제를 해결합니다. 어떤 제3자도 DNS를 보면 안 된다는 것이 우려라면, 두 프로토콜 모두 도움이 되지 않습니다. 직접 재귀 리졸버를 운영해야 하는데, 그것은 또 다른 프로젝트입니다.
신뢰하는 리졸버에 요구할 수 있는 것: 명확한 로깅 정책, 제3자 감사, 쿼리 최소화 지원(업스트림 권위 서버가 필요한 쿼리 부분만 볼 수 있도록), DNSSEC 검증. 주요 공개 DoH/DoT 제공업체들은 모두 정책을 공개합니다. 읽어보세요. 이에 대한 더 깊은 가이드는 2026년 DoH 상세 가이드에 있습니다.
결론
DoT와 DoH는 동일한 근본적인 문제 — DNS 평문이 브라우징 목적지를 네트워크에 유출하는 것 — 를 두 가지 다른 아키텍처 전략으로 해결합니다. DoT는 솔직한 설계입니다. 전용 포트, 쉬운 식별, 쉬운 관리, 쉬운 차단. DoH는 위장된 설계입니다. HTTPS 트래픽 속에 숨겨져 있고, 엔드포인트 차단 목록 없이는 식별하기 어려우며, 대규모 차단이 어렵습니다.
적대적인 네트워크의 소비자에게는 DoH가 올바른 선택입니다. 실제로 엔드포인트에 도달하는 것이기 때문입니다. DNS 가시성이 필요한 기업에게는 DoT가 더 협조적인 선택입니다. 집에서 자체 필터링 DNS를 운영하는 사람에게는 DoT가 더 설정하기 쉽고 앱 수준에서 사용자가 우회하기 어렵습니다. VPN 사용자에게는 선택이 대부분 보이지 않습니다 — VPN 클라이언트가 처리합니다.
진짜 질문은 "DoT냐 DoH냐"가 아닌 경우가 대부분입니다 — "어떤 리졸버를 신뢰하는지, 그리고 그 로깅 정책은 무엇인지"입니다. 신뢰하는 리졸버를 선택하고, 브라우저별이 아닌 시스템 전체에서 설정하고, DNS 유출 테스트로 설정이 실제로 올바른지 확인하세요. 리졸버와 대화하는 데 사용하는 프로토콜은 반대편 끝의 엔드포인트 정책보다 덜 중요합니다.