Для диагностики DNS начните с dig +noall +comments +answer enterno.io A: строка status показывает результат запроса, а ANSWER — полученную запись. Если разные резолверы отвечают по-разному, спросите авторитетные NS напрямую. +short удобен для скрипта, но пустой вывод не отличает отсутствие записи от ошибки.
Этот справочник пригодится, когда домен указывает не туда, обновление DNS видно не всем или проверка почты показывает неожиданный MX. Ниже — 25 запущенных команд и реальные ответы с публичных доменов. Для каждого набора есть следующий диагностический шаг; команды, которые лишь печатают запись, сами по себе не доказывают исправность всей зоны.
Сначала отделите отсутствие записи от ошибки
dig +short печатает значение записи, но убирает код ответа. На нашем замере запросы AAAA и CAA к enterno.io напечатали пустую строку и завершились с кодом 0. По одному такому выводу нельзя сказать, был ли ответ NOERROR без записи или NXDOMAIN. Повторите запрос с +comments +answer и проверьте заголовок.
$ dig +noall +comments +answer enterno.io A
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34558
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
# … omitted OPT pseudo-section
;; ANSWER SECTION:
enterno.io. 2989 IN A 81.163.20.249В образце видны NOERROR и флаги rd ra: запрос прошёл через рекурсивный резолвер. Число 2989 — TTL в этом ответе в момент замера, а не настройка, одинаковая у всех кешей. У авторитетного NS тот же A-адрес пришёл с флагом aa и TTL 3600. Для объяснения TTL при переносе есть отдельный разбор DNS TTL; типы записей собраны в справочнике DNS-записей.
25 команд по четырём диагностическим маршрутам
Сначала спросите нужный тип записи; затем сравните рекурсивные ответы. Если они расходятся, запросите два авторитетных сервера. Делегирование проверяйте на родительской зоне, а подпись DNSSEC — отдельно. В таблице вывод сокращён до диагностического фрагмента; полный stdout каждой команды сохранён в методике.
| № | Команда | Реальный фрагмент вывода | Что проверять дальше |
|---|---|---|---|
| 1 | dig -v | DiG 9.18.33 | Версия утилиты; вывод идёт в stderr, это нормально. |
| 2 | dig +short enterno.io A | 81.163.20.249 | A-запись: IPv4-адрес без статуса и TTL. |
| 3 | dig +short enterno.io AAAA | пустой stdout | Пусто. Проверить полный ответ перед выводом об ошибке. |
| 4 | dig +short enterno.io MX | 1 smtp.google.com. | Приоритет и имя почтового сервера. |
| 5 | dig +short enterno.io NS | dns1.yandex.net. | Имена NS из рекурсивного ответа. |
| 6 | dig +short enterno.io SOA | dns1.yandex.net. dns-hosting.yandex.ru. 42 900 90 86400 900 | SOA содержит serial и таймеры зоны. |
| 7 | dig +short enterno.io TXT | "v=spf1 ip4:81.163.20.249 include:_spf.google.com -all" | TXT может содержать несколько разных политик; не трактуйте весь вывод как SPF. |
| 8 | dig +short enterno.io CAA | пустой stdout | Пусто. Это отсутствие ответа на тип CAA, а не диагноз TLS. |
| 9 | dig +short _dmarc.enterno.io TXT | "v=DMARC1; p=none; rua=mailto:postmaster@enterno.io" | Политика DMARC ищется на имени _dmarc. |
| 10 | dig @1.1.1.1 +short enterno.io A | 81.163.20.249 | Ответ рекурсивного резолвера 1.1.1.1. |
| 11 | dig @8.8.8.8 +short enterno.io A | 81.163.20.249 | В этом замере адрес совпал с 1.1.1.1. |
| 12 | dig @9.9.9.9 +short enterno.io A | 81.163.20.249 | Третий независимый рекурсивный ответ. |
| 13 | dig @dns1.yandex.net +norecurse +noall +comments +answer enterno.io A | flags: qr aa; enterno.io. 3600 IN A 81.163.20.249 | Флаг aa: ответ получен от авторитетного NS. |
| 14 | dig @dns2.yandex.net +norecurse +noall +comments +answer enterno.io A | flags: qr aa; enterno.io. 3600 IN A 81.163.20.249 | Второй NS отдаёт тот же A-адрес. |
| 15 | dig @dns1.yandex.net +norecurse +noall +answer enterno.io SOA | enterno.io. 900 IN SOA dns1.yandex.net. dns-hosting.yandex.ru. 42 900 90 86400 900 | Serial на первом NS. |
| 16 | dig @dns2.yandex.net +norecurse +noall +answer enterno.io SOA | enterno.io. 900 IN SOA dns1.yandex.net. dns-hosting.yandex.ru. 42 900 90 86400 900 | Serial на втором NS; сравнивайте значения, а не TTL. |
| 17 | dig @a0.nic.io +norecurse +noall +answer +authority enterno.io NS | enterno.io. 3600 IN NS dns2.yandex.net. | Делегирование из родительской зоны .io. |
| 18 | dig @dns1.yandex.net +norecurse +noall +answer enterno.io NS | enterno.io. 900 IN NS dns1.yandex.net. | NS из самой зоны enterno.io. |
| 19 | dig +trace enterno.io NS | ; <<>> DiG 9.18.33 <<>> +trace enterno.io NS | Путь от корня к авторитетным NS; длинный вывод сверните до нужного участка. |
| 20 | dig +short cloudflare.com DS | 2371 13 2 32996839A6D808AFE3EB4A795A0E6A… | DS хранится в родительской зоне подписанного примера. |
| 21 | dig +short cloudflare.com DNSKEY | 257 3 13 mdsswUyr3DPW132mOi8V9… | DNSKEY опубликован в дочерней зоне. |
| 22 | dig @1.1.1.1 +dnssec +noall +comments +answer cloudflare.com A | flags: qr rd ra ad; cloudflare.com. 300 IN A 104.16.132.229 | Флаг ad в ответе валидирующего резолвера. |
| 23 | dig @1.1.1.1 +cd +noall +comments +answer cloudflare.com A | flags: qr rd ra cd; cloudflare.com. 206 IN A 104.16.132.229 | Флаг cd запрашивает отключение проверки у резолвера. |
| 24 | dig @1.1.1.1 +tcp +noall +answer enterno.io A | enterno.io. 3064 IN A 81.163.20.249 | Тот же A-запрос по TCP; сравните с UDP при сбоях. |
| 25 | dig -x 1.1.1.1 +short | one.one.one.one. | PTR для IP-адреса 1.1.1.1. |
Список не заменяет экспорт зоны у DNS-провайдера. Запрос ANY не обязан вернуть все типы: RFC 8482 разрешает минимальный ответ. Для инвентаризации спрашивайте конкретные типы и сверяйте экспорт. Это особенно важно при переезде, когда забытая AAAA или TXT-запись останется вне случайного ответа ANY.
Сравните рекурсивные ответы с авторитетными
В замере 1.1.1.1, 8.8.8.8 и 9.9.9.9 вернули один A-адрес для enterno.io. Оба NS Яндекса вернули тот же адрес с флагом aa. Если публичный резолвер отличается от авторитетного, сначала проверьте TTL и время изменения записи; если отличаются сами авторитетные NS, исправляйте зону у DNS-провайдера. Удобно начать с проверки DNS на enterno.io, затем подтвердить спорный ответ прямой командой dig @NS +norecurse.
Не сравнивайте голые строки целиком: порядок NS и A-записей может меняться, а TTL у рекурсивных ответов уменьшается в кеше. Сравнивайте множество адресов или имён, код ответа и флаги. При проблеме «работает у меня, не работает у коллеги» добавьте проверку распространения DNS, но её результат тоже фиксирует лишь момент запроса.
Проверьте делегирование в родительской зоне
Авторитетные NS домена и NS, указанные родительской зоной, должны вести к одной рабочей конфигурации. В нашем замере прямой запрос к a0.nic.io и к dns1.yandex.net вернул два имени: dns1.yandex.net и dns2.yandex.net. Разный порядок строк ничего не меняет. Если наборы различаются, сначала выясните, какую сторону ещё не обновили: запись у регистратора или NS внутри самой зоны.
dig +trace enterno.io NS показывает переход от корня к .io и дальше к NS домена. Он помогает локализовать ошибку делегирования, но длинный вывод нельзя читать только по последней строке: ищите, на каком переходе адреса серверов или ответы изменились. Подробный разбор неполадок — в диагностике неразрешающегося DNS.
DNSSEC: запрашивать подпись и проверять её — разные операции
На подписанном cloudflare.com запросы DS и DNSKEY вернули записи. Ответ от 1.1.1.1 с +dnssec имел флаг ad; с +cd — флаг cd. По RFC 4035 эти флаги относятся к поведению валидации ответа. Команда dig +dnssec запрашивает DNSSEC-данные, но сама не строит проверку цепочки доверия; для этого у ISC есть delv.
Сравнение обычного ответа и +cd полезно при SERVFAIL: если ответ появляется лишь с отключённой проверкой у резолвера, проверяйте DS, DNSKEY и подписи. Если оба запроса дают ошибку, это ещё не доказательство поломанного DNSSEC. Следуйте разбору DNSSEC и проверяйте каждый NS. Точное поведение флагов и опций — в руководстве ISC по dig.
Как сделан материал
13 ноября 2026 года на сервере srv2029141.hstgr.cloud запущены 25 команд из method.py с DiG 9.18.33. Сохранены argv, код завершения, stdout и stderr в data.json. Использованы публичные домены enterno.io и cloudflare.com; частные домены пользователей и данные клиентов не использовались. Все 25 команд завершились с кодом 0; пустые stdout у dig -v, AAAA и CAA имеют разные причины. DNS-ответы меняются, поэтому значения нужно перепроверить перед публикацией. Материал подготовлен на собственных замерах и первоисточниках; полный вывод команд сохранён в редакционном архиве.
Частые вопросы
Почему dig +short ничего не выводит?
Короткий формат скрывает статус. Повторите запрос с +noall +comments +answer: NOERROR без записи выбранного типа обычно означает NODATA; проверьте секции ответа и CNAME. NXDOMAIN — отсутствие имени, а SERVFAIL — сбой обработки. О полном маршруте проверки читайте в разборе проблем DNS.
Чем dig @1.1.1.1 отличается от запроса к NS домена?
Первый запрос идёт к рекурсивному резолверу и может получить ответ из кеша. Запрос с +norecurse к авторитетному NS показывает данные, которые этот сервер отдаёт для зоны сейчас. Сопоставляйте код, флаг aa, сами значения и TTL.
Проверяет ли dig +dnssec подпись DNSSEC?
Нет, этот флаг запрашивает DNSSEC-записи в ответе. Для проверки цепочки используйте валидирующий резолвер и delv; результат +cd помогает отделить ошибку валидации от других сбоев. Не удаляйте DS у регистратора по одному выводу dig.
Можно ли получить всю зону через dig ANY?
Нет. ANY относится к одному имени, а сервер вправе вернуть лишь часть типов записей. Для полного списка имён и записей нужен доступ к зоне у провайдера; для точечной проверки используйте A, AAAA, MX, NS, SOA, TXT и CAA отдельно.
