Как пользоваться dig в Linux для диагностики DNS

Содержание

• Что такое DNS и как работает dig
• Установка dnsutils в Linux
• Базовые запросы dig
• Кастомные запросы и полезные опции
• Использование dig в скриптах и пакетная обработка
• Методика диагностики DNS с dig (SOP)
• Роли и чек-листы
• Критерии приёмки
• Часто задаваемые вопросы
• Краткое резюме

Что такое DNS и как работает dig

DNS (Domain Name System) переводит удобочитаемые доменные имена в IP‑адреса. Это аналог телефонной книги для сетей: по имени ищется «адрес» машины. DNS распределён по иерархии серверов: корневые, доменов верхнего уровня (TLD), авторитетные неймсервера для конкретных доменов.

Когда вы открываете сайт, система использует последовательность запросов к известным серверам, пока не получит запись (например, A для IPv4 или AAAA для IPv6). Утилита dig показывает этот процесс: она отправляет DNS‑запросы и печатает подробный ответ от сервера, включая заголовки, вопросы, ответы и информацию о сервере, который ответил.

Коротко: dig — инструмент для ручных или автоматизированных DNS‑запросов и диагностики.

Important: Если нужен простейший быстрый ответ (только IP), используйте опцию +short.

Установка dnsutils в Linux

dig обычно входит в комплект пакета dnsutils (Debian/Ubuntu) или bind‑tools (Fedora/Red Hat) / bind‑tools (Arch). Если команда не найдена, установите соответствующий пакет.

На Ubuntu/Debian:

sudo apt install dnsutils

На Fedora/CentOS/RHEL:

sudo yum install bind-utils

На Arch Linux и производных:

sudo pacman -S bind-tools

Примечание: в некоторых сборках пакет называется bind-tools или bind-utils. После установки команда dig доступна напрямую.

Базовые запросы dig

Основной сценарий — запрос A‑записи, содержащей IPv4 адрес для домена:

dig maketecheasier.com

Вывод dig можно логически разделить на разделы: HEADER (заголовок), QUESTION (вопрос), ANSWER (ответ), AUTHORITY / ADDITIONAL (дополнения) и секцию с информацией о сервере (QUERY TIME, SERVER, MSG SIZE). Заголовок показывает параметры запроса и статус, секция вопроса — что именно запрошено, секция ответа — найденные записи и TTL.

Если нужен только IP без дополнительного вывода:

dig +short maketecheasier.com

Разбор типичного вывода:

• Status: показывает код результата (NOERROR, NXDOMAIN и т. д.).
• ANSWER секция: имя, TTL, класс (IN), тип (A/AAAA/CNAME/MX) и значение.
• SERVER: IP адрес DNS‑сервера, к которому был отправлен запрос.
• QUERY TIME: миллисекунды, потраченные на запрос.

Примеры основных типов записей

• A — IPv4 адрес.
• AAAA — IPv6 адрес.
• MX — почтовые серверы домена (приоритет и хост).
• CNAME — каноническое имя (псевдоним) для домена.
• NS — авторитетные неймсервера домена.
• TXT — произвольные текстовые записи (SPF, DKIM и т. п.).

Пример запроса AAAA (IPv6):

dig maketecheasier.com aaaa

Пример запроса MX:

dig maketecheasier.com mx

Примеры CNAME и NS:

dig maketecheasier.com cname

dig maketecheasier.com ns

Кастомные запросы и полезные опции

dig имеет множество опций, которые полезны при диагностике.

+short — минимальный вывод (только значения).

+trace — трассировка запроса в стиле «от корня к авторитету»: показывает, через какие сервера происходило разрешение имени.

dig maketecheasier.com +trace

@ — указание конкретного сервера, к которому направить запрос. Удобно, когда вы хотите проверить работу конкретного неймсервера:

dig maketecheasier.com A @168.138.12.137

+noall +answer — вывод только секции ANSWER. Полезно для парсинга в скриптах:

dig maketecheasier.com +noall +answer +nocomments mx

-4 и -6 — заставляют dig использовать только IPv4 или только IPv6 для связи с DNS‑сервером:

dig -4 +qr maketecheasier.com mx

+qr — «краткий режим ответа», полезен при пакетной обработке или в логах.

-f — чтение запросов из файла (каждая строка — пара «домен тип» или специальные флаги, см. ниже).

!Важно: кэширование DNS может давать устаревшие ответы. Если результаты не соответствуют ожидаемым, попробуйте запросить другой неймсервер или очистить системный DNS‑кеш.

Примеры для расследования

• Проверка авторитетного сервера:

dig @ns1.example.net example.com SOA

• Проверка TXT/спуфинга SPФ:

dig example.com TXT +short

• Идентификация цепочки CNAME:

dig +trace service.example.com

Использование dig в скриптах и пакетная обработка

Для массовой проверки доменов пригодна опция -f. Файл должен содержать строки вида “домен тип” или специальные флаги.

Пример файла запросов (queries.txt):

maketecheasier.com mx
maketecheasier.com ns
-x maketecheasier.com

Запуск:

dig -f queries.txt

Альтернатива: использование конструкции xargs для параллельных запросов или простые циклы shell:

while read domain; do
dig +short "$domain" >> ips.txt
done < domains.txt

Для скриптов важно:

• использовать +noall +answer для простого парсинга;
• обрабатывать коды ответа (NXDOMAIN, SERVFAIL);
• логировать IP сервера, к которому отправлялись запросы.

Методика диагностики DNS с dig — пошаговый SOP

Цель: быстро локализовать проблему разрешения имени и установить, на каком уровне она возникает.

Шаги:

1. Быстрая проверка локального резолвера
   • Выполните: dig +short example.com
   • Если ответ корректный — локальная запись найдена.
2. Проверка системного кеша и сетевого уровня
   • Запустите: dig example.com @127.0.0.1
   • Если локальный пуст, попробуйте публичный DNS: dig example.com @1.1.1.1
3. Проверка авторитетных серверов
   • Узнайте NS для домена: dig example.com ns +short
   • Попросите конкретный NS: dig @ example.com A
4. Трассировка цепочки
   • Выполните: dig example.com +trace
   • Найдите, на каком уровне возникает расхождение или отсутствие записи.
5. Проверка TTL и кеширования
   • Сравните TTL в ответах от разных серверов. Если TTL большой, возможно, нужно дождаться истечения.
6. Проверка связанных записей
   • MX, SPF/TXT, CNAME: dig example.com mx; dig example.com txt; dig sub.example.com cname
7. Параллельные проверки и логирование
   • Для множества доменов используйте парсинг +noall +answer и сохраняйте результаты с отметкой сервера и времени.

Критерии приёмки

• Получен ответ от авторитетного NS с ожидаемой записью.
• TTL и конфигурация соответствуют ожиданиям.
• Нет конфликтующих CNAME/MX записей.
• Для почты MX и SPF проверены соответствующие TXT записи.

Роли и чек-листы

Чек‑лист для сетевого администратора

• Проверить локальный резолвер: dig +short domain
• Проверить системный DNS‑кеш (systemd‑resolved/svc): flush if necessary
• Проверить связь с авторитетным NS: dig @ns-ip domain SOA
• Посмотреть трассировку: dig domain +trace

Чек‑лист для DevOps / SRE

• Проверить конфигурацию DNS в инфраструктуре (Route53, Cloud DNS и т. п.)
• Согласовать TTL и инвалидацию при деплое
• Проверить CNAME цепочки и load‑balancer targets
• Автоматизировать мониторинг (скрипты с dig +short и проверки SLI/SLO)

Чек‑лист для пентестера / разведчика

• Собрать MX, NS, CNAME и TXT записи
• Использовать +trace для понимания инфраструктуры
• Проверить обратные PTR записи: dig -x
• Сопоставить публичные записи с обнаруженными сервисами

Риски и примечания

• Неправильная конфигурация NS у регистратора может привести к полной неработоспособности домена.
• Большие значения TTL усложняют быстрое исправление записей.
• Публичный неймсервер может быть кэширован на стороне ISP — используйте авторитетные NS для проверки правды.

Когда dig не даёт ответа или выдаёт странное значение — возможные причины

1. Кеширование у провайдера или у локального резолвера.
2. Неправильная запись у регистратора или у хостинг‑провайдера.
3. Ограничения firewall/ACL, блокирующие UDP/TCP на 53 порту.
4. Проблемы репликации между мастер/слейв DNS серверами.
5. DNSSEC‑ошибки (если домен подписан).

Как проверить:

• Попробуйте запрос к разным серверам (@1.1.1.1, @8.8.8.8, затем к авторитетным);
• Проверьте доступность порта 53 (nc/telnet) и логи DNS сервера;
• Для DNSSEC: dig +dnssec example.com

Сравнение dig и nslookup (кратко)

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

Для большинства продвинутых задач рекомендуют dig.

Набор примеров и шаблонов команд (cheat sheet)

• Получить только IP:

dig +short example.com

• Получить MX и отсортировать по приоритету:

dig example.com mx +short | sort -n

• Проверить конкретный NS:

dig @ns1.example.net example.com A +noall +answer

• Трассировка разрешения имени:

dig example.com +trace

• Пакетная обработка через файл:

dig -f queries.txt > results.txt

• Простой скрипт для списка доменов:

while read d; do echo "$d: $(dig +short $d | tr '\n' ',' )"; done < domains.txt

1‑line глоссарий

• DNS: система сопоставления имён и адресов.
• A: запись IPv4.
• AAAA: запись IPv6.
• MX: почтовые сервера домена.
• NS: авторитетные неймсервера.
• TTL: время жизни записи в секундах.
• DNSSEC: криптографическая защита записей DNS.

Риски, ограничение и когда использовать альтернативы

Когда dig не подходит или стоит использовать другие инструменты:

• Для анализа трафика на сетевом уровне используйте tcpdump/wireshark — они покажут пакеты DNS, но не дадут удобного разбора ответов.
• Для тестирования HTTP/HTTPS и подтверждения доступности сервиса используйте curl.
• Для массового мониторинга DNS лучше подключать специализированные сервисы (Zabbix, Prometheus + blackbox exporter).

Edge cases:

• Если домен использует DNS‑based load balancing и CNAME на внешние CDN, ответы могут отличаться в зависимости от точки запроса.
• При DNSSEC‑ошибках ряд резолверов вовсе не вернёт запись.

Decision flowchart: когда использовать dig и какие опции

flowchart TD
  A[Проблема: сайт недоступен] --> B{Доступен IP?}
  B -- да --> C[Проверить HTTP/HTTPS через curl/telnet]
  B -- нет --> D[dig +short domain]
  D --> E{Есть ответ?}
  E -- да --> F[dig domain @ +noall +answer]
  E -- нет --> G[dig domain +trace]
  G --> H{Проблема на уровне провайдера?}
  H -- да --> I[Проверить firewall, порт 53, ISP]
  H -- нет --> F
  F --> J[Проверить MX/TXT/CNAME при необходимости]
  J --> K[Документировать и действовать]

Часто задаваемые вопросы

Можно ли использовать dig в локальной сети?

Да. Dig работает с любым DNS‑сервером, доступным по сети. Если у вас есть внутренний DNS, запросы будут разрешаться у него.

Можно ли «хакнуть» сервер с помощью dig?

Нет. dig — инструмент для запросов DNS и диагностики. Он не даёт прямого доступа к серверу. Тем не менее, собранная информация может быть использована в рамках разведки при тестировании безопасности, как и любая сетевая информация.

Как заставить dig работать только по IPv4?

Добавьте опцию -4. Пример:

dig -4 +qr maketecheasier.com mx

Чем отличается dig от nslookup?

dig более гибкий и информативный, лучше подходит для автоматизации. nslookup проще, но имеет меньше опций.

Полезные советы и рекомендации

• При миграции DNS заранее уменьшите TTL, чтобы ускорить смену записей.
• Для отладки обращайтесь напрямую к авторитетным неймсерверам, чтобы избежать кеширования.
• Логируйте ответы и время запроса при массовых проверках.
• Автоматизируйте повседневные тесты и оповещения об изменениях DNS.

Image credits: Unsplash. Скриншоты и правки — Ramces Red.

Краткое резюме

dig — незаменимый инструмент для инженера, DevOps и специалиста по безопасности при работе с DNS. Он позволяет выполнять детальные запросы, трассировать путь разрешения, тестировать конкретные неймсервера и автоматизировать проверки. Освоив базовые команды (+short, +trace, @server, +noall +answer, -f), вы сможете быстро локализовать и устранить большинство проблем с разрешением имён.

Важно: всегда проверяйте ответы от авторитетных серверов и учитывайте кеширование и TTL при внесении изменений.