Команда dig: DNS-запросы в Linux и разбор вывода +short и +trace

Q: 📌 Какой пакет установить, если появляется dig: command not found?

На двух проверенных серверах dig входил в пакет bind-utils в AlmaLinux 9 и в пакет bind9-dnsutils в Debian 12. Поэтому в семействе RHEL его устанавливают через [sudo dnf install bind-utils], а в семействе Debian — через [sudo apt install bind9-dnsutils]. Оба пакета заодно устанавливают nslookup.

Q: 📌 Как не добавлять одни и те же параметры при каждом запуске dig?

По официальному руководству, dig читает параметры из файла .digrc в домашней папке и применяет их раньше аргументов командной строки. С одной строкой +short в .digrc команда [dig example.com] вывела только IP-адреса, а с -r файл .digrc не читался, и строки записей выводились целиком.

Q: 📌 Как выполнить запрос по TCP вместо UDP?

С +tcp запрос отправляется по TCP. В dig 9.18 на сервере Debian 12 после добавления +tcp конец строки SERVER сменился с (UDP) на (TCP), а полученные записи остались теми же.

Тестовая средаСемейство RHELAlmaLinux 9.8dig 9.16Учётная запись rootDebian 12 · dig 9.18 обычная учётная записьПроверено 2026-11-04

Сетевые командыdigРасположение/usr/bin/dig

Чтобы проверить DNS-записи домена вплоть до заголовка ответа DNS-сервера, используйте команду dig. Мы запросили записи example.com по типам на серверах AlmaLinux 9 и Debian 12, меняя опрашиваемый DNS-сервер, и убедились, что по одним только status и flags в заголовке ответа можно отличить имя, которого не существует, DNS-сервер, не сумевший дать ответ, и ответ, который напрямую дал сервер, управляющий записями.

Вывод ниже получен на сервере AlmaLinux 9.8 (учётная запись root) и сервере Debian 12 (обычная учётная запись). Адрес DNS-сервера, заданного на сервере, заменён примером 192.0.2.53, номера версий dig тоже заменены примерами.

Содержание

8 мин чтения

1️⃣ Как пользоваться командой dig

↪️ Как читать вывод по умолчанию

Базовая форма — [dig @сервер имя тип], сервер и тип можно не указывать. По официальному руководству, без сервера dig обращается к DNS-серверу из /etc/resolv.conf, а без типа запрашивает запись A.

dig example.com

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

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

;; ANSWER SECTION:
example.com.		62	IN	A	104.20.23.154
example.com.		62	IN	A	172.66.147.243

;; Query time: 1 msec
;; SERVER: 192.0.2.53#53(192.0.2.53)
;; WHEN: Thu Oct 29 00:09:18 UTC 2026
;; MSG SIZE  rcvd: 72

Строки, начинающиеся с точки с запятой, — это пояснения, а строки без неё — реально полученные записи. Что смотреть в каждом разделе, показано ниже.

Вывод	Что показывает
; <<>> DiG 9.16.20-RH <<>> example.com	Версия запущенного dig и введённые аргументы
->>HEADER<<- … status: NOERROR, id: 62441	Код ответа (status) и номер запроса (id)
flags: qr rd ra	Флаги заголовка ответа — выполнил ли ответивший сервер рекурсивный поиск и управляет ли он записями
QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1	Число записей в каждом разделе
OPT PSEUDOSECTION · EDNS … udp: 4096	Сведения расширения EDNS и размер ответа (байты), который можно принять по UDP
QUESTION SECTION	Отправленный вопрос — имя, класс (IN), тип записи
ANSWER SECTION	Полученные записи — имя, TTL (секунды), класс, тип и значение по порядку
Query time: 1 msec	Время до получения ответа
SERVER: 192.0.2.53#53(192.0.2.53)	Адрес и номер порта ответившего DNS-сервера
WHEN · MSG SIZE rcvd: 72	Время запроса и размер полученного ответа (байты)

В строке flags qr означает ответ, rd — запрос рекурсии, ra — поддержку рекурсии (RFC 1035). Раз есть ra, но нет aa, этот ответ прислал DNS-сервер, выполняющий рекурсивный поиск, а не сервер, управляющий записями.

62 в разделе ANSWER — это TTL, оставшееся время (в секундах), в течение которого запись может храниться в кэше. Сразу после этого тот же запрос к 8.8.8.8 вернул 300: число зависело от того, когда каждый DNS-сервер положил запись в кэш.

Если выполнить тот же запрос через Команда nslookup , код ответа и TTL в выводе по умолчанию не появятся. Различия в выводе двух команд показаны ниже.

Сравнение	dig	nslookup
Код ответа	Всегда в status строки HEADER	Только при ошибке, строкой server can't find
TTL	В каждой строке записи в ANSWER	Только с -debug
Ответивший DNS-сервер	Строка SERVER в самом низу	Строки Server · Address в самом верху
Код возврата при NXDOMAIN	0	1

Установленную версию dig проверяют через -v. На сервере AlmaLinux 9 это была 9.16, на сервере Debian 12 — 9.18.

dig -v

DiG 9.16.20-RH

2️⃣ Запрос записей через dig

↪️ A, AAAA, MX, NS, TXT, CNAME, SOA

Если после имени указать тип записи, запрашивается только эта запись. Что хранит каждый тип и какие результаты получены в этой статье, показано ниже.

Тип	Что хранит	Результат запроса
A	IPv4-адресом	example.com → 104.20.23.154 и ещё 1
AAAA	IPv6-адрес	example.com → 2606:4700:10::6814:179a и ещё 1
MX	Почтовый сервер и приоритет	example.com → 0 . (почту не принимает)
NS	Серверы имён, управляющие записями	example.com → hera · elliott.ns.cloudflare.com.
TXT	Текстовое значение без фиксированного формата (SPF и др.)	example.com → v=spf1 -all и ещё 1
CNAME	Псевдоним другого имени	www.github.com → github.com.
SOA	Основной сервер имён зоны и временные значения	example.com → elliott.ns.cloudflare.com. …
PTR	Имя, связанное с IP-адресом (обратная)	-x 8.8.8.8 → dns.google.

Почтовые серверы проверяют по записи MX. Запрос MX для example.com вернул в разделе ANSWER одну строку [0 .].

dig example.com MX

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

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

;; ANSWER SECTION:
example.com.		300	IN	MX	0 .

;; Query time: 5 msec
;; SERVER: 192.0.2.53#53(192.0.2.53)
;; WHEN: Thu Oct 29 00:09:23 UTC 2026
;; MSG SIZE  rcvd: 55

0 — это приоритет, а MX, у которого на месте имени почтового сервера стоит одна точка, — это Null MX: домен не принимает почту (RFC 7505). Тип, записанный строчными буквами как mx, дал тот же результат.

Чтобы видеть только строки записей, добавьте [+noall +answer]. По официальному руководству, +noall отключает все разделы вывода, а +answer снова включает только раздел ANSWER.

dig example.com NS +noall +answer

example.com.		12192	IN	NS	hera.ns.cloudflare.com.
example.com.		12192	IN	NS	elliott.ns.cloudflare.com.

У example.com было два сервера имён. Это авторитетные серверы имён, которые напрямую управляют записями example.com.

dig example.com TXT +noall +answer

example.com.		300	IN	TXT	"v=spf1 -all"
example.com.		300	IN	TXT	"_k2n1y4vw3qtb4skdx9e7dxt97qrmmq9"

В запись TXT можно поместить текстовое значение без фиксированного формата. v=spf1 -all — значение SPF, означающее, что ни один сервер не может отправлять почту от имени этого домена.

dig www.github.com CNAME +noall +answer

www.github.com.		291	IN	CNAME	github.com.

www.github.com оказался псевдонимом (CNAME) github.com. При запросе того же имени без типа сразу после строки CNAME появилась запись A для github.com.

С +multiline у записи SOA рядом с каждым числом появляется комментарий с названием и временем, и её легче читать.

dig example.com SOA +multiline +noall +answer

example.com.		1765 IN	SOA elliott.ns.cloudflare.com. dns.cloudflare.com. (
				2418004112 ; serial
				10000      ; refresh (2 hours 46 minutes 40 seconds)
				2400       ; retry (40 minutes)
				604800     ; expire (1 week)
				1800       ; minimum (30 minutes)
				)

serial — порядковый номер, который растёт при каждом изменении записей, а refresh, retry и expire — временные значения, по которым вторичный сервер имён сверяет записи с основным. minimum — время, в течение которого ответ о несуществующем имени или записи может храниться в кэше.

Если нужны только значения, добавьте +short. У записи A остались только IP-адреса, у MX — только приоритет и имя почтового сервера.

dig +short example.com

172.66.147.243
104.20.23.154

dig google.com MX +short

10 smtp.google.com.

Если после [+noall +answer] добавить +stats, появятся также время запроса и строка ответившего сервера. В dig 9.18 на сервере Debian 12 в конце строки SERVER был указан способ отправки запроса, (UDP); dig 9.16 на сервере AlmaLinux 9 этого не показывал.

dig example.com +noall +answer +stats

example.com.		235	IN	A	172.66.147.243
example.com.		235	IN	A	104.20.23.154
;; Query time: 0 msec
;; SERVER: 192.0.2.53#53(192.0.2.53) (UDP)
;; WHEN: Thu Oct 29 00:10:26 UTC 2026
;; MSG SIZE  rcvd: 72

3️⃣ Выбор DNS-сервера в dig и обратный запрос

↪️ @сервер, aa, -x

Если перед именем указать @ и DNS-сервер, запрос уйдёт этому серверу вместо DNS-сервера, заданного на сервере. При запросе к 8.8.8.8 строка SERVER сменилась на 8.8.8.8, а во flags добавился ad.

dig @8.8.8.8 example.com

; <<>> DiG 9.16.20-RH <<>> @8.8.8.8 example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61431
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
example.com.		300	IN	A	104.20.23.154
example.com.		300	IN	A	172.66.147.243

;; Query time: 30 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Oct 29 00:09:29 UTC 2026
;; MSG SIZE  rcvd: 72

ad — флаг того, что ответивший сервер проверил подписи DNSSEC и счёл записи в ответе достоверными (RFC 4035). В ответах DNS-сервера, заданного на сервере, ad не было.

Если после @ указать сервер имён из запроса NS, вы обращаетесь напрямую к серверу, который управляет записями example.com.

dig @elliott.ns.cloudflare.com example.com

; <<>> DiG 9.16.20-RH <<>> @elliott.ns.cloudflare.com example.com
; (6 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61828
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

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

;; ANSWER SECTION:
example.com.		300	IN	A	172.66.147.243
example.com.		300	IN	A	104.20.23.154

;; Query time: 4 msec
;; SERVER: 2606:4700:58::a29f:2ce4#53(2606:4700:58::a29f:2ce4)
;; WHEN: Thu Oct 29 00:09:29 UTC 2026
;; MSG SIZE  rcvd: 72

На этот раз во flags появился aa — значит, ответил сам авторитетный сервер имён. Этот сервер не поддерживает рекурсивный поиск, при котором имена ищутся через другие серверы, поэтому ra пропал, а добавилась строка [WARNING: recursion requested but not available].

(6 servers found) означает, что имя сервера имён разрешилось в три адреса IPv4 и три адреса IPv6. В строке SERVER показан тот из IPv6-адресов, который прислал ответ.

Если после -x указать IP-адрес, dig запросит запись PTR и найдёт имя, связанное с этим адресом.

dig -x 8.8.8.8 +noall +answer

8.8.8.8.in-addr.arpa.	300	IN	PTR	dns.google.

dig запросил имя, составленное из 8.8.8.8, записанного в обратном порядке, с добавлением in-addr.arpa, и значение PTR — dns.google. — оказалось именем 8.8.8.8.

4️⃣ Путь делегирования в dig +trace

↪️ От корневых серверов имён до серверов имён example.com

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

dig +trace +nodnssec example.com

; <<>> DiG 9.16.20-RH <<>> +trace +nodnssec example.com
;; global options: +cmd
.			86333	IN	NS	j.root-servers.net.
.			86333	IN	NS	g.root-servers.net.
.			86333	IN	NS	b.root-servers.net.
.			86333	IN	NS	e.root-servers.net.
.			86333	IN	NS	k.root-servers.net.
.			86333	IN	NS	f.root-servers.net.
.			86333	IN	NS	l.root-servers.net.
.			86333	IN	NS	m.root-servers.net.
.			86333	IN	NS	h.root-servers.net.
.			86333	IN	NS	c.root-servers.net.
.			86333	IN	NS	d.root-servers.net.
.			86333	IN	NS	a.root-servers.net.
.			86333	IN	NS	i.root-servers.net.
;; Received 239 bytes from 192.0.2.53#53(192.0.2.53) in 1 ms

com.			172800	IN	NS	a.gtld-servers.net.
com.			172800	IN	NS	b.gtld-servers.net.
com.			172800	IN	NS	c.gtld-servers.net.
com.			172800	IN	NS	d.gtld-servers.net.
com.			172800	IN	NS	e.gtld-servers.net.
com.			172800	IN	NS	f.gtld-servers.net.
com.			172800	IN	NS	g.gtld-servers.net.
com.			172800	IN	NS	h.gtld-servers.net.
com.			172800	IN	NS	i.gtld-servers.net.
com.			172800	IN	NS	j.gtld-servers.net.
com.			172800	IN	NS	k.gtld-servers.net.
com.			172800	IN	NS	l.gtld-servers.net.
com.			172800	IN	NS	m.gtld-servers.net.
;; Received 836 bytes from 2001:7fd::1#53(k.root-servers.net) in 30 ms

example.com.		172800	IN	NS	hera.ns.cloudflare.com.
example.com.		172800	IN	NS	elliott.ns.cloudflare.com.
;; Received 359 bytes from 2001:503:d414::30#53(f.gtld-servers.net) in 66 ms

example.com.		300	IN	A	104.20.23.154
example.com.		300	IN	A	172.66.147.243
;; Received 72 bytes from 108.162.195.228#53(elliott.ns.cloudflare.com) in 3 ms

На каждом шаге последняя строка [Received … from] показывает сервер, приславший этот ответ. Опрошенные на четырёх шагах серверы и полученное от них показаны ниже.

Уровень	Опрошенный сервер	Что получено
1	DNS-сервер, заданный на сервере (192.0.2.53)	13 корневых (.) серверов имён
2	k.root-servers.net	13 серверов имён .com (gtld-servers.net)
3	f.gtld-servers.net	2 сервера имён example.com
4	elliott.ns.cloudflare.com	2 записи A для example.com

Вывод +trace похож на историю отслеживания заказного письма.

Запись A на последнем шаге прислал напрямую сервер имён example.com, поэтому это текущее значение, а не из кэша. Сразу после смены серверов имён сначала проверьте на шаге 3, отвечают ли серверы .com новыми серверами имён.

5️⃣ Ошибки ответа и параметры dig

↪️ NXDOMAIN, SERVFAIL, connection timed out

🔲 Ошибки ответа

При запросе несуществующего имени status показывает NXDOMAIN. .invalid — домен верхнего уровня, зарезервированный, чтобы никогда не использоваться на деле, поэтому он подошёл для проверки этого ответа.

dig example.invalid

; <<>> DiG 9.16.20-RH <<>> example.invalid
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23779
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

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

;; AUTHORITY SECTION:
invalid.		10800	IN	SOA	localhost. nobody.invalid. 1 3600 1200 604800 10800

;; Query time: 1 msec
;; SERVER: 192.0.2.53#53(192.0.2.53)
;; WHEN: Thu Oct 29 00:09:33 UTC 2026
;; MSG SIZE  rcvd: 96

ANSWER был 0, а в разделе AUTHORITY находилась запись SOA этой зоны. Последнее число SOA, 10800, — время (в секундах), в течение которого этот ответ может храниться в кэше.

no-such-host.example.com завершился не NXDOMAIN, а статусом NOERROR и ANSWER 0. Это ответ без кода ошибки, в котором просто нет записей, поэтому проверяйте status и число ANSWER вместе.

dig no-such-host.example.com

; <<>> DiG 9.16.20-RH <<>> no-such-host.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31671
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;no-such-host.example.com.	IN	A

;; AUTHORITY SECTION:
example.com.		1800	IN	SOA	elliott.ns.cloudflare.com. dns.cloudflare.com. 2418004112 10000 2400 604800 1800

;; Query time: 7 msec
;; SERVER: 192.0.2.53#53(192.0.2.53)
;; WHEN: Thu Oct 29 00:09:33 UTC 2026
;; MSG SIZE  rcvd: 115

SERVFAIL — код ответа, означающий, что DNS-сервер не смог сформировать ответ (RFC 1035). Запрос к 8.8.8.8 о dnssec-failed.org, публичном домене для проверки сбоев валидации DNSSEC, вернул SERVFAIL вместе со строкой EDE.

dig @8.8.8.8 dnssec-failed.org

; <<>> DiG 9.16.20-RH <<>> @8.8.8.8 dnssec-failed.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57521
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 9 (DNSKEY Missing): (No DNSKEY matches DS RRs of dnssec-failed.org)
;; QUESTION SECTION:
;dnssec-failed.org.		IN	A

;; Query time: 333 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Oct 29 00:09:41 UTC 2026
;; MSG SIZE  rcvd: 97

EDE — расширенный код ошибки, добавляющий её причину (RFC 8914). 9 (DNSKEY Missing) означает, что не найден DNSKEY, соответствующий записи DS родительской зоны, и 8.8.8.8 вернул SERVFAIL вместо адреса для имени, подпись которого не смог проверить.

Если DNS-сервер не отвечает, вывод заканчивается строкой [connection timed out; no servers could be reached] без строки status. При запросе к 192.0.2.1, адресу для примеров в документации, с [+timeout=2 +tries=1] эта строка появилась через 2 секунды.

dig @192.0.2.1 example.com +timeout=2 +tries=1

; <<>> DiG 9.16.20-RH <<>> @192.0.2.1 example.com +timeout=2 +tries=1
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Без параметров тот же адрес выдал ту же строку через 15 секунд. Причина в том, что значения по умолчанию в официальном руководстве — 5 секунд на ответ и 3 попытки. В dig 9.18 на сервере Debian 12 сначала появилась строка [communications error to 192.0.2.1#53: timed out], а последней строкой была [no servers could be reached].

Если скрипт разделяет результаты по коду возврата, учитывайте, что NXDOMAIN тоже даёт 0. После запроса example.invalid с +short вывод кода возврата показал 0 при пустом результате, а запрос к 192.0.2.1, оставшийся без ответа, дал 9.

dig +short example.invalid; echo $?

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

Вывод	Назначение	Что проверить дальше
status: NXDOMAIN	Такого имени нет	Написание и состояние регистрации домена, путь делегирования через +trace
status: NOERROR · ANSWER: 0	В ответе нет записи такого типа	Тип записи и настройки записей на сервере имён
status: SERVFAIL	DNS-сервер не смог сформировать ответ	Строка EDE, ответы других DNS-серверов (@8.8.8.8 · @1.1.1.1)
connection timed out	DNS-сервер не отвечает	Адрес DNS-сервера и брандмауэр, блокирующий порт 53

🔲 Параметры команды dig

📌 Основные опции: результаты из этой статьи

Опция	Назначение	Результат в этой статье
@сервер	Обращается к указанному серверу вместо DNS-сервера, заданного на сервере	С @8.8.8.8 строка SERVER сменилась на 8.8.8.8, а во flags добавился ad; у авторитетного сервера имён — aa
Тип	Запрашивает только тип записи, указанный после имени	example.com MX дал одну строку [0 .]; mx строчными — тот же результат
-x адрес	Запрашивает запись PTR IP-адреса	-x 8.8.8.8 дал dns.google.
-v	Выводит версию	9.16 на сервере AlmaLinux 9, 9.18 на сервере Debian 12
-r	Не читает .digrc из домашней папки	Даже с +short в .digrc при -r строки записей выводились целиком
+short	Выводит только значения записей	A дал два IP-адреса; google.com MX дал 10 smtp.google.com.
+noall +answer	Отключает все разделы вывода и снова включает только ANSWER	Для example.com NS остались только две строки серверов имён
+multiline	Разбивает длинные записи вроде SOA на несколько строк с комментариями	Названия и время вроде serial и refresh появляются комментарием рядом с каждым числом
+stats	Выводит также время запроса и строку ответившего сервера	В dig 9.18 на сервере Debian 12 — (UDP) в конце строки SERVER
+trace	Опрашивает по очереди, начиная с корневых серверов имён, и выводит путь делегирования	На каждом из четырёх шагов последняя строка [Received … from] показывает ответивший сервер
+nodnssec	Не запрашивает записи подписей DNSSEC	Используется вместе с +trace, чтобы остался только путь делегирования
+timeout=СЕКУНДЫ	Время ожидания одного ответа, по умолчанию 5 секунд	Запрос к 192.0.2.1 с +timeout=2 +tries=1 дал [connection timed out] через 2 секунды, без параметров — через 15 секунд
+tries=ЧИСЛО	Сколько раз отправляется запрос, по умолчанию 3	При значении 1 вместе с +timeout=2 dig спросил только один раз и завершился через 2 секунды
+tcp	Отправляет запрос по TCP вместо UDP	В dig 9.18 на сервере Debian 12 конец строки SERVER сменился с (UDP) на (TCP), записи остались теми же

📎 Другие опции: по официальному руководству

Опция	Назначение
-4	Запрос только по IPv4
-6	Запрос только по IPv6
-t ТИП	Задаёт тип запрашиваемой записи
-q ИМЯ	Задаёт запрашиваемое имя, чтобы его не спутать с другими аргументами
-p ПОРТ	Запрос через указанный порт вместо 53
-b АДРЕС	Задаёт исходный IP-адрес, с которого отправляется запрос
-f ФАЙЛ	Выполняет по очереди запросы, записанные в файле по одному на строку
+norecurse	Запрос с выключенным требованием рекурсии (RD)
+dnssec	Запрашивает также записи DNSSEC
+nssearch	Находит авторитетные серверы имён и выводит запись SOA каждого из них
+nocmd	Вывод без строк версии и параметров в начале
+nocomments	Вывод без поясняющих строк вроде заголовка ответа и названий разделов
+ttlunits	Выводит TTL в единицах s, m, h, d и w
+retry=ЧИСЛО	Число повторных отправок без учёта первого запроса, по умолчанию 2

🔲 Симулятор команды dig

В симуляторе ниже можно самому вводить dig, меняя тип записи, DNS-сервер и параметры вывода.

Симулятор команды digdig 9.16

[root@server work]#

Работает только в вашем браузере; ответы берутся из виртуального DNS со значениями реальных запросов, а ↑↓ возвращает ранее введённые команды.

🔢 FAQ & рекомендуемые материалы

На двух проверенных серверах dig входил в пакет bind-utils в AlmaLinux 9 и в пакет bind9-dnsutils в Debian 12. Поэтому в семействе RHEL его устанавливают через [sudo dnf install bind-utils], а в семействе Debian — через [sudo apt install bind9-dnsutils]. Оба пакета заодно устанавливают nslookup.

По официальному руководству, dig читает параметры из файла .digrc в домашней папке и применяет их раньше аргументов командной строки. С одной строкой +short в .digrc команда [dig example.com] вывела только IP-адреса, а с -r файл .digrc не читался, и строки записей выводились целиком.

С +tcp запрос отправляется по TCP. В dig 9.18 на сервере Debian 12 после добавления +tcp конец строки SERVER сменился с (UDP) на (TCP), а полученные записи остались теми же.

🔝 Команды Linux по категориям

🔗 Рекомендуемые материалы

Распространение DNS Время распространения DNS после смены серверов имён: замеры по резолверам и проверка DNSSEC Статья, в которой после смены серверов имён каждые 5 минут записывались ответы 7 резолверов и проверялось, почему перед переносом нужно отключить DNSSEC. Читать →

Отключение DNSSEC для смены серверов имён (включённое состояние)

Инструменты · Домены WHOIS-проверка домена и серверов имён Инструмент, который после ввода домена сразу показывает в браузере регистрационные данные, серверы имён и DNS-записи.

Проверка A-записи базовой командой host – так же, как командой nslookup

Сеть · DNS Команда host в Linux | команда для DNS-запросов Команда host для поиска IP-адреса по имени хоста или преобразования IP-адреса в имя хоста.

DNS · Понятия Сервер имён и DNS: в чём разница & 4 основных типа DNS-записей Статья о том, чем различаются серверы имён и DNS и что хранит каждый из четырёх часто используемых типов DNS-записей.

🪐ИсточникиОфициальная документация / RFC

📡dig — официальное руководство BIND 9 (ISC) 📡dig(1) — руководство bind9-dnsutils в Debian 12 📡RFC 1035 — формат DNS-сообщений и флаги заголовка (IETF) 📡RFC 4035 — DNSSEC и флаг AD (IETF) 📡RFC 7505 — Null MX для доменов, не принимающих почту (IETF) 📡RFC 8914 — Extended DNS Errors(EDE) (IETF) 📡RFC 2606 — зарезервированные имена example.com и .invalid (IETF)

ℹ️ О партнёрских ссылках
Материалы этого сайта содержат партнёрские ссылки. Если посетитель покупает товар или услугу по такой ссылке, сайт получает комиссию от продавца. При этом сумма, которую платит покупатель ^{(при акционных скидках сумма снижается ↓)}, не увеличивается. Указанные цены, скидки и наличие актуальны на момент написания и могут отличаться, поэтому перед покупкой уточняйте их у продавца. Товары выбираются и оцениваются по нашим собственным критериям, а комиссия не влияет ни на порядок, ни на содержание обзоров.