# DNS не работает через VPN > DNS не работает через VPN: как отличить сбой разрешения имён от пропажи сети, почему wg-quick не применяет DNS без resolvconf, приватный DNS, MTU и утечки. Источник: https://vpn-ne-rabotaet.ru/ne-rabotaet/dns/ Страница обновлена: 2026-08-16 --- **Если DNS не работает через VPN, сам канал обычно исправен: рукопожатие прошло, трафик идёт, а превратить имя сайта в адрес некому.** Разводит эти два случая пара запросов — по IP-адресу и по имени. Пакеты по адресу ходят, а по имени нет — ни шифрование, ни маршруты трогать не надо. > **Коротко.** Убедитесь, что туннель жив: `wg show` печатает latest-handshake и счётчики transfer. Дальше три причины. На Linux строка `DNS =` не применяется без resolvconf — в Debian пакет лежит в Suggests. На Android строгий «Приватный DNS» ходит по DoT на порт 853 и отката на порт 53 не имеет. Третья — размер: по UDP всё длиннее 512 байт усекается с битом TC, а буфер EDNS с 2020 года равен 1232 байтам. ## Как отличить сбой резолвинга от пропажи сети? Тремя командами: 1. `ping 1.1.1.1` — проходимость канала по адресу, без участия имён. 2. `nslookup example.com` — получение адреса по имени. 3. `wg show` — состояние туннеля. Первая отвечает, вторая молчит — виноват DNS. Свежий latest-handshake в выводе `wg show` значит, что пакеты доходят в обе стороны. Растущий transfer-tx при нулевом transfer-rx — уже не про имена, а про отсутствие ответов вообще: этот случай разобран в статье [«подключён, но сайты не открываются»](/ne-rabotaet/podklyuchen-no-ne-rabotaet/). ## Почему поле DNS в конфиге не применяется на Linux? Потому что применяет его внешняя утилита, а не сам wg-quick. По man-странице wg-quick(8) строка DNS в секции `[Interface]` задаёт и резолверы, и поисковые домены — различаются они по формату значения. При подъёме скрипт вызывает `resolvconf -a tun.<интерфейс> -m 0 -x`, при опускании — `resolvconf -d ...`, а список подаёт на stdin строками `nameserver ...`. Нет resolvconf — применять нечем: интерфейс поднимется, а резолвер останется прежним. В Debian wireguard-tools предлагает «openresolv | resolvconf | systemd-resolved» в Suggests, а не в Recommends: по умолчанию не ставится ничего. Флаг `-x` не косметика: он отображается в дополнительный поисковый домен `~.`, после чего запросы преимущественно уходят на резолверы этого интерфейса — кроме доменов, явно закреплённых за другими линками; без `-x` они разъезжаются по всем линкам. Сама поддержка `-x` в systemd-resolvconf реализована частично. Без resolvconf DNS навешивают через `PostUp` и `PostDown` — man называет их обычным местом для таких настроек. ## Чем смотреть реальные резолверы вместо resolv.conf? Командой `resolvectl status`: она показывает глобальные и по-интерфейсные настройки DNS, действующие сейчас. Рядом — `resolvectl query <имя>` и `resolvectl flush-caches`. Привычный `cat /etc/resolv.conf` при systemd-resolved бесполезен: `/run/systemd/resolve/stub-resolv.conf` держит единственным сервером заглушку 127.0.0.53, и дальнейший маршрут запроса не виден. ## Что делать с приватным DNS на Android? На время диагностики перевести его в «Автоматически» или «Выключено» — менять хост бесполезно. Функция появилась в Android 9 (API level 28): Settings → Network & internet → Private DNS. Строгий режим (вписано имя хоста) требует TLS-соединения на порт 853; невозможность его установить — жёсткая ошибка, при которой служба DNS не работает вовсе, отката на порт 53 нет. Оппортунистический режим при неудаче возвращается на порт 53 без защиты. Обратная половина: javadoc `VpnService.Builder.addDnsServer` говорит, что при незаданном сервере используются DNS-серверы сети по умолчанию. При пустом поле DNS туннель работает, а имена уходят к резолверу оператора или Wi-Fi — это и есть утечка. Остальное — в разборе [VPN не работает на Android](/ne-rabotaet/na-android/). ## Откуда берётся утечка DNS на Windows? Из механизма Smart Multi-Homed Name Resolution: система шлёт параллельные запросы DNS, LLMNR и NetBIOS по всем сетям и при нескольких ответах выбирает по порядку привязки. Отключает его политика «Turn off smart multi-homed name resolution»; в реестре — `Software\Policies\Microsoft\Windows NT\DNSClient`, значение `DisableSmartNameResolution`. Клиент WireGuard для Windows закрывает это фаерволом, но только когда у интерфейса ровно один пир и у него в `AllowedIPs` есть префикс /0 (`0.0.0.0/0` или `::/0`): тогда пакеты на порт 53 пропускаются лишь к резолверам из конфигурации. Замена маршрута парой `0.0.0.0/1` и `128.0.0.0/1` выглядит эквивалентно, но документация предупреждает: фаервольная семантика не активируется. Проверка — `nslookup mydomain.com 1.1.1.1` (первый параметр имя, второй сервер), `set vc` переводит на TCP; в PowerShell — `Resolve-DnsName` с `-Server`, `-TcpOnly`, `-DnsOnly`. ## Почему большие ответы DNS теряются в туннеле? Потому что размер ответа упирается в MTU. RFC 1035 ограничивает сообщения по UDP 512 байтами; длиннее — усечение и бит TC в заголовке. RFC 7766 (март 2016) сделал TCP обязательным транспортом DNS, а не аварийным. EDNS(0) (RFC 6891) даёт объявить буфер больше, но предупреждает: слишком большое значение гарантирует фрагментацию на уровне IP, а потеря одного фрагмента убивает весь ответ. DNS Flag Day 2020 зафиксировал дефолт 1232 байта — MTU 1280 из спецификации IPv6 минус 48 байт заголовков (`edns-buffer-size: 1232` в Unbound). Режет и сам туннель: wg-quick вычитает из MTU пути ровно 80 байт, при обычных 1500 интерфейс получает 1420. Клиент для Windows делает так же, а Android-приложение WireGuard без поля MTU ставит 1280 — поэтому совет «поставьте 1280» на телефоне часто не меняет ничего. Симптом: короткие A-записи разрешаются, а DNSSEC и длинные TXT виснут. ## Симптом, причина и команда проверки | Что наблюдаете | Вероятная причина | Чем проверить | |---|---|---| | По IP-адресу открывается, по имени нет | Резолвер недоступен из туннеля | `nslookup example.com 1.1.1.1` | | wg-quick не нашёл команду resolvconf | Пакет в Suggests, не установлен | `type -P resolvconf` пусто → openresolv или `PostUp` | | `/etc/resolv.conf` показывает 127.0.0.53 | Заглушка systemd-resolved | `resolvectl status`, блок нужного интерфейса | | Android: туннель есть, имена не разрешаются | Строгий приватный DNS без отката | Приватный DNS → «Автоматически» | | Windows: отвечает домашний резолвер | Smart Multi-Homed Name Resolution | `Resolve-DnsName example.com -DnsOnly` | | TXT и DNSSEC виснут, A-записи приходят | Усечение больших ответов | `dig +tcp example.com`, буфер 1232 | ## Сколько признаков страны видит сайт? Как минимум четыре, и расходятся они независимо: адрес выхода туннеля, резолвер, WebRTC и часовой пояс. Резолвер попал в список из-за EDNS Client Subnet (RFC 7871): иначе авторитетный сервер видит адрес рекурсивного резолвера, а не источника запроса, и CDN подбирают узел по нему. Про WebRTC то же говорит RFC 8828 (январь 2021): раскрыться может и адрес туннеля, и адрес провайдера. Поэтому утечка DNS и «не та страна» — разные последствия одного дефекта; что видно снаружи, разобрано на странице про [безопасность VPN](/bezopasnost-vpn/). ## Частые вопросы Короткие ответы на типовые вопросы про разрешение имён собраны ниже.