dig: проверка DNS из консоли — 18 команд и разбор вывода по строкам

Онлайн-чекеры DNS показывают результат, но не показывают, откуда он взялся: из кэша, от вашего провайдера или действительно с авторитативного сервера. dig показывает весь ответ целиком — с флагами, кодом, TTL и временем запроса. Разбираем каждую строку и собираем набор готовых команд.

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

Где взять dig

На десктопных Linux и macOS утилита обычно уже есть. В контейнерах и минимальных образах — почти никогда, потому что пакет с ней не входит в базовый набор.

Синтаксис за тридцать секунд

dig [@сервер] [имя] [тип] [+опции]

dig example.com                 # A-запись через резолвер из resolv.conf
dig example.com MX              # почтовые серверы
dig @8.8.8.8 example.com NS     # спросить конкретный резолвер
dig +short example.com          # только результат, без обвязки

Порядок аргументов свободный: dig MX example.com и dig example.com MX работают одинаково.

Полный вывод и что означает каждая строка

; <<>> DiG 9.20.26 <<>> example.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41234
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            300     IN      A       93.184.216.34

;; Query time: 23 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Sep 14 08:15:03 UTC 2026
;; MSG SIZE  rcvd: 56

Число 300 в строке ответа — это TTL в секундах: сколько резолверы имеют право держать запись в кэше. При смене IP именно оно определяет, сколько вы будете ждать переключения.

Флаги в заголовке — самое полезное поле

В строке flags: перечислены только установленные биты. По ним читается, откуда пришёл ответ.

Коды ответа: что означает status

Поле status — это диагноз в одном слове. Шесть значений покрывают почти все реальные случаи.

Опции, которые нужны каждый день

По умолчанию dig ждёт ответа 5 секунд и делает 3 попытки — зависший запрос упирается в 15 секунд. В любом скрипте и мониторинге это нужно сокращать явно.

Восемнадцать команд под реальные задачи

# 1. Какой сейчас IP у сайта
dig +short example.com

# 2. То же, но с TTL — видно, сколько ещё будет висеть кэш
dig +noall +answer example.com

# 3. Спросить напрямую авторитативный сервер, минуя кэши
dig @ns1.example.com example.com A +norecurse

# 4. Сравнить два резолвера: свой и публичный
dig @8.8.8.8 +short example.com
dig @1.1.1.1 +short example.com

# 5. Почтовые серверы с приоритетами
dig +noall +answer example.com MX

# 6. Проверить SPF и другие TXT-записи
dig +short example.com TXT

# 7. Проверить DKIM-селектор
dig +short mail._domainkey.example.com TXT

# 8. Политика DMARC
dig +short _dmarc.example.com TXT

# 9. NS-серверы домена
dig +short example.com NS

# 10. SOA с расшифровкой всех полей
dig example.com SOA +multiline +noall +answer

# 11. Обратный запрос: чей это IP
dig -x 8.8.8.8 +short

# 12. Весь путь от корня — куда реально делегирован домен
dig +trace example.com

# 13. Опросить все NS зоны и сравнить серийники
dig example.com +nssearch

# 14. Проверить, отвечает ли сервер по TCP (важно для больших зон)
dig @ns1.example.com example.com ANY +tcp

# 15. Посмотреть DNSSEC-подписи
dig example.com A +dnssec +multiline

# 16. Быстрый запрос для мониторинга: 2 секунды, одна попытка
dig +short +timeout=2 +tries=1 @8.8.8.8 example.com

# 17. Проверить пачку доменов одной командой
dig -f domains.txt +short

# 18. Машиночитаемый вывод
dig example.com A +yaml

Что показывает +trace и почему результат бывает другим

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

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

dig, nslookup или host

Распространённое заблуждение: nslookup не объявлен устаревшим — слова «deprecated» в актуальных man-страницах BIND нет. Но для диагностики он неудобен, потому что скрывает служебные поля.

Сколько должен занимать запрос

Строка Query time — недооценённый показатель. Норматива на неё нет, но эмпирические диапазоны устойчивые.

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

Чего dig не покрывает

dig отвечает на вопрос «что в DNS прямо сейчас, с этой машины». Он не ответит на два других: что было ночью и что видят пользователи в других регионах. А проблемы DNS редко бывают постоянными — чаще один из четырёх NS-серверов отвечает через раз, или запись подменилась после чьей-то правки в панели регистратора.

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