Polecenie dig: zapytania DNS w Linuksie i odczyt wyniku +short i +trace

Q: 📌 Jaki pakiet zainstalować, gdy pojawia się dig: command not found?

Na dwóch sprawdzonych serwerach dig był w pakiecie bind-utils w AlmaLinux 9 i w pakiecie bind9-dnsutils w Debian 12. Dlatego w rodzinie RHEL instalujesz go przez [sudo dnf install bind-utils], a w rodzinie Debian przez [sudo apt install bind9-dnsutils]. Oba pakiety instalują też nslookup.

Q: 📌 Jak nie dodawać tych samych opcji przy każdym uruchomieniu dig?

Według oficjalnego podręcznika dig czyta opcje zapisane w pliku .digrc w katalogu domowym i stosuje je przed argumentami wiersza poleceń. Z jednym wierszem +short w .digrc [dig example.com] wypisało same adresy IP, a z -r plik .digrc nie został odczytany i wiersze rekordów pojawiły się w całości.

Q: 📌 Jak wysłać zapytanie przez TCP zamiast UDP?

Z +tcp zapytanie jest wysyłane przez TCP. W dig 9.18 na serwerze Debian 12 po dodaniu +tcp koniec wiersza SERVER zmienił się z (UDP) na (TCP), a otrzymane rekordy były te same.

Środowisko testoweRodzina RHELAlmaLinux 9.8dig 9.16konto rootDebian 12 · dig 9.18 zwykłe kontoSprawdzono 2026-11-04

Polecenia sieciowedigLokalizacja/usr/bin/dig

Gdy chcesz sprawdzić rekordy DNS domeny aż do nagłówka odpowiedzi serwera DNS, używasz polecenia dig. Po odpytaniu rekordów example.com według typu na serwerach z AlmaLinux 9 i Debian 12 oraz zmianie odpytywanego serwera DNS okazało się, że już same status i flags w nagłówku odpowiedzi pozwalają odróżnić nazwę, która nie istnieje, serwer DNS, który nie zdołał udzielić odpowiedzi, oraz odpowiedź udzieloną bezpośrednio przez serwer zarządzający rekordami.

Poniższe wyniki pochodzą z serwera AlmaLinux 9.8 (konto root) i serwera Debian 12 (zwykłe konto). Adres serwera DNS ustawionego na serwerze zastąpiono przykładową wartością 192.0.2.53, a numery wersji dig również wartościami przykładowymi.

Spis treści

8 min czytania

1️⃣ Jak używać polecenia dig

↪️ Odczyt domyślnego wyniku

Podstawowa postać to [dig @serwer nazwa typ], a serwer i typ można pominąć. Według oficjalnego podręcznika bez serwera dig pyta serwer DNS ustawiony w /etc/resolv.conf, a bez typu sprawdza rekord 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

Wiersze zaczynające się od średnika to komentarze, a wiersze bez średnika to faktycznie otrzymane rekordy. Co pokazuje każda sekcja, opisano poniżej.

Wynik	Co pokazuje
; <<>> DiG 9.16.20-RH <<>> example.com	Uruchomiona wersja dig i podane argumenty
->>HEADER<<- … status: NOERROR, id: 62441	Kod odpowiedzi (status) i numer zapytania (id)
flags: qr rd ra	Flagi nagłówka odpowiedzi — czy odpowiadający serwer wykonał zapytanie rekurencyjne i czy zarządza rekordami
QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1	Liczba rekordów w każdej sekcji
OPT PSEUDOSECTION · EDNS … udp: 4096	Informacje rozszerzenia EDNS i rozmiar odpowiedzi (bajty) możliwy do odebrania przez UDP
QUESTION SECTION	Wysłane pytanie — nazwa, klasa (IN), typ rekordu
ANSWER SECTION	Otrzymane rekordy — nazwa, TTL (sekundy), klasa, typ i wartość w tej kolejności
Query time: 1 msec	Czas do nadejścia odpowiedzi
SERVER: 192.0.2.53#53(192.0.2.53)	Adres i numer portu serwera DNS, który odpowiedział
WHEN · MSG SIZE rcvd: 72	Czas zapytania i rozmiar otrzymanej odpowiedzi (bajty)

W wierszu flags qr oznacza odpowiedź, rd prośbę o zapytanie rekurencyjne, a ra obsługę zapytań rekurencyjnych (RFC 1035). Jest ra, a nie ma aa, więc tę odpowiedź wysłał serwer DNS wykonujący zapytania rekurencyjne, a nie serwer zarządzający rekordami.

62 w sekcji ANSWER to TTL, czyli pozostały czas (sekundy), przez który rekord może być trzymany w pamięci podręcznej. Zaraz potem to samo zapytanie do 8.8.8.8 dało 300 — liczba zależała od tego, kiedy dany serwer DNS zapisał rekord w pamięci podręcznej.

Jeśli to samo zapytanie wykonasz przez polecenie nslookup , kod odpowiedzi i TTL nie pojawią się w domyślnym wyniku. Różnice między wynikami obu poleceń są poniżej.

Porównanie	dig	nslookup
Kod odpowiedzi	Zawsze w status w wierszu HEADER	Tylko przy błędzie, jako wiersz server can't find
TTL	W każdym wierszu rekordu w ANSWER	Tylko z -debug
Serwer DNS, który odpowiedział	Wiersz SERVER na samym dole	Wiersze Server · Address na samej górze
Kod wyjścia przy NXDOMAIN	0	1

Zainstalowaną wersję dig sprawdzisz przez -v. Na serwerze AlmaLinux 9 była to 9.16, na serwerze Debian 12 — 9.18.

dig -v

DiG 9.16.20-RH

2️⃣ Sprawdzanie rekordów poleceniem dig

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

Jeśli po nazwie wpiszesz typ rekordu, sprawdzany jest tylko ten rekord. Co zawiera każdy typ i jakie wyniki uzyskano w tym artykule, pokazano poniżej.

Typ	Co zawiera	Wynik zapytania
A	adres IPv4	example.com → 104.20.23.154 i 1 więcej
AAAA	Adres IPv6	example.com → 2606:4700:10::6814:179a i 1 więcej
MX	Serwer poczty i priorytet	example.com → 0 . (nie przyjmuje poczty)
NS	Serwery nazw zarządzające rekordami	example.com → hera · elliott.ns.cloudflare.com.
TXT	Wartość tekstowa bez ustalonego formatu (SPF itp.)	example.com → v=spf1 -all i 1 więcej
CNAME	Alias innej nazwy	www.github.com → github.com.
SOA	Główny serwer nazw strefy i wartości czasu	example.com → elliott.ns.cloudflare.com. …
PTR	Nazwa przypisana do adresu IP (odwrotna)	-x 8.8.8.8 → dns.google.

Serwery poczty sprawdza się rekordem MX. Zapytanie o MX domeny example.com dało w sekcji ANSWER jeden wiersz [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 to priorytet, a MX, w którym w miejscu nazwy serwera poczty stoi tylko kropka, to Null MX — domena nie przyjmuje poczty (RFC 7505). Typ wpisany małymi literami jako mx dał ten sam wynik.

Aby zobaczyć tylko wiersze rekordów, dodaj [+noall +answer]. Według oficjalnego podręcznika +noall wyłącza wszystkie sekcje wyniku, a +answer włącza z powrotem tylko sekcję 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 miała dwa serwery nazw. To autorytatywne serwery nazw, które bezpośrednio zarządzają rekordami example.com.

dig example.com TXT +noall +answer

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

Rekord TXT może zawierać wartość tekstową bez ustalonego formatu. v=spf1 -all to wartość SPF mówiąca, że żaden serwer nie może wysyłać poczty z tej nazwy domeny.

dig www.github.com CNAME +noall +answer

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

www.github.com był aliasem (CNAME) github.com. Przy zapytaniu o tę samą nazwę bez typu po wierszu CNAME od razu pojawił się rekord A github.com.

Z +multiline rekord SOA dostaje przy każdej liczbie komentarz z nazwą i czasem, dzięki czemu łatwiej go czytać.

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 to numer kolejny, który rośnie przy każdej zmianie rekordów, a refresh, retry i expire to wartości czasu, których zapasowy serwer nazw używa do uzgadniania rekordów z głównym. minimum to czas, przez który odpowiedź o nieistniejącej nazwie lub rekordzie może być trzymana w pamięci podręcznej.

Gdy potrzebujesz tylko wartości, dodaj +short. Z rekordu A zostały same adresy IP, a z MX tylko priorytet i nazwa serwera poczty.

dig +short example.com

172.66.147.243
104.20.23.154

dig google.com MX +short

10 smtp.google.com.

Gdy po [+noall +answer] dodasz +stats, pojawi się też czas zapytania i wiersz serwera, który odpowiedział. W dig 9.18 na serwerze Debian 12 na końcu wiersza SERVER dopisany był sposób wysłania zapytania, (UDP); dig 9.16 na serwerze AlmaLinux 9 tego nie pokazywał.

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️⃣ Wybór serwera DNS w dig i zapytanie odwrotne

↪️ @serwer, aa, -x

Jeśli przed nazwą wpiszesz @ i serwer DNS, zapytanie trafi do tego serwera zamiast do serwera DNS ustawionego na serwerze. Przy pytaniu 8.8.8.8 wiersz SERVER zmienił się na 8.8.8.8, a do flags doszło 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 to flaga oznaczająca, że odpowiadający serwer zweryfikował podpisy DNSSEC i uznał rekordy w odpowiedzi za wiarygodne (RFC 4035). Odpowiedzi serwera DNS ustawionego na serwerze nie miały ad.

Jeśli po @ wpiszesz serwer nazw z zapytania NS, pytasz bezpośrednio serwer zarządzający rekordami 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

Tym razem w flags pojawiło się aa, co potwierdziło, że odpowiedział bezpośrednio autorytatywny serwer nazw. Ten serwer nie obsługuje zapytań rekurencyjnych, które szukają nazw przez inne serwery, więc ra zniknęło, a doszedł wiersz [WARNING: recursion requested but not available].

(6 servers found) oznacza, że nazwa serwera nazw została rozwiązana na trzy adresy IPv4 i trzy IPv6. W wierszu SERVER pojawił się ten z adresów IPv6, który wysłał odpowiedź.

Jeśli po -x wpiszesz adres IP, dig sprawdzi rekord PTR i znajdzie nazwę przypisaną do tego adresu.

dig -x 8.8.8.8 +noall +answer

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

dig odpytał nazwę utworzoną przez zapisanie 8.8.8.8 od tyłu i dodanie in-addr.arpa, a jej wartość PTR, dns.google., była nazwą 8.8.8.8.

4️⃣ Ścieżka delegacji w dig +trace

↪️ Od głównych serwerów nazw do serwerów nazw example.com

Z +trace dig pyta po kolei, zaczynając od głównych serwerów nazw, i krok po kroku pokazuje, do którego serwera przekazano nazwę. Według oficjalnego podręcznika +trace prosi też o wiersze podpisów DNSSEC, dlatego dodano +nodnssec, aby zobaczyć samą ścieżkę delegacji.

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

Na każdym kroku ostatni wiersz [Received … from] pokazuje serwer, który wysłał tę odpowiedź. Serwery odpytane w czterech krokach i to, co od nich przyszło, są poniżej.

Poziom	Odpytany serwer	Co przyszło
1	Serwer DNS ustawiony na serwerze (192.0.2.53)	13 głównych (.) serwerów nazw
2	k.root-servers.net	13 serwerów nazw .com (gtld-servers.net)
3	f.gtld-servers.net	2 serwery nazw example.com
4	elliott.ns.cloudflare.com	2 rekordy A example.com

Wynik +trace przypomina historię śledzenia przesyłki poleconej.

Rekord A z ostatniego kroku wysłał bezpośrednio serwer nazw example.com, więc jest to bieżąca wartość, nie z pamięci podręcznej. Zaraz po zmianie serwerów nazw najpierw sprawdź w kroku 3, czy serwery .com odpowiadają nowymi serwerami nazw.

5️⃣ Błędy odpowiedzi i opcje dig

↪️ NXDOMAIN, SERVFAIL, connection timed out

🔲 Błędy odpowiedzi

Przy zapytaniu o nazwę, która nie istnieje, status ma wartość NXDOMAIN. .invalid to domena najwyższego poziomu zarezerwowana tak, by nigdy nie była naprawdę używana, dlatego posłużyła do sprawdzenia tej odpowiedzi.

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 wynosiło 0, a w sekcji AUTHORITY był rekord SOA tej strefy. Ostatnia liczba w SOA, 10800, to czas (sekundy), przez który tę odpowiedź można trzymać w pamięci podręcznej.

no-such-host.example.com zakończyło się nie NXDOMAIN, lecz statusem NOERROR i ANSWER 0. To odpowiedź bez kodu błędu, w której brakuje tylko rekordów, więc sprawdzaj status i liczbę ANSWER razem.

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 to kod odpowiedzi oznaczający, że serwer DNS nie zdołał przygotować odpowiedzi (RFC 1035). Zapytanie 8.8.8.8 o dnssec-failed.org, publiczną domenę do testowania nieudanej weryfikacji DNSSEC, dało SERVFAIL razem z wierszem 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 to rozszerzony kod błędu, który dodaje przyczynę błędu (RFC 8914). 9 (DNSKEY Missing) oznacza, że nie znaleziono DNSKEY pasującego do rekordu DS strefy nadrzędnej, a 8.8.8.8 zwrócił SERVFAIL zamiast adresu dla nazwy, której podpisu nie mógł potwierdzić.

Gdy serwer DNS nie odpowiada, wynik kończy się wierszem [connection timed out; no servers could be reached] bez wiersza status. Zapytanie 192.0.2.1, adresu do przykładów w dokumentacji, z [+timeout=2 +tries=1] dało ten wiersz po 2 sekundach.

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

Bez opcji ten sam adres dał ten sam wiersz po 15 sekundach. To dlatego, że domyślne wartości z oficjalnego podręcznika to 5 sekund na odpowiedź i 3 próby. W dig 9.18 na serwerze Debian 12 najpierw pojawił się wiersz [communications error to 192.0.2.1#53: timed out], a ostatnim wierszem było [no servers could be reached].

Jeśli skrypt rozdziela wyniki według kodu wyjścia, pamiętaj, że NXDOMAIN też daje 0. Po zapytaniu o example.invalid z +short wypisanie kodu wyjścia dało 0 przy pustym wyniku, a zapytanie do 192.0.2.1, które nie dostało odpowiedzi, dało 9.

dig +short example.invalid; echo $?

Dla każdego błędu odpowiedzi poniżej podano wiersz do sprawdzenia w wyniku i to, co sprawdzić potem.

Wynik	Znaczenie	Co sprawdzić dalej
status: NXDOMAIN	Taka nazwa nie istnieje	Pisownia i stan rejestracji domeny, ścieżka delegacji przez +trace
status: NOERROR · ANSWER: 0	Brak rekordu tego typu w odpowiedzi	Typ rekordu i ustawienia rekordów na serwerze nazw
status: SERVFAIL	Serwer DNS nie zdołał przygotować odpowiedzi	Wiersz EDE, odpowiedzi innych serwerów DNS (@8.8.8.8 · @1.1.1.1)
connection timed out	Serwer DNS nie odpowiada	Adres serwera DNS i zapora blokująca port 53

🔲 Opcje polecenia dig

📌 Główne opcje: wyniki z tego artykułu

Opcja	Zadanie	Wynik w tym artykule
@serwer	Pyta wskazany serwer zamiast serwera DNS ustawionego na serwerze	Z @8.8.8.8 wiersz SERVER zmienił się na 8.8.8.8, a do flags doszło ad; autorytatywny serwer nazw dał aa
Typ	Sprawdza tylko typ rekordu wpisany po nazwie	example.com MX dało jeden wiersz [0 .]; mx małymi literami ten sam wynik
-x adres	Sprawdza rekord PTR adresu IP	-x 8.8.8.8 dało dns.google.
-v	Wypisuje wersję	9.16 na serwerze AlmaLinux 9, 9.18 na serwerze Debian 12
-r	Nie czyta .digrc z katalogu domowego	Nawet z +short w .digrc, po dodaniu -r wiersze rekordów pojawiły się w całości
+short	Wypisuje tylko wartości rekordów	A dało dwa adresy IP; google.com MX dało 10 smtp.google.com.
+noall +answer	Wyłącza wszystkie sekcje wyniku i włącza z powrotem tylko ANSWER	Przy example.com NS zostały tylko dwa wiersze serwerów nazw
+multiline	Dzieli długie rekordy, takie jak SOA, na kilka wierszy z komentarzami	Nazwy i czasy, takie jak serial i refresh, pojawiają się jako komentarz przy każdej liczbie
+stats	Wypisuje też czas zapytania i wiersz serwera, który odpowiedział	W dig 9.18 na serwerze Debian 12 (UDP) na końcu wiersza SERVER
+trace	Pyta po kolei od głównych serwerów nazw i wypisuje ścieżkę delegacji	Na każdym z czterech kroków ostatni wiersz [Received … from] pokazuje serwer, który odpowiedział
+nodnssec	Nie prosi o rekordy podpisów DNSSEC	Używane z +trace, aby została sama ścieżka delegacji
+timeout=sekundy	Czas oczekiwania na jedną odpowiedź, domyślnie 5 sekund	Zapytanie 192.0.2.1 z +timeout=2 +tries=1 dało [connection timed out] po 2 sekundach, bez opcji po 15 sekundach
+tries=liczba	Liczba wysłań zapytania, domyślnie 3	Ustawione na 1 razem z +timeout=2 pytało tylko raz i kończyło się po 2 sekundach
+tcp	Wysyła zapytanie przez TCP zamiast UDP	W dig 9.18 na serwerze Debian 12 koniec wiersza SERVER zmienił się z (UDP) na (TCP), a rekordy były te same

📎 Pozostałe opcje: według oficjalnego podręcznika

Opcja	Zadanie
-4	Zapytanie tylko przez IPv4
-6	Zapytanie tylko przez IPv6
-t typ	Określa typ sprawdzanego rekordu
-q nazwa	Określa sprawdzaną nazwę, aby nie pomylić jej z innymi argumentami
-p port	Pyta przez wskazany port zamiast portu 53
-b adres	Określa źródłowy adres IP, z którego wysyłane jest zapytanie
-f plik	Wykonuje po kolei zapytania zapisane w pliku po jednym w wierszu
+norecurse	Pyta z wyłączoną prośbą o rekurencję (RD)
+dnssec	Prosi też o rekordy DNSSEC
+nssearch	Znajduje autorytatywne serwery nazw i wypisuje rekord SOA każdego z nich
+nocmd	Wypisuje bez wierszy wersji i opcji na początku
+nocomments	Wypisuje bez wierszy komentarzy, takich jak nagłówek odpowiedzi i nazwy sekcji
+ttlunits	Wypisuje TTL w jednostkach s, m, h, d i w
+retry=liczba	Liczba ponowień bez pierwszego zapytania, domyślnie 2

🔲 Symulator polecenia dig

W symulatorze poniżej możesz sam wpisywać dig, zmieniając typ rekordu, serwer DNS i opcje wyniku.

Symulator polecenia digdig 9.16

[root@server work]#

Działa tylko w Twojej przeglądarce; odpowiedzi pochodzą z wirtualnego DNS z wartościami z prawdziwych zapytań, a ↑↓ przywołuje wcześniej wpisane polecenia.

🔢 FAQ & polecane treści

Na dwóch sprawdzonych serwerach dig był w pakiecie bind-utils w AlmaLinux 9 i w pakiecie bind9-dnsutils w Debian 12. Dlatego w rodzinie RHEL instalujesz go przez [sudo dnf install bind-utils], a w rodzinie Debian przez [sudo apt install bind9-dnsutils]. Oba pakiety instalują też nslookup.

Według oficjalnego podręcznika dig czyta opcje zapisane w pliku .digrc w katalogu domowym i stosuje je przed argumentami wiersza poleceń. Z jednym wierszem +short w .digrc [dig example.com] wypisało same adresy IP, a z -r plik .digrc nie został odczytany i wiersze rekordów pojawiły się w całości.

Z +tcp zapytanie jest wysyłane przez TCP. W dig 9.18 na serwerze Debian 12 po dodaniu +tcp koniec wiersza SERVER zmienił się z (UDP) na (TCP), a otrzymane rekordy były te same.

🔝 Polecenia Linux

🔗 Polecane treści

Propagacja DNS Czas propagacji DNS po zmianie serwerów nazw: pomiary dla każdego resolvera i sprawdzenie DNSSEC Artykuł, który po zmianie serwerów nazw co 5 minut zapisywał odpowiedzi 7 resolverów i sprawdzał, dlaczego przed przeniesieniem trzeba wyłączyć DNSSEC. Czytaj wpis →

Wyłączenie DNSSEC przed zmianą serwerów nazw (stan włączony)

Przykład wyszukiwania WHOIS domeny (naver)

Narzędzie · domena Wyszukiwanie WHOIS domeny · sprawdzanie serwerów nazw Narzędzie, które po wpisaniu domeny od razu pokazuje w przeglądarce dane rejestracji, serwery nazw i rekordy DNS.

Sprawdzanie rekordu A podstawowym poleceniem host – tak samo jak poleceniem nslookup

Sieć · DNS Polecenie host w Linuksie | polecenie do zapytań DNS Polecenie host do znajdowania adresu IP dla nazwy hosta lub zamiany adresu IP na nazwę hosta.

DNS · Pojęcia Serwer nazw a DNS: różnice & 4 główne typy rekordów DNS Artykuł o tym, czym różnią się serwery nazw i DNS oraz co zawiera każdy z czterech często używanych typów rekordów DNS.

🪐ŹródłaOficjalna dokumentacja / RFC

📡dig — oficjalny podręcznik BIND 9 (ISC) 📡dig(1) — podręcznik bind9-dnsutils w Debian 12 📡RFC 1035 — format wiadomości DNS i flagi nagłówka (IETF) 📡RFC 4035 — DNSSEC i flaga AD (IETF) 📡RFC 7505 — Null MX dla domen, które nie przyjmują poczty (IETF) 📡RFC 8914 — Extended DNS Errors(EDE) (IETF) 📡RFC 2606 — zarezerwowane nazwy example.com i .invalid (IETF)

ℹ️ Informacja o linkach partnerskich
Treści tej witryny zawierają linki partnerskie. Jeśli odwiedzający kupi produkt lub usługę przez taki link, witryna otrzymuje od sprzedawcy prowizję. Kwota płacona przy tym przez kupującego^{(podczas promocji spada↓)} nie wzrasta. Podane ceny, rabaty i dostępność odnoszą się do chwili pisania i mogą różnić się od stanu faktycznego, dlatego przed zakupem sprawdź je u sprzedawcy. Produkty wybieramy i oceniamy według własnych kryteriów, a prowizja nie wpływa ani na kolejność prezentacji, ani na treść ocen.