Как реально работают DNS-лики (и как их чинить)
DNS-лик — это когда твои DNS-запросы (запросы, переводящие доменные имена в IP-адреса) идут на DNS-сервер, отличный от того, через который тебя направляет VPN. Результат: даже при активном VPN субъект, контролирующий тот DNS-сервер (обычно твой провайдер), видит каждый посещённый домен.
DNS-лики распространены. Случаются даже с приличными VPN-клиентами, часто незаметно для пользователя, и могут полностью обнулить пользу VPN для приватности. Вот техническая версия — почему и как чинить.
Что делает DNS и почему это важно
Когда вводишь example.com, компьютер спрашивает у DNS-сервера IP-адрес. Запрос — открытым текстом (с редкими исключениями ниже). Тот, кто обслуживает твой DNS, видит домен, на который ты пытаешься попасть.
Без VPN запросы обычно идут на DNS-сервер провайдера. Провайдер видит каждый домен, который ты ищешь — часто самые приватно-чувствительные метаданные о твоей интернет-активности.
С активным VPN, корректно настроенным, DNS-запросы должны идти через VPN-туннель и резолвиться на DNS-сервере VPN-провайдера. Провайдер видит зашифрованный туннель к VPN-провайдеру; что ты ищешь — не видит.
DNS-лик случается, когда что-то отправляет часть запросов в обход туннеля к другому резолверу — обычно провайдеру. Провайдер получает ту же видимость, как если бы VPN не было.
Как случаются DNS-лики
Несколько технических механизмов:
1. Windows SMHNR (Smart Multi-Homed Name Resolution). У Windows есть фича — отправлять DNS-запросы на несколько сетевых интерфейсов параллельно и использовать тот, что ответит первым. Если у тебя активен VPN и обычный сетевой интерфейс, Windows может отправить запросы на ОБА одновременно. DNS провайдера отвечает первым, потому что ближе; Windows использует этот ответ. DNS VPN видит тот же запрос и даёт избыточный ответ. Провайдер уже увидел запрос.
Это самая частая причина DNS-ликов в Windows. SMHNR включён по умолчанию. VPN-клиенты должны его активно отключать, идеально на уровне WFP (Windows Filtering Platform).
2. IPv6 DNS-лики. Многие VPN-клиенты туннелируют IPv4-трафик, но не обрабатывают IPv6 правильно. Если сеть поддерживает IPv6, а VPN не туннелирует IPv6 — IPv6 DNS-запросы идут к провайдеру. IPv4-трафик приватный; IPv6 DNS течёт с той же доменной информацией.
3. NRPT (Name Resolution Policy Table). Фича Windows, направляющая запросы конкретных доменов на конкретные DNS-серверы. Некоторые VPN-клиенты используют NRPT; при неправильной настройке часть запросов утекает.
4. Кэшированные DNS-записи. ОС держит DNS-кэш. Когда подключаешься к VPN, в кэше остаются записи, сделанные до VPN. Последующие запросы к тем доменам не генерируют новых лукапов; ОС использует кэшированный ответ. Сам кэш — не лик, но тайминг важен: если ты зашёл на сайт до подключения к VPN, тот заход был виден.
5. DNS уровня приложения. Некоторые приложения (Chrome, Firefox с включённым DoH) делают свои DNS-запросы в обход OS DNS. Если DNS приложения идёт другим путём, чем OS — может утекать.
6. WebRTC IP-лики (связано, но отдельно). WebRTC даёт peer-to-peer соединения в браузере. WebRTC может выдать реальный IP через STUN/TURN, даже когда трафик идёт через VPN. Не строго DNS-лик, но часто путают.
Обнаружение DNS-ликов
Стандартный тест:
- Подключи VPN
- Зайди на сайт-тест DNS-ликов (инструмент Fexyn /tools/dns-leak-test или сторонние вроде dnsleaktest.com)
- Запусти extended-тест
- Проверь резолверы в результате
Если резолверы принадлежат твоему VPN-провайдеру — лика нет. Если хоть один принадлежит провайдеру, домашнему провайдеру, OS DNS или кому-то кроме VPN — у тебя лик.
Для IPv6-ликов отдельно проверь, что тест покрывает IPv6 (часть старых инструментов проверяет только IPv4). Инструмент Fexyn покрывает оба.
Починка DNS-ликов
Реальные фиксы по типам клиентов:
Современные VPN-клиенты (Fexyn, ProtonVPN, Mullvad, NordVPN, ExpressVPN). Активно предотвращают DNS-лики через:
- WFP-фильтры, блокирующие DNS-запросы на нетуннельных интерфейсах
- Отключение SMHNR через реестр Windows / NRPT-конфигурацию
- Защита от IPv6-лика (полная блокировка IPv6 или туннелирование)
- Принудительное направление всех DNS-запросов через резолверы VPN
Если используешь один из них и видишь лики — что-то сломано, заводи тикет в поддержку. Лика быть не должно.
Старые или простые VPN-клиенты. Часто без одного или нескольких из вышеперечисленного. Фикс на стороне пользователя:
- Вручную настрой DNS сетевого адаптера на privacy-respecting резолвер (Cloudflare 1.1.1.1, Quad9 9.9.9.9) вместо автоматики
- Отключи IPv6 на сетевом адаптере полностью, если VPN его не обрабатывает
- Используй файрвол ОС для блокировки DNS-запросов куда-либо, кроме DNS VPN
DNS уровня приложения. Браузерные настройки DoH, обходящие OS DNS: отключи DoH, если хочешь, чтобы весь DNS шёл через VPN. Или настрой DoH на DoH-эндпоинт VPN-провайдера, если есть.
Как Fexyn предотвращает DNS-лики
Несколько слоёв:
1. WFP-фильтры блокируют DNS не в туннель. Когда VPN-туннель поднят, WFP-правила блокируют UDP/53 куда-либо, кроме DNS VPN. Даже Windows SMHNR не может утечь, потому что правила работают на уровне ядра.
2. SMHNR явно отключён. Установщик меняет ключ реестра, контролирующий SMHNR. Возвращается при удалении.
3. IPv6 обработан. Либо туннелируется (когда конфиг VPN это поддерживает), либо блокируется (когда конфиг IPv4-only). В обоих случаях открытые IPv6-запросы не текут.
4. Внутритуннельный DNS. Все DNS-запросы внутри туннеля резолвятся на наших DNS-серверах, не на внешних резолверах.
5. Boot-time persistence (опционально). WFP-правила переживают ребуты, так что DNS не течёт даже в окне между загрузкой и стартом VPN-клиента.
DoH и DoT — зашифрованный DNS
DNS-over-HTTPS (DoH) и DNS-over-TLS (DoT) — протоколы, шифрующие DNS-запросы между клиентом и резолвером. Полезны в двух сценариях:
Без VPN. Зашифрованный DNS не даёт провайдеру видеть запросы. DNS-резолвер всё равно их видит; ты сместил доверие с провайдера на резолвер. Cloudflare 1.1.1.1 с DoH — частая конфигурация.
С VPN. Belt-and-suspenders. VPN уже шифрует туннель; DoH внутри туннеля добавляет избыточное шифрование, которое не даст DNS VPN быть читаемым для VPN-провайдера в случае компрометации логов на стороне провайдера. Большинству пользователей этот слойный подход не нужен.
С зашифрованным DNS, но без VPN. Шифрованный DNS скрывает содержимое запросов от провайдера; провайдер всё равно видит метаданные подключения (какой DNS-резолвер, когда, как часто). В основном полезно, если хочешь немного DNS-приватности без оверхеда VPN.
Для максимальной DNS-приватности: VPN + DoH внутри туннеля + no-logs VPN-провайдер с зашифрованным upstream DNS. Стэк слоёв приватности; большинству не нужно.
Часто спрашивают
Как узнать, что мой VPN леакает DNS?
Запусти тест DNS-лика (Fexyn на /tools/dns-leak-test или сторонний). Если резолверы — VPN-провайдер, лика нет. Что-то ещё — есть лик.
Почему мой VPN леакает DNS?
Чаще всего: Windows SMHNR отправляет запросы на несколько интерфейсов. Реже: IPv6-лик, DNS уровня приложения, неправильно настроенный VPN-клиент.
DNS-лик даст провайдеру мою историю браузинга?
Да для leaked-запросов. Провайдер видит доменные имена, которые ты ищешь. DNS-лик даёт ту же видимость, что без VPN.
Достаточно ли зашифрованного DNS отдельно?
Зашифрованный DNS скрывает содержимое от провайдера. Не шифрует остальной трафик. IP назначения всё равно виден провайдеру другими путями (SNI в TLS-handshakes, маршрутизация). VPN — более сильный общий приватный инструмент.
Стоит ли использовать DNS на роутере?
Если роутер можно настроить на privacy-respecting DNS (Cloudflare, Quad9) — да. Это применяется ко всем устройствам в сети. Лучше в комбинации с VPN на уровне устройства для полного шифрования.
Fexyn использует свой DNS или сторонний?
Fexyn использует свои DNS-резолверы внутри туннеля. Сами резолверы не логируют запросы. Сейчас не используем upstream encrypted DNS (DoH/DoT к upstream); резолюция идёт прямо к root и TLD-серверам с наших резолверов.
Попробуй Fexyn бесплатно 7 дней — WFP-защита от DNS-ликов, IPv6 leak protection, kernel-level kill switch. Тест на /tools/dns-leak-test. Kill switch объяснён — про архитектуру WFP.
Последняя ревизия 2026-05-09.