Предотвращение утечек DNS: пути разрешения, прокси и проверки

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

Устранение утечки сводится к вопросу принадлежности: для каждого запроса нужно знать, кто разрешает имя, где находится этот резолвер и кто может читать его журналы. Ниже эти вопросы разобраны для SOCKS5, SOCKS5H и HTTP CONNECT, сравниваются типовые меры и пробел, который остаётся у каждой, а в конце описан тест утечек, где любое расхождение считается проваленной проверкой.

TL;DR

• socks5:// может разрешать имена локально, а socks5h:// передаёт имя хоста прокси.
• Чистая загрузка страницы не доказывает, что prefetch, dns-prefetch, IPv4 и IPv6 используют ожидаемый резолвер.
• Запишите ожидаемые оператор и регион, а необъяснимый резолвер считайте провалом проверки.

Contents

• Кто разрешает имя хоста
• Что раскрывает утечка
• Предварительная загрузка и другие запросы, которые нужно проверять отдельно
• Выбор между SOCKS5H, локальным DNS, системным DNS, DoH и DNS через VPN
• Запуск теста утечек и чтение результата
• Заключение

Кто разрешает имя хоста

В статье глоссария MDN о DNS описана система, которая сопоставляет доменные имена и IP-адреса. Браузеру нужно это сопоставление до открытия соединения, поэтому каждая навигация, каждый встроенный ресурс и каждый фоновый запрос ставят один и тот же вопрос: какой компонент выполняет разрешение. Когда на пути стоит прокси, кандидатов несколько, и ответ определяет схема прокси.

Три распространённых варианта ведут себя по-разному:

• SOCKS5. Браузер разрешает имя локальным резолвером и передаёт прокси IP-адрес. Запрос выполняется вне маршрута прокси, поэтому имя видит резолвер локальной сети.
• SOCKS5H. Браузер передаёт прокси само имя хоста, и прокси разрешает его сам. Локальный резолвер не спрашивают об именах, которые идут через это соединение.
• HTTP CONNECT. Браузер указывает целевой хост в запросе на туннель, и прокси-сервер сам подключается к нему. Разрешение имени цели обычно происходит на стороне прокси.

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

Спецификация SOCKS5, RFC 1928, позволяет клиенту отправить прокси либо адрес, либо доменное имя. Схема socks5h://, которую используют браузеры и утилиты командной строки, является соглашением на стороне клиента для выбора второго варианта. Читайте схему в своей конфигурации буквально: socks5:// и socks5h:// означают разные решения, и одна буква переносит запрос с вашего компьютера к провайдеру.

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

Что раскрывает утечка

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

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

Третье раскрытие связано с журналами, которые вы не контролируете. Резолвер может хранить записи об именах, на которые он ответил. Если направить браузер к другому резолверу, изменится только то, у кого хранятся эти записи, но сами записи не исчезнут. Поэтому полезный вопрос никогда не звучит как «скрыт ли DNS», а звучит как «какой оператор видит эти имена, в каком регионе и совпадает ли он с оператором и регионом, которые вы выбрали».

Важны и семейства адресов. Браузер, который может использовать IPv4 и IPv6, способен добраться до назначения по семейству, не охваченному маршрутом прокси, поэтому тест, проверяющий только одно семейство, может пропустить утечку. Выясните, какие семейства адресов поддерживают ваш прокси и тест утечек, и сопоставьте их с ожидаемым поведением.

Предварительная загрузка и другие запросы, которые нужно проверять отдельно

Браузеры разрешают имена до того, как их просят загрузить. Страница с множеством ссылок может в фоне запускать запросы для целей этих ссылок, а адресная строка может разрешать имя хоста, пока человек ещё печатает. Эти упреждающие запросы, включая prefetch и dns-prefetch, идут по пути разрешения самого браузера, а не по пути соединения, которое вы открыли намеренно. Если этот путь выходит за маршрут прокси, среди раскрытых имён оказываются сайты, которые вы никогда не посещали.

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

Упреждающие запросы можно проверить, не полагаясь на публичную страницу теста. Возьмите домен, который вы контролируете и авторитетный сервер имён которого записывает запросы, опубликуйте страницу со ссылкой на уникальное имя хоста в этом домене, откройте её через настроенный маршрут и посмотрите, какие адреса резолверов появились в журнале запросов сервера. Запрос с адреса, который не принадлежит ни вашему провайдеру, ни выбранному вами резолверу, является утечкой, которую тест на одной странице не показал бы.

Кэширование усложняет картину. Имя, разрешённое ранее в том же сеансе, позже может быть отдано из памяти, поэтому чистый результат при втором посещении мало что доказывает. Запускайте браузер заново, используйте имена хостов, которые раньше не разрешались, и повторяйте проверку после каждого изменения конфигурации.

Отличаются и режимы отказа. Когда настроенный резолвер недоступен, некоторые конфигурации молча переключаются на другой, и это переключение становится новым путём, который описанный ниже тест должен обнаружить. Предпочитайте конфигурации, которые отказывают заметно, тем, что тихо перенаправляют запросы в другое место, и выясняйте свой случай, блокируя резолвер в собственной тестовой среде и наблюдая за поведением браузера.

Выбор между SOCKS5H, локальным DNS, системным DNS, DoH и DNS через VPN

Ни одна мера не закрывает все пробелы, поэтому полезно сравнивать остаточный пробел, который оставляет каждая. Варианты помогают разобрать четыре вопроса: кто разрешает имя, в каком регионе, кто может его записать и действует ли настройка только на этот браузер или на всю машину.

SOCKS5H. Он не пускает имена, идущие через соединение с прокси, к локальному резолверу и не требует от браузера никаких функций, кроме самой схемы. Пробелы здесь такие: собственный вышестоящий резолвер провайдера, который вы не можете проверить, прокси без поддержки удалённого разрешения и запросы, которые браузер делает вне соединения через прокси.

Локальный DNS браузера с --bot-local-dns. Встроенный резолвер BotBrowser делает разрешение независимым от поведения DNS у провайдера, что помогает, когда провайдер блокирует, переписывает или замедляет запросы. Пробел в том, что он управляет только стороной браузера. Он не меняет того, что провайдер делает для соединения, которое провайдер разрешает сам, а если указать ему конкретный DNS-сервер, этот сервер становится новым наблюдателем, которому вам придётся доверять.

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

DNS через HTTPS. RFC 8484 передаёт сообщения DNS поверх HTTPS, и наблюдатели на сетевом пути не могут ни прочитать их, ни изменить. Резолвер по-прежнему видит каждое имя, его регион по-прежнему должен совпадать с маршрутом, а сама настройка не решает, кто выполняет разрешение. Элементы управления браузера и ограничения резолвера разобраны в статье о DNS через HTTPS.

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

Комбинации полезны, когда пробелы не пересекаются, например SOCKS5H плюс осознанно выбранный резолвер на стороне браузера. Но они добавляют решений, и каждый новый элемент становится ещё одним наблюдателем или ещё одним местом для расхождения. Выбирайте наименьший набор, наблюдателей которого вы можете назвать, а затем проверяйте его.

Когда выбор неочевиден, помогает простое правило. Если провайдер поддерживает SOCKS5H и вы доверяете его резолверу, начните с этого и проверьте результат. Если провайдер блокирует, переписывает или замедляет запросы либо предлагает только SOCKS5, резолвер на стороне браузера даёт политику, не зависящую от DNS провайдера. Если защита нужна и другим приложениям на машине, это задача операционной системы или VPN, а не параметра браузера.

Запуск теста утечек и чтение результата

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

1. Запишите адрес выхода прокси, его страну и оператора, которого для него указывает провайдер.
2. Запустите браузер заново с теми самыми параметрами, с которыми собираетесь работать.
3. Откройте тест утечек, например dnsleaktest.com, и запустите его расширенный тест, который выполняет несколько запросов, а не один.
4. Запишите каждый резолвер, о котором сообщает тест, вместе с его оператором и регионом.
5. Сравните этот список с шагом 1. Каждый резолвер должен принадлежать оператору и региону, которые вы можете объяснить.

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

Характер результата указывает на причину. Резолвер вашего собственного провайдера обычно означает, что имя было разрешено локально, поэтому проверьте схему и охвачена ли предзагрузка. Известный публичный резолвер не в том регионе указывает на DNS операционной системы, настройку DoH или VPN. Резолвер в правильном регионе, но у неожиданного оператора указывает на выбор вышестоящего резолвера провайдером, который можно изменить только сменой провайдера.

У теста утечек есть ограничения. Он показывает резолверы, которые серверы самого теста увидели в тот момент для имён хостов, использованных тестом. Он не наблюдает запросы к другим именам, не показывает журналы на стороне провайдера и не может доказать анонимность. Чистый результат свидетельствует лишь о том, что один путь совпал в один день.

Второе ограничение касается охвата. Разрешение имён является лишь одним из нескольких сетевых путей. Раскрытие адресов через WebRTC, адрес выхода самого прокси и транспортное поведение соединения проверяются отдельно, и успешный тест DNS ничего о них не говорит.

Параметры ниже показывают документированный способ запустить BotBrowser с прокси SOCKS5H и локальным резолвером:

chrome --bot-profile="path/to/profile.enc" \
       --proxy-server="socks5h://user:[email protected]:1080" \
       --bot-local-dns

Та же конфигурация из Playwright, где пути к исполняемому файлу и профилю берутся из окружения:

import { chromium } from 'playwright-core';
const browser = await chromium.launch({
  executablePath: process.env.BOTBROWSER_EXEC_PATH,
  headless: true,
  args: [
    `--bot-profile=${process.env.BOT_PROFILE_PATH}`,
    '--proxy-server=socks5h://user:[email protected]:1080',
    '--bot-local-dns',
  ],
});
const page = await browser.newPage();
await page.goto('https://www.dnsleaktest.com');
await browser.close();

Когда разные контексты браузера используют разные прокси, ожидание задаётся для каждого контекста отдельно. У каждого контекста свой выход, свой регион и, следовательно, свой ожидаемый оператор резолвера, поэтому запускайте последовательность по одному разу на каждый маршрут и храните результаты рядом. Один чистый результат для одного маршрута ничего не говорит о втором маршруте, который использует другого провайдера.

Заранее решите, что происходит после проваленной проверки. Лучше всего работает ограниченный ответ: остановить запуск, сохранить конфигурацию и список наблюдённых резолверов и менять по одной переменной за раз. Избегайте циклов повторных попыток, которые продолжают отправлять трафик, пока запросы остаются необъяснёнными, и не собирайте больше, чем оператор и регион.

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

Что поддерживает BotBrowser и что остаётся за его пределами

Параметр --bot-local-dns описан в документации как функция ENT Tier1. Параметр без значения или со значением true выполняет разрешение через встроенный резолвер браузера, false отключает его, и тогда имена разрешает прокси, а значение IP или IP:port отправляет запросы только на этот DNS-сервер, причём порт по умолчанию равен 53. Недопустимое значение трактуется как false. Если пользовательский сервер не возвращает ответа, BotBrowser не переключается на системный резолвер. Для поддерживаемых прокси-соединений в документации также сказано, что выбор целевого адреса при двойном стеке остаётся согласованным с активным маршрутом прокси без дополнительного параметра.

BotBrowser документирует --bot-local-dns (ENT Tier1) как встроенный DNS-резолвер, который делает разрешение имён независимым от поведения DNS у провайдера прокси, и направляет запросы предзагрузки DNS по тому же пути прокси, поэтому команда может применять повторяемую политику DNS и проверять её тестом утечек. BotBrowser не может контролировать или гарантировать вышестоящий DNS провайдера прокси, DNS-серверы и журналы вне браузера, а также то, как интерпретируется тест утечек, и он не заменяет выбор SOCKS5H или надёжного провайдера.

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

Заключение

Выберите самый короткий путь разрешения, для которого вы можете назвать оператора и регион. Проверьте его в новом сеансе с неиспользовавшимися именами хостов, включите упреждающие запросы и оба семейства адресов, а затем остановите выпуск, если наблюдаемый резолвер нельзя объяснить политикой прокси.

Источники

• Документация BotBrowser: предотвращение утечек DNS
• MDN: DNS
• RFC 8484: запросы DNS поверх HTTPS (DoH)
• RFC 1928: SOCKS версии 5
• Тест утечек DNS