Проверка DNS-записей домена с помощью dig

Базовый запрос имеет вид: dig имя-домена. Без указания типа утилита обычно запрашивает запись A, содержащую IPv4-адрес. В выводе важны несколько блоков. В строке статуса отображается результат обработки запроса. Значение NOERROR означает, что DNS-сервер корректно обработал запрос, но само по себе не гарантирует наличие нужной записи. Статус NXDOMAIN указывает, что запрошенного доменного имени не существует.

Основная информация находится в секции ANSWER SECTION. Здесь приводятся имя, TTL, класс IN, тип записи и значение. Например, для A-записи последним полем будет IPv4-адрес, для MX — приоритет и почтовый сервер, для TXT — текстовая политика. Если секция ответа пуста, полезно проверить статус, секцию полномочий и тип запрошенной записи.

Строка SERVER показывает DNS-резолвер, который дал ответ. По умолчанию это настроенный в системе рекурсивный сервер. Время выполнения отражается в поле Query time. Эти данные помогают отличить ошибку зоны от проблемы конкретного локального резолвера или кеша.

Для проверки IPv4-адреса используется команда dig имя-домена A, а для IPv6 — dig имя-домена AAAA. Если сайт не открывается по одной из сетевых версий, сравнение A и AAAA записей помогает обнаружить устаревший или ошибочный адрес. Для краткого вывода без технических секций добавляют параметр +short: dig имя-домена A +short.

Почтовые настройки проверяются запросом dig имя-домена MX. В ответе у каждого почтового узла есть числовой приоритет: чем меньше число, тем выше приоритет доставки. Важно убедиться, что указанные в MX имена разрешаются в A или AAAA записи и не являются некорректным псевдонимом CNAME.

Для просмотра серверов имен зоны используется dig имя-домена NS. Результат нужно сопоставить с настройками у регистратора: при несовпадении делегирование может вести на другую DNS-зону. Запрос dig имя-поддомена CNAME показывает псевдоним и помогает проверить, куда фактически направлен поддомен.

TXT-записи проверяют командой dig имя-домена TXT. Они часто содержат параметры подтверждения владения доменом, правила SPF, данные DKIM и политики DMARC. Длинное значение может отображаться несколькими фрагментами в кавычках; при анализе его следует рассматривать как единую строку в том порядке, в котором вернул сервер.

Чтобы получить ответ от конкретного сервера, перед именем домена указывают его адрес после символа @: dig @адрес-сервера имя-домена A. Такой запрос особенно полезен при переносе DNS-зоны. Можно отдельно проверить авторитетный сервер, публичный резолвер и локальный DNS, а затем сравнить возвращаемые данные.

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

Параметр +trace запускает последовательную проверку цепочки DNS: от корневых серверов к серверам доменной зоны и далее к авторитетному серверу нужного домена. Команда dig имя-домена A +trace помогает выявить проблему делегирования, отсутствующие glue-записи или несогласованность между уровнями DNS. Такой вывод объемнее обычного, но он показывает, на каком шаге нарушается разрешение имени.

Если требуется получить ответ без рекурсивного поиска, используют параметр +norecurse. Он полезен при обращении к авторитетному серверу: в корректном ответе обычно присутствует признак авторитетности. Это позволяет убедиться, что данные получены непосредственно из зоны, а не из кеша промежуточного резолвера.

Статус NXDOMAIN чаще всего означает опечатку в имени, отсутствие поддомена или неправильное делегирование. Если домен существует, но в ANSWER SECTION нет записи нужного типа, это может быть нормальным результатом: например, у домена может не быть AAAA-записи. В таком случае следует проверить другие типы записей и корректность поставленной задачи.

Ответ SERVFAIL говорит о том, что сервер не смог завершить обработку запроса. Причинами бывают недоступность авторитетных серверов, ошибки DNSSEC, сбой конфигурации зоны или проблемы сети. Для диагностики нужно повторить запрос к разным резолверам, проверить NS-записи и выполнить запрос с +trace. Если ошибка проявляется только у одного сервера, вероятна проблема его кеша или настроек.

При использовании DNSSEC полезна команда dig имя-домена A +dnssec. В ответе могут присутствовать DNSSEC-связанные записи и флаги. Ошибка в цепочке подписей способна привести к тому, что валидирующие резолверы возвращают SERVFAIL, хотя невалидирующие серверы показывают обычный ответ. В такой ситуации нужно проверять DS-запись в родительской зоне, ключи DNSKEY и актуальность подписей.

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

Начните с короткой проверки адреса: dig имя-домена A +short и при необходимости dig имя-домена AAAA +short. Затем запросите NS-записи и определите, какие серверы являются авторитетными. После этого выполните одинаковые запросы к каждому из них через символ @, чтобы исключить рассинхронизацию зоны.

Для почтового домена проверьте MX, TXT, а также записи селектора DKIM и политики DMARC, если они используются. При диагностике поддомена сначала выясните, является ли он A-записью, CNAME или отдельной делегированной зоной. Не стоит судить о корректности DNS только по одному ответу локального провайдера: он может содержать закешированные данные.

Сохраняйте вывод команд до и после изменения записей. Сравнение статуса, секции ответа, TTL и выбранного сервера помогает быстро понять, где именно возникла задержка. Для регулярной проверки удобно использовать краткий формат +short, а при ошибках переходить к полному выводу и трассировке +trace.