dig находит адрес, приложение нет: сравниваем DNS и системное разрешение имён

Инженер запускает dig, получает правильный адрес и закрывает сетевую часть расследования. Но приложение на сервере продолжает обращаться к старому адресу. Команды не обязательно используют один путь разрешения. dig делает DNS-запрос, а обычный Linux-клиент часто обращается к системному механизму, который учитывает порядок источников имён.

Спросите системный механизм

getent ahosts api.internal.example
dig api.internal.example A
dig api.internal.example AAAA
cat /etc/nsswitch.conf
cat /etc/hosts

В nsswitch.conf найдите строку hosts. Она задаёт источники и условия перехода между ними. Например, локальный файл может проверяться раньше DNS. Тогда забытая запись в hosts объяснит, почему системный клиент видит другой адрес при правильном ответе dig.

Допустим, DNS возвращает 10.30.0.20, а getent — 10.30.0.10. В hosts обнаруживается старое соответствие имени адресу. Теперь есть конкретный объект исправления. Удалять его вслепую тоже не стоит: запись могла обеспечивать временный обход. Уточните назначение, согласуйте возврат к DNS и повторите обе проверки.

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

Учитывайте корпоративный DNS

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

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

Отделите кэш от открытого соединения

После исправления системного ответа приложение может продолжать использовать прежний IP. Оно могло закэшировать адрес или держать соединение открытым. Запустите новый экземпляр диагностического клиента и посмотрите адрес назначения. Если новый процесс работает, а старый нет, исследуйте жизненный цикл его DNS-кэша и соединений.

Для воспроизводимого отчёта сохраните имя, ответы getent и dig, строку источников hosts и наличие VPN. Локальные адреса перед публичной отправкой отчёта замените учебными. Часто это небольшое различие объясняет, почему ошибка возникает только на одной машине, хотя все проверяют «тот же DNS».

Результат исправления проверяют через системный механизм и через приложение. Прямой DNS-запрос остаётся контрольным измерением, но занимает своё место в цепочке. Такая последовательность помогает не менять исправную зону из-за старой локальной настройки.

Соберите последовательный подход к сетевым сбоям Linux. В программе Linux и Bash для DevOps-инженеров есть сеть, DNS и сопровождение учебного сервиса. Откройте программу, чтобы переходить от различий инструментов к конкретной причине в окружении приложения.

Ещё по теме

• Проверяем новый сервер до переключения DNS: curl --resolve с настоящим именем
• DNS после изменения записи: сравниваем авторитетный сервер и резолвер