Как проверить DNS: команды dig, nslookup и разбор ответов

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

Начните с nslookup example.com. Если нужно увидеть код ответа и сами DNS-записи, выполните dig example.com A. Разберём, как прочитать вывод обеих команд и выбрать следующую проверку.

Будем использовать example.com — зарезервированный для документации домен. Понадобятся утилиты BIND 9 dig и nslookup в командной строке. В Debian и Ubuntu их предоставляет пакет bind9-dnsutils; в других дистрибутивах название пакета может отличаться. На macOS наличие и конкретную реализацию нужно проверить отдельно. Для начала можно вывести версии:

dig -v
nslookup -version

Запускайте команды там, где возникает проблема: например, на рабочей станции или внутри контейнера. В разных окружениях могут быть настроены разные DNS-серверы. Учтите, что dig и nslookup не обязательно используют тот же механизм разрешения имён, что браузер или приложение.

Как проверить DNS через nslookup

Выполните обычный запрос:

nslookup example.com

В начале вывода поля Server и Address показывают DNS-сервер, к которому обратилась утилита. Ниже ищите полученные адреса example.com. Пометка Non-authoritative answer означает, что ответ не был помечен как авторитетный; при обращении через рекурсивный DNS-сервер это обычная ситуация.

Чтобы проверить конкретный тип записи, укажите -type:

nslookup -type=A example.com
nslookup -type=AAAA example.com
nslookup -type=MX example.com

A содержит IPv4-адреса, AAAA — IPv6-адреса, MX — сведения о почтовых обменниках. У одного имени могут быть записи A, но отсутствовать MX. В ответе также может оказаться несколько записей, причём их значения и порядок способны изменяться.

Если нужно сравнить DNS-серверы, можно явно указать другой адрес:

nslookup example.com 1.1.1.1

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

Если по краткому выводу неясно, что произошло, используйте dig: он показывает код DNS-ответа и его разделы.

Команда dig: полная и краткая проверка DNS

Начните с запросов адресных записей:

dig example.com A
dig example.com AAAA

dig показывает заголовок DNS-сообщения, заданный вопрос, полученные записи и адрес ответившего сервера. В отличие от краткого вывода, здесь можно увидеть код DNS-ответа и разобраться в причине отсутствия записи.

Для быстрого просмотра записей можно сократить вывод:

dig example.com A +short
dig example.com MX +noall +answer
dig example.com NS +noall +answer

Параметр +short скрывает подробный заголовок и сведения о сервере ответа. Сочетание +noall +answer оставляет раздел ANSWER, включая имя, TTL, класс, тип и данные записей, если они пришли. Эти переключатели описаны в справочнике dig.

Пустой вывод +short нельзя трактовать как доказательство отсутствия домена. Чтобы установить причину, повторите запрос без сокращения — dig example.com A — и прочитайте status, ANSWER и сообщения утилиты. Отсутствие записи нужного типа, ошибка сервера и таймаут требуют разных действий.

Уточняйте тип, соответствующий проблеме: для IPv6 берите AAAA, для почтовой доставки — MX, для делегирования — NS. Не используйте запрос ANY как универсальную проверку всех записей зоны.

Как читать ответ dig: статус, записи и TTL

Разберите вывод сверху вниз. В условном примере ниже показан формат ответа: имя api.example.test и IPv4-адреса из диапазона для документации. Реальный ответ будет зависеть от запрошенного имени и DNS-сервера:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1234
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;api.example.test.       IN A

;; ANSWER SECTION:
api.example.test.  300   IN A    192.0.2.10

;; SERVER: 192.0.2.53#53(192.0.2.53) (UDP)

Сначала проверьте QUESTION SECTION: в нём должны совпасть имя и тип, которые вы собирались запросить. status: NOERROR означает отсутствие DNS-ошибки на уровне кода ответа; сам по себе этот статус ещё не гарантирует наличия подходящей записи. В ANSWER SECTION показаны имя, TTL в секундах, класс IN, тип A и адрес. TTL — срок жизни ответа для кэша, а не время до обновления сайта; в кэширующем резолвере оставшийся TTL может уменьшаться.

Поле SERVER — адрес сервера, от которого пришёл ответ. Оно не означает, что этот сервер авторитетен для запрошенной зоны. В DNS-заголовке AA отмечает авторитетный ответ, RD — запрос рекурсии, RA — доступность рекурсии у сервера. Значение флагов определено RFC 1035, раздел 4.1.1.

Наблюдение	Что означает	Следующая проверка
`NOERROR`, подходящая запись в `ANSWER`	Запись запрошенного типа получена	Сверить значение, сервер и дальнейшую доступность приложения
`NXDOMAIN`	Отрицательный ответ об имени	Проверить написание имени и нужную DNS-зону
`NOERROR`, нет подходящих записей	Возможный NODATA, но требуется контекст	Проверить `AUTHORITY`, `SOA`, `CNAME` и тип запроса
`SERVFAIL`	Сервер не смог обработать запрос	Сравнить с разрешённым другим резолвером и проверить серверные журналы
Сообщение о таймауте вместо DNS-ответа	Ответ не получен за время ожидания	Проверить путь до резолвера и доступность DNS по сети

NXDOMAIN обозначает отсутствие имени, а не только записи запрошенного типа. Если же имя существует, но данных нужного типа нет, возможен отрицательный ответ NODATA. NODATA — не отдельный код ответа: обычно это NOERROR без подходящих записей, который нужно оценивать с учётом других разделов. Например, запись SOA (параметры DNS-зоны) в AUTHORITY SECTION помогает отличить NODATA от перенаправления к другому DNS-серверу. Если присутствует CNAME (псевдоним), проверьте имя, на которое он указывает. Критерии и исключения приведены в RFC 2308, разделы 2.1–2.2.

Как сравнить ответы двух DNS-серверов

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

dig example.com A
dig @1.1.1.1 example.com A

Здесь первая команда использует DNS-сервер, выбранный dig по настройкам его окружения (в BIND 9 на Linux обычно из /etc/resolv.conf). Вторая явно направляет запрос к 1.1.1.1. Это публичный рекурсивный резолвер Cloudflare, а не авторитетный сервер для example.com. Синтаксис @server описан в справочнике dig.

Сравните четыре признака: QUESTION (одинаковое имя и тип), status, записи в ANSWER и SERVER. TTL полезен для понимания кэша, но его различие само по себе не говорит о сбое. Обязательно запишите время запросов: содержимое зоны и кэшей может меняться.

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

Для внутренних имён сравнивайте только корпоративные DNS-серверы, к которым разрешён доступ. Если такой сервер один, проверьте его настройки и доступность, не отправляя внутреннее имя публичному резолверу.

Что делать при NXDOMAIN, SERVFAIL и таймауте

Если вернулся NXDOMAIN. Убедитесь, что запрашиваете верное полное имя и нужную зону. Если проверяете корпоративный ресурс, уточните, какой внутренний DNS-сервер отвечает за его зону. Смена типа A на AAAA сама по себе не исправит NXDOMAIN.

Если NOERROR, но ANSWER пуст. Сначала повторите полный запрос нужного типа и посмотрите AUTHORITY. При наличии CNAME проверьте конечное имя, а при SOA — контекст отрицательного ответа. Пустой ANSWER не всегда означает NODATA: в ответе может содержаться делегирование к другому серверу.

Если SERVFAIL. Сервер вернул DNS-ошибку обработки. Запишите SERVER, тип запроса и время. Сравните тот же запрос через другой разрешённый резолвер. Если проблема воспроизводится, передайте администратору имя, тип запроса, время и адреса проверенных серверов. По этим данным можно проверить журналы DNS-сервера, рекурсию, делегирование и возможные ошибки DNSSEC.

Если ответа нет. Для ограниченной повторной попытки можно указать время ожидания и число попыток:

dig example.com A +time=2 +tries=1

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

Отрицательные ответы DNS могут кэшироваться, поэтому повторный запрос не обязательно обращается к авторитетному серверу. RFC 2308, раздел 5 описывает правила отрицательного кэширования. Различайте задержку обновления кэша и продолжающуюся ошибку на сервере: проверить это помогают запросы к разрешённым авторитетным серверам зоны, если они известны.

Если запись получена, переходите к проверке порта, TLS и ответа приложения. Эти проверки отделяют успешное разрешение имени от доступности самого сервиса.

Итог: последовательность проверки DNS

Для быстрой проверки используйте nslookup example.com, а для диагностики — dig example.com A. Сверьте имя и тип запроса, затем status, ANSWER и SERVER. При необходимости повторите запрос с типом AAAA, MX или NS; пустой вывод +short требует проверки полного ответа.

Если записи нет, определите, что произошло: NXDOMAIN, возможный NODATA, SERVFAIL или таймаут. При расхождении ответов сравните настройки и кэши разрешённых резолверов. Когда запись найдена, продолжайте диагностику соединения с сервисом.

Чтобы воспроизвести положительный ответ, NXDOMAIN и NODATA без зависимости от публичного DNS, используйте учебный loopback-стенд XNova. Следуйте инструкциям в README: команда python article_demo.py позволит увидеть положительный ответ с A-записью, NXDOMAIN и NOERROR без записи нужного типа. Пример работает через локальный DNS-сервер и не отправляет запросы к публичным резолверам.