Debian/Ubuntu: Temporary failure in name resolution — как быстро найти и исправить DNS-сбой

Сообщение Temporary failure in name resolution в Debian и Ubuntu означает не то, что «интернет пропал целиком», а более узкую проблему: система не смогла преобразовать доменное имя в IP-адрес в момент запроса. Из-за этого перестают работать apt update, ssh по имени хоста, curl, wget, агенты мониторинга и любые приложения, которым нужен DNS.

Проблема неприятна тем, что внешний симптом почти всегда одинаковый, а причин много: сломанный /etc/resolv.conf, зависший systemd-resolved, ошибка в netplan, недоступный DNS-сервер, отсутствие маршрута по умолчанию, фильтрация UDP/53, проблемы с IPv6 или неудачная правка сетевого конфига.

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

Ниже — практический runbook для Debian и Ubuntu, где могут использоваться systemd-resolved, resolvectl и netplan. Отдельно разберём, как понять, кто именно управляет DNS на конкретной машине: DHCP-клиент, NetworkManager, systemd-networkd или статический /etc/resolv.conf.

Главное правило перед любыми правками: сначала диагностика, потом изменения. Очень часто администратор начинает «чинить DNS», хотя реальная причина — в отсутствии default route, в недоступности резолвера или в конфликте сетевых служб.

Как проявляется проблема

Ошибка встречается в разных местах. apt пишет, что не удаётся разрешить имя зеркала. ssh не подключается по hostname, но по IP работает. curl и wget завершаются на этапе lookup. Для пользователя это выглядит как «DNS не работает», но для администратора важно понять, где именно ломается цепочка.

Самая полезная быстрая проверка — сравнить доступ по IP и по имени. Если по IP всё работает, а по имени нет, почти наверняка проблема в резолвинге. Если не работает ни IP, ни имя, искать нужно уже не в DNS, а в маршрутизации, firewall или общей сетевой доступности.

ping -c 2 1.1.1.1
ping -c 2 deb.debian.org
getent hosts deb.debian.org
apt update

Если первый ping успешен, а второй нет, круг причин уже сильно сужается. Если getent hosts тоже не возвращает адрес, значит проблема проявляется на уровне системного resolver API, а не только внутри одной утилиты.

С чего начинать диагностику DNS в Linux

Правильный порядок такой: сначала проверяем сеть как транспорт, затем смотрим, какие DNS-серверы система использует прямо сейчас, потом проверяем сервисы-резолверы и только после этого правим netplan, /etc/resolv.conf или интерфейсные настройки.

Первый шаг — убедиться, что интерфейс поднят, IP назначен, а маршрут наружу существует.

ip a
ip route
ip route get 1.1.1.1

В выводе должен быть активный интерфейс с адресом и маршрут по умолчанию через корректный gateway. Если default route отсутствует, DNS-запросы могут просто никуда не уходить, и ошибка будет выглядеть как DNS-сбой, хотя на деле это обычная сетевая проблема.

Второй шаг — посмотреть, что система считает DNS-серверами в текущий момент.

cat /etc/resolv.conf
resolvectl status

Эти две команды часто дают больше пользы, чем долгие догадки. По /etc/resolv.conf видно, куда приложения отправляют запросы. По resolvectl status — как ситуацию видит systemd-resolved: какие DNS-серверы назначены глобально и по интерфейсам, какие search domains используются и есть ли вообще активные upstream-серверы.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Почему /etc/resolv.conf может вводить в заблуждение

На Ubuntu и части Debian-систем /etc/resolv.conf часто не является статическим файлом. Это может быть символьная ссылка на stub-resolver 127.0.0.53, который обслуживает systemd-resolved. В таком случае строка nameserver 127.0.0.53 сама по себе нормальна.

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

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf

Если ссылка ведёт в /run/systemd/resolve/, система, скорее всего, использует systemd-resolved. Если это обычный файл, DNS может быть настроен вручную или управляться другой подсистемой.

Проверяем systemd-resolved

systemd-resolved — локальный сервис резолвинга, который может кешировать ответы, слушать локальный stub на 127.0.0.53 и принимать DNS-настройки от сетевого стека. Если он работает некорректно, ошибка Temporary failure in name resolution появляется даже при нормальной сети по IP.

Сначала смотрим состояние службы и её логи.

systemctl status systemd-resolved
journalctl -u systemd-resolved -b --no-pager

Обращайте внимание на такие признаки:

• служба не запущена или находится в состоянии failed;
• не назначены upstream DNS-серверы;
• ошибки таймаутов при обращении к резолверам;
• проблемы после переподнятия интерфейса или смены конфигурации;
• жалобы на DNSSEC, если он используется.

Дальше полезно выполнить точечный запрос через resolvectl. Так вы проверяете не только наличие конфига, но и реальную способность сервиса отвечать.

resolvectl query deb.debian.org
resolvectl query archive.ubuntu.com
resolvectl statistics

Если запросы через resolvectl не проходят, а сеть по IP есть, проблема почти наверняка находится внутри DNS-цепочки. Если же resolvectl отвечает, а отдельные приложения нет, тогда уже стоит смотреть /etc/nsswitch.conf, контейнерное окружение или специфические настройки самого приложения.

Быстрая перезагрузка DNS-цепочки

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

systemctl restart systemd-resolved
resolvectl flush-caches
resolvectl reset-server-features

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

Проверяем netplan в Ubuntu

На Ubuntu Server DNS-адреса часто задаются через netplan. Ошибка в YAML, неверное имя интерфейса, отсутствие секции nameservers или неудачное применение конфига легко приводят к тому, что сеть поднимается без рабочего DNS.

Сначала смотрим текущие YAML-файлы.

ls -l /etc/netplan
sed -n '1,200p' /etc/netplan/*.yaml

Типовой пример статической настройки может выглядеть так:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: false
      addresses:
        - 192.0.2.10/24
      routes:
        - to: default
          via: 192.0.2.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8
        search:
          - example.internal

Если используется DHCP, конфиг может быть проще, но это не отменяет проверки того, действительно ли DNS был получен и применён в runtime.

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

netplan generate
netplan try

netplan try особенно полезен при работе по SSH: если вы ошиблись и сеть пропадёт, конфигурация откатится автоматически. Это одна из тех привычек, которые реально спасают от потери доступа.

netplan apply
resolvectl status
ip route

После применения изменений нужно сверять не только сам YAML, но и фактический результат. Если DNS в файле есть, а в resolvectl status его нет, проблема в рендерере, в конфликте служб или в том, что конфиг не был принят.

Частые ошибки в netplan

• неправильное имя интерфейса, например ens3 вместо eth0;
• DNS указан, но отсутствует маршрут по умолчанию;
• ошибки в YAML-отступах;
• одновременное управление сетью через NetworkManager и systemd-networkd;
• указан renderer, который в системе не используется;
• настроен только IPv6 DNS при нерабочей IPv6-связности.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Что делать в Debian, где netplan может не использоваться

В Debian картина зависит от версии и способа установки. На минимальных системах DNS нередко задаётся классическими механизмами, а netplan может вообще отсутствовать. Поэтому здесь особенно важно не предполагать, а проверять.

systemctl is-active systemd-resolved
systemctl is-active systemd-networkd
systemctl is-active NetworkManager
grep '^hosts:' /etc/nsswitch.conf

Строка hosts: в /etc/nsswitch.conf полезна для проверки порядка источников имён. Если файл испорчен ручной правкой или неудачным пакетом, некоторые приложения могут вести себя странно даже при формально рабочем DNS.

Если используется обычный статический /etc/resolv.conf, минимальный рабочий вариант для диагностики может быть таким:

nameserver 1.1.1.1
nameserver 8.8.8.8
options timeout:2 attempts:2

Но это именно временный или осознанно статический вариант. Если файл позже перезаписывается DHCP-клиентом или systemd-resolved, ручная правка исчезнет после перезагрузки или обновления интерфейса.

Когда виноват не DNS, а доступ до DNS-сервера

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

ping -c 2 1.1.1.1
nc -u -z -v 1.1.1.1 53
nc -z -v 1.1.1.1 53

Такие проверки не идеальны, но помогают быстро заметить очевидные блокировки. Если UDP/53 фильтруется, часть клиентов будет долго ждать таймаута, а часть попробует TCP. Снаружи это выглядит как нестабильный или «плавающий» DNS.

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

На практике это часто встречается в контейнерах и на сложных веб-серверах. Если у вас несколько приложений на одном узле, полезно также держать в порядке сетевую архитектуру и конфигурацию окружения. Для похожих задач может пригодиться материал про несколько пулов PHP-FPM в Nginx, где ошибки на уровне сервиса легко спутать с системными сетевыми проблемами.

Разбор типичных сценариев

Сценарий 1: apt update пишет Temporary failure in name resolution

Это один из самых частых кейсов. Начинайте с простого: может ли система разрешить имя зеркала вручную?

getent hosts deb.debian.org
getent hosts archive.ubuntu.com
resolvectl query deb.debian.org

Если не может, проверяйте /etc/resolv.conf, состояние systemd-resolved и активные DNS-адреса. Если может, но apt update всё равно падает, смотрите прокси, нестандартные репозитории и возможные проблемы с IPv6.

Иногда картина портится из-за AAAA-записей и нерабочей IPv6-связности: резолвинг проходит успешно, но соединение после этого зависает или завершается ошибкой. Внешне это нередко принимают за чистый DNS-сбой.

Сценарий 2: SSH по имени не работает, по IP работает

Это почти готовый индикатор, что проблема именно в резолвинге имени. Для начала проверьте, видит ли его система вообще.

getent hosts myhost.example.com
ssh -v user@myhost.example.com

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

На серверах бывает и обратная ситуация: входящий SSH тормозит из-за reverse lookup или недоступного DNS. Но это уже другой класс симптомов: не ошибка разрешения исходящего имени, а медленный login и задержки в аутентификации.

Сценарий 3: после правки netplan DNS пропал полностью

Обычно виноват один из трёх факторов: неверный интерфейс, неправильный шлюз или не применившийся блок nameservers. Сверяйте не только YAML, но и реальное состояние через resolvectl status. Если в конфиге DNS указан, а в runtime его нет, проблема не в самом адресе, а в механизме применения.

Сценарий 4: /etc/resolv.conf указывает на 127.0.0.53, и кажется, что это ошибка

Сам по себе адрес 127.0.0.53 нормален для systemd-resolved. Ошибка не в нём, а в том, что за локальным stub может не быть рабочего upstream DNS. Если локальный слушатель есть, а resolvectl status показывает пустые DNS Servers, значит резолвить просто нечем.

Пошаговый runbook: как починить быстро и без лишних движений

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

1. Проверить IP-связность: ping до внешнего IP, ip route, наличие default route.
2. Проверить системный резолвинг: getent hosts, resolvectl query.
3. Посмотреть /etc/resolv.conf и понять, это symlink, stub или статический файл.
4. Проверить systemd-resolved: статус, логи, активные DNS-серверы.
5. Если это Ubuntu с netplan, проверить YAML, интерфейс, gateway, DNS и использовать netplan try.
6. Если DNS-серверы указаны, но не отвечают, проверить доступность до них и локальные правила firewall.
7. Если нужно срочно восстановить работу, временно задать рабочий nameserver, а потом уже искать, почему штатная схема не применяет настройки.

Ценность этого порядка в том, что он не смешивает уровни диагностики. Большинство долгих инцидентов затягиваются потому, что администратор одновременно правит resolv.conf, перезапускает сеть, меняет netplan и при этом забывает проверить маршрут.

Безопасное временное восстановление резолвинга

Когда сервер уже не может скачать пакеты, обновить индексы или достучаться до внешних API, иногда сначала нужно вернуть DNS, а уже потом спокойно разбирать первопричину. Для этого можно временно использовать статический /etc/resolv.conf, но только если вы понимаете, кто обычно его генерирует.

Перед любыми правками сохраните текущее состояние.

cp -a /etc/resolv.conf /root/resolv.conf.backup
ls -l /etc/resolv.conf
cat /etc/resolv.conf

Дальше логика простая: либо исправляете источник правды — netplan, DHCP или systemd-resolved, либо временно прописываете рабочие DNS вручную. Второй вариант допустим как аварийная мера, но не должен становиться постоянной схемой.

Если вы разворачиваете проекты на VDS, полезно сразу после создания сервера делать короткий smoke test сети: IP, маршрут, DNS, доступ к репозиториям и внутренним именам. Это экономит заметно больше времени, чем кажется.

Как понять, где источник правды для DNS

Это ключевой вопрос всей темы. Пока вы не понимаете, кто реально управляет DNS на машине, любые правки превращаются в угадайку. В одной системе источник — YAML netplan, в другой — DHCP lease, в третьей — drop-in для systemd-resolved, в четвёртой — логика инициализации облачного образа.

Практический подход такой: смотрите на /etc/resolv.conf, затем на симлинк, затем на активные сервисы и runtime-статус через resolvectl. После этого картина обычно становится понятной. Если нет — поднимайте логи сетевого стека после загрузки системы.

journalctl -b --no-pager | grep -Ei 'dns|resolved|network|dhcp'

По этим сообщениям часто видно, кто прислал DNS-серверы, почему они не применились и что именно сломалось после последнего изменения конфигурации.

Профилактика: как больше не ловить этот сбой

Полностью исключить DNS-инциденты нельзя, но можно резко снизить их вероятность и сократить время восстановления.

• Документируйте, кто управляет сетью и DNS на конкретном сервере.
• Не смешивайте несколько сетевых менеджеров без необходимости.
• На удалённых машинах применяйте изменения через netplan try или с заранее продуманным откатом.
• Используйте как минимум два DNS-сервера, если это соответствует вашей схеме.
• После изменений проверяйте не только ping, но и getent hosts, resolvectl query, apt update.
• Следите за логами systemd-resolved после перезагрузки и смены сетевого профиля.
• Не редактируйте /etc/resolv.conf вслепую, пока не поняли, будет ли он автоматически перезаписан.

Если в инфраструктуре используются собственные домены и внутренние зоны, не забывайте поддерживать в порядке и базовые доменные операции. В смежных сценариях может быть полезна статья про перенос домена, EPP-коды и DNS, особенно если проблема началась после изменений у регистратора или провайдера DNS.

Итог

Ошибка Temporary failure in name resolution в Debian и Ubuntu почти никогда не требует магии. Достаточно разложить проблему по шагам: есть ли сеть по IP, есть ли маршрут, кто управляет DNS, что показывает /etc/resolv.conf, жив ли systemd-resolved, применился ли netplan, доступны ли сами DNS-серверы.

Если держать в голове эту последовательность, то и сбой в apt, и неработающий ssh по имени, и «внезапно пропавший DNS» после сетевых правок перестают быть хаотичной аварией. Это становится обычной задачей диагностики, которую можно закрыть быстро и без лишнего риска для продакшена.