Диагностика DNS с dig и nslookup: как читать ответы

Когда домен открывает старый сервер или не находится, фраза «проблема с DNS» слишком широка. Нужно определить, что именно отвечает неверно: авторитетная зона, делегирование, рекурсивный кеш или локальный компьютер.

dig показывает подробный DNS-ответ и удобен в Linux/macOS. nslookup доступен в Windows и подходит для базовой проверки. Обе программы только читают данные — они не меняют домен, поэтому откат после команд не требуется.

Запишите ожидаемый результат

До диагностики определите имя, тип записи и правильное значение. Для сайта это может быть A с IPv4, AAAA с IPv6 или CNAME с именем площадки. Отдельно запишите авторитетные NS, указанные у DNS-провайдера.

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

В примерах используется example.com, зарезервированный для документации. Замените его своим доменом. Команды запускаются в терминале локального компьютера; административные права не нужны.

Получите короткий ответ с помощью dig

Сначала запросите A-запись через настроенный в системе рекурсивный резолвер. На Linux dig обычно входит в пакет DNS-утилит дистрибутива; на macOS он доступен из системы.

dig example.com A +noall +answer

dig отправляет DNS-запрос, A выбирает IPv4-запись, +noall скрывает все разделы, а +answer возвращает только ответ. Ожидается строка с именем, оставшимся TTL, классом IN, типом A и IP-адресом. Если строк нет, выполните полный dig example.com A и посмотрите статус: NXDOMAIN означает отсутствие имени, а SERVFAIL — невозможность получить проверяемый ответ.

Так же запросите AAAA, CNAME, MX или TXT, меняя только тип. Не ищите CNAME после того, как резолвер уже вернул конечный A, не посмотрев полный ответ: программа может показать цепочку в нескольких строках.

Узнайте авторитетные серверы домена

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

dig example.com NS +noall +answer

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

Спросите запись прямо у источника зоны

Замените ns1.dns-provider.example реальным NS из предыдущего ответа. Символ @ указывает dig, к какому серверу обратиться, минуя выбранный системой рекурсивный резолвер.

dig @ns1.dns-provider.example example.com A +noall +answer

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

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

Проследите делегирование от корня

При подозрении на неверные NS используйте трассировку. Команда последовательно спрашивает корневые, верхнеуровневые и авторитетные серверы. Она ничего не изменяет, но вывод получается длинным.

dig +trace example.com

Читайте вывод сверху вниз. Сначала видны серверы корня, затем NS доменной зоны верхнего уровня, после них делегирование example.com и конечный ответ. Остановившаяся цепочка или неожиданный набор NS указывает, на каком уровне искать ошибку. Учтите: корпоративный firewall может блокировать прямые DNS-запросы и мешать +trace; повторите тест из другой разрешённой сети, прежде чем менять домен.

Выполните базовую проверку в Windows

В PowerShell или командной строке Windows запросите A-запись встроенной программой nslookup. Команда использует DNS-сервер, настроенный в системе.

nslookup -type=A example.com

Сначала выводится используемый резолвер, затем ответ для домена. Метка Non-authoritative answer означает, что данные пришли из рекурсивного поиска или кеша, а не прямо от авторитетного источника; это нормально. Если адрес не совпадает с ожидаемым, запросите NS командой nslookup -type=NS example.com, а затем укажите конкретный сервер последним аргументом: nslookup -type=A example.com ns1.dns-provider.example.

nslookup показывает меньше деталей о секциях ответа и TTL, поэтому для сложной диагностики удобнее dig. Но для проверки, что имя находится на обычном Windows-компьютере, его достаточно.

Различайте основные статусы

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

Тайм-аут отличается от отрицательного ответа: сервер не ответил вовремя. Проверьте сеть, firewall и другие NS. Не создавайте новую запись только потому, что один публичный резолвер временно недоступен.

После DNS откройте сайт по HTTPS и проверьте HTTP-код. Верный IP не гарантирует правильный виртуальный хост и сертификат. Порядок подключения описан в статье о домене и хостинге, а устройство делегирования — в уроке об NS-серверах.

Источники

• BIND 9 documentation: dig manual
• Microsoft Learn: nslookup
• RFC 1035: Domain Names — Implementation and Specification