DNS over HTTPS(DoH): 암호화가 보호하는 범위와 남는 개인정보
DoH는 DNS 질의와 응답을 HTTPS 요청·응답으로 운반해 네트워크 구간의 내용을 보호합니다. 암호화의 경계, 리졸버가 볼 수 있는 정보, GET·POST 및 캐시 동작을 RFC 8484와 운영 문서에 근거해 설명합니다.
발행·오류 제보: infostoa · 편집 기준
이 글의 개별 작성자와 전문 검토자 정보는 제공되지 않습니다.
DNS over HTTPS(DoH)는 도메인 이름을 IP 주소로 찾는 DNS 교환을 HTTPS 안에 실어 보내는 방식입니다. 네트워크 중간에서 평문 DNS 질의 내용을 그대로 읽기 어렵게 만들지만, DNS 리졸버 자체가 질의를 볼 수 없게 하거나 방문 활동 전체를 익명화하는 기술은 아닙니다. 어떤 사업자의 리졸버를 쓰는지, 단말이 다른 이름 해석 경로를 함께 쓰는지, HTTPS 연결의 목적지가 누구인지가 여전히 중요합니다.
1. DNS 메시지를 HTTP 교환으로 운반하기
RFC 8484는 하나의 DNS 질의·응답 쌍을 HTTP 교환에 대응시킵니다. 클라이언트는 DNS wire-format 메시지를 HTTPS 요청에 넣고, 리졸버는 DNS 응답을 HTTP 응답 본문으로 돌려줍니다. 표준은 GET과 POST를 모두 정의합니다. GET은 질의가 URL의 인코딩된 매개변수에 들어가 HTTP 캐시가 처리하기 쉬울 수 있지만, URL이 로그나 텔레메트리에 남을 수 있으므로 민감한 내용을 포함하지 않도록 주의해야 합니다. POST는 메시지 본문에 질의를 담아 URL 노출을 줄이는 방식입니다.
DoH는 DNS의 의미를 다른 이름 해석 시스템으로 바꾸지 않습니다. 질의와 응답은 DNS 형식을 유지하며, HTTP 상태 코드나 헤더 같은 전송 특성이 추가됩니다. DNS 캐시 정책도 사라지지 않습니다. RFC는 HTTP 캐싱 의미를 사용할 수 있게 하지만, 실제 재사용은 응답 헤더, 중간 캐시, 클라이언트 구현에 달려 있습니다. 따라서 DoH를 켰다는 사실만으로 질의가 항상 캐시되거나 항상 캐시되지 않는다고 단정할 수 없습니다.
2. 암호화 구간과 관측 가능한 주체
HTTPS는 클라이언트와 DoH 서버 사이의 전송을 암호화하고 서버를 인증합니다. 같은 경로의 네트워크 사업자나 공용 Wi-Fi 관찰자는 암호화되지 않은 DNS 패킷에서처럼 질의 이름을 직접 읽기 어렵습니다. 그러나 클라이언트가 연결한 리졸버는 요청을 처리하기 위해 DNS 질문을 알게 됩니다. 리졸버 운영자의 보존·접근 정책, 계정 연결 여부, 관할권은 기술 규격만으로 결정되지 않습니다.
또한 DoH는 브라우저나 운영체제의 모든 이름 해석을 자동으로 한 경로에 모으지 않습니다. 애플리케이션별 리졸버 설정, VPN, 프록시, 로컬 네트워크의 정책, 다른 DNS 경로가 함께 존재할 수 있습니다. DNS 질의가 보호되더라도 연결된 웹사이트와의 HTTPS 통신, 단말의 브라우저 기록, 서비스 로그인 정보까지 숨겨지는 것은 아닙니다. “DNS 암호화”와 “익명 브라우징”을 같은 의미로 취급하면 보호 범위를 과장하게 됩니다.
3. 리졸버 선택과 운영상의 절충
DoH 클라이언트는 특정 HTTPS endpoint를 지정해 DNS 리졸버와 통신합니다. Cloudflare의 문서는 자사 1.1.1.1 리졸버에 연결하는 클라이언트 설정을 설명합니다. 다른 제공자도 자체 보존 정책과 운영 조건이 있으므로 선택 전에 정책을 직접 확인해야 합니다. 조직이 관리하는 단말에서는 무단으로 설정을 바꾸기보다 회사 DNS, 필터링, 사고대응 정책이 DoH와 어떻게 상호작용하는지 운영자와 합의하는 것이 중요합니다.
DoH가 일반 HTTPS 트래픽과 비슷하게 보일 수 있다는 특성은 연결성에 도움을 줄 수 있지만, 네트워크 정책과 충돌할 수도 있습니다. 관리형 네트워크는 알려진 리졸버 endpoint, 브라우저 정책, 단말의 설정을 함께 점검해야 의도한 이름 해석 경로를 파악할 수 있습니다. 차단이나 강제 리디렉션을 적용할 때는 호환성, 정책 투명성, 장애 대응을 고려하고, 어떤 리졸버에 질의가 전달되는지 사용자와 관리자에게 명확히 알려야 합니다.
4. 전문가 관점: 개인정보 보호를 검증하는 질문
운영 문서를 읽을 때는 “암호화되어 있다”는 문구만으로 결론을 내리지 말고, 클라이언트에서 실제로 선택한 endpoint, 해당 리졸버의 데이터 처리 정책, URL과 요청 메타데이터의 기록 여부, 오류 시 대체 경로를 확인합니다. 표준은 프로토콜 형식과 상호운용성을 정의하고, 제공자 문서는 특정 서비스의 설정과 정책을 설명합니다. 이 두 종류의 근거는 답하는 질문이 다릅니다.
검증은 단말에서 어떤 DNS 요청이 어디로 나가는지 확인하는 데서 시작할 수 있습니다. 관리되는 네트워크라면 브라우저·운영체제의 DoH 설정과 VPN 정책을 함께 확인하고, 리졸버의 개인정보 처리 설명과 보존 기간을 읽습니다. 이용자 보호의 범위는 이 연결 경로 전체에 달려 있습니다. DoH는 평문 DNS 구간의 노출을 줄이는 수단이지, 리졸버를 신뢰할 필요를 없애거나 모든 추적을 막는 완전한 해결책은 아닙니다.