DNS over HTTPS: 무엇이며 어떻게 쿼리를 보호하는가

알파 가이드 » 컴퓨팅 » DNS over HTTPS: 무엇이며 어떻게 쿼리를 보호하는가

웹 주소를 입력할 때, 사용자가 올바른 사이트에 접속하도록 보장하는 백그라운드 구성 요소가 작동합니다. 바로 도메인 이름 시스템(DNS)입니다. DNS는 기억하기 쉬운 이름을 컴퓨터가 이해할 수 있는 IP 주소로 변환합니다. 편리한 기능이지만, 오랫동안 DNS에는 심각한 취약점이 있었습니다. 바로 이러한 쿼리가 암호화되지 않은 상태로 전송되었다는 점입니다. 이러한 이유로 DNS over HTTPS(DoH)가 널리 사용되고 있습니다. DoH는 인터넷 서비스 제공업체가 사용자가 방문하는 도메인을 추적하기 어렵게 만드는 추가적인 보안 계층입니다.

먼저 한 가지를 분명히 해야 합니다. DoH는 DNS 쿼리의 개인 정보 보호를 강화하지만 VPN과는 다르며, 전체 연결을 비밀 터널로 바꾸는 것도 아닙니다 . 이 글에서는 DoH가 정확히 무엇인지, 왜 인기를 얻게 되었는지, Chrome, Edge, Firefox에서 활성화하는 방법, 장단점, DNS over TLS 및 VPN과의 차이점, 그리고 기술적 및 실질적 한계에 대해 자세히 살펴보겠습니다.

DNS란 무엇이며, 기존 시스템의 한계는 무엇일까요?

DNS 서버는 거의 아무도 관심을 기울이지 않는 구성 요소 중 하나이지만, 온라인 브라우징의 상당 부분을 뒷받침하는 핵심적인 역할을 합니다. DNS 서버 의 역할은 도메인 이름을 해당 서버의 IP 주소에 연결하는 것입니다 . 웹사이트에 접속하면 컴퓨터는 문자를 인식하지 못하고, 어떤 서버에 연결해야 하는지 알기 위해 IP 주소가 필요합니다. 많은 공유기에는 인터넷 서비스 제공업체에서 DNS 서버를 미리 설정해 놓아 편리하지만, 이러한 방식은 해당 인프라를 관리하는 주체에게 가시적인 흔적을 남기기도 합니다.

근본적인 문제는 기존 DNS 쿼리가 보호 장치 없이 평문으로 이루어진다는 점입니다 . 이로 인해 도청, 중간자 공격, 그리고 응답 조작이 가능해집니다. 인터넷 서비스 제공업체는 사용자가 어떤 도메인에 언제 쿼리를 보내는지 파악할 수 있으며, 공유 네트워크상의 공격자는 요청을 가로채서 위조된 응답을 보낼 수 있습니다. 이러한 기법을 DNS 하이재킹이라고 하며, 결국 가짜 페이지, 원치 않는 광고, 또는 개인 정보를 탈취하려는 사이트로 연결될 수 있습니다. 정부와 인터넷 서비스 제공업체는 과거에도 이러한 취약점을 악용하여 검열을 시행하거나, 도메인을 차단하거나, 추가 광고를 표시해 왔습니다.

• 수동적 듣기: 누군가가 사용자의 검색어를 분석하여 어떤 서비스나 웹사이트를 자주 이용하는지 추론합니다.
• 중간자: 통신이 가로채지고 응답이 서버를 가장하도록 변조됩니다.
• 차단 및 필터링: 이는 콘텐츠 접근을 제어하기 위해 특정 도메인의 접속을 차단하는 기능입니다.

HTTPS를 통한 DNS: 쿼리를 암호화하여 누구나 볼 수 없도록 합니다.

DNS over HTTPS(DoH)는 HTTPS 프로토콜을 활용하여 DNS 쿼리와 응답을 암호화된 형태로 전송하는 솔루션입니다 . 장치는 일반적인 DNS 요청을 보내는 대신, 일반적으로 보안 웹사이트에서 사용하는 포트인 443번 포트를 사용하여 보안 연결로 요청을 캡슐화합니다. 이렇게 하면 쿼리와 응답 모두 보호되어 외부 관찰자가 쉽게 읽을 수 없게 됩니다.

이 기능을 사용하려면 쿼리 대상 DNS 서버도 도메인 기반 DNS(DoH )를 지원해야 합니다. 브라우저에서 해당 옵션을 활성화하는 것만으로는 충분하지 않으며, 선택한 리졸버가 이 표준을 준수해야 합니다. DoH 사양은 지속적으로 발전해 왔으며 여전히 개발 중인 기술로 간주되지만, 2018년부터 Google과 Mozilla Foundation과 같은 기업들이 이를 테스트하고 통합해 왔습니다. DoH는 개인 정보 보호 강화 외에도, 전체 도메인을 해석할 필요 없이 필요한 최소한의 부분만 해석하기 때문에 지연 시간을 줄이고 쿼리 속도를 향상시킬 수 있다는 테스트 결과가 있습니다.

DoH의 장점: 더 나은 개인 정보 보호, 조작 가능성 감소, 더 나은 성능

가장 확실한 장점은 보안입니다. DNS 쿼리는 암호화되어 전송되므로 도청이나 변조가 훨씬 어려워집니다 . 이는 중간자 공격을 어렵게 하고, 공용 Wi-Fi 네트워크에서의 노출을 줄이며, 지역 통신 사업자가 사용자가 어떤 도메인에 접속하는지 명확하게 파악하는 것을 방지합니다. DoH 트래픽은 443번 포트를 사용하기 때문에 다른 HTTPS 연결과 섞여 일반 웹 방문과 구별하기 어렵습니다.

성능적인 이점도 있습니다. DoH는 이름 확인 방식 변경과 캐시 활용 개선을 통해 지연 시간을 줄이고 DNS 통신 속도를 향상시킬 수 있습니다 . 예를 들어, 일부 API의 GET 메서드는 더 효율적으로 캐싱되도록 설계되었습니다. 실제로 이는 웹 브라우징 속도를 약간 향상시키는 효과를 가져올 수 있지만, 완벽한 해결책은 아니며 개선 효과가 항상 체감되는 것은 아닙니다. 또한, DoH는 브라우저에 내장되어 있으므로 사용자는 인터넷 서비스 제공업체의 활성화를 기다릴 필요가 없습니다.

암호화의 단점과 논쟁: 암호화가 삶을 복잡하게 만드는 경우

도메인 기반 암호화(DoH)를 모두가 긍정적으로 보는 것은 아닙니다. 사용자를 보호하는 동시에 네트워크 모니터링을 어렵게 만드는 암호화 방식이기 때문입니다 . 많은 자녀 보호 프로그램은 DNS 쿼리를 검사하여 자녀가 접속하려는 웹사이트를 파악하는데, DoH를 사용하면 이 작업이 훨씬 복잡해지고 심지어 불가능해질 수도 있습니다. 기업 네트워크 관리자 역시 비슷한 상황에 직면합니다. 어떤 도메인에서 쿼리가 실행되는지 파악하기 어려워지고 특정 규칙을 쉽게 적용할 수 없게 됩니다.

인터넷 서비스 제공업체는 기관의 요청에 따라 접속을 모니터링하고 특정 도메인을 차단하는 기능을 잃게 됩니다. 이는 상당한 논쟁을 불러일으켰는데, 일부는 이를 개인정보 보호의 승리로 보는 반면, 다른 일부는 통제 및 관리 문제로 간주합니다 . DoT의 경우, 자체적으로 식별 가능한 포트를 사용한다는 점에서도 비판을 받았습니다. 이 포트 때문에 정확히 어떤 쿼리인지 알지 못해도 DNS 쿼리를 식별할 수 있기 때문입니다. DoH는 HTTPS 트래픽 내에 자신을 위장함으로써 이러한 명확한 신호를 피하지만, 그 대가로 네트워크 관리자는 통신을 관리할 수 있는 도구가 줄어들게 됩니다.

Chrome, Edge, Firefox에서 DoH를 활성화하는 방법

최신 브라우저에서 DNS(도메인 이름 시스템)를 활성화하는 것은 일반적으로 간단합니다. 특히 크로미움이나 파이어폭스 기반 브라우저라면 더욱 그렇습니다. DNS 옵션은 존재하지만, 경우에 따라 고급 설정 메뉴에 숨겨져 있을 수 있습니다 . 설정을 변경하기 전에 브라우저는 자체 쿼리만 보호한다는 점을 이해하는 것이 중요합니다. 시스템 수준에서 DNS가 구성되지 않은 경우, 기기의 다른 애플리케이션은 다른 DNS 시스템을 계속 사용할 수 있습니다.

Google Chrome

크롬에서 가장 빠른 방법은 입력하는 것입니다. chrome://flags/#dns-over-https 주소 표시 줄에서. 그러면 크롬의 플래그 또는 실험적 기능 페이지로 바로 이동합니다.'보안 DNS 조회'라는 옵션이 선택되어 있는 것을 볼 수 있습니다. '기본값'이라고 표시된 드롭다운 메뉴를 클릭하고 '사용'을 선택하세요. 변경 사항을 적용하려면 브라우저를 다시 시작해야 합니다.

마이크로 소프트 에지

크롬 기반 Edge에서도 과정은 사실상 동일합니다. 브라우저를 열고 입력하세요 edge://flags/#dns-over-https 검색 창에서Edge의 플래그 설정으로 들어가면 동일한 보안 DNS 조회 옵션이 나타납니다. 기본값을 사용으로 변경하고 메시지가 표시되면 브라우저를 다시 시작하세요.

모질라 파이어 폭스

Firefox에서는 플래그 메뉴로 이동할 필요가 없습니다. 오른쪽 상단의 메뉴 버튼을 클릭하고 옵션을 선택하세요 . 일반 섹션에서 아래로 스크롤하여 네트워크 설정을 클릭합니다. 열리는 창에서 HTTPS를 통한 DNS 사용 옆의 확인란을 선택합니다. 그러면 Cloudflare, NextDNS와 같은 제공업체 중에서 HTTPS를 통한 암호화를 수행할 업체를 선택할 수 있습니다.

DNS over TLS(DoT): 또 다른 암호화 경로

DNS over TLS(DoT)는 DNS 쿼리를 보호하는 또 다른 방법입니다. HTTPS 대신 TCP 연결과 표준 포트인 853을 통해 TLS를 사용합니다. TLS는 HTTPS와 동일한 보안 기반을 사용하므로 개념은 유사합니다. 즉, 두 참여자만 정보를 해독하고 처리할 수 있는 암호화된 터널을 생성하는 것입니다. 이를 통해 중간자 공격이 어려워지고 제3자가 쿼리를 읽거나 조작하는 것을 방지할 수 있습니다.

.NET DNS는 특히 보안 조치가 없는 기존 DNS와 비교했을 때 여러 장점이 있습니다. 암호화를 통해 사이버 범죄자가 요청을 가로채는 것을 방지하고 특정 검열 조치에도 대응할 수 있습니다 . 하지만 클라이언트와 서버 모두 호환성이 필요합니다. 여러 제공업체에서 호환 가능한 서버를 제공하지만, 데스크톱이나 노트북에서 사용하려면 일반적으로 추가 소프트웨어를 설치해야 합니다. 최신 안드로이드 기기(최소 안드로이드 9 이상)에서는 이미 통합되어 있습니다. 윈도우와 리눅스용 솔루션도 있지만, 항상 원하는 만큼 직관적이지는 않습니다.

단점 중 하나로, 많은 데이터 보호 전문가들은 DoT가 단일하고 식별 가능한 포트를 사용한다는 점을 비판합니다. 어떤 웹사이트에 접속하는지 알 수는 없지만, DNS 트래픽은 감지할 수 있습니다 . 일부 네트워크 관리자에게는 이를 통해 전체 상황을 파악할 수 있어 유용하지만, 다른 관리자에게는 숨기고 싶은 신호일 수 있습니다. 또한 DoT는 아직 기존 DNS만큼 널리 보급되지 않았고, 서버 측 도입도 제한적입니다. 몇몇 기업이 DNS 쿼리를 집중시켜 일종의 국제적 독점 체제를 형성할 가능성에 대한 우려가 제기되고 있습니다.

보건부(DoH) vs. 교통부(DoT): 같은 것을 보호하는 두 가지 방법

DoH와 DoT의 주요 차이점은 포트와 트래픽 위장 방식에 있습니다. DoT는 자체 포트인 853을 사용하는 반면, DoH는 443 포트를 사용하며 일반 HTTPS 연결과 섞여 들어갑니다 . 이 사소해 보이는 차이점이 상당한 논쟁을 불러일으켰습니다. 개인정보 보호 관점에서 DNS 쿼리가 다른 트래픽과 구별되지 않는다는 것은 장점입니다. 인식되지 않으면 조작하기가 더 어려워지기 때문입니다. 그러나 네트워크 관리 관점에서는 제어력이 약해지고 보안 또는 필터링 정책을 구현하기가 더 어려워집니다.

본질적으로 두 가지 비전이 존재합니다. 여러 인터넷 표준을 개발하는 컨소시엄인 IETF는 DoT(Domain-Oriented Technology)를 지지하는 반면, 구글과 모질라 재단은 DoH(Domain-Oriented Network)를 강력하게 추진해 왔습니다. 이 두 기술은 서로 대립하는 기술이 아니라, 개인정보 보호, 네트워크 가시성, 그리고 중개자의 역할에 대한 서로 다른 이해 방식을 나타냅니다. 어느 쪽을 선택할지는 무엇을 보호해야 하는지, 그리고 누가 네트워크를 관리해야 하는지에 따라 달라집니다.

DoH와 VPN의 차이점: 질문 자체는 보호하지만, 전체 여정은 보호하지 않습니다.

DoH와 VPN은 개인정보 보호에 대한 논의에서 자주 언급되지만, 둘은 서로 다른 기능을 합니다. DoH는 이름 쿼리를 보호하는 반면, VPN은 데이터가 이동하는 경로를 보호합니다 . 이를 쉽게 이해하려면 DoH는 민감한 질문을 밀봉된 봉투에 넣는 것과 같다고 생각하면 됩니다. 반면 VPN은 전체 여정을 개인 터널을 통해 이동시킨 후 다시 공용 도로로 나오게 합니다. 둘 다 개인정보 보호를 강화할 수 있지만, 휴대폰, 태블릿, 컴퓨터의 트래픽을 포괄적으로 보호하도록 설계된 것은 VPN뿐입니다.

사이트가 로드되기 전에 DNS는 어떤 역할을 하나요?

브라우저가 웹사이트를 로드하기 전에 기기는 자신의 위치를 ​​알아야 합니다. DNS는 전화번호부처럼 웹사이트 이름을 IP 주소로 변환하는 역할을 합니다 . 이 과정은 웹페이지를 열거나, 앱을 실행하거나, 이메일을 업데이트하거나, 동영상을 재생할 때마다 끊임없이 발생합니다. 대부분의 경우 이 과정은 조용히 진행되기 때문에 사용자는 알아차리지 못합니다. 편리함 면에서는 좋지만, 이 때문에 개인정보 보호 문제를 간과하기 쉽습니다. 기존 DNS 쿼리는 암호화되지 않으므로 인터넷 서비스 제공업체, 회사, 학교, 카페 Wi-Fi 또는 호텔 네트워크에서 사용자의 기기가 어떤 도메인에 접속하려는지 확인할 수 있습니다. HTTPS 페이지의 전체 콘텐츠를 볼 수는 없지만, 사용자의 활동에 대한 상당히 자세한 개요를 파악할 수 있습니다.

DNS 쿼리는 사용자가 방문한 모든 페이지나 입력한 모든 내용을 드러내지는 않지만, 도메인 목록을 통해 사용자의 습관, 관심사, 업무 도구, 건강 관련 정보 검색, 금융 서비스 이용 내역 등을 파악할 수 있습니다 . 바로 이러한 이유로 암호화된 DNS는 유용한 개인정보 보호 기능으로 자리 잡았습니다. 모든 것을 드러내지는 않지만, 많은 사람들이 인식하는 것보다 훨씬 더 많은 정보를 노출할 수 있습니다.

보건부는 무엇을 숨기고 무엇을 드러내는가?

DoH는 보안 웹사이트에서 사용하는 것과 동일한 암호화 프로토콜인 HTTPS를 통해 DNS 쿼리를 전송합니다. 요청은 암호화된 상태로 기기를 출발하여 표준 HTTPS를 지원하는 리졸버에 도달합니다 . 공용 Wi-Fi 환경에서는 네트워크 사업자가 실수로 쿼리를 읽기 어렵게 만들 수 있습니다. 인터넷 서비스 제공업체가 DNS를 관리하는 경우, DoH 리졸버로 전환하면 제공업체가 이러한 쿼리를 일반적인 방식으로 볼 수 없도록 방지할 수 있습니다. 또한, 네트워크에서 이름 확인 결과를 조작하는 경우 암호화된 DNS는 이러한 조작을 줄일 수 있습니다.

DoH는 전체 대화가 아닌 쿼리 자체를 숨깁니다. 일부 관찰자가 도메인 조회를 명확하게 볼 수 없도록 막을 수는 있지만, 인터넷 연결 전체를 암호화된 터널로 만들지는 않습니다 . 기기가 IP 주소를 알게 되면 다른 개인 정보 보호 도구가 경로를 변경하지 않는 한 나머지 연결은 정상적인 경로를 따릅니다. DoH는 사용자가 접속하는 웹사이트, 앱 또는 서비스에서 실제 IP 주소를 숨기거나 다른 도시나 국가에 있는 것처럼 보이게 하지 않습니다. 계정에 로그인하면 서비스는 사용자가 누구인지 알고 있습니다. 브라우저에 쿠키, 저장된 세션, 광고 식별자 또는 식별 가능한 지문이 있는 경우 DoH는 이러한 신호를 지우지 않습니다.

또한 시스템 수준에서 설정되어 있고 애플리케이션이 해당 설정을 준수하지 않는 한 모든 애플리케이션을 보호하는 것은 아닙니다. 예 를 들어, 같은 기기에서 한 브라우저는 보안 DNS를 사용하지만 다른 애플리케이션은 다른 DNS 경로를 사용할 수 있습니다 . 일부 앱은 자체 네트워크를 관리하며 시스템이나 브라우저 설정과 항상 일치하지는 않습니다. 따라서 DoH는 완벽한 보호라는 잘못된 인식을 심어줄 수 있습니다. DNS 쿼리의 개인 정보 보호는 향상시키지만, VPN처럼 파일 전송, 메시지 트래픽, 화상 통화, 게임 연결, 백그라운드 동기화 또는 스트리밍 애플리케이션을 보호하지는 않습니다.

VPN은 무엇을 보호하고 무엇을 숨길 수 없을까요?

VPN은 인터넷 여정의 다른 부분을 보호합니다. VPN 은 사용자의 기기와 VPN 서버 사이에 암호화된 터널을 생성하여 인터넷 트래픽을 해당 서버를 통해 라우팅합니다 . 인터넷 서비스 제공업체(ISP) 또는 로컬 Wi-Fi 네트워크는 사용자가 접속하는 모든 사이트와 서비스를 직접 볼 수 있는 것이 아니라 VPN 서버와의 암호화된 연결만 보게 됩니다. 또한 VPN은 웹사이트와 앱이 보는 공용 IP 주소를 변경합니다. 즉, 집이나 이동통신사의 IP 주소 대신 VPN 서버의 IP 주소를 보게 됩니다. 이를 통해 위치 기반 추적을 줄이고, 일부 ISP 프로필을 우회하며, 공용 Wi-Fi를 더욱 안전하게 사용할 수 있습니다.

종합적인 VPN은 브라우저, 스트리밍 앱, 이메일 클라이언트, 클라우드 백업 도구, 메시징 앱, 게임 및 백그라운드 서비스를 보호할 수 있습니다. 또한 제대로 설정하면 암호화된 터널을 통해 DNS 요청을 라우팅할 수 있으므로 DNS 유출 테스트를 실행하는 것이 좋습니다. 하지만 VPN이 마법과 같은 것은 아닙니다. 소셜 네트워크, 이메일 계정, 스트리밍 서비스 또는 온라인 쇼핑몰에 로그인하면 해당 서비스는 여전히 사용자가 누구인지 알고 있습니다. VPN은 사용자의 원래 IP 주소를 숨길 수는 있지만 로그인 정보를 익명화하지는 않습니다. 이름, 이메일 주소, 결제 정보, 배송 주소, 사진 또는 메시지와 같이 직접 전송하는 모든 정보에도 동일하게 적용됩니다.

쿠키와 브라우저 지문은 여전히 ​​중요합니다. 앱은 광고 식별자, 권한, 위치 접근, 블루투스 스캔, 주변 Wi-Fi 이름 및 스캔 도구를 통해 유사한 문제를 일으킬 수 있습니다. 악성 소프트웨어 또한 VPN 터널에 도달하기 전에 데이터를 탈취할 수 있기 때문에 어려운 문제입니다 . 요컨대, VPN은 많은 활동을 숨기고 암호화하지만 모든 디지털 지문을 감출 수는 없습니다.

DoH와 VPN은 동시에 사용할 수 있습니다.

네, 함께 사용할 수 있지만, 최적의 설정은 기기, 브라우저, VPN 앱이 DNS를 처리하는 방식에 따라 달라집니다. 대부분의 경우 가장 간단한 해결책은 VPN이 DNS를 처리하도록 하는 것입니다 . 좋은 VPN 앱은 암호화된 터널을 통해 DNS 쿼리를 전송하므로 ISP가 직접 쿼리를 수신하지 않습니다. 이렇게 하면 브라우저 설정을 별도로 조정할 필요 없이 VPN 연결의 일부로 DNS 개인 정보 보호를 누릴 수 있습니다.

이 문제는 브라우저가 자체 도메인 관리 기관(DoH) 구성을 사용하는 반면 VPN은 시스템 수준에서 DNS를 관리하려고 할 때 발생합니다. 심각한 오류는 발생하지 않을 수 있지만 혼란이 생길 ​​수 있습니다 . 모든 쿼리가 VPN을 통해 전송되는 것처럼 보일 수 있지만 실제로는 브라우저가 일부 쿼리를 다른 리졸버로 보내는 것입니다. 이때 DNS 유출 테스트가 유용합니다. VPN에 연결한 후 ISP의 DNS 서버가 표시되면 예상대로 작동하지 않는 것이고, VPN과 연결된 서버가 표시되면 구성이 제대로 작동하고 있을 가능성이 높습니다.

DoH만으로 충분한 경우는 언제이며, VPN을 사용하는 것이 더 나은 경우는 언제인가요?

DoH(보안 DNS)는 브라우저에서 DNS 쿼리의 기본적인 개인 정보 보호가 가장 중요한 경우 충분한 선택이 될 수 있습니다. 신뢰할 수 있는 홈 네트워크 환경에서 보안 DNS를 활성화하면 위치를 변경하거나 모든 애플리케이션을 보호하지 않고도 평문 노출을 줄일 수 있습니다 . 또한 DNS 필터링이나 조작이 우려되는 네트워크 환경에서도 유용합니다. HTTPS를 통해 전송하면 검사 또는 수정이 훨씬 어려워지기 때문입니다. 그렇다고 모든 제한을 우회하거나 검열을 완전히 차단하는 것은 아니지만, 암호화되지 않은 DNS에 비해 상당한 개선입니다. 게다가 DoH는 가볍습니다. VPN 서버를 선택하거나 라우팅을 크게 변경할 필요가 없으며, 일반적으로 속도 저하도 거의 느끼지 못할 것입니다.

VPN은 단순히 DNS 조회뿐 아니라 기기 전체를 ​​보호하고 싶을 때 가장 유용합니다. 공항, 호텔, 학교, 공유 오피스, 카페, 임대 숙소 등이 여기에 해당합니다 . 공유 네트워크에서는 누가 라우터를 제어하는지, 누가 연결되어 있는지, 누군가 트래픽을 가로채려고 하는지 알 수 없습니다. 또한 VPN은 ISP가 사용자의 인터넷 사용 패턴 프로필을 구축하는 것을 막는 데에도 도움이 됩니다. HTTPS가 웹페이지 콘텐츠를 보호하더라도 네트워크 메타데이터를 통해 유용한 패턴을 파악할 수 있기 때문입니다. 여행도 VPN을 사용하면 안정적인 연결을 유지하고, 익숙하지 않은 네트워크에서도 사용자를 보호하며, 웹사이트가 사용자의 임시 로컬 연결 대신 VPN 서버의 위치를 ​​표시하도록 할 수 있습니다.

Google Public DNS DoH API의 기술적 세부 정보

Google Public DNS는 두 가지 DoH API를 제공합니다. 하나는 RFC 8484를 준수하도록 설계되었으며 https://dns.google/dns-query에서 GET 및 POST 요청을 허용합니다. 다른 하나는 https://dns.google/resolve에서 GET 요청만 지원하는 JSON API입니다 . 또한 https://dns.google/에서 웹 인터페이스를 통해 브라우저에 JSON 결과를 표시할 수 있지만, 이 인터페이스는 완전한 API를 구현하지는 않습니다. 이 인터페이스는 API URL이나 https://dns.google/query와 혼동해서는 안 됩니다. 이 서비스는 보안되지 않은 HTTP URL을 지원하지 않으며, Google의 공용 DNS64 서비스에서도 DoH를 지원하지만 이 경우에는 IPv6만 지원합니다. Google의 보안 전송 문서에는 curl 예제와 TLS, DoT, DoH에 대한 자세한 내용이 포함되어 있습니다.

사용 가능한 HTTP 메서드

GET 메서드는 캐싱 효율이 높아 지연 시간을 줄일 수 있습니다. RFC 8484에 따르면 GET 요청에는 Base64Url로 인코딩된 DNS 메시지가 포함된 `?dns=` 매개변수가 반드시 포함되어야 하며 , JSON API에서 지원하는 유일한 메서드입니다. POST 메서드 역시 RFC 8484에서만 사용 가능하며, 요청 및 응답 본문에 `application/dns-message`가 포함된 바이너리 DNS 메시지를 사용합니다. HEAD 메서드는 현재 지원되지 않으며 400 Bad Request 오류를 반환합니다. 다른 메서드들은 501 Not Implemented 오류를 반환합니다.

상태 코드 및 오류

API는 알아두면 유용한 몇 가지 HTTP 코드를 반환합니다. 200 OK는 HTTP 구문 분석 및 DNS 확인자와의 통신이 성공했음을 나타냅니다 . 응답 본문은 엔드포인트, Accept 헤더 및 GET 매개변수에 따라 바이너리 DNS 응답 또는 JSON 형식일 수 있습니다. 참고: HTTP 오류는 DNS 오류일 수도 있으므로, SERVFAIL, FORMERR, REFUSED 또는 NOTIMP와 같은 오류가 있는지 확인하기 위해 JSON의 "Status" 필드와 같은 DNS 응답 코드를 확인하는 것이 좋습니다.

• 301호가 영구적으로 이전되었습니다: 클라이언트는 Location에 지정된 URL에서 요청을 다시 시도해야 합니다. 원래 요청이 POST 방식이었다면, 새 URL에 DNS 매개변수가 지정된 경우에만 GET 방식으로 다시 시도해야 하며, 그렇지 않은 경우에는 POST 방식으로 다시 시도해야 합니다. 302, 307, 308 상태 코드가 발생할 수 있으며, DoH 클라이언트는 이 네 가지 상태 코드를 모두 처리해야 합니다. 301 및 308 상태 코드는 영구적으로 캐시될 수 있습니다. 307 또는 308 상태 코드를 수신한 POST 요청은 항상 POST 방식으로 다시 시도해야 합니다.
• 400 잘못된 요청: GET 매개변수 구문 분석 문제 또는 잘못된 DNS 요청 메시지. 대부분의 잘못된 DNS 메시지는 FORMERR와 함께 200 OK 응답을 받지만, 질문 섹션이 없거나, 응답을 나타내는 QR 코드가 있거나, 의미 없는 코드 조합이 포함된 읽을 수 없는 메시지의 경우 HTTP 오류가 발생합니다.
• 413 페이로드 용량 초과: POST RFC 8484 요청 본문이 최대 메시지 크기인 512바이트를 초과했습니다.
• 414 URI가 너무 깁니다: GET 쿼리 헤더가 너무 크거나 DNS 매개변수가 512바이트를 초과했습니다.
• 415 지원되지 않는 미디어 유형: POST 본문에 콘텐츠 유형 헤더인 application/dns-message가 없습니다.
• 429 요청이 너무 많습니다: 지정된 기간 내에 너무 많은 요청이 전송되었습니다. 클라이언트는 Retry-After 헤더에 지정된 시간까지 기다려야 합니다.
• 500 내부 서버 오류: 보건부 서비스 내부 오류입니다.
• 501 구현되지 않음: GET과 POST 방식만 구현되어 있으며, 나머지는 이 오류를 반환합니다.
• 502 나쁜 게이트웨이 : DoH 서비스가 Google 공용 DNS 확인자와 통신할 수 없습니다. 다른 주소를 시도해 보면 해결될 수도 있지만, 더 효과적인 방법은 다른 DoH 서비스를 이용하거나 UDP 또는 TCP를 사용하는 기존 DNS 서버(8.8.8.8)로 전환하는 것입니다.

개인정보 보호 및 성능 향상을 위한 모범 사례

DoH 애플리케이션 개발자는 HTTP 헤더를 최소화해야 합니다. Cookie, User-Agent, Accept-Language와 같은 헤더는 클라이언트 구현에 대한 정보를 노출하고 익명성 해제에 기여할 수 있습니다 . DoH에 필요한 헤더, 즉 Host, Content-Type(POST 요청의 경우), 그리고 필요한 경우 Accept 헤더만 전송하는 것이 좋습니다. User-Agent 헤더는 개발 또는 테스트 버전에서만 포함해야 합니다. 또한 EDNS 패딩 옵션을 사용하여 쿼리를 일반적인 길이로 줄이고 트래픽 분석을 어렵게 하는 것이 좋습니다. HTTP/2 패딩도 가능하지만, EDNS 패딩과 달리 DoH 서버 응답에는 패딩이 생성되지 않습니다.

RFC 8484의 POST 메서드는 개인 정보 보호에 민감한 애플리케이션이나 브라우저 모드에서만 사용해야 합니다. POST를 사용하면 캐시 용량이 줄어들고 지연 시간이 증가할 수 있으므로 일반적으로 권장되지 않습니다 . 그러나 사용자가 최근 방문한 도메인을 파악하려는 웹 앱 동기화 공격을 방지하려는 애플리케이션의 경우 캐시 크기를 줄이는 것이 바람직할 수 있습니다. HTTPS 방식에는 다음과 같은 실질적인 이점도 있습니다. HTTPS API는 널리 사용 가능하고 지원되므로 구현이 간소화됩니다. HTTPS 서비스를 통해 웹 앱은 모든 유형의 DNS 레코드에 액세스할 수 있으므로 일반적으로 호스트-주소 조회로 제한되는 브라우저 또는 운영 체제 API의 한계를 극복할 수 있습니다. 또한 QUIC를 사용하여 UDP를 통해 HTTPS를 구현하는 클라이언트는 TCP에서 발생하는 라인 헤드 차단과 같은 문제를 방지할 수 있습니다. 버그를 발견했거나 새로운 기능을 요청하려면 일반적인 채널을 통해 DoH 관련 문제를 보고해 주십시오.

DoH 및 VPN 관련 자주 묻는 질문

가장 자주 묻는 질문 중 하나는 이미 VPN을 사용 중인 경우 DoH를 사용하는 것이 타당한지에 대한 것입니다. 가능은 하지만, 일반적으로 가장 실용적인 방법은 VPN이 DNS를 처리하도록 하고 , 누출 테스트를 통해 쿼리가 올바른 채널을 통해 전송되는지 확인하는 것입니다. 브라우저가 자체 쿼리를 한 방향으로 보내고 VPN이 다른 방향으로 보내는 경우, 예상치 못한 문제가 발생할 수 있습니다.

또 다른 일반적인 질문은 DoH가 인터넷 서비스 제공업체가 사용자의 웹사이트 방문 기록을 볼 수 없도록 막아주는지 여부입니다. DoH는 DNS 쿼리를 여러 관찰자로부터 숨기지만, 모든 메타데이터를 제거하거나 IP 주소를 숨기는 것은 아닙니다 . 즉, ISP는 여전히 사용자가 접속하는 IP 주소와 기타 네트워크 정보를 확인할 수 있습니다. 보다 포괄적인 보호를 위해서는 VPN을 사용하거나 여러 개인정보 보호 계층을 조합하여 사용하는 것이 좋습니다.

공용 Wi-Fi에서 DomainHost(DoH)만으로 충분한지 생각해 볼 필요가 있습니다. DoH 는 네트워크 운영자가 사용자의 DNS 쿼리를 쉽게 읽는 것을 방지하는 데 도움이 될 수 있지만, 전체 연결이나 모든 애플리케이션의 트래픽을 보호하지는 못합니다 . 공항, 호텔, 카페와 같은 곳에서는 VPN을 사용하는 것이 일반적으로 더 효과적이며, 특히 라우터를 누가 관리하는지 모르거나 다른 사람이 연결되어 있는 경우에는 더욱 그렇습니다.

도메인 이름 시스템(DoH)과 VPN은 직접적인 경쟁 관계가 아니라 서로 다른 기능을 가진 도구입니다. DoH는 도메인 조회를 암호화하여 해당 과정의 노출을 줄여줍니다. VPN은 기기와 서버 간의 경로를 암호화하고 목적지에서 보이는 IP 주소를 변경합니다 . 둘 다 사용자를 완전히 익명으로 만들지는 않습니다. 계정, 쿠키, 브라우저 지문, 앱 권한, 악성코드, 그리고 사용자가 직접 공유하는 모든 데이터는 여전히 사용자를 식별할 수 있습니다. 하지만 그렇다고 해서 둘 다 쓸모없는 것은 아닙니다. 단지 각각의 역할이 다를 뿐입니다. DoH는 주소 조회를 보호하고, VPN은 데이터가 이동하는 경로의 훨씬 더 많은 부분을 보호합니다.