ODoH를 이용한 익명 DNS: IP와 쿼리 사이의 연결 끊기

Pi-hole, AdGuard Home 또는 일반 포워딩 리졸버를 사용하는 사용자에게는 프라이버시 트레이드오프가 명확합니다: 단일 운영자가 여러분의 IP 주소와 방문하는 모든 사이트를 모두 볼 수 있습니다. Unbound와 같은 재귀 리졸버로 전환하면 중간자를 없앨 수 있지만, 권한 있는 네임서버에 IP가 직접 노출됩니다—즉 .com이나 google.com이 정확히 누가 요청했는지 알게 됩니다. DNS over HTTPS(DoH)와 DNS over TLS(DoT)도 전송을 암호화할 뿐, 데이터를 누가 보유하고 있는지는 바꾸지 못합니다.

이를 해결하기 위해 IETF는 Oblivious DNS over HTTPS (ODoH)(RFC 9230)를 도입했습니다. 목표는 DNS 체인 내 어느 단일 엔터티도 요청자의 신원(IP 주소)과 요청 자체를 동시에 알지 못하도록 하는 것입니다. Numa 프로젝트는 최근 ODoH 클라이언트와 릴레이를 하나의 Rust 바이너리로 제공하고, 생태계에 남아 있는 몇 안 되는 공개 릴레이 중 하나를 배포함으로써 이를 구현했습니다.

ODoH 작동 방식: 분할 경로 아키텍처

ODoH는 DNS 해석 경로를 릴레이와 타깃이라는 두 개의 별도 엔터티로 나누어 익명성을 확보합니다.

The Client: 사용자는 대상(Target)의 공개키(HPKE)를 사용해 DNS 쿼리를 암호화합니다. 이 암호화에는 응답을 위한 대칭키가 포함됩니다.
The Relay: 쿼리는 릴레이로 전송됩니다. 릴레이는 클라이언트의 IP 주소를 보지만 쿼리를 복호화할 수 없습니다. 단순히 암호문을 타깃으로 전달합니다.
The Target: 타깃(예: Cloudflare)은 쿼리를 복호화합니다. 요청은 보이지만 원본 클라이언트가 아닌 릴레이의 IP 주소만 확인합니다.
The Return: 타깃은 대칭키로 답변을 암호화하고 릴레이를 통해 클라이언트에게 반환합니다. 릴레이는 여전히 암호문만을 봅니다.

릴레이와 타깃이 서로 다른 조직에 의해 운영된다는 전제하에, 사용자의 IP와 DNS 쿼리 사이의 연결이 암호학적으로 끊어집니다.

Numa Relay 엔지니어링

공개 릴레이를 구현하려면 단순히 패킷을 전달하는 것을 넘어, 인프라가 악용되지 않도록 엄격한 보안 경계를 설정해야 합니다.

SSRF 강화

요청에 지정된 타깃으로의 아웃바운드 연결을 열기 때문에, 릴레이는 Server‑Side Request Forgery(SSRF)의 주요 표적이 됩니다. 악의적인 클라이언트가 릴레이에게 내부 클라우드 메타데이터 서비스(169.254.169.254)를 조회하도록 강제할 수 있습니다. 이를 방지하기 위해 Numa는 RFC 1035 ASCII 라벨만 허용하고 IP 리터럴, IDN, 비표준 포트를 금지하는 정규식 기반 호스트명 검증기를 사용합니다.

동일 운영자 검사

릴레이와 타깃이 같은 조직에 속한다면 ODoH는 "security theater"에 불과합니다. 로그를 단순히 상관관계 분석해 사용자를 재식별할 수 있기 때문입니다. Numa는 기본적으로 릴레이와 타깃이 동일한 도메인 소유자를 공유하는 구성을 거부하도록 eTLD+1 검사를 구현했습니다.

주요 제한 사항 및 트레이드오프

ODoH가 프라이버시를 크게 향상시키지만, 만능 해결책은 아닙니다. 여러 운영 및 이론적 위험이 남아 있습니다:

Target Trust: ODoH는 신뢰를 제거하지 않고 이동시킵니다. 타깃은 여전히 질문을 보며, 보호는 운영적(타깃이 여러분이 누구인지 모름)이며 암호학적이지 않습니다.
Traffic Analysis: 작은 릴레이는 타이밍 공격에 취약합니다. 릴레이에 활성 사용자가 한 명뿐이라면, 타깃은 쿼리 도착 시점을 클라이언트 활동과 연관시킬 수 있습니다. 익명성은 사용자 수와 패딩 트래픽의 양에 비례합니다.
Centralized Key Distribution: 현재 클라이언트는 표준 HTTPS를 통해 타깃의 HPKE 구성을 가져옵니다. 이는 WebPKI 시스템에 의존하므로, 인증기관이 손상될 경우 ODoH 구성이 위조될 수 있습니다.
Egress Leaks: ODoH는 클라이언트‑타깃 구간만 보호합니다. 타깃이 재귀 리졸버인 경우, 루트 및 TLD 서버에 대한 후속 쿼리는 일반적으로 평문 UDP/TCP로 전송됩니다.

ODoH 생태계 현황

공개 ODoH 인프라는 현재 매우 희박합니다. 오랫동안 생태계는 단일 공개 릴레이(odoh-relay.edgecompute.app)에 거의 전적으로 의존했습니다. odoh-relay.numa.rs를 배포함으로써 Numa는 두 번째 독립 운영자를 추가해 네트워크의 다양성과 복원력을 높였습니다.

커뮤니티 논의는 관리형 익명성 vs. 자체 호스팅 사이의 지속적인 논쟁을 강조합니다. 일부 사용자는 완전한 제어를 원하는 경우 로컬 Unbound 인스턴스를 커스텀 캐시 워밍 전략과 함께 운영하는 것이 우수하다고 주장합니다. 다른 이들은 DNS를 Tor(DoHoT)로 라우팅하는 것이 더 강력한 위협 모델을 제공하지만 지연 시간이 증가한다는 점을 지적합니다.

Numa 시작하기

익명 DNS를 구현하려는 이들을 위해 Numa는 턴키 솔루션을 제공합니다. 바이너리를 설치하고 설정 파일에 mode = "odoh"을 지정하면 쿼리가 두 개의 독립 조직을 통해 라우팅됩니다. Docker 사용자를 위해 사전 구성된 compose 레시피가 제공되어 클라이언트 또는 자체 호스팅 릴레이를 배포하고 공개 생태계의 익명성 집합을 확장할 수 있습니다.