Ошибка «Temporary failure in name resolution» на VDS: почему Linux и Docker теряют интернет и как починить резолвинг DNS

Ситуация, знакомая каждому администратору и разработчику: сервер внезапно теряет возможность обращаться к внешним ресурсам. Команды apt update, curl, git clone или docker pull прерываются с сообщением Could not resolve host или критической ошибкой «Temporary failure in name resolution». При этом сетевое соединение живо: прямые пинги до публичных IP-адресов (например, ping 77.88.8.8 или ping 1.1.1.1) проходят без единой потери пакетов.

Причина кроется в сбое подсистемы преобразования доменных имен (DNS-резолвинга). В современных дистрибутивах Linux (Ubuntu 22.04 / 24.04 LTS, Debian 12) архитектура управления DNS претерпела серьезные изменения по сравнению со старыми выпусками: за разрешение имен отвечает демон systemd-resolved через локальный сокет-заглушку, а Docker использует собственную изолированную логику трансляции запросов. В этой практической инструкции мы разберем анатомию сбоя, проведем экспресс-диагностику и устраним все типовые источники проблемы.

1. Симптомы сбоя: почему пинг по IP работает, а доменные имена недоступны

Сетевой стек операционной системы разделяет транспортную доставку пакетов (уровень IP-маршрутизации L3) и прикладной уровень разрешения символических имен в сетевые адреса. Системные вызовы getaddrinfo() и gethostbyname() обращаются к локальным резолверам через библиотеку glibc (файл /etc/nsswitch.conf), прежде чем приложение вообще попытается открыть TCP/UDP-сокет.

Для быстрой проверки гипотезы выполните два встречных теста в консоли сервера:

# Тест 1: Проверка прямого IP-канала (L3)
ping -c 3 77.88.8.8

# Тест 2: Проверка символьного резолвинга
ping -c 3 syskit.ru

Если тест по IP проходит успешно (0% packet loss), а тест по доменному имени моментально возвращает ping: syskit.ru: Temporary failure in name resolution — физический линк и таблица маршрутизации шлюза исправны. Сбой локализован строго в цепочке DNS-резолвинга.

2. Архитектура DNS в современных дистрибутивах: systemd-resolved, stub-listener 127.0.0.53 и resolv.conf

Чтобы осознанно починить систему, а не просто применить случайную команду из интернета, важно понимать актуальную цепочку обработки DNS-запроса в Ubuntu и Debian:

Ключевая точка уязвимости — файл /etc/resolv.conf. Исторически это был статичный конфигурационный файл. В современных системах под управлением systemd он обязан быть символической ссылкой на /run/systemd/resolve/stub-resolv.conf. Если старый скрипт, панель управления или утилита NetworkManager заменили эту ссылку обычным файлом со статическим содержимым, то при смене сети или падении указанного там IP-адреса вся сетевая подсистема прекращает резолвинг.

3. Экспресс-диагностика VDS за 2 минуты: команды для поиска узкого места

Для локализации проблемы выполните последовательно четыре команды. Они покажут, на каком именно этапе рвется цепочка преобразования имен.

# Шаг 1: Проверка статуса службы systemd-resolved
sudo systemctl status systemd-resolved

# Шаг 2: Просмотр активных DNS-серверов и привязок к интерфейсам
resolvectl status

# Шаг 3: Проверка типа файла /etc/resolv.conf (симлинк или обычный файл)
ls -la /etc/resolv.conf

# Шаг 4: Тестовый запрос напрямую к локальному stub-резолверу
dig @127.0.0.53 syskit.ru +short

При нормальной работе системы утилита ls -la /etc/resolv.conf обязана показать стрелку символической ссылки:

lrwxrwxrwx 1 root root 39 Feb 15 10:20 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Если команда resolvectl status выводит пустые списки в графе DNS Servers, служба systemd-resolved находится в состоянии inactive (dead) или запрос через dig @127.0.0.53 зависает по таймауту — переходим к устранению конкретной неисправности.

4. Причина 1: Сбитый или перезаписанный симлинк /etc/resolv.conf

Самая распространенная причина ошибки после ручной настройки VPN, установки пакетов resolvconf или переноса сервера — превращение /etc/resolv.conf в обычный статичный файл с неактуальными записями.

# Проверяем содержимое файла
cat /etc/resolv.conf

Если вы видите строки вроде nameserver 10.0.0.1 или nameserver 127.0.0.1, при этом файл не является ссылкой, восстановите эталонную конфигурацию systemd:

# Удаляем поврежденный статичный файл или битый симлинк
sudo rm -f /etc/resolv.conf

# Создаем корректную символическую ссылку на stub-resolv.conf
sudo ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

# Перезапускаем службу резолвинга
sudo systemctl restart systemd-resolved

# Проверяем результат
ping -c 2 syskit.ru

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

5. Причина 2: Сбой службы systemd-resolved и настройка надежных upstream DNS

Иногда сервер получает сетевые настройки по DHCP от виртуального шлюза провайдера, но предоставленные провайдером DNS-серверы начинают терять пакеты, попадают под блокировки или зависают. В этом случае локальный stub 127.0.0.53 не получает ответов и возвращает приложению ошибку Temporary failure in name resolution.

Настроим независимые, отказоустойчивые внешние апстримы напрямую в конфигурационном файле /etc/systemd/resolved.conf.

# Открываем файл конфигурации
sudo nano /etc/systemd/resolved.conf

Приведите блок [Resolve] к следующему эталонному виду (раскомментируйте и заполните директивы):

[Resolve]
DNS=77.88.8.8 1.1.1.1 8.8.8.8
FallbackDNS=77.88.8.1 1.0.0.1 8.8.4.4
Domains=~.
DNSSEC=allow-downgrade
DNSOverTLS=opportunistic
MulticastDNS=no
LLMNR=no
Cache=yes

Примените настройки и сбросьте накопившийся кэш DNS-ответов:

# Перезапуск службы
sudo systemctl restart systemd-resolved

# Сброс локального DNS-кэша
sudo resolvectl flush-caches

# Проверка активного статуса
resolvectl status

В выводе команды вы должны увидеть список указанных DNS-серверов в секции Global. Проверьте запрос через утилиту resolvectl:

resolvectl query syskit.ru

Команда должна вывести актуальные IP-адреса и подтверждение разрешения имени через выбранный апстрим.

7. Причина 3: Специфика Docker — почему хост видит сеть, а контейнеры выдают ошибку DNS

Классическая ловушка для DevOps-инженеров и сисадминов: на самом сервере VDS команды curl и ping выполняются моментально, но внутри Docker-контейнеров сборка образов (RUN apt-get update) или запуск приложений завершается ошибкой Temporary failure in name resolution.

По этой причине демон Docker при чтении хостового /etc/resolv.conf игнорирует локальный адрес 127.0.0.53 и по умолчанию подставляет в контейнеры публичные DNS Google (8.8.8.8 и 8.8.4.4). Если провайдер хостинга или сетевые правила фильтруют прямые UDP-запросы на 8.8.8.8, контейнеры полностью слепнут.

Чтобы раз и навсегда решить эту проблему на уровне всего хоста, задайте глобальные DNS-серверы в конфигурации демона /etc/docker/daemon.json:

{
  "dns": [
    "77.88.8.8",
    "1.1.1.1"
  ],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "20m",
    "max-file": "3"
  }
}

Примените настройки перезапуском Docker:

sudo systemctl restart docker

Проверьте работоспособность резолвинга внутри свежего изолированного контейнера:

docker run --rm alpine nslookup syskit.ru

Если вывод возвращает адресное соответствие без задержек — подсистема DNS в Docker работает стабильно.

8. Причина 4: Блокировки фаервола UFW, проблемы с DNSSEC и таймауты

Если адресные серверы прописаны корректно, но запросы продолжают зависать по таймауту, проверьте сетевой экран сервера. DNS работает преимущественно по протоколу UDP на 53 порту, однако при получении ответов размером более 512 байт (например, при ответах с ключами DNSSEC или объемными TXT-записями) протокол автоматически переключается на TCP порт 53.

Если на сервере включен межсетевой экран UFW с политикой блокировки исходящих соединений по умолчанию (default deny outgoing), обязательно откройте 53 порт для обоих протоколов:

# Разрешаем исходящий DNS-трафик по UDP и TCP
sudo ufw allow out 53/udp
sudo ufw allow out 53/tcp

# Перезагружаем правила UFW
sudo ufw reload

Протестировать доступность удаленного DNS-сервера по TCP можно с помощью встроенной утилиты Netcat:

# Проверка TCP-порта 53 на сервере Яндекса
nc -zvw3 77.88.8.8 53

Ответ Connection to 77.88.8.8 53 port [tcp/domain] succeeded! подтверждает, что фаервол и канал хостинг-провайдера не блокируют DNS-трафик.

9. Итоговый чек-лист сетевой устойчивости сервера

Для закрепления результата и предотвращения повторных сбоев пройдите по контрольному чек-листу настройки сетевого стека:

1. Проверка симлинка: Файл /etc/resolv.conf является символической ссылкой на ../run/systemd/resolve/stub-resolv.conf.
2. Апстримы в resolved: В /etc/systemd/resolved.conf явно указаны DNS=77.88.8.8 1.1.1.1 и Domains=~., исключающие зависимость от сбоев шлюза провайдера.
3. Режим DNSSEC: Установлен флаг DNSSEC=allow-downgrade, предотвращающий падение резолвинга зон с ошибками криптографических подписей.
4. Глобальный DNS в Docker: В /etc/docker/daemon.json прописан внешний массив "dns": ["77.88.8.8", "1.1.1.1"].
5. Исходящие порты: Фаервол UFW пропускает исходящий трафик на 53 порт по протоколам UDP и TCP.