Перейти к содержимому

dig: отладка DNS-запросов в CLI

Раздел: Посты Слов: 695 4 мин
Lead DevOps

DNS- resolver отдал не тот адрес, клиенты не видят обновление, или просто непонятно, какой сервер сейчас отвечает на запросы. dig (Domain Information Groper) — стандартный инструмент для диагностики DNS из терминала. Работает на Linux, macOS, есть в Windows через WSL.

Установка

# Debian/Ubuntu
apt install dnsutils

# RHEL/CentOS/Alma
dnf install bind-utils

# macOS — уже в системе
# Windows — через WSL или официальный бинарник ISC

Базовые флаги

dig имеет два класса опций: короткие флаги (начинаются с -) и ключевые слова с +. Первые управляют поведением запроса, вторые — форматом вывода.

dig example.com

Без аргументов вывод избыточен: много технической информации в header. Для отладки берём нужные куски.

ФлагНазначение
-b <addr>Исходящий IP-адрес (если несколько интерфейсов)
-f <file>Читать запросы из файла, по одному на строку
-p <port>Нестандартный порт DNS-сервера
-t <type>Тип записи: A, AAAA, MX, TXT, SOA, NS, CNAME, ANY
-c <class>Класс сети (по умолчанию IN — Internet)
-x <addr>Обратный запрос (PTR)
-6Принудительный IPv6
-4Принудительный IPv4

Быстрый ответ: +short

Для скриптов и быстрой проверки:

dig example.com +short
# 93.184.216.34
dig mail.example.com +short
# 10 mailgateway.example.com.

Если запись не существует — пустой вывод. Если CNAME — увидите финальный адрес, но не цепочку.

Для AAAA-записей:

dig example.com AAAA +short
# 2606:2800:220:1::248a:2873
Примечание

+short не показывает TTL и не гарантирует, что это итоговый ответ. CNAME-петля отдаст последнюю запись в цепочке, а не ошибку.

Полный ответ: +noall +answer

Когда нужен TTL, каноническое имя и все записи разом:

dig example.com +noall +answer
# ;; Truncated, retry in binary mode.
dig @8.8.8.8 example.com +noall +answer +未知
dig example.com +noall +answer
# example.com.         86400   IN      A       93.184.216.34
dig example.com MX +noall +answer
# example.com.         3600    IN      MX      10 mailstore1.example.com.
# example.com.         3600    IN      MX      20 mailstore2.example.com.

TTL в секундах. Если видите маленькое значение (60–300) — запись часто обновляется.

Подробный ответ с timing:

dig example.com +stats

Обратный запрос: -x

Обратная зона: IP → имя хоста.

dig -x 93.184.216.34 +short
# domain.example.com.
dig -x 8.8.4.4 @1.1.1.1 +short
# dns.google.
Подсказка

Не все PTR-зоны заполнены. Пустой ответ при -x — нормально, особенно для клиентских адресов.

IPv6: -6

Принудительный IPv6-транспорт к DNS-серверу:

dig -6 @2001:4860:4860::8888 example.com AAAA +short
# 2606:2800:220:1::248a:2873

Если хотите AAAA-запись через IPv4-транспорт — просто запрашивайте тип:

dig @1.1.1.1 example.com AAAA +short

Трассировка цепочки: +trace

Показывает путь от корневых серверов до финального ответа:

dig example.com +trace +noall +answer

Вывод разбит на секции: . (root), TLD (.com), авторитативный NS, ответ.

dig internal.example.com +trace +noall +answer
# .                       518400  IN      NS      a.root-servers.net.
# com.                    172800  IN      NS      a.gtld-servers.net.
# example.com.            172800  IN      NS      a.iana-servers.net.
# internal.example.com.   300     IN      A       10.0.1.50

+trace медленная — обходит иерархию рекурсивно. Используйте для диагностики NXDOMAIN и SERVFAIL.

Определенный resolver: @server

По умолчанию dig берёт системный resolver из /etc/resolv.conf. Явное указание — для сравнения ответов или обхода локального кэша:

dig @8.8.8.8 example.com +short
dig @1.1.1.1 example.com +short
dig @9.9.9.9 example.com +short
dig @ns1.example.com example.com AXFR +short

AXFR-трансфер работает только если NS разрешает.

Предупреждение

AXFR всей зоны — чувствительная операция. Не делайте так на чужих NS без необходимости.

Типичные сценарии

Проверка SOA и NS зоны

dig example.com SOA +short
# ns1.example.com. admin.example.com. 2024011501 7200 3600 1209600 86400

dig example.com NS +short
# ns1.example.com.
# ns2.example.com.

Serial в SOA — если вы обновили записи, а он не вырос, трансфер не произошёл.

TTL конкретной записи

dig example.com A +noall +answer +ttlid
# example.com.         300     IN      A       93.184.216.34

300 секунд — низкий TTL, нормально для часто меняющихся записей. Для статики обычно 3600+.

CNAME chain

dig www.example.com +trace +noall +answer

Цепочка отображается целиком. Если редирект сломался на середине — на каком этапе NXDOMAIN или SERVFAIL станет ясно из вывода.

Сравнение ответов разных resolver’ов

for ns in 8.8.8.8 1.1.1.1 9.9.9.9; do
  echo "=== $ns ===";
  dig @$ns example.com +short;
done
# Результат
=== 8.8.8.8 ===
93.184.216.34
=== 1.1.1.1 ===
93.184.216.34
=== 9.9.9.9 ===
93.184.216.34

Если адреса разные — проблема не на стороне вашего сервиса, а в конкретном resolver или propagate записи.

Анализ SERVFAIL

dig @ns1.example.com _sip._tcp.example.com SRV +noall +answer +stats

Смотрите flags: SERVFAIL в ответе означает NS не смог получить данные. Проверяйте, что запрашиваемый тип записи вообще существует в зоне.

ANY-запрос (осторожно)

dig example.com ANY +short

Deprecated в продакшене. Но для быстрой диагностики всех типов записи на новом NS — сойдёт.

Изменено 01.09.2026