dig +trace +short: как проследить цепочку DNS от корня и получить краткий ответ

Утилита dig — основной инструмент диагностики DNS в Linux и macOS. Её ключи-модификаторы начинаются со знака плюс. Модификатор +short убирает всё лишнее и печатает только значения записей: для адреса это одна строка с IP, для MX — приоритет и имя сервера. Идеален для скриптов и быстрой проверки.

Модификатор +trace включает иной режим: dig не обращается к вашему резолверу за готовым ответом, а сам проходит цепочку делегирования. Он начинает с корневых серверов, спрашивает, кто отвечает за верхнюю зону, затем спрашивает сервер этой зоны про домен, и так далее до сервера, у которого лежит нужная запись. Вы видите каждый шаг и понимаете, на каком звене цепочка ломается.

Для каких ситуаций нужна трассировка: домен только что переехал на другие серверы имён, а результат разный у разных пользователей; сайт не открывается, а записи вроде бы правильные; подозрение на неверное делегирование. В остальных случаях обычно достаточно простого запроса.

Общая форма: dig, затем знак «@» с адресом сервера, имя, тип и модификаторы. Часть со знаком «@» необязательна: без неё используется резолвер из настроек системы. Тип по умолчанию A. Порядок слов свободен, но модификаторы обычно ставят в конце.

Где взять dig. В Linux пакет dnsutils в Debian и Ubuntu либо bind-utils в семействе Fedora; в macOS утилита уже установлена. В Windows её нет: можно поставить набор утилит BIND или запускать dig в подсистеме Linux, а для повседневных задач воспользоваться Resolve-DnsName.

Полезный вариант без потери информации: +noall +answer оставляет только строки ответа вместе с TTL, что удобно, когда значение времени жизни важно для проверки изменений.

Пример структуры вывода (пример): сначала список корневых серверов с TTL и пометка о том, от какого сервера и за какое время получен ответ. Затем блок серверов зоны верхнего уровня, например для com, снова с пометкой источника. Дальше — серверы имён самого домена, и в конце итоговая запись, которую отдал авторитетный сервер, например адрес в разделе ответа.

• Каждое звено сопровождает строка «Received N bytes from сервер в X ms». По ней видно, какой сервер ответил и с какой скоростью.
• Если на каком-то шаге ответа нет, dig покажет ошибку или тайм-аут: значит, узел недоступен либо делегирование указывает на неработающий сервер.
• Если серверы имён, названные родительской зоной, отличаются от тех, что отдаёт сама зона, это рассогласование: у части пользователей запросы будут идти не туда.
• Ответ авторитетного сервера, отличающийся от результата вашего обычного резолвера, означает устаревший кэш или неоконченное распространение изменений.

Комбинация dig +trace +short выводит более сжатую картину: вместо подробных блоков печатаются записи каждого звена с пометкой, от какого сервера они получены. Точный формат зависит от версии dig, поэтому сравнивайте с выводом собственной системы.

1. Выполните dig +short example.com и запомните результат вашего резолвера.
2. Опросите другой резолвер: dig +short example.com @203.0.113.53. Если ответы отличаются, различие в кэшах.
3. Выполните dig +trace example.com и найдите итоговую запись. Это то, что реально настроено у авторитетного сервера.
4. Запросите NS у родительской зоны и у самой зоны: если наборы серверов не совпадают, исправьте делегирование у регистратора.
5. Проверьте TTL в разделе ответа: пока он не истёк, кэши могут отдавать прошлое значение.
6. Если авторитетный сервер отвечает статусом SERVFAIL или REFUSED, проблема в его настройке.

Обратите внимание на статус в заголовке полного ответа: NOERROR — всё нормально, NXDOMAIN — имени нет, SERVFAIL — сбой обработки, REFUSED — сервер отказал. Флаг aa в строке flags говорит, что ответ дал авторитетный сервер.

Трассировка показывает, что происходит на пути от корня, но использует тот резолвер, что установлен в системе, только для получения списка корневых серверов. Если ваша сеть не пропускает исходящие запросы к произвольным DNS-серверам на порт 53, +trace завершится по тайм-ауту, хотя обычные сайты открываются: провайдер или межсетевой экран разрешают только собственный резолвер. Ключ +tcp и другие настройки не всегда помогут.

Кэширование не участвует в трассировке, поэтому её время больше обычного запроса и не отражает скорость повседневной работы. Для измерения реальной задержки сравнивайте строку Query time при обычных запросах.

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

Разберём несколько ситуаций, которые встречаются постоянно. Пустой ответ при +short без ошибки — записи запрошенного типа нет либо имя не существует; чтобы отличить, уберите +short и посмотрите статус в заголовке. Разные адреса при повторных запросах к одному имени — обычная ротация у сервисов с несколькими серверами, а не сбой. Разные ответы у разных резолверов при неистёкшем TTL — нормальное расхождение кэшей.

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