Защита от DNS-утечек: скройте свои следы в сети

DNS-утечка происходит, когда ваше устройство отправляет запросы на разрешение доменных имён резолверу вне ожидаемого защищённого канала — как правило, резолверу вашего провайдера вместо резолвера VPN, — раскрывая каждый посещаемый сайт, даже когда остальной трафик зашифрован. Чтобы это предотвратить, направляйте DNS через туннель VPN (или через зашифрованный резолвер по DNS over HTTPS либо DNS over TLS), отключите откат к открытому тексту и закройте побочные каналы IPv6 и WebRTC. Быстрее всего убедиться в защищённости можно, запустив тест на DNS-утечки и проверив, какие IP-адреса резолверов появляются.

Что такое разрешение DNS и почему оно чувствительно для приватности

Каждый раз, когда вы открываете сайт, браузеру нужно перевести понятное человеку имя вроде browserinsight.net в числовой IP-адрес. Этот перевод выполняет система доменных имён (DNS). Ваше устройство обращается к DNS-резолверу — обычно его держит ваш интернет-провайдер, если вы не сменили настройки, — и резолвер возвращает адрес, чтобы можно было установить соединение.

Проблема приватности проста: тот, кто управляет этим резолвером, видит журнал каждого домена, который вы запрашиваете, с метками времени. Даже если страница загружается по HTTPS и её содержимое зашифровано, имя нужного вам сайта раскрывается на этапе DNS. По умолчанию классические DNS-запросы передаются открытым текстом по UDP на порту 53, поэтому они видны любому на сетевом пути, а не только оператору резолвера.

Думайте о DNS как об адресной книге интернета. Шифрование письма внутри конверта (HTTPS) мало чем поможет, если при каждой отправке вы громко выкрикиваете имя получателя.

Что такое DNS-утечка

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

Утечка «тихая», потому что внешне ничего не ломается — страницы по-прежнему загружаются нормально. Обнаружить её можно только тестированием.

Частые причины DNS-утечек

• Резолвер ОС в обход туннеля. Операционные системы иногда удерживают ранее настроенные DNS-серверы или используют стратегию «самый быстрый ответ», запуская гонку между резолвером VPN и резолвером провайдера, и могут выбрать неверный.
• Раздельное туннелирование (split tunneling). Если через VPN проходят только некоторые приложения или подсети, DNS для исключённого трафика — а иногда и для всего трафика — может уходить напрямую.
• Утечка через IPv6. Многие конфигурации VPN туннелируют только IPv4. Если в вашей сети есть IPv6 и VPN его игнорирует, DNS-запросы по IPv6 проскальзывают наружу незащищёнными.
• Неправильно настроенные или упрощённые клиенты. Некоторые VPN-приложения не навязывают собственный DNS или не восстанавливают защиту после ухода устройства в сон, смены сети либо переподключения.
• Прозрачный перехват DNS. Некоторые провайдеры перехватывают весь трафик на порту 53 и отвечают на него сами, независимо от настроенного вами резолвера, провоцируя утечки, если ваш DNS не зашифрован.

Почему это важно даже при использовании VPN

Люди часто полагают, что VPN делает их анонимными. VPN шифрует ваш трафик и скрывает ваш IP от серверов назначения, но защищает DNS только в том случае, если клиент настроен перехватывать и туннелировать эти запросы. При утечке DNS ваш провайдер — и любое правительство или рекламодатель, с которыми он делится данными, — может восстановить историю вашего просмотра по доменам, даже не читая содержимого страниц. Та же логика применима к WebRTC, который способен раскрыть ваш реальный IP прямо из браузера, полностью отдельно от DNS; об этом побочном канале читайте в нашем руководстве по предотвращению утечек IP через WebRTC.

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

Зашифрованный DNS: DoH, DoT и DNSCrypt

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

• DNS over HTTPS (DoH) отправляет DNS-запросы внутри обычного HTTPS-трафика на порту 443. Поскольку он выглядит как обычный веб-трафик, его трудно выделить или заблокировать, и он встроен прямо в современные браузеры (Chrome, Firefox, Edge) под названием «безопасный DNS».
• DNS over TLS (DoT) оборачивает DNS в TLS-сессию на выделенном порту (853). Он понятен и удобен для мониторинга на сетевом уровне, что делает его популярным для общесистемных и роутерных конфигураций, — но выделенный порт враждебной сети заблокировать проще.
• DNSCrypt — более старый протокол, который аутентифицирует и шифрует запросы между вами и поддерживающими его резолверами. Сегодня он встречается реже, но всё ещё используется некоторыми инструментами приватности.

Обычный DNS против DoH, DoT и DNS через туннель VPN

Метод	Транспорт / порт	Шифрование	Скрывает запросы от провайдера	Примечания
Обычный DNS	UDP/TCP 53	Нет	Нет	По умолчанию; виден провайдеру и наблюдателям на пути
DNS over HTTPS (DoH)	HTTPS 443	Да	Да	Сливается с веб-трафиком; для приложения или браузера
DNS over TLS (DoT)	TLS 853	Да	Да	Легко развернуть на уровне ОС/роутера; порт можно заблокировать
DNSCrypt	UDP/TCP, особый	Да	Да	Нишевый; аутентифицирует резолвер
DNS через туннель VPN	Внутри туннеля VPN	Да (через туннель)	Да (от провайдера)	Провайдер не видит ничего; вы доверяете резолверу VPN

Зашифрованный DNS скрывает ваши запросы от сети, но выбранный вами резолвер всё равно их видит. Выбирайте резолвер, которому действительно доверяете, — переход от «мой провайдер видит всё» к «логирующая третья сторона видит всё» улучшением не является. Для помощи в оценке провайдеров смотрите наше сравнение инструментов приватности.

Шифрование — не то же самое, что доверие: целостность DNS-ответа

Всё вышеописанное защищает конфиденциальность DNS — не даёт сетевому пути и вашему провайдеру увидеть, какие имена вы запрашиваете. Но это ничего не говорит о том, подлинен ли полученный ответ. Резолвер — или кто угодно, способный внедрить пакеты на пути к нему, — может вернуть поддельный IP-адрес для домена, и шифрование DoH/DoT этого не заметит: подделанный ответ просто приходит по зашифрованному каналу вместо открытого. Проверка того, что сам ответ не был подменён, — отдельная задача, которую решает DNSSEC (DNS Security Extensions): он позволяет резолверу криптографически подтвердить, что ответ действительно пришёл от авторитетных серверов домена и не был изменён при передаче.

Инцидент с .al: что происходит, когда DNSSEC ломается

В июле 2026 года домен верхнего уровня Албании .al стал недоступен для резолверов, проверяющих DNSSEC. Оператор реестра опубликовал новый ключ подписи, но DS-запись в корневой зоне — указатель, сообщающий валидаторам, какому ключу доверять, — по-прежнему ссылалась на старый. Это несоответствие разом разорвало цепочку доверия для всех доменов .al: валидирующий резолвер считает подписанный, но непроверяемый ответ ошибкой, а не молча принимает его, поэтому запросы к сайтам .al начали проваливаться. Затем оператор реестра вовсе удалил новый ключ, не оставив ни одного действующего, а в итоге DS-запись была полностью убрана из корневой зоны, и .al остался без подписи. Полную хронологию событий Cloudflare привела в своём разборе инцидента.

Негативные якоря доверия: обмен валидации на доступность

Столкнувшись с тем, что целый ccTLD стал нерезолвируемым, Cloudflare примерно за три часа применила к .al на 1.1.1.1 негативный якорь доверия (negative trust anchor, NTA). NTA — это экстренная настройка на стороне резолвера, которая заставляет валидатор прекратить проверку подписей DNSSEC для конкретной сломанной зоны, чтобы пользователи могли продолжать заходить на эти сайты, — сознательный отказ от защиты от подделанных ответов ради восстановления доступности. Это крайняя мера: применяя её, оператор резолвера решает, что «работает, но без проверки» лучше, чем «корректно проверено, но недоступно», пока оператор зоны не исправит подпись.

Расширенная ошибка DNS 33: делаем этот компромисс видимым

Проблема NTA в том, что его эффект исторически был незаметен — ответ, выданный под негативным якорем доверия, выглядел точно так же, как полностью прошедший проверку DNSSEC. RFC 8914 (Extended DNS Errors) закрывает этот пробел, определяя машиночитаемые коды ошибок, которые резолвер может прикрепить к ответу. 1.1.1.1 теперь возвращает код EDE 33 («RRSIGs Missing») для ответов, покрытых негативным якорем доверия, что означает: это настоящий, подлинный ответ, но он не прошёл проверку DNSSEC. Инструменты и резолверы, читающие коды EDE, теперь могут различать эти две ситуации, а не считать их одинаково надёжными.

Как заслуживающий доверия VPN должен маршрутизировать DNS

Хорошо построенный VPN не просто шифрует ваши данные — он полностью владеет DNS. В частности, он должен:

• Запускать собственные DNS-резолверы внутри туннеля, чтобы запросы никогда не касались вашего провайдера.
• Принудительно направлять весь DNS через туннель, переопределяя настроенные в ОС серверы, без гонок «самого быстрого ответа», утекающих на порт 53.
• Обрабатывать или отключать IPv6, чтобы запросы по IPv6 не могли ускользнуть из туннеля, рассчитанного только на IPv4.
• Включать аварийный выключатель (kill switch), который блокирует весь трафик — включая DNS, — если туннель отключается, вместо отката к резолверу провайдера.

Если VPN-клиент не предлагает ни одной из этих гарантий, считайте его склонным к утечкам, пока не проверите сами.

Как протестировать DNS-утечку

Тестирование занимает минуту и является единственным способом убедиться. Подключите VPN (или включите зашифрованный DNS), затем проверьте, какие IP-адреса резолверов отвечают на ваши запросы. Если вы видите резолвер своего провайдера или адрес, который геолокация относит к вашему домашнему региону, вместо резолвера VPN — у вас утечка. Насколько точно IP резолвера на самом деле указывает на ваше местоположение — это отдельный вопрос; см. насколько точна IP-геолокация на самом деле.

В командной строке можно осмотреть разрешение напрямую:

# Какому резолверу уходит и от какого возвращается один запрос?
nslookup browserinsight.net

# Linux (systemd-resolved): показать DNS-серверы, реально используемые на каждом интерфейсе
resolvectl status

# Linux/macOS: посмотреть резолвер, вернувший ответ на запрос (смотрите SERVER:)
dig browserinsight.net

Посмотрите на строку Server: / SERVER:: там должен быть резолвер вашего VPN или выбранный вами провайдер зашифрованного DNS, но никогда — узел вашего провайдера. Чтобы увидеть, как внешний мир воспринимает вас со стороны браузера, запустите проверку IP от BrowserInsight до и после подключения — IP и определяемая сеть должны измениться. Проверка VPN/прокси поможет подтвердить, что ваш трафик выходит там, где вы ожидаете.

Это подтверждает, какой резолвер ответил, но не то, проверял ли он ответ. Чтобы проверить и это, выполните dig +dnssec browserinsight.net и посмотрите на флаг ad (Authenticated Data) в заголовке ответа — его наличие означает, что резолвер провалидировал DNSSEC для этого ответа. Если ваш резолвер поддерживает расширенные ошибки DNS, код EDE в ответе (например, код 33, о котором шла речь выше) подскажет, что он намеренно пропустил проверку для сломанной зоны, а не просто не поддерживает валидацию вовсе.

Конкретные шаги предотвращения

Операционная система

• Задайте доверенный резолвер для всей системы. В Windows 11 «Параметры → Сеть → Назначение DNS-сервера» позволяет включить зашифрованный DNS (DoH). В macOS установите DNS-профиль или используйте клиент, навязывающий DoH/DoT. В Linux настройте systemd-resolved с DNSOverTLS=yes и явной записью DNS=.
• Отключите IPv6, если ваш VPN его не туннелирует, либо используйте VPN, который явно обрабатывает IPv6, чтобы не было утечки через стек v6.
• Включите аварийный выключатель VPN, чтобы при разрыве туннеля не происходил откат к открытому DNS.

Браузер

• Включите безопасный DNS / DNS over HTTPS в настройках браузера (Chrome: «Конфиденциальность и безопасность → Безопасность → Использовать безопасный DNS»; Firefox: «Настройки → Приватность и защита → DNS over HTTPS»).
• Отключите WebRTC или используйте расширение, не дающее WebRTC раскрывать локальные и публичные IP, — это отдельная от DNS утечка, но не менее выдающая.
• Избегайте расширений, которые незаметно меняют ваши настройки DNS или прокси.

Роутер

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

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

Предотвращает ли использование VPN DNS-утечки автоматически?

Нет. VPN предотвращает DNS-утечки только в том случае, если его клиент принудительно направляет DNS через туннель и обрабатывает IPv6. Многие утечки случаются во время работы VPN, потому что ОС тихо продолжает пользоваться резолвером провайдера. Всегда тестируйте, а не предполагайте.

Зашифрованный DNS (DoH/DoT) — это то же самое, что VPN?

Нет. Зашифрованный DNS защищает только разрешение доменных имён; он скрывает от сети, какие сайты вы запрашиваете, но не шифрует остальной трафик и не скрывает ваш IP от посещаемых сайтов. VPN делает последнее. Эти два средства дополняют друг друга, а не взаимозаменяемы.

Сможет ли провайдер по-прежнему видеть, какие сайты я посещаю, если я использую DoH?

После шифрования через DoH ваш провайдер больше не может читать ваши DNS-запросы, поэтому не может так логировать домены. Однако он всё ещё может вывести некоторые адресаты по IP-адресам, к которым вы подключаетесь, и по имени сервера (SNI), отправляемому во время TLS-рукопожатия. DoH закрывает именно DNS-канал.

Как узнать, каким резолвером я на самом деле пользуюсь?

Запустите nslookup или dig и прочтите строку Server:, либо используйте resolvectl status в Linux. Для быстрого внешнего взгляда проверка IP от BrowserInsight показывает IP и сеть, которые видит внешний мир; при подключении они должны совпадать с вашим VPN, а не с домашним провайдером.

Означает ли зашифрованный DNS, что ответу можно доверять?

Нет — шифрование (DoH/DoT) и валидация (DNSSEC) решают разные задачи. Зашифрованный DNS скрывает от сети, какие сайты вы запрашиваете; DNSSEC подтверждает, что полученный ответ действительно пришёл от настоящих серверов домена и не был подделан или изменён при передаче. Одно может быть без другого: запрос по DoH может вернуть полностью провалидированный ответ, непровалидированный ответ, либо — как случилось во время сбоя DNSSEC у .al в июле 2026 года — ответ, выданный под негативным якорем доверия резолвера: подлинный, но явно непроверенный. Резолвер, поддерживающий расширенные ошибки DNS, может пометить такой компромисс (например, кодом EDE 33), вместо того чтобы оставлять его незаметным.

Утечка DNS раскрывает ваши собственные запросы не тому резолверу, но DNS-разрешение можно развернуть и в обратную сторону против вас: владелец сайта может через CNAME-запись направить поддомен на серверы трекера, чтобы ответы трекера выглядели как first-party. О том, как это работает и какие браузеры теперь это распознают, см. CNAME cloaking: как трекеры маскируются под first-party.

DNS обычно становится самой большой отдельной утечкой после перехода на HTTPS повсеместно, но это не единственный остаток метаданных на зашифрованном соединении — о том, как DNS соотносится с IP назначения, SNI и временем трафика, читайте в статье «Что провайдер всё ещё видит, когда вы используете HTTPS».

Рекомендуемое чтение

• Защита от утечек WebRTC: обязательно к прочтению пользователям VPN
• Сравнение инструментов приватности: VPN, прокси и зашифрованный DNS
• CNAME Cloaking: как трекеры маскируются под first-party
• Что провайдер всё ещё видит, когда вы используете HTTPS