DNS-диагностика: getent, dig и путь имени до адреса

DNS сопоставляет имена с записями, но приложение в Linux может использовать более широкий Name Service Switch: локальный hosts, DNS, mDNS или корпоративный provider. Поэтому dig отвечает на вопрос о DNS-сервере, а getent — ближе к тому, что получит обычная программа через системный resolver.

Начните с системного результата

getent ahosts example.com
getent hosts example.com
grep '^hosts:' /etc/nsswitch.conf

Если имя есть в /etc/hosts, getent может вернуть его даже при отсутствии DNS-записи. Порядок sources задаёт строка hosts в nsswitch.conf. Не редактируйте её до фиксации текущего поведения.

Исследуйте DNS через dig

dig example.com A +noall +answer
dig example.com AAAA +noall +answer
dig example.com CNAME +noall +answer

Answer содержит тип, TTL и данные. Пустой ответ не всегда означает несуществующее имя: тип может отсутствовать, а status быть NOERROR. Смотрите header через обычный dig. NXDOMAIN означает, что authoritative сторона заявила отсутствие имени; SERVFAIL — resolver не смог получить проверяемый ответ.

Resolver, authoritative server и cache

Файл /etc/resolv.conf показывает configured nameservers/search, но на systemd-resolved он может указывать на локальный stub. Команда resolvectl status, если доступна, покажет реальные upstream по интерфейсам. Запрос к выбранному серверу задаётся как dig @address name, однако сравнение public resolver с корпоративным может дать разные корректные ответы split DNS.

TTL сообщает, сколько ответ разрешено кэшировать. После изменения записи часть клиентов некоторое время видит старое значение. Нельзя обещать мгновенное «распространение DNS»: важны прежний TTL, negative caching и cache конкретного resolver.

DNS — не проверка доступности сервиса

Успешный A/AAAA говорит только об адресе. Следом нужно проверить route/TCP/TLS/HTTP. И наоборот, сервис может быть доступен по уже закэшированному адресу во время сбоя resolver. Всегда записывайте имя, тип записи, сервер ответа, время и фактический address приложения.

Ошибка и диагностика

Симптом «dig работает, приложение пишет Name or service not known» часто связан с NSS, search domain, контейнерным resolver или разным namespace. Выполните getent в той же среде и под тем же runtime, затем сравните /etc/nsswitch.conf и resolv.conf. Не подменяйте production hostname в локальном hosts как постоянное исправление: это скрывает реальную цепочку.

Практика

Для одного публичного имени сравните getent и dig A/AAAA, запишите TTL и status. Выполните запрос с завершающей точкой в имени и без неё, если настроен search domain. Нарисуйте путь: приложение → NSS → resolver → cache → authoritative server.

Что важно запомнить

Источники