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

Автор: Казачкин Даниил Михайлович · Обновлено 18 августа 2026 г.

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.

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

• getent проверяет системный NSS-путь, dig — конкретно DNS.
• NOERROR без answer, NXDOMAIN и SERVFAIL имеют разные причины.
• Разрешённое имя ещё не доказывает, что порт и приложение доступны.

Частые вопросы

Почему ping находит имя, а dig нет?

Имя могло прийти из /etc/hosts, mDNS или другого NSS source. Ping обычно вызывает системный resolver, а dig обращается к DNS.

Что означает TTL ноль?

Ответ не следует долго кэшировать, но поведение конкретного промежуточного слоя нужно проверять. Это не гарантия мгновенного обновления всех клиентов.

Нужно ли очищать DNS-cache после изменения?

Только в контролируемом диагностическом сценарии. Сначала выясните, какой resolver/cache используется; без этого команда очистки может не затронуть нужный слой.