Почему dig и приложение видят разные адреса: проверяем resolvectl

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

Инструкция относится к Linux, где установлен и работает systemd-resolved. Если система использует другой резолвер, команды могут быть недоступны или не описывать реальный путь приложения. Не включайте новый сервис только ради выполнения этой инструкции.

Посмотрите общие настройки и сведения по каждому интерфейсу: DNS-серверы, домены и роль соединения. При активном VPN именно эти различия часто объясняют, почему внутреннее имя должно разрешаться через корпоративную сеть.

Введите доменное имя без протокола и пути:

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

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

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

Запишите состояние VPN, интерфейс, DNS-сервер, доменное правило и результат запроса. Если нужно сравнение до и после переподключения, проводите его в понятном порядке и отмечайте время. Не очищайте кэш как первое действие: это может временно изменить симптом, не объяснив причину.

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

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

The DNS utility returns the expected address, but the app continues connecting to another. The cause may be that they use different name resolution paths. On systems with systemd-resolved, DNS selection depends not only on a single global file but also on interfaces and domain rules.

This guide applies to Linux systems where systemd-resolved is installed and running. If the system uses a different resolver, the commands may be unavailable or may not describe the actual path used by the app. Do not enable the new service solely to follow this instruction.

View general settings and details for each interface: DNS servers, domains, and connection role. With an active VPN, these differences often explain why an internal name must resolve via the corporate network.

Enter the domain name without protocol and path:

In an organization, some names may be served by internal DNS, while others use a standard internet connection. After connecting to a VPN, not necessarily all DNS changes, but only the routing of requests for specific domains. Therefore, universally replacing all servers with public ones can break working services.

Example: a public site opens, but the internal portal stops resolving after reconnection to the VPN. First, compare the settings of the relevant interface and domain rules. If the corporate DNS disappears from the connection state, the issue cannot be resolved by editing a public domain record.

Also check the exact name: a short name with a search suffix and a fully qualified domain name can trigger different queries. Do not modify the configuration until it is confirmed which name the problematic application is actually requesting.

Record the VPN state, interface, DNS server, domain rule, and query result. If a before-and-after comparison is needed after reconnection, perform it in a clear order and note the time. Do not clear the cache as the first step: this may temporarily alter the symptom without explaining the cause.

A fix is considered verified only when the correct response is received by the specific application in the expected network. Distinguish between a system query, a direct DNS query, and browser behavior: these differences help identify the error level. A single successful utility response does not replace this verification.

If the error occurs only after waking from sleep or changing networks, note this in the report: the timing of the connection configuration update is critical.