DoH가 암호화하는 구간

DNS over HTTPS(DoH)는 DNS 질의·응답을 HTTPS의 HTTP 교환으로 전달합니다. TLS는 기기와 설정된 DoH 리졸버 사이의 통신을 암호화하고 서버 신원을 확인합니다. 따라서 경로 중간 장비는 평문 DNS 대신 HTTPS 연결과 트래픽 메타데이터를 보게 됩니다. 이 보호는 선택한 리졸버까지만 이어집니다. 리졸버는 질의를 처리해야 하므로 도메인 이름을 볼 수 있고, 연결 정보와 함께 요청을 기록하거나 연계할 가능성은 해당 서비스의 운영·개인정보 정책에 달려 있습니다.

DoH 자체가 DNS 응답의 진위를 보증하는 것은 아닙니다. HTTPS는 클라이언트와 리졸버 사이의 채널을 보호하고, DNSSEC은 서명된 DNS 데이터의 검증을 다룹니다. 필요한 신뢰 속성이 다르므로 하나가 다른 하나를 자동으로 대신하지 않습니다.

관찰 위치에 따라 달라지는 것

관찰자보통 볼 수 있는 정보DoH가 바꾸는 점
기기와 선택된 리졸버 사이의 경로기기·리졸버 IP, 연결 시각과 크기 같은 메타데이터질의·응답 본문은 TLS로 보호되지만 연결 대상이나 트래픽 분석 가능성까지 사라지는 것은 아닙니다.
선택된 DoH 리졸버처리할 DNS 질의·응답과 연결 메타데이터네트워크 중간자 대신 리졸버를 신뢰 경계로 선택합니다. 보존·사용 정책을 확인해야 합니다.
조회 뒤 접속하는 웹사이트해당 사이트에 보내는 연결과 요청DoH는 이후 웹 요청을 숨기거나 사이트가 방문자를 식별하지 못하게 하지 않습니다.

RFC 8484는 HTTPS의 기본 포트 443과 다른 HTTPS 트래픽과의 연결 공유가 경로 장비의 간섭을 억제하고 분석을 어렵게 할 수 있다고 설명합니다. 이것은 모든 네트워크 관찰자에게 DoH가 일반 HTTPS와 구별 불가능하다는 뜻은 아닙니다.

HTTP 요청 형식과 전송 구분

RFC 8484에서 클라이언트는 DNS wire-format 메시지를 HTTP GET 또는 POST로 보냅니다. GET에서는 메시지를 Base64URL로 인코딩해 URI의 dns 변수에 넣고, POST에서는 바이너리 메시지를 요청 본문에 싣습니다. 미디어 타입은 application/dns-message입니다. HTTP/2는 TCP 위에서 동작하고, HTTP/3는 QUIC 위에서 HTTP 의미를 전달합니다. 따라서 “TCP와 UDP의 443 포트를 모두 쓴다”처럼 DoH 하나의 전송 방식으로 뭉뚱그리지 마세요.

가상 배포 사례: 내부 이름이 있는 회사

회사 노트북이 wiki.intra.example을 사내 DNS에서만 찾도록 구성되어 있다고 가정합니다. 사용자가 브라우저만 공용 DoH 리졸버로 바꾸면, 그 질의가 기존 사내 리졸버의 분할 DNS나 필터 정책을 거치지 않을 수 있습니다. 이 경우 도메인을 찾지 못하거나 조직의 관측·차단 규칙이 기대와 다르게 적용될 수 있습니다. 이는 가상 사례이며 특정 제품에서 실행한 결과가 아닙니다.

배포 전에는 다음을 확인하세요.

  1. 어떤 리졸버를 선택하며 그 운영자의 데이터 보존·사용 정책은 무엇인가?
  2. 사설 영역, 분할 DNS, 악성 도메인 필터, 장애 시 대체 경로가 계속 적용되는가?
  3. 관리형 기기에서 브라우저별 설정이 시스템 DNS 정책과 다른 경로를 만들지 않는가?
  4. 새 연결과 재사용 연결을 구분해 실제 지연을 측정했는가? RFC만으로 특정 연결의 지연 개선을 단정할 수 없습니다.

예를 들면 현재 공개 문서가 안내하는 wire-format URI는 Cloudflare https://cloudflare-dns.com/dns-query, Google https://dns.google/dns-query, Quad9 https://dns.quad9.net/dns-query입니다. 이는 연결 형식의 예시이지 추천이나 개인정보 정책 비교가 아닙니다. 설정 전에 해당 제공자의 현재 문서와 조직 정책을 확인하세요.

자료