# dig: отладка DNS-запросов в CLI Индекс LLMS: [llms.txt](/llms.txt) --- DNS- resolver отдал не тот адрес, клиенты не видят обновление, или просто непонятно, какой сервер сейчас отвечает на запросы. `dig` (Domain Information Groper) — стандартный инструмент для диагностики DNS из терминала. Работает на Linux, macOS, есть в Windows через WSL. Установка ```bash # Debian/Ubuntu apt install dnsutils # RHEL/CentOS/Alma dnf install bind-utils # macOS — уже в системе # Windows — через WSL или официальный бинарник ISC ``` ## Базовые флаги `dig` имеет два класса опций: короткие флаги (начинаются с `-`) и ключевые слова с `+`. Первые управляют поведением запроса, вторые — форматом вывода. ```bash dig example.com ``` Без аргументов вывод избыточен: много технической информации в header. Для отладки берём нужные куски. | Флаг | Назначение | |------|------------| | `-b ` | Исходящий IP-адрес (если несколько интерфейсов) | | `-f ` | Читать запросы из файла, по одному на строку | | `-p ` | Нестандартный порт DNS-сервера | | `-t ` | Тип записи: A, AAAA, MX, TXT, SOA, NS, CNAME, ANY | | `-c ` | Класс сети (по умолчанию IN — Internet) | | `-x ` | Обратный запрос (PTR) | | `-6` | Принудительный IPv6 | | `-4` | Принудительный IPv4 | ## Быстрый ответ: +short Для скриптов и быстрой проверки: ```bash dig example.com +short # 93.184.216.34 ``` ```bash dig mail.example.com +short # 10 mailgateway.example.com. ``` Если запись не существует — пустой вывод. Если CNAME — увидите финальный адрес, но не цепочку. Для AAAA-записей: ```bash dig example.com AAAA +short # 2606:2800:220:1::248a:2873 ``` > [!NOTE] > `+short` не показывает TTL и не гарантирует, что это итоговый ответ. CNAME-петля отдаст последнюю запись в цепочке, а не ошибку. ## Полный ответ: +noall +answer Когда нужен TTL, каноническое имя и все записи разом: ```bash dig example.com +noall +answer # ;; Truncated, retry in binary mode. dig @8.8.8.8 example.com +noall +answer +未知 ``` ```bash dig example.com +noall +answer # example.com. 86400 IN A 93.184.216.34 ``` ```bash 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: ```bash dig example.com +stats ``` ## Обратный запрос: -x Обратная зона: IP → имя хоста. ```bash dig -x 93.184.216.34 +short # domain.example.com. ``` ```bash dig -x 8.8.4.4 @1.1.1.1 +short # dns.google. ``` > [!TIP] > Не все PTR-зоны заполнены. Пустой ответ при `-x` — нормально, особенно для клиентских адресов. ## IPv6: -6 Принудительный IPv6-транспорт к DNS-серверу: ```bash dig -6 @2001:4860:4860::8888 example.com AAAA +short # 2606:2800:220:1::248a:2873 ``` Если хотите AAAA-запись через IPv4-транспорт — просто запрашивайте тип: ```bash dig @1.1.1.1 example.com AAAA +short ``` ## Трассировка цепочки: +trace Показывает путь от корневых серверов до финального ответа: ```bash dig example.com +trace +noall +answer ``` Вывод разбит на секции: `.` (root), TLD (`.com`), авторитативный NS, ответ. ```bash 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`. Явное указание — для сравнения ответов или обхода локального кэша: ```bash dig @8.8.8.8 example.com +short dig @1.1.1.1 example.com +short dig @9.9.9.9 example.com +short ``` ```bash dig @ns1.example.com example.com AXFR +short ``` AXFR-трансфер работает только если NS разрешает. > [!WARNING] > AXFR всей зоны — чувствительная операция. Не делайте так на чужих NS без необходимости. ## Типичные сценарии **Проверка SOA и NS зоны** ```bash 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 конкретной записи** ```bash dig example.com A +noall +answer +ttlid # example.com. 300 IN A 93.184.216.34 ``` 300 секунд — низкий TTL, нормально для часто меняющихся записей. Для статики обычно 3600+. **CNAME chain** ```bash dig www.example.com +trace +noall +answer ``` Цепочка отображается целиком. Если редирект сломался на середине — на каком этапе NXDOMAIN или SERVFAIL станет ясно из вывода. **Сравнение ответов разных resolver'ов** ```bash for ns in 8.8.8.8 1.1.1.1 9.9.9.9; do echo "=== $ns ==="; dig @$ns example.com +short; done ``` ```bash # Результат === 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** ```bash dig @ns1.example.com _sip._tcp.example.com SRV +noall +answer +stats ``` Смотрите flags: SERVFAIL в ответе означает NS не смог получить данные. Проверяйте, что запрашиваемый тип записи вообще существует в зоне. **ANY-запрос (осторожно)** ```bash dig example.com ANY +short ``` Deprecated в продакшене. Но для быстрой диагностики всех типов записи на новом NS — сойдёт.