Главная
» LINUX
»
Исправлена ошибка «Временная ошибка разрешения DNS» в Debian 12 при использовании systemd-resolved.
Исправлена ошибка «Временная ошибка разрешения DNS» в Debian 12 при использовании systemd-resolved.
Ошибка Temporary failure in name resolutionозначает, что приложение не смогло преобразовать имя хоста, например, deb.debian.orgв IP-адрес. В Debian 12 (Bookworm) это не означает автоматически, systemd-resolvedчто что-то не работает. Debian 12 не устанавливает systemd-resolvedDNS по умолчанию, и вместо этого DNS может управляться напрямую NetworkManager, ifupdown, инструментами DHCP или другим резолвером. Если вы намеренно включили DNS systemd-resolved, самое быстрое решение — определить, какой слой не работает, прежде чем изменять конфигурацию.
Данное практическое руководство посвящено системам, которые используют или предназначены для использования системы systemd-resolved systemd-resolved. В документации к пакету Bookworm в Debian говорится об установке systemd-resolvedпараметров /etc/resolv.confуправления systemd-resolved. Сама служба предоставляет локальный DNS-заглушку 127.0.0.53и принимает информацию от вышестоящих DNS-серверов из глобальной конфигурации, конфигурации сети для каждого канала, DHCP resolvectlи служб управления сетью. См. страницу пакета systemd-resolved в Debian и руководство по systemd-resolved в Debian .
Контрольный список для быстрой диагностики
Проверять
Командование
Что показывает результат?
Базовый сетевой путь
ping -c 3 1.1.1.1
Если IP-адрес работает, а имя хоста — нет, проверьте DNS. ICMP может быть заблокирован, поэтому не рассматривайте неудачный пинг как доказательство того, что сеть не работает.
Служба разрешения конфликтов
systemctl is-active systemd-resolved
activeПодтверждает, что демон запущен; это не доказывает работоспособность вышестоящего DNS-сервера.
Эффективная DNS
resolvectl status
Отображает глобальные и поканальные DNS-серверы, области действия, домены маршрутизации и активный режим разрешения имен.
путь поиска glibc
getent ahosts debian.org
Проверяет разрешение имени хоста через путь переключения служб имен системы, а не только с помощью инструмента, специфичного для DNS.
Журналы разрешения конфликтов
journalctl -u systemd-resolved -b
Полезно при недоступности DNS-серверов, резервном режиме работы и проблемах с протоколом.
1. Убедитесь, что проблема связана с DNS, а не с общим подключением.
Если поиск имени хоста завершается неудачей, а прямая проверка IP-адреса проходит успешно, вероятной причиной неисправности является DNS. Если оба варианта не работают, сначала проверьте интерфейс, маршрут, шлюз, VLAN, соединение Wi-Fi, брандмауэр или вышестоящую сеть. Изменение DNS не может исправить отсутствующий маршрут по умолчанию.
Прямой IP-пинг проходит успешно, в то время как разрешение адреса debian.org завершается неудачей, что является полезным признаком наличия подключения, но нарушения разрешения DNS.
Для более точной проверки маршрутизации выполните также следующие действия:
ip address
ip route
Обычно у вас должен быть адрес на ожидаемом интерфейсе и маршрут по умолчанию. Точное имя интерфейса может быть enp1s0, ens160, eth0, или что-то другое.
2. Проверьте, действительно ли используется systemd-resolved.
Не стоит предполагать, что он присутствует только потому, что на машине используется systemd. Проверьте как пакет, так и службу:
dpkg -s systemd-resolved 2>/dev/null | grep '^Status'
systemctl status systemd-resolved --no-pager
resolvectl status
Если пакет отсутствует, а на вашем компьютере установлена другая рабочая система управления DNS, установка systemd-resolvedне является автоматически правильным решением. Если система должна использовать этот пакет, а служба установлена, но остановлена, включите и запустите её:
sudo systemctl enable --now systemd-resolved
Если эта команда не сработает, проверьте журналы, прежде чем повторно перезапускать службу:
journalctl -u systemd-resolved -b --no-pager
3. Перед заменой проверьте файл /etc/resolv.conf.
Наиболее распространенная ошибка конфигурации — это обработка /etc/resolv.confфайла как изолированного. С помощью systemd-resolvedкоманды `systemd-resolved` он может работать в нескольких поддерживаемых режимах. Рекомендуемый разработчиками режим «заглушки» ссылается /etc/resolv.confна `systemd-resolved` /run/systemd/resolve/stub-resolv.conf, который направляет традиционные DNS-клиенты на ` systemd-resolved` 127.0.0.53. Другой допустимый режим ссылается на /run/systemd/resolve/resolv.conf`systemd-resolved`, который напрямую предоставляет доступ к известным серверам разработчиков, но теряет маршрутизацию DNS для каждого канала связи для приложений, которые читают этот файл напрямую.
ls -l /etc/resolv.conf
cat /etc/resolv.conf
Перед внесением изменений в файл /etc/resolv.conf проверьте, является ли он обычным файлом или символической ссылкой; разные сетевые менеджеры используют разные модели владения.
Обычный файл не обязательно является некорректным. NetworkManager или другой менеджер разрешения имен может намеренно владеть им. Однако, если этот хост предназначен для использования режима заглушки systemd-resolved, устаревший обычный файл, неработающая символическая ссылка или файл, указывающий на недоступные серверы имен, могут привести к ошибкам поиска.
Восстановите рекомендуемую ссылку-заглушку, если предполагается использование режима заглушки.
Если на этом хосте намеренно используется systemd-resolved в режиме заглушки, файл /etc/resolv.conf может указывать на поддерживаемый файл заглушки по адресу /run/systemd/resolve/stub-resolv.conf.
Наличие этого nameserver 127.0.0.53в файле-заглушке ожидаемо. Это локальный слушатель, а не вышестоящий DNS-сервер. Используйте команду resolvectl status, чтобы узнать, с какими вышестоящими серверами systemd-resolved фактически будет связываться. Это различие описано в руководстве по systemd-resolved Bookworm .
4. Проверьте, есть ли у systemd-resolved доступный вышестоящий DNS-сервер.
Бегать:
resolvectl status
Сосредоточьтесь на ссылке, которая передает маршрут по умолчанию. В исправной конфигурации обычно отображается один или несколько DNS-серверов для этой ссылки или подходящие глобальные DNS-серверы. Если подходящего DNS-сервера нет, исправление одной лишь символической ссылки не поможет: локальному заглушке некуда отправлять полезные запросы.
Вы можете протестировать средство разрешения конфликтов напрямую:
resolvectl query debian.org
В руководстве Debian resolvectlstatus описаны команды DNS query, flush-cachesиспользуемые для проверки и устранения неполадок на уровне отдельных каналов связи.
5. Если интерфейсом владеет NetworkManager, исправьте DNS в профиле подключения.
В настольных системах и многих универсальных системах Debian NetworkManager может предоставлять systemd-resolved информацию о DNS для каждого канала связи. Сначала определите активный профиль и текущие значения DNS:
nmcli connection show --active
nmcli device show
В системах NetworkManager следует проверять и изменять DNS-запросы в профиле подключения, вместо того чтобы многократно вручную редактировать файл /etc/resolv.conf.
Если DHCP предоставляет некорректный DNS-сервер, измените профиль NetworkManager, а не редактируйте его /etc/resolv.confпосле каждой перезагрузки. Например, если ваша сетевая политика разрешает использование публичных DNS-серверов:
6. Если интерфейсом управляет systemd-networkd, настройте DNS для каждого канала связи отдельно.
Для серверов, использующих DHCP systemd-networkd, разместите настройки DNS в соответствующем .networkфайле в каталоге /etc/systemd/network/. Простой пример для DHCP:
UseDNS=noЭто важно, когда вы хотите специально игнорировать DNS-серверы, предоставляемые DHCP. Без него по умолчанию используется DHCP DNS. Domains=~.Это домен только для маршрутизации для корневого DNS-сервера, что делает эту связь подходящей для запросов, которые не соответствуют более конкретному домену маршрутизации. Не добавляйте его вслепую в многосетевых или VPN-системах, где разделение DNS является преднамеренным.
sudo systemctl restart systemd-networkd
resolvectl status ens160
С помощью systemd-networkd можно задать DNS для каждого канала связи в файле .network, а затем проверить его с помощью resolvectl.
7. Используйте глобальный файл resolved.conf только в том случае, если вам действительно нужен DNS-сервер для всей системы.
/etc/systemd/resolved.confИли же можно использовать встраиваемый модуль /etc/systemd/resolved.conf.d/для определения системных DNS-серверов. Это полезно для политики, действующей на уровне всего хоста, но менее точно, чем конфигурация для каждого канала связи на машинах с VPN, несколькими интерфейсами или частными зонами DNS.
Обычно локальная установка кода проще, чем редактирование основного файла в стиле стороннего разработчика:
sudo systemctl restart systemd-resolved
resolvectl status
В руководстве Debian resolved.conf поясняется, что DNS=это указывает на наличие системных DNS-серверов, и что настройки, выполняемые администратором, /etc/systemd/resolved.conf.d/имеют приоритет над настройками с более низким приоритетом.
8. Очищайте кэш только после исправления базовой конфигурации.
Устаревший кэш может затруднить поиск и устранение неисправностей, но очистка кэша не заменяет восстановление недоступного вышестоящего сервера или неработающей конфигурации ссылок. После внесения реальных изменений в конфигурацию вы можете выполнить следующую команду:
После исправления конфигурации DNS очищайте кэш только тогда, когда это необходимо для устранения неполадок, и запрашивайте имя хоста напрямую через systemd-resolved.
В документации Systemd отмечается, что кэши обычно автоматически очищаются при изменении сетевой конфигурации, поэтому многократная ручная очистка не должна быть основным решением проблемы.
9. Прочитайте журнал обработчика ошибок, если ошибка сохраняется.
Если resolvectl statusвсё выглядит нормально, но запросы по-прежнему завершаются с ошибкой по истечении времени ожидания, проверьте журнал локального резолвера при загрузке системы:
Журнал systemd-resolved может выявить сбои на вышестоящих серверах, ухудшение обработки протоколов и поведение резервных вариантов.
Обратите внимание на повторяющиеся таймауты сервера, изменения резервного сервера, сбои проверки DNSSEC или сообщения, указывающие на ограниченные возможности протокола. Резолвер может работать в обычном режиме, в то время как его настроенный вышестоящий сервер недоступен через брандмауэр, VPN, политику маршрутизации или список контроля доступа сети.
10. Проверьте полный путь поиска.
Не останавливайтесь после одного успешного resolvectlзапроса. Проверьте путь, используемый обычными приложениями:
В завершение проверьте как путь к системному резолверу, так и приложение, которое изначально выдало ошибку, например, apt.
getentЭто полезно, потому что поиск имени хоста в glibc выполняется в соответствии со hosts:строкой в файле /etc/nsswitch.conf. Если resolvectl queryвыполняется успешно, но getentне удается, проверьте конфигурацию NSS. В руководстве Debian по nss-resolve описан необязательный libnss-resolveмодуль и рекомендуемый порядок, который позволяет направлять поиск имени хоста в glibc через systemd-resolved, сохраняя при этом резервные варианты.
Общие симптомы и наиболее вероятное место для поиска
Симптом
Вероятная область
Следующая проверка
IP-соединение работает; все имена хостов не работают.
DNS-сервер, служба разрешения имен или файл resolv.conf
resolvectl statusиls -l /etc/resolv.conf
resolvectl queryРаботает; обычные приложения не работают.
NSS или путь к резолверу, специфичному для приложения.
getent ahostsи/etc/nsswitch.conf
DNS-соединения перестают работать после перезагрузки или повторного подключения.
Конфигурация, принадлежащая сетевому менеджеру
Профиль NetworkManager или systemd-networkd
Публичные имена работают; внутренние имена не работают.
Разделение DNS, VPN, доменов маршрутизации
DNS-серверы для каждого канала связи и Domains=вresolvectl status
Только одно приложение не сработало.
Приложение, контейнер, прокси или пользовательский обработчик событий
Сравните это приложение с getentиresolvectl query
Рекомендуемый порядок ремонта
Убедитесь в наличии базового сетевого подключения и маршрута по умолчанию.
Уточните, systemd-resolvedдействительно ли данная функция предназначена для управления DNS на этом хосте.
Проверьте systemd-resolvedсостояние сервиса и resolvectl status.
/etc/resolv.confПеред изменением проверьте права собственности и режим создания символических ссылок.
Если предполагается использование режима заглушки, восстановите stub-resolv.confсоединение.
Исправьте настройки DNS-сервера у фактического владельца: NetworkManager, systemd-networkd, DHCP, VPN или в глобальной конфигурации разрешения имен.
Очищайте кэш только после исправления конфигурации.
Проверьте с помощью resolvectl, getent, и приложения, которое изначально не сработало.
Ключевой принцип — владение: /etc/resolv.confsystemd-resolved и сетевой менеджер являются частями одной цепочки резолверов. Надежное исправление изменяет DNS на уровне, которому оно принадлежит, вместо того, чтобы многократно заменять сгенерированный окончательный файл.