Сбои DNS на выделенном сервере: от приложения к резолверу

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

В этой статье используется Ubuntu Server 24.04 LTS. После оплаты выделенного сервера AMDSSH данные для входа доступны в панели управления; подключение выполняется по SSH. Если у сервера несколько адресов, используйте первый. Приведённые ниже проверки не меняют адреса сетевых интерфейсов, маршруты и межсетевой экран, поэтому подходят для первоначального сбора диагностических данных.

1. Зафиксируйте имя запроса и исходную ошибку

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

Ниже amdssh.com. используется как пример формата запроса; наличие в ответе какого-либо конкретного адреса не предполагается. Для итоговой проверки замените его именем, которое требуется приложению и для которого подтверждено наличие нужных записей. Сначала проверьте доступность инструментов, затем сохраните основные сведения об окружении:

command -v getent resolvectl dig
date -Is
readlink -f /etc/resolv.conf
cat /etc/resolv.conf
grep '^hosts:' /etc/nsswitch.conf
systemctl is-active systemd-resolved
resolvectl status

Утилита dig входит в пакет dnsutils. Если она ещё не установлена, подготовьте инструменты через уже настроенные репозитории. Когда разрешение имён уже не работает, неудачная установка не является новым свидетельством первопричины сбоя.

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

2. Сопоставьте NSS и системную службу разрешения имён

Три способа запроса не равнозначны

getent выполняет запрос через NSS и ближе к обычным системным вызовам разрешения адресов. resolvectl обращается к systemd-resolved. dig выполняет DNS-запрос и не проверяет весь путь через NSS.

getent ahostsv4 amdssh.com.
resolvectl query --type=A amdssh.com.
dig amdssh.com. A +time=2 +tries=1

Результаты всех трёх запросов нужно рассматривать вместе. Если getent возвращает старый адрес, а DNS-запрос — новый, сначала проверьте /etc/hosts и порядок модулей в строке hosts:. Если resolvectl отрабатывает успешно, а getent — нет, проверьте наличие модулей NSS, корректность их порядка и то, не работает ли служба в другом окружении файловой системы.

/etc/resolv.conf может указывать на локальную точку входа в службу разрешения имён, а не содержать адреса конечных вышестоящих серверов. Этот файл также может создаваться средством управления сетью. Наличие локального адреса само по себе не доказывает ошибку конфигурации. Не перезаписывайте символическую ссылку, чтобы затем проверить, исчез ли сбой.

Некоторые приложения используют собственную DNS-библиотеку и обходят NSS. Поэтому успешный вызов getent подтверждает исправность системного пути, но не восстановление работы всех приложений.

3. Запросите вышестоящий сервер напрямую и отделите ошибки ответа от сбоев транспорта

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

read -r -p 'DNS server address: ' DNS_SERVER
dig @"$DNS_SERVER" amdssh.com. A +time=2 +tries=1
dig @"$DNS_SERVER" amdssh.com. A +tcp +time=2 +tries=1
dig @"$DNS_SERVER" amdssh.com. AAAA +time=2 +tries=1

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

Действуйте в зависимости от статуса ответа

NXDOMAIN означает, что имя не существует. Сначала проверьте написание имени, домены поиска и записи на авторитетном сервере. NOERROR с пустой секцией ответов может означать лишь отсутствие записи данного типа; это не следует считать сетевым сбоем. SERVFAIL указывает на ошибку в процессе разрешения имени — для дальнейшей проверки нужны журналы вышестоящего сервера или помощь его администратора. При REFUSED проверьте права на выполнение запроса.

Если запрос по UDP завершается по тайм-ауту, а запрос по TCP проходит успешно, транспортные пути ведут себя по-разному; следующим шагом может быть проверка соответствующих сетевых правил. Если оба запроса завершаются по тайм-ауту, проверьте маршрут до этого вышестоящего сервера и правила доступа. Однако по одному тайм-ауту нельзя заключить, что сервер не работает. Если вышестоящий сервер отвечает, а системный путь не работает, вернитесь к локальной конфигурации и кэшам.

4. Исправляйте причину по собранным данным, не подменяя владельца конфигурации

Сначала выясните, какой компонент управляет настройками DNS. В Ubuntu Server конфигурация может передаваться через Netplan конкретному сетевому бэкенду, но возможны и другие способы управления. Для постоянного изменения нужно править конфигурационный файл компонента, который действительно управляет настройками, а не только сгенерированный /etc/resolv.conf.

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

resolvectl statistics
sudo resolvectl flush-caches
resolvectl query --type=A amdssh.com.
getent ahostsv4 amdssh.com.

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

Перед изменением порядка NSS сохраните исходный файл и выясните, какие модули отвечают за локальные файлы, DNS и другие источники имён. Модули с условными действиями могут завершать поиск раньше времени, поэтому недостаточно просто проверить наличие слова dns.

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

5. Подтвердите результат в окружении рабочего процесса

После восстановления работы хоста проверьте файлы настройки разрешения имён, доступные контейнеру или изолированной службе. У контейнера может быть собственный /etc/resolv.conf, а процесс может продолжать использовать закэшированные старые адреса. Повторите запросы в фактическом окружении выполнения, а не только в терминале хоста.

Итоговая проверка включает следующие пункты:

• Выполните запросы нужных типов записей для полного доменного имени приложения и убедитесь, что адреса соответствуют ожидаемому назначению.
• Сопоставьте результаты NSS, системной службы разрешения имён и фактически используемого вышестоящего сервера.
• Выполните реальный запрос приложения, чтобы отличить ошибку разрешения имени от последующего сбоя подключения.
• Проверьте, не закреплён ли в приложении старый адрес и не требуется ли обновить его кэш через интерфейс управления.
• Убедитесь, что постоянная конфигурация сохранена компонентом, который должен ею управлять; после контролируемой перезагрузки проверьте, не была ли она перезаписана.
• Сохраните вывод до и после изменений, различия в конфигурации и результаты запросов приложения, а не только отметку «работа восстановлена».

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

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