DoH와 DoT 기술 비교 분석
Categories:
DNS over HTTPS(DoH)와 DNS over TLS(DoT)는 두 가지 일반적인 암호화 DNS 전송 방식입니다. 이들은 서로 다른 프로토콜 스택을 통해 DNS 쿼리의 안전한 전송을 구현합니다. DoT 표준은 RFC 7858에 의해 정의되었으며, DoH는 DNS Queries over HTTPS (DoH) 표준에 의해 정의됩니다. 이 두 기술의 본질적인 차이를 이해하려면 네트워크 프로토콜 계층 구조부터 분석해야 합니다.
네트워크 프로토콜 계층 구조
현대 네트워크 프로토콜 스택은 계층별 설계를 채택하고 있으며, 각 계층은 서로 다른 기능을 제공합니다. DNS는 응용 계층 프로토콜로서 특정 전송 방식에 바인딩되지 않으며, 다양한 전달 프로토콜 위에서 실행될 수 있습니다.
응용 계층(L7)에는 HTTP/1.1, HTTP/2, HTTP/3, FTP 및 DNS와 같은 프로토콜이 포함됩니다. 주목할 점은 HTTP/3의 의미(Semantics)가 여전히 응용 계층에 있지만, 전송 담당으로서 QUIC를 사용한다는 것입니다. 보안 계층은 응용 계층과 전송 계층 사이에 위치하며, 주로 TLS와 그 변형을 포함합니다. TLS는 일반적으로 TCP(예: HTTPS 및 DoT)에서 실행됩니다. DTLS는 TLS의 데이터그램 버전으로, UDP에서 실행될 수 있습니다. QUIC 프로토콜은 비교적 특수하며, TLS 1.3 핸드셰이크와 키 파생(Key Derivation)을 프로토콜 내부에 직접 통합했습니다.
QUIC는 UDP를 기반으로 확장되어 기존 전송 계층의 기능을 제공하는 L4.5 계층 프로토콜로 간주할 수 있습니다. 전송 계층(L4)에는 TCP, UDP 및 QUIC가 포함됩니다. 엔지니어링 구현 관점에서 QUIC는 UDP를 기반으로 하지만, 신뢰성, 혼잡 제어, 멀티플렉싱, 암호화 핸드셰이크 등의 기능을 내장하고 있어 엔지니어링적으로는 독립적인 전송 계층 프로토콜로 취급됩니다. 네트워크 계층(L3)은 IP 프로토콜(IPv4/IPv6)을 사용하여 패킷의 라우팅과 포워딩을 담당합니다. 데이터 링크 계층(L2)은 이더넷(Ethernet) 및 Wi-Fi(802.11) 등의 기술을 포함합니다.
TLS는 암호화 수단으로서 응용 계층과 전송 계층 사이에서 작동합니다. DoT에서 TLS 암호화를 분리하면, DoT는 본질적으로 DNS over TCP가 됩니다. 이러한 계층별 설계는 암호화를 선택 사항으로 만들며, 프로토콜 자체의 강제적인 제약 조건이 아닙니다.
Plain DNS의 특징
가장 일반적인 DNS는 Plain DNS라고 불리며, UDP 또는 TCP에서 실행될 수 있습니다. UDP는 연결 설정이 간단하고 첫 번째 쿼리 속도가 빠르기 때문에 가장 일반적인 전송 방식입니다. 하지만 UDP의 약점은 신뢰성이 없어 패킷이 네트워크에서 쉽게 손실될 수 있다는 점입니다. TCP는 핸드셰이크 횟수가 많아 첫 번째 연결 속도가 UDP보다 약 30% 느리지만, 장기 연결이 설정된 후에는 응답 속도가 UDP와 동일합니다.
통신사(ISP)는 네트워크가 혼잡할 때 장비 부하를 줄이기 위해 UDP 패킷을 폐기하기로 선택할 수 있습니다. 일부 통신사에서 UDP 패킷 손실이 심한 지역의 경우, TCP를 사용하여 DNS 쿼리를 수행하는 것이 더 유리할 수 있습니다. TCP는 재전송 메커니즘이 있어 패킷 손실이 발생해도 데이터의 신뢰성 있는 도착을 보장합니다. 반면 UDP 패킷을 폐기하는 것은 소규모 통신사 장비의 부하를 줄여주지 않으며, 오히려 재시도로 인해 더 많은 불확실성을 초래합니다.
응용 계층 중첩
DNS와 HTTP는 모두 응용 계층 프로토콜에 속하며, DoH는 본질적으로 응용 계층 프로토콜이 다른 응용 계층 프로토콜을 중첩한 것입니다. DoH가 반드시 DNS over HTTPS일 필요는 없으며, 일반 HTTP를 사용하는 것도 가능합니다. 단, 암호화되지 않은 DoH는 평문 요청이므로 Plain DNS에 비해 어떠한 이점도 없으며, 극소수의 특수한 요구 사항 시나리오에서만 사용됩니다.
이론적으로는 FTP 등 어떤 응용 계층 프로토콜 위에서도 DNS를 전달할 수 있습니다. 예를 들어 DNS over FTP도 구현할 수 있으며, 이를 위해서는 해당 서버와 클라이언트를 개발하기만 하면 됩니다. 이러한 유연성은 응용 계층 프로토콜 조합의 가능성을 보여줍니다.
flowchart TD
subgraph L7["응용 계층"]
A[DNS]
B[HTTP]
C[FTP]
end
subgraph Security["보안 계층"]
D[TLS]
E[DTLS]
end
subgraph Transport["전송 계층"]
F[TCP]
G[UDP]
H[QUIC]
end
subgraph L3["네트워크 계층"]
I[IP]
end
subgraph L2["데이터 링크 계층"]
J[Ethernet]
K[WiFi]
end
A --> D
B --> D
C --> D
D --> F
E --> G
H --> G
F --> I
G --> I
H --> I
I --> J
I --> K
style A fill:#e1f5ff
style B fill:#e1f5ff
style C fill:#e1f5ff
style D fill:#fff4e1
style E fill:#fff4e1
style F fill:#ffe1e1
style G fill:#ffe1e1
style H fill:#e1ffe1전송 계층 중첩
QUIC 프로토콜은 UDP를 기반으로 하면서 전송 계층에서 연결 지향형 서비스를 제공합니다. QUIC는 TCP가 가진 연결 지향, 혼잡 제어, 재전송, 흐름 제어, 분할 및 재조립 등 전송 계층 기능을 구현했습니다. TCP에 비해 QUIC는 지연 시간이 더 낮으며, UDP에 비해 더 진보되고 신뢰성이 높습니다.
프로토콜 조합 관계
응용 계층과 전송 계층 사이에는 필연적인 제한 관계가 없으며, 암호화는 추가할 수도 추가하지 않을 수도 있습니다. HTTP는 TCP에서 실행할 수도 있고 QUIC에서 실행할 수도 있습니다. DNS는 TCP, UDP, 또는 QUIC에서 실행할 수 있습니다.
이러한 가능성을 바탕으로 다음과 같은 조합 관계를 정리할 수 있습니다. Plain DNS는 UDP 또는 TCP에 DNS 프로토콜을 더한 것입니다. HTTP/2는 TCP에 TLS 1.2 또는 TLS 1.3을 더하고 그 위에 HTTP 프로토콜을 얹은 것입니다. HTTP/3는 QUIC에 TLS 1.3을 더하고 그 위에 HTTP 프로토콜을 얹은 것입니다.
DoH(DNS over HTTPS)는 HTTP/2 또는 HTTP/3에 DNS 프로토콜을 더한 것입니다. DoT(DNS over TLS)는 TCP에 TLS 1.2 또는 TLS 1.3을 더하고 그 위에 DNS 프로토콜을 얹은 것입니다. DoQ(DNS over QUIC)는 QUIC에 TLS 1.3을 더하고 그 위에 DNS 프로토콜을 얹은 것입니다.
flowchart LR
subgraph DoT["DoT DNS over TLS"]
direction LR
T1[TCP] --> T2[TLS]
T2 --> T3[DNS]
end
subgraph DoH2["DoH over HTTP/2"]
direction LR
H1[TCP] --> H2[TLS]
H2 --> H3[HTTP/2]
H3 --> H4[DNS]
end
subgraph DoH3["DoH over HTTP/3"]
direction LR
Q1[QUIC] --> Q2[TLS 1.3]
Q2 --> Q3[HTTP/3]
Q3 --> Q4[DNS]
end
subgraph DoQ["DoQ DNS over QUIC"]
direction LR
D1[QUIC] --> D2[TLS 1.3]
D2 --> D3[DNS]
end
style T1 fill:#e3f2fd
style T2 fill:#fff3e0
style H1 fill:#e3f2fd
style H2 fill:#fff3e0
style Q1 fill:#e8f5e9
style Q2 fill:#fff3e0
style D1 fill:#e8f5e9
style D2 fill:#fff3e0성능 및 호환성 분석
프로토콜 계층 구조를 이해한 후, DoH와 DoT의 장단점을 분석할 수 있습니다.
TCP와 QUIC의 비교는 통신사의 실제 네트워크 환경을 결합하여 논의해야 합니다. QUIC는 비교적 최신 프로토콜로 일부 오래된 네트워크 문제를 해결했지만, 결국 UDP를 기반으로 합니다. 네트워크 지연 시간 관점에서 볼 때, QUIC 기반 프로토콜은 TCP보다 지연 시간이 약 35% 낮기 때문에, 이론적으로 DNS over HTTP/3와 DoQ(DNS over QUIC)는 DNS over HTTP/2와 DoT보다 성능이 더 좋습니다.
하지만 실제 네트워크 환경에서는 패킷 손실로 인한 재전송 지연 문제가 존재합니다. 통신사는 네트워크가 혼잡할 때 UDP 패킷을 폐기하도록 선택하며, QUIC 역시 UDP로 인식되어 폐기될 수 있습니다. QUIC는 재전송을 지원하지만, 재전송으로 인해 발생하는 지연 때문에 QUIC의 실제 지연 시간은 TCP보다 더 높아질 수 있습니다.
프라이버시와 보안 측면에서 DoH와 DoT는 모두 암호화 트래픽이므로 도청이나 변조될 위험이 없습니다. DoT가 식별된 후 차단되는 문제에 대해서는, 주로 Android 시스템의 암호화 DNS 설정이 기본적으로 853 포트를 사용하기 때문에 853 포트가 민감한 포트가 된 원인이 큽니다. DoT 자체는 일반적인 암호화 트래픽이며, DNS 전용 트래픽으로 식별되지 않습니다. 실제로 임의의 포트에서 DoT 서비스를 제공할 수 있으며, 이는 Android에서는 서드파티 앱을 통해 구현해야 하지만 iOS에서는 임의 포트를 사용하는 DoT를 기본적으로 지원합니다.
확장성은 DoH의 중요한 장점 중 하나입니다. HTTP로 캡슐화된 DNS와 Plain DNS에 비해, HTTP는 확장성이 월등히 뛰어납니다. 서비스 제공자는 443 포트에서 DoH를 포함한 수많은 서비스를 제공할 수 있으며, 기능을 쉽게 확장할 수 있습니다. DoT와 DoQ는 일반적으로 포트를 독점해야 하며, 확장 기능은 완전히 Plain DNS에 기반합니다. 이는 서비스 제공자 관점의 차이이며, 일반 사용자에게는 당장 크게 체감되지 않습니다.
DNS 요청 처리 속도 면에서 HTTP의 처리 속도는 Plain DNS보다 몇 CPU 클럭 사이클 정도 느릴 수 있지만, 실제 사용에서 이러한 차이는 무시할 수 있는 수준입니다. 호환성 측면에서는 서비스 제공자에게 DoH의 확장성이 좋기 때문에 DoH가 더 주류가 될 것입니다.
현재 주요 플랫폼의 암호화 DNS 지원 현황은 각기 다릅니다. Chromium 커널 브라우저는 DoH를 지원합니다. Windows 11 시스템은 DoH를 기본 지원합니다. Android 8 이상 버전은 DoT를 기본 지원합니다. Android 11 이상 버전은 DoT와 DoH를 기본 지원합니다. macOS 시스템은 DoT와 DoH를 기본 지원합니다. iOS 시스템은 DoT와 DoH를 기본 지원합니다.
실질적인 선택 가이드
일반 사용자에게는 DoH를 사용하는 것이 DoT보다 더 편리합니다. DoT에 비해 DoH는 대부분의 경우 더 우수한 지연 시간을 제공하고, 소수의 경우에는 유사한 지연 시간을 제공합니다. DoQ에 비해 DoH는 대부분의 경우 유사한 지연 시간을 보이며, 소수의 경우에는 더 우수한 지연 시간을 제공합니다.
이 결론의 전제는 서비스 제공자가 DNS over HTTP/3 서비스를 제공한다는 것입니다. 서비스 제공자가 HTTP/3를 제공하지 않는다면 DoH와 DoT의 큰 차이는 없습니다. DoH는 네트워크 품질이 좋을 때 자동으로 DoH/3를 사용하여 낮은 지연 시간을 얻고, 네트워크 품질이 나쁠 때 자동으로 HTTP/2로 낮춥니다. 이러한 적응형 기능은 서비스 제공자가 구현해야 하지만, 주요 서비스 제공자들은 일반적으로 구현해 두었습니다.
NullPrivate을 사용해 보는 것을 추천합니다. DoT와 DoH/3를 지원하며, 광고 차단 및 DNS 분할(Split Tunneling) 기능을 기본으로 제공합니다. 직접 배포하려면 해당 오픈 소스 라이브러리를 사용할 수 있습니다.
네트워크 프로토콜 선택은 통신사 네트워크 품질, 서비스 제공자 지원 현황, 장치 호환성 등 여러 요소를 종합적으로 고려해야 합니다. 대부분의 사용자에게 DoH는 성능, 호환성, 프라이버시 보호의 균형을 맞춘 훌륭한 선택입니다.