DNS over HTTPS и прокси: может ли DNS обойти прокси?

Краткий ответ

Да. Сайт может загружаться через прокси, в то время как DNS-запрос для этого сайта отправляется напрямую с вашего устройства на DNS over HTTPS (DoH) сервер. При этом соединение с DoH-сервером тоже может проходить через прокси. А если приложение передает имя сайта непосредственно прокси-серверу, устройству вообще может не потребоваться выполнять собственный DoH-запрос для этого имени.

DoH шифрует обмен данными с DNS-резолвером. Но сам по себе этот факт ничего не говорит о маршруте до резолвера. В проверяемом профиле браузера сначала выясните, передает ли браузер имя сайта прокси-серверу или разрешает его самостоятельно. Затем проверьте, как браузер подключается к DoH-серверу. Страница проверки IP может подтвердить выходной IP веб-трафика, но не отвечает ни на один из этих DNS-вопросов.

Главное

• Прокси, используемый для загрузки веб-страниц, может не использоваться для соединения приложения с DoH-сервером.
• При прямом DoH наблюдатель в локальной сети видит соединение с резолвером, но не запрашиваемое доменное имя внутри HTTPS. Сам резолвер может прочитать запрос и видит IP-адрес, с которого было установлено соединение.
• DNS-запросы для proxy.example или dns.example могут понадобиться просто для подключения к этим сервисам. Они отличаются от DNS-запроса для посещаемого сайта.
• В Firefox уровень защиты Default может переключиться на DNS-резолверы по умолчанию, если DoH не работает. Другие клиенты используют собственные правила резервного разрешения.
• Браузерный DNS-тест показывает резолверы, обнаруженные во время собственных тестовых запросов. Он не определяет, прошло ли HTTPS-соединение с DoH-резолвером через прокси.

Какие соединения нужно различать?

Открытие example.com через прокси не обязательно приводит к DNS-запросу для example.com на вашем устройстве. Клиент с удаленным разрешением имен передает hostname прокси-серверу. Клиент, который сначала разрешает имя через DoH, создает отдельное соединение со своим DNS-резолвером, и этому соединению нужен собственный маршрут.

Проверку могут усложнить еще два имени. Прежде чем клиент сможет подключиться к proxy.example, ему нужно получить IP-адрес proxy.example. Аналогичная ситуация возникает с DoH-сервисом dns.example: клиенту нужен его адрес до того, как он сможет открыть HTTPS-соединение. Некоторые реализации используют для такого первоначального запроса обычный механизм DNS; например, libcurl документирует такое поведение для имени своего DoH-сервера. Запросы этих служебных имен сами по себе не означают, что example.com разрешался в обход прокси.

Когда DNS действительно обходит прокси?

Предположим, ваша конфигурация должна направлять через прокси и загрузку веб-страниц, и соединения с DNS-сервисом. Если соединение с DoH-сервером устанавливается напрямую, это нарушает такое правило, даже если сама страница по-прежнему загружается через прокси.

Рассмотрим три варианта маршрута для example.com.

Путь 1. Клиент передает example.com прокси-серверу как hostname, а прокси самостоятельно получает его IP-адрес перед подключением. Для этого запроса клиенту не нужно разрешать example.com самостоятельно. При этом ему все еще может потребоваться разрешить имя самого прокси-шлюза или другие служебные имена.

Путь 2. Клиент получает IP-адрес example.com у своего DoH-сервера, а затем передает этот IP прокси. Если HTTPS-соединение с DoH-сервером идет напрямую, только последующее соединение с сайтом проходит через прокси. Это обход предполагаемого маршрута. DoH-сервер получает DNS-запрос и видит источник прямого соединения, хотя сам сайт видит IP-адрес прокси.

Путь 3. Приложение подключается к DoH-серверу через тот же прокси, а затем через этот прокси соединяется с сайтом. DNS-обмен остается зашифрованным до DoH-сервера. При этом резолвер все равно узнает запрашиваемое имя: прокси и DNS-сервис выполняют разные задачи.

Переключатель с надписью «DoH включен» не показывает, по какому маршруту прошел конкретный запрос. Он выбирает способ разрешения имен, а не ведет журнал маршрута каждого запроса.

Почему включенный DoH не обязательно применяется к каждому запросу?

Firefox наглядно показывает это различие в настройках DNS over HTTPS. При уровне защиты Default проблема с DoH может привести к выполнению запроса через DNS-резолверы по умолчанию. При уровне Max Firefox вместо этого показывает предупреждение, если защищенный резолвер недоступен, и позволяет создать исключение для домена.

Автоматически включенный DoH также может стать неактивным из-за условий сети. Перед интерпретацией результатов DNS-теста зафиксируйте и выбранный уровень защиты, и отображаемый статус: Active, Not active или Off. Отсутствие DoH-запроса для отдельного имени также может объясняться закэшированным адресом или исключением для домена.

Другие программные клиенты могут работать иначе. В libcurl параметр CURLOPT_DOH_URL, установленный для передачи, не распространяет proxy options этой передачи на DoH-разрешение имени. Libcurl также документирует исключения, которые продолжают использовать его стандартный резолвер.

Поэтому, если сервис проверки IP показывает адрес вашего прокси, соединение с DoH-сервером все равно нужно проверять отдельно. Ответ веб-сервиса ничего не говорит о маршруте DNS. Эти особенности относятся к libcurl и не описывают универсальную DNS-политику браузеров.

Что на самом деле показывает браузерный DNS-тест?

Публичный тест – полезная первая проверка. Запускайте его в том же профиле браузера, который используется для вашей задачи. Запишите внешний IP-адрес, список обнаруженных резолверов и текущий статус DoH.

Также проверьте, какие настройки прокси действительно используются этим профилем и существуют ли исключения. Если вы используете Firefox, отдельно проверьте настройки прокси и исключения. Расширение браузера, системная настройка или файл автоматической конфигурации прокси могут менять маршрут отдельных запросов.

У результата DNS-теста есть важное ограничение. Он фиксирует резолверы, участвовавшие в запросах самой тестовой страницы. Он не трассирует соединение браузера с его DoH-провайдером.

Поэтому наличие публичного резолвера в результатах говорит о том, куда пришли соответствующие DNS-запросы, но не показывает, подключался ли браузер к этому резолверу напрямую. Страна, указанная рядом с резолвером, дает еще меньше информации о маршруте: DNS-резолвер и выходной узел веб-трафика – разные системы.

Для контролируемой проверки при каждом запуске запрашивайте новый случайный поддомен домена, которым вы управляете. Повторное использование одного и того же имени может привести к тому, что ответ из кэша скроет новый DNS-запрос.

Запишите время проверки и профиль браузера, а затем сравните authoritative DNS log с соединениями клиента к DoH endpoint и с обычным DNS-трафиком. В authoritative-журнале обычно будет виден рекурсивный резолвер, который запрашивал ответ.

Но чтобы определить, прошло ли DoH-соединение самого клиента через прокси, все равно нужны данные со стороны клиента. Authoritative DNS log не показывает этот участок маршрута.

Как исправить обнаруженный маршрут?

Если вам нужно разрешение имен на стороне прокси, найдите в приложении настройку, которая передает прокси hostname, а не уже разрешенный IP-адрес. Название и наличие такой настройки зависят от клиента и используемого прокси-протокола.

После изменения повторите тест в том же приложении. Простая замена системного DNS-сервера не заставляет прокси самостоятельно разрешать доменные имена.

Если выбранный DoH-провайдер тоже должен быть доступен только через прокси, проверьте, применяет ли приложение настройки прокси к DoH-трафику. Настройка, распространяющаяся только на загрузку страниц, не обязательно охватывает это соединение.

После изменения повторите проверку и посмотрите, что делает клиент, когда DoH-провайдер недоступен. Резервный переход на системный DNS может нарушить ожидаемый вами маршрут.

При этом прямое DoH-соединение может быть именно тем, что вам нужно, если цель – зашифровать DNS в локальной сети и нет требования направлять через прокси абсолютно все соединения. В такой конфигурации различие между DNS-резолвером и выходным узлом прокси ожидаемо. Важнее убедиться, что клиент использует выбранный вами резолвер.

Практические примеры

Случай 1

Страница проверки IP показывает ожидаемый адрес прокси, а DNS-тест указывает публичный резолвер, выбранный в браузере.

Это гипотетический пример, а не результат проведенного нами тестирования. Такая комбинация совместима как с DoH через прокси, так и с прямым DoH.

Прежде чем менять прокси, проверьте статус DoH в браузере, исключения из прокси и маршрут соединения браузера с этим резолвером.

Случай 2

Задача libcurl использует прокси для веб-запроса и отдельно задает DoH URL. Веб-ответ приходит через ожидаемый выходной IP прокси.

Это не подтверждает маршрут DNS: DoH-разрешение не наследует proxy options родительской передачи. Разработчику нужно отдельно проверить соединение с DoH-сервером и первоначальное разрешение hostname самого DoH-сервера.

Такой тест скрипта ничего не говорит о поведении профиля браузера.

Проверьте используемый профиль браузера

После настройки прокси и DoH запустите DNS Leak Test в том же профиле браузера. Сохраните внешний IP-адрес, список резолверов и текущий режим DoH.

Результаты WebRTC и IPv6 отвечают на отдельные вопросы. Если список DNS-резолверов оказался неожиданным, вернитесь к настройкам DoH-провайдера, резервного разрешения и исключений прокси именно в этом профиле.

Скрипт или другой профиль браузера необходимо проверять отдельно.

Глоссарий

DoH – передача DNS-запросов и ответов между клиентом и резолвером через HTTPS.

Резолвер – сервис, который получает DNS-информацию для запрошенного hostname.

Удаленное разрешение (remote resolution) – передача hostname прокси-серверу, чтобы имя разрешалось на стороне прокси.

DNS fallback – альтернативный способ разрешения имени, который клиент может использовать в соответствии со своими правилами.

Итоги

Страница проверки IP позволяет разобраться только с маршрутом веб-запроса.

Для интересующего вас hostname сначала определите, передал ли клиент имя прокси-серверу, разрешил его через DoH или после сбоя воспользовался системным DNS-резолвером. Затем отдельно проверьте маршрут любого DoH-соединения.

Такие наблюдения позволяют найти конкретную настройку, которую нужно изменить, вместо того чтобы делать выводы только по имени обнаруженного DNS-резолвера.

Часто задаваемые вопросы

Здесь мы ответили на самые часто задаваемые вопросы. Все равно не можешь найти ответа?

Задать вопрос

Может ли подключение к DoH-серверу потребовать обычного DNS-запроса?

Да. Клиент не может открыть HTTPS-соединение с dns.example, пока не узнает IP-адрес dns.example.

Например, libcurl использует стандартный механизм разрешения для имени своего DoH-сервера. Это отдельный запрос, и он не является доказательством того, что имя посещаемого сайта утекло за пределы предполагаемого маршрута.

Заставит ли блокировка порта 53 направлять DoH через прокси?

Нет. Правило firewall для обычного DNS не может заставить HTTPS-соединение с DoH-сервером следовать настройкам прокси.

Кроме того, блокировка может нарушить резервное DNS-разрешение или разрешение имени самого прокси-шлюза.

Почему статус DoH в Firefox изменился на Not active после включения прокси?

Firefox может отключать автоматически активированный DoH при определенных условиях сети. В документации реализации обнаружение прокси указано среди возможных причин.

В Firefox откройте Settings → Privacy & Security и сравните отображаемый статус DoH с выбранным уровнем защиты.