Как устранить проблемы с разрешением DNS в Ubuntu

Если DNS в Ubuntu не работает, сначала убедитесь, что сетевой канал и IP-маршрут исправны: проблемы с разрешением DNS в Ubuntu есть только тогда, когда этот путь работает, но имя не разрешается или даёт неверный результат. Затем выполните resolvectl status и resolvectl query, чтобы узнать фактический DNS-сервер и домен маршрутизации активного соединения, и до проверки одного временного изменения сохраните владельца и исходные значения. После снятия временного изменения позвольте владельцу конфигурации применить настройки заново и сравните результат с сохранённым состоянием.

Ключевые выводы

• Связь Wi-Fi или Ethernet, IP-маршрут, доступ в интернет и DNS — разные уровни.
• Ubuntu может выбирать DNS для каждого соединения; глобальный сервер не обязательно обрабатывает конкретный запрос.［1］
• /etc/resolv.conf может управляться systemd-resolved или другим сетевым компонентом. Не перезаписывайте и не удаляйте ссылку вслепую.［2］
• Публичный DNS годится для временного сравнения, но не является универсальным постоянным исправлением.

Если возможны несколько уровней сбоя, начните с общего руководства. Обзор ошибки DNS-сервера объясняет общую механику, а здесь рассматривается текущее состояние Ubuntu.

Как устранить проблемы с разрешением DNS в Ubuntu по шагам?

Шаг 1: Зафиксируйте состояние сбоя

До любых изменений сохраните проблемное имя хоста, точную ошибку, время, активный интерфейс и текущий вывод resolvectl status.

Шаг 2: Докажите наличие канала и маршрута

Убедитесь, что ожидаемый канал Wi-Fi или Ethernet поднят, а для проблемного пути есть маршрут. Если канала или маршрута нет, оставайтесь на этой ветви и не меняйте DNS.

Шаг 3: Сравните поведение IP и имени

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

Шаг 4: Определите выбранный путь разрешения имён

Выполните resolvectl status и resolvectl query для точного имени. Определите выбранное соединение, сервер, домен маршрутизации и то, затрагивает ли сбой всё разрешение имён или только один домен.

Шаг 5: Найдите владельца настройки

Осмотрите /etc/resolv.conf и активный сетевой стек. Запишите, откуда приходит значение: из NetworkManager, Netplan, DHCP, VPN, systemd-resolved или из политики.

Шаг 6: Проверьте одно временное значение для соединения

Если владелец и среда это допускают, временно измените одно значение DNS для соединения, повторите тот же запрос, затем выполните resolvectl revert для этого соединения.

Шаг 7: Позвольте владельцу применить настройки заново

Дайте владельцу конфигурации снова применить свои настройки и сравните новый статус с сохранённым выводом. Не описывайте revert как восстановление сохранённого снимка.

Шаг 8: Исправьте управляющий слой и проверьте

Постоянное исправление вносите только в управляющем слое и с путём отката, затем повторите исходный запрос и убедитесь, что внутренние и публичные имена ведут себя так, как задумано.

Результат каждого шага определяет следующую ветвь. Если не проходят ни IP-проверка, ни запрос имени, сравнение с публичным DNS-сервером не докажет, что сбой только в DNS. Если не разрешается лишь одно имя из схемы split DNS, замена всех серверов может сломать маршруты, которые ещё работают. Если временный сервер помог, у вас есть полезное сравнение, но не разрешение оставить после себя неуправляемое переопределение.

Как доказать, что неисправен именно DNS?

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

ip -brief link
ip route

Затем сравните IP-адрес назначения, который вам разрешено проверять, с именем хоста того же сервиса. Работающий IP-путь при неудачном запросе имени поддерживает гипотезу DNS. Если не работает ни то ни другое, исследуйте роутер, страницу авторизации в сети (captive portal), локальный маршрут, межсетевой экран или вышестоящее подключение. Сбои всей сети разобраны в дереве диагностики роутера без интернета.

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

Что показывает resolvectl status?

Выполните:

resolvectl status
resolvectl query example.com

Замените example.com настоящим проблемным именем, если его можно безопасно показывать локально. Статус отображает глобальные DNS-серверы и серверы отдельных соединений, домены поиска и домены только для маршрутизации, протоколы и состояние активного интерфейса. Запрос сообщает полученные адреса и, как правило, задействованное соединение и протокол. Руководство resolvectl также описывает статистику и сброс кэша, но сброс кэша должен следовать из доказательств, а не заменять диагностику.

Обратите внимание:

• активно ли ожидаемое соединение Wi-Fi, Ethernet, VPN или туннель;
• у какого соединения DNS-маршрут по умолчанию или наиболее точно совпадающий домен маршрутизации;
• откуда получен DNS-сервер: из DHCP, управляемой сети, VPN или ручной настройки;
• не отказывает ли только один домен, особенно внутреннее имя в схеме split DNS;
• меняется ли результат после переподключения того же соединения.

Раздельная маршрутизация по соединениям означает, что два сервера в выводе не обязательно взаимозаменяемы. Корпоративный домен может намеренно направляться через VPN, а публичные имена — через домашнее подключение.

Кто управляет настройкой DNS?

Изучите файл службы разрешения имён, а не редактируйте его:

ls -l /etc/resolv.conf
cat /etc/resolv.conf
systemctl is-active systemd-resolved

Руководство systemd-resolved описывает несколько поддерживаемых режимов /etc/resolv.conf, включая символические ссылки на локальный stub или на сгенерированный список серверов, а также работу с файлом, которым управляет другой компонент. Сгенерированный файл может измениться, когда DHCP, NetworkManager, Netplan, VPN или политика управления обновляют соединение.

Определите фактического владельца на этой машине. У профилей NetworkManager, конфигурации Netplan, серверных сетевых инструментов и политики организации разные пути постоянной настройки. Не копируйте путь из другой версии Ubuntu, считая его универсальным. Если устройство управляемое, спросите администратора, прежде чем менять DNS или профиль VPN.

Как выполнить обратимый тест DNS в Ubuntu?

Сначала сохраните релевантный вывод resolvectl status и определите имя интерфейса. Если активным состоянием этого соединения владеет systemd-resolved, администратор может временно задать на нём тестовый сервер:

sudo resolvectl dns interface-name resolver-address
resolvectl query example.com
sudo resolvectl revert interface-name

Подставьте реальные значения, подходящие вашей сети. Команда revert удаляет временное переопределение и сбрасывает все DNS-параметры соединения к значениям по умолчанию; она не восстанавливает сохранённую конфигурацию. После отмены позвольте фактическому владельцу конфигурации применить настройки заново — переподключайтесь только в том случае, если это поддерживаемый им способ, — и сравните resolvectl status с выводом, сохранённым до теста. Выполните один и тот же запрос до, во время и после изменения. Успех во время теста говорит о том, что исходный сервер или маршрут к нему требует проверки, но не доказывает, что тестовый сервер — верный постоянный выбор.

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

Как сделать постоянное исправление?

Исправляйте тот уровень, которому принадлежит значение:

• для DNS, полученного по DHCP, исправьте роутер или DHCP-сервер, если неверное значение получают все клиенты;
• для соединения под управлением NetworkManager используйте поддерживаемый параметр этого профиля и переподключайтесь осознанно;
• для сервера под управлением Netplan используйте схему, поддерживаемую данным выпуском Ubuntu, проверьте изменение и сохраните доступ к консоли;
• для VPN или управляемого устройства исправьте профиль VPN или обратитесь к администратору;
• если отказывает один авторитетный домен, обратитесь к владельцу домена или сервиса, а не меняйте службу разрешения имён на каждом клиенте.

Перед постоянным изменением запишите исходную конфигурацию и подготовьте путь отката. Затем переподключайтесь или применяйте настройки только через инструмент-владелец и повторите resolvectl status и исходный запрос.

Что делать, если DNS-ошибка видна только в apt update?

Сохраните точное имя хоста репозитория и текст ошибки. Если resolvectl query для этого имени не проходит, оставайтесь в ветви DNS. Если имя разрешается, а APT сообщает об ошибке подписи, Release-файла, TLS, репозитория или зависимостей, DNS не является основным диагнозом. Переходите к руководству по ошибкам APT и восстановлению зависимостей.

Итоги

Прежде чем называть сбой проблемой DNS, докажите работу канала и IP-доступность. Прочитайте глобальное состояние и состояние каждого соединения через resolvectl, определите компонент-владелец значений и меняйте только одну переменную. Снимите временное переопределение и позвольте владельцу применить настройки заново; постоянное исправление вносите в NetworkManager, Netplan, DHCP, VPN или политику, а не слепой заменой /etc/resolv.conf.

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

Почему IP-адрес работает, а имя хоста нет?

Такая картина может указывать на сбой разрешения имён, потому что IP-маршрут работает без преобразования имени. Подтвердите это через resolvectl query и исключите прокси или кэш конкретного приложения.

Почему показано несколько DNS-серверов?

Ubuntu может получать серверы от нескольких соединений. Домены маршрутизации и DNS-маршрут по умолчанию определяют, какое соединение обработает запрос, особенно при split DNS через VPN.

Нужно ли править /etc/resolv.conf напрямую?

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

Всегда ли помогает перезапуск systemd-resolved?

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

Можно ли удалить символическую ссылку /etc/resolv.conf?

Нет. Сначала определите её документированный режим и владельца конфигурации. Удаление может отрезать приложения от локального stub-резолвера или сгенерированного списка серверов.

Можно ли навсегда использовать публичный DNS-сервер?

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

Что делать, если DNS не работает в Ubuntu Server?

В Ubuntu Server постоянными значениями DNS обычно управляет Netplan: они задаются в ключе nameservers интерфейса — в addresses и необязательном search. Правьте управляющий файл Netplan или настройку cloud-init, которая его создала, а не /etc/resolv.conf, затем примените изменение командой sudo netplan try: она откатит изменение, если вы не подтвердите его до истечения тайм-аута, по умолчанию 120 секунд. Сохраните консольный доступ, убедитесь, что отклонённое изменение действительно откатилось, и повторите resolvectl status и исходный запрос.

Как отменить временный тест resolvectl dns?

Выполните sudo resolvectl revert interface-name для того же соединения. Команда снимет временное переопределение и сбросит DNS-параметры этого соединения к значениям по умолчанию, но не восстановит сохранённые настройки. Позвольте владельцу конфигурации применить настройки заново, затем сравните resolvectl status с выводом, сохранённым до теста.

Меняет ли VPN выбор DNS в Ubuntu?

Если имя перестаёт разрешаться только после подключения VPN, сравните выбранное соединение, DNS-сервер и домен маршрутизации для того же имени до и после подключения. Профиль VPN может передавать DNS для отдельного соединения или домены только для маршрутизации, поэтому отказ, ограниченный внутренним именем, может отражать маршрутизацию split DNS, а не неисправность публичного сервера. Для сравнения не меняйте физическую сеть и следуйте политике её владельца.［1］［2］

Если в проверяемом подключении участвует AethoVPN, запишите его состояние вместе с resolvectl status и результатом исходного запроса. Это наблюдение нужно, чтобы установить, меняет ли данная конфигурация DNS; само название продукта не определяет владельца настройки. Неверное значение DHCP или постоянную настройку NetworkManager/Netplan исправляйте у источника и после снятия временного переопределения убедитесь, что внутренние имена по-прежнему работают.

---

Отказ от ответственности: Владение настройками зависит от выпуска Ubuntu, сетевого стека, VPN и политики организации. Сохраните исходные значения и консольный доступ.

Источники:

1. Ubuntu Manpage Repository — resolvectl(1) — https://manpages.ubuntu.com/manpages/noble/man1/resolvectl.1.html
2. Ubuntu Manpage Repository — systemd-resolved(8) — https://manpages.ubuntu.com/manpages/noble/man8/systemd-resolved.8.html

Sources checked 4 октября 2026 г.

---

Рекомендуемые статьи:

• Безопасная диагностика устройств и приложений
• Проверка причин отказа DNS-сервера
• Роутер подключён, но интернета нет
• Как исправить ошибки apt update