bestEffortDnsParsing в WSL: когда включать и как проверить DNS

Как работает bestEffortDnsParsing

Microsoft описывает параметр узко: когда `wsl2.dnsTunneling=true`, Windows может извлечь вопрос из DNS-запроса и попытаться разрешить его, игнорируя неизвестные записи. Это механизм совместимости, а не альтернативный DNS-сервер и не настройка кэша. Хороший кандидат для теста — ситуация, где обычные имена разрешаются, но один клиент или один тип запроса стабильно не проходит через tunneling. Плохой кандидат — дистрибутив вообще не получает имена, `/etc/resolv.conf` вручную заменён, VPN полностью блокирует трафик или приложение обращается к неверному домену. В таких случаях bestEffortDnsParsing может только отвлечь от основной причины.

Совет: Зафиксируйте один домен и одну команду, которые стабильно воспроизводят сбой. A/B-тест по разным сайтам и разным клиентам мало что доказывает.

Проверьте dnsTunneling до экспериментального флага

Зависимость от `dnsTunneling=true` — обязательное условие, прямо указанное в документации. Этот параметр находится в секции `[wsl2]` файла `%UserProfile%\.wslconfig`; bestEffortDnsParsing — в `[experimental]`. Перед изменением посмотрите текущий конфиг и не включайте одновременно mirrored networking, proxy, firewall и другие экспериментальные опции ради одного DNS-теста. После правки глобального файла перезапустите WSL через `wsl --shutdown`. Если используется корпоративный VPN, проводите оба варианта при одинаковом состоянии VPN: подключён или отключён, одна и та же сеть, тот же DNS-суффикс. Иначе изменение маршрутов или серверов имён будет сильнее влиять на результат, чем тестируемый флаг.

Предупреждение: Не меняйте `/etc/resolv.conf` в том же эксперименте. Иначе вы сравниваете сразу два разных DNS-механизма и не сможете связать результат с bestEffortDnsParsing.

Симптом и первый диагностический шаг

• не разрешается ни один домен. dnsTunneling, VPN, базовую сеть и resolv.conf
• `getent` работает, одно приложение нет. как приложение формирует DNS-запрос; затем A/B флага
• проблема только при VPN. одинаковое состояние VPN, split DNS и политики
• IP доступен, имя нет. DNS отдельно от маршрутизации приложения
• ошибка появилась после ручной правки resolv.conf. вернуть контролируемую DNS-конфигурацию

Важно: bestEffortDnsParsing не предназначен для исправления любой сетевой ошибки. Сначала докажите, что проблема находится именно на этапе DNS-разрешения.

Какими командами сравнить поведение

Используйте минимум два клиента, потому что они проходят разные кодовые пути. `getent hosts example.com` показывает, как имя разрешает системная библиотека; `nslookup` или `dig` позволяют увидеть DNS-ответ более явно, если пакет установлен. Затем повторите запрос из проблемного приложения — например, package manager, CLI или runtime. Важно сравнивать не только «сработало/не сработало», но и время, код ошибки и полученные адреса. Если системные инструменты одинаково успешны при false и true, а ломается только приложение, соберите его собственный debug-лог. Возможно, причина в прокси, TLS, DoH или настройке приложения, которая выглядит как DNS-ошибка.

Как провести A/B-тест

1. 1: При `bestEffortDnsParsing=false` или без ключа воспроизведите ошибку на одном домене и сохраните вывод команды.
2. 2: Убедитесь, что в `[wsl2]` задано `dnsTunneling=true` и что вы не меняете VPN, сеть и resolv.conf между прогонами.
3. 3: Добавьте в `[experimental]` строку `bestEffortDnsParsing=true`.
4. 4: Выполните `wsl --shutdown` и снова запустите тот же дистрибутив.
5. 5: Повторите те же DNS-команды и тот же запрос проблемного приложения.
6. 6: Если эффект есть, верните false, ещё раз перезапустите WSL и подтвердите, что исходный сбой возвращается.

Почему ручной resolv.conf мешает диагностике

DNS tunneling должен управлять тем, как запросы из WSL передаются Windows. Если одновременно запретить автоматическую генерацию resolv.conf или вручную прописать сторонний nameserver, фактический путь запроса может отличаться от того, который вы пытаетесь проверить. Поэтому не переносите старые советы для NAT/VPN автоматически на современную конфигурацию. Сначала сделайте минимальный тест на поддерживаемой схеме Microsoft. Если организация требует собственный resolver, зафиксируйте это как отдельное ограничение и тестируйте его после проверки tunneling. Такой порядок особенно полезен при split DNS: публичный домен может работать, а внутренний — зависеть от VPN-политики и корпоративных DNS-серверов.

Что делать, если bestEffortDnsParsing не помог

Верните экспериментальный ключ в false или удалите его и продолжайте диагностику на слое, где есть расхождение. Если не работает ни один resolver — смотрите DNS tunneling, сеть и VPN. Если `dig` работает, а package manager сообщает ошибку разрешения имени, сравните, какой resolver и proxy он использует. Если имя разрешается, но соединение к полученному IP не устанавливается, это уже маршрутизация, firewall или сервис назначения. Не наращивайте `.wslconfig` случайными флагами. Чем меньше одновременно изменяемых переменных, тем быстрее находится причина. Полезно сохранить вывод `wsl --version`, конфиг и две короткие трассы «до/после» для повторяемой диагностики.

Чек-лист чистого DNS-теста

• `dnsTunneling=true` подтверждён
• проблема воспроизводится на одном и том же домене
• состояние VPN одинаково в обоих прогонах
• `resolv.conf` не меняется одновременно
• между вариантами выполнен полный restart WSL
• проверены системный resolver и проблемное приложение
• результат подтверждён обратным переключением true→false
• если DNS уже успешен, диагностика переносится на следующий сетевой слой

Когда оставлять bestEffortDnsParsing включённым

Оставляйте параметр только если A/B-тест показывает устойчивую связь: при false конкретный DNS-запрос ломается, при true проходит, а возврат false воспроизводит сбой. Запишите приложение и симптом рядом с конфигурацией, потому что экспериментальные параметры WSL могут со временем менять статус и поведение. Периодически проверяйте, нужен ли workaround после обновления WSL. Не используйте этот флаг как средство «ускорить Интернет»: документация описывает обработку неизвестных записей в DNS-запросе, а не оптимизацию задержки. Для медленного DNS измеряйте время ответа, серверы и VPN-маршрут отдельно. Это сохраняет конфигурацию объяснимой и снижает количество мистических сетевых твиков.

Что учитывать

DNS tunneling должен управлять тем, как запросы из WSL передаются Windows. Если одновременно запретить автоматическую генерацию resolv.conf или вручную прописать сторонний nameserver, фактический путь запроса может отличаться от того, который вы пытаетесь проверить. Поэтому не переносите старые советы для NAT/VPN автоматически на современную конфигурацию. Сначала сделайте минимальный тест на поддерживаемой схеме Microsoft. Если организация требует собственный resolver, зафиксируйте это как…

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. Advanced settings configuration in WSL). Пример и формулировки — редакция N1RO на 2026-09-20.

• Advanced settings configuration in WSL
• Accessing network applications with WSL