Comando dig: query DNS su Linux e come leggere l'output di +short e +trace

Q: 📌 Quale pacchetto installo se compare dig: command not found?

Sui due server controllati, dig si trovava nel pacchetto bind-utils di AlmaLinux 9 e nel pacchetto bind9-dnsutils di Debian 12. Quindi si installa con [sudo dnf install bind-utils] sulla famiglia RHEL e con [sudo apt install bind9-dnsutils] sulla famiglia Debian. Entrambi i pacchetti installano anche nslookup.

Q: 📌 Come evito di aggiungere le stesse opzioni ogni volta che eseguo dig?

Secondo il manuale ufficiale, dig legge le opzioni scritte nel file .digrc della cartella home e le applica prima degli argomenti della riga di comando. Con una riga +short in .digrc, [dig example.com] ha mostrato solo gli indirizzi IP; con -r il file .digrc non è stato letto e le righe dei record sono comparse per intero.

Q: 📌 Come interrogo via TCP invece che via UDP?

Con +tcp la query viene inviata via TCP. Con dig 9.18 sul server Debian 12, aggiungendo +tcp la fine della riga SERVER è passata da (UDP) a (TCP), e i record ricevuti erano gli stessi.

Ambiente di testFamiglia RHELAlmaLinux 9.8dig 9.16account rootDebian 12 · dig 9.18 account normaleVerificato il 2026-11-04

Comandi di retedigPosizione/usr/bin/dig

Per controllare i record DNS di un dominio fino all'intestazione di risposta del server DNS si usa il comando dig. Interrogando per tipo i record di example.com su server AlmaLinux 9 e Debian 12 e cambiando il server DNS interrogato, abbiamo verificato che bastano status e flags nell'intestazione di risposta per distinguere un nome che non esiste, un server DNS che non è riuscito a dare una risposta e una risposta data direttamente dal server che gestisce i record.

L'output qui sotto è stato ottenuto su un server AlmaLinux 9.8 (account root) e su un server Debian 12 (account normale). L'indirizzo del server DNS impostato sul server è stato sostituito con il valore di esempio 192.0.2.53, e anche i numeri di versione di dig con valori di esempio.

Indice

8 min di lettura

1️⃣ Come usare il comando dig

↪️ Leggere l'output predefinito

La forma di base è [dig @server nome tipo], e server e tipo si possono omettere. Secondo il manuale ufficiale, senza server interroga il server DNS impostato in /etc/resolv.conf, e senza tipo interroga il record 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

Le righe che iniziano con un punto e virgola sono commenti, mentre quelle senza punto e virgola sono i record ricevuti davvero. Ecco cosa mostra ogni sezione.

Output	Cosa mostra
; <<>> DiG 9.16.20-RH <<>> example.com	Versione di dig eseguita e argomenti inseriti
->>HEADER<<- … status: NOERROR, id: 62441	Codice di risposta (status) e numero della query (id)
flags: qr rd ra	Flag dell'intestazione di risposta — se il server che ha risposto ha fatto una ricerca ricorsiva e se gestisce i record
QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1	Numero di record in ogni sezione
OPT PSEUDOSECTION · EDNS … udp: 4096	Informazioni dell'estensione EDNS e dimensione della risposta (byte) ricevibile via UDP
QUESTION SECTION	Domanda inviata — nome, classe (IN), tipo di record
ANSWER SECTION	Record ricevuti — nome, TTL (secondi), classe, tipo e valore, in quest'ordine
Query time: 1 msec	Tempo impiegato dalla risposta per arrivare
SERVER: 192.0.2.53#53(192.0.2.53)	Indirizzo e numero di porta del server DNS che ha risposto
WHEN · MSG SIZE rcvd: 72	Ora della query e dimensione della risposta ricevuta (byte)

Nella riga flags, qr indica risposta, rd ricorsione richiesta e ra ricorsione disponibile (RFC 1035). Con ra ma senza aa, questa risposta arriva da un server DNS che esegue ricerche ricorsive, non dal server che gestisce i record.

Il 62 nella sezione ANSWER è il TTL, il tempo residuo (secondi) per cui il record può restare in cache. Chiedendo subito dopo lo stesso nome a 8.8.8.8 è uscito 300: il numero cambiava in base a quando ciascun server DNS l'aveva messo in cache.

Se fai la stessa query con il comando nslookup , il codice di risposta e il TTL non compaiono nell'output predefinito. Ecco le differenze tra gli output dei due comandi.

Confronto	dig	nslookup
Codice di risposta	Sempre in status nella riga HEADER	Solo in caso di errore, come riga server can't find
TTL	In ogni riga di record di ANSWER	Solo con -debug
Server DNS che ha risposto	Riga SERVER in fondo	Righe Server · Address in cima
Codice di uscita con NXDOMAIN	0	1

La versione di dig installata si controlla con -v. Era 9.16 sul server AlmaLinux 9 e 9.18 sul server Debian 12.

dig -v

DiG 9.16.20-RH

2️⃣ Interrogare i record con dig

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

Se scrivi un tipo di record dopo il nome, viene interrogato solo quel record. Ecco il valore contenuto in ogni tipo e i risultati ottenuti in questo articolo.

Variante	Cosa contiene	Risultato della query
A	indirizzo IPv4	example.com → 104.20.23.154 e 1 altro
AAAA	Indirizzo IPv6	example.com → 2606:4700:10::6814:179a e 1 altro
MX	Server di posta e priorità	example.com → 0 . (non riceve posta)
NS	Name server che gestiscono i record	example.com → hera · elliott.ns.cloudflare.com.
TXT	Valore di testo senza formato fisso (SPF ecc.)	example.com → v=spf1 -all e 1 altro
CNAME	Alias di un altro nome	www.github.com → github.com.
SOA	Name server primario della zona e valori temporali	example.com → elliott.ns.cloudflare.com. …
PTR	Nome associato a un indirizzo IP (inverso)	-x 8.8.8.8 → dns.google.

I server di posta si controllano con il record MX. Interrogando l'MX di example.com, la sezione ANSWER ha mostrato una sola riga [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 è la priorità, e un MX con un solo punto al posto del nome del server di posta è un Null MX, che indica che il dominio non riceve posta (RFC 7505). Scrivendo il tipo in minuscolo, mx, il risultato è stato lo stesso.

Per vedere solo le righe dei record, aggiungi [+noall +answer]. Secondo il manuale ufficiale, +noall disattiva tutte le sezioni di output e +answer riattiva solo la sezione 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 aveva due name server. Sono i name server autorevoli che gestiscono direttamente i record di example.com.

dig example.com TXT +noall +answer

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

Un record TXT può contenere un valore di testo senza formato fisso. v=spf1 -all è un valore SPF che indica che nessun server può inviare posta con questo nome di dominio.

dig www.github.com CNAME +noall +answer

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

www.github.com era un alias (CNAME) di github.com. Interrogando lo stesso nome senza tipo, dopo la riga CNAME è comparso subito il record A di github.com.

Con +multiline, il record SOA riceve accanto a ogni numero un commento con nome e durata, e diventa più facile da leggere.

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 è un numero progressivo che aumenta a ogni modifica dei record; refresh, retry ed expire sono valori temporali che un name server secondario usa per allineare i record con il primario. minimum è il tempo per cui una risposta su un nome o un record inesistente può restare in cache.

Quando ti servono solo i valori, aggiungi +short. Del record A sono rimasti solo gli indirizzi IP, dell'MX solo la priorità e il nome del server di posta.

dig +short example.com

172.66.147.243
104.20.23.154

dig google.com MX +short

10 smtp.google.com.

Se aggiungi +stats dopo [+noall +answer], compaiono anche il tempo della query e la riga del server che ha risposto. Con dig 9.18 sul server Debian 12, in fondo alla riga SERVER compariva il modo di invio della query, (UDP); dig 9.16 sul server AlmaLinux 9 non lo indicava.

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️⃣ Scegliere il server DNS con dig e ricerca inversa

↪️ @server, aa, -x

Se scrivi @ e un server DNS prima del nome, viene interrogato quel server al posto del server DNS impostato sul server. Chiedendo a 8.8.8.8, la riga SERVER è diventata 8.8.8.8 e ai flags si è aggiunto 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 è il flag che indica che il server che ha risposto ha verificato le firme DNSSEC e ha giudicato affidabili i record della risposta (RFC 4035). Le risposte del server DNS impostato sul server non avevano ad.

Se scrivi dopo @ un name server ottenuto dalla query NS, interroghi direttamente il server che gestisce i record di 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

Questa volta nei flags è comparso aa, a conferma che ha risposto direttamente il name server autorevole. Poiché questo server non supporta la ricerca ricorsiva, che trova i nomi passando per altri server, ra è sparito ed è stata aggiunta la riga [WARNING: recursion requested but not available].

(6 servers found) significa che il nome del name server è stato risolto in tre indirizzi IPv4 e tre IPv6. Nella riga SERVER è comparso, tra questi, l'indirizzo IPv6 che ha inviato la risposta.

Se scrivi un indirizzo IP dopo -x, dig interroga il record PTR e trova il nome associato a quell'indirizzo.

dig -x 8.8.8.8 +noall +answer

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

dig ha interrogato un nome ottenuto scrivendo 8.8.8.8 al contrario e aggiungendo in-addr.arpa, e il suo valore PTR, dns.google., era il nome di 8.8.8.8.

4️⃣ Il percorso di delega di dig +trace

↪️ Dai root name server ai name server di example.com

Con +trace, dig interroga in ordine partendo dai root name server e mostra passo per passo a quale server è stato delegato il nome. Secondo il manuale ufficiale, +trace richiede anche le righe di firma DNSSEC, quindi è stato aggiunto +nodnssec per vedere solo il percorso di delega.

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

A ogni passo, l'ultima riga [Received … from] indica il server che ha inviato quella risposta. Ecco i server interrogati nei quattro passi e cosa è arrivato.

Livello	Server interrogato	Cosa è arrivato
1	Server DNS impostato sul server (192.0.2.53)	13 root name server (.)
2	k.root-servers.net	13 name server .com (gtld-servers.net)
3	f.gtld-servers.net	2 name server di example.com
4	elliott.ns.cloudflare.com	2 record A di example.com

L'output di +trace è come il tracciamento di una raccomandata.

Il record A dell'ultimo passo è stato inviato direttamente dal name server di example.com, quindi è il valore attuale, non preso da una cache. Subito dopo aver cambiato i name server, controlla prima al passo 3 se i server .com rispondono con i nuovi name server.

5️⃣ Errori di risposta e opzioni di dig

↪️ NXDOMAIN, SERVFAIL, connection timed out

🔲 Errori di risposta

Interrogando un nome che non esiste, status risulta NXDOMAIN. .invalid è un dominio di primo livello riservato perché non venga mai usato davvero, per questo è servito a controllare questa risposta.

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 era 0, e la sezione AUTHORITY conteneva il record SOA di quella zona. L'ultimo numero del SOA, 10800, è il tempo (secondi) per cui questa risposta può restare in cache.

no-such-host.example.com è terminato con status NOERROR e ANSWER 0 invece di NXDOMAIN. È una risposta senza codice di errore in cui mancano solo i record, quindi controlla status e il numero di ANSWER insieme.

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 è il codice di risposta che indica che il server DNS non è riuscito a produrre una risposta (RFC 1035). Chiedendo a 8.8.8.8 di dnssec-failed.org, un dominio pubblico per provare i fallimenti della convalida DNSSEC, è uscito SERVFAIL insieme a una riga 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 è un codice di errore esteso che aggiunge il motivo dell'errore (RFC 8914). 9 (DNSKEY Missing) significa che non è stata trovata una DNSKEY corrispondente al record DS della zona superiore, e 8.8.8.8 ha restituito SERVFAIL invece di un indirizzo per un nome di cui non poteva verificare la firma.

Se il server DNS non risponde, l'output termina con [connection timed out; no servers could be reached] senza riga status. Chiedendo a 192.0.2.1, un indirizzo per gli esempi della documentazione, con [+timeout=2 +tries=1], questa riga è comparsa dopo 2 secondi.

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

Senza opzioni, lo stesso indirizzo ha dato la stessa riga dopo 15 secondi. Questo perché i valori predefiniti del manuale ufficiale sono 5 secondi per risposta e 3 tentativi. Con dig 9.18 sul server Debian 12 è comparsa prima la riga [communications error to 192.0.2.1#53: timed out], e l'ultima riga era [no servers could be reached].

Se uno script separa i risultati in base al codice di uscita, tieni conto che anche NXDOMAIN restituisce 0. Interrogando example.invalid con +short e stampando poi il codice di uscita è uscito 0 con un risultato vuoto, mentre la query a 192.0.2.1, rimasta senza risposta, ha dato 9.

dig +short example.invalid; echo $?

Per ogni errore di risposta, ecco la riga da controllare nell'output e cosa verificare dopo.

Output	Significato	Cosa controllare dopo
status: NXDOMAIN	Quel nome non esiste	Ortografia e stato di registrazione del dominio, percorso di delega con +trace
status: NOERROR · ANSWER: 0	Nessun record di quel tipo nella risposta	Tipo di record e impostazioni dei record del name server
status: SERVFAIL	Il server DNS non è riuscito a produrre una risposta	Riga EDE, risposte di altri server DNS (@8.8.8.8 · @1.1.1.1)
connection timed out	Il server DNS non risponde	Indirizzo del server DNS e firewall che bloccano la porta 53

🔲 Opzioni del comando dig

📌 Opzioni principali: risultati di questo articolo

Opzione	Compito	Risultato in questo articolo
@server	Interroga il server indicato al posto del server DNS impostato sul server	Con @8.8.8.8 la riga SERVER è diventata 8.8.8.8 e ai flags si è aggiunto ad; con il name server autorevole, aa
Variante	Interroga solo il tipo di record scritto dopo il nome	example.com MX ha dato una sola riga [0 .]; mx in minuscolo lo stesso risultato
-x indirizzo	Interroga il record PTR di un indirizzo IP	-x 8.8.8.8 ha dato dns.google.
-v	Mostra la versione	9.16 sul server AlmaLinux 9, 9.18 sul server Debian 12
-r	Non legge il .digrc nella cartella home	Anche con +short in .digrc, con -r le righe dei record sono comparse per intero
+short	Mostra solo i valori dei record	A ha dato due indirizzi IP; google.com MX ha dato 10 smtp.google.com.
+noall +answer	Disattiva tutte le sezioni di output e riattiva solo ANSWER	example.com NS ha lasciato solo le due righe dei name server
+multiline	Divide record lunghi come SOA su più righe con commenti	Nomi e durate come serial e refresh compaiono come commento accanto a ogni numero
+stats	Mostra anche il tempo della query e la riga del server che ha risposto	Con dig 9.18 sul server Debian 12, (UDP) in fondo alla riga SERVER
+trace	Interroga in ordine dai root name server e mostra il percorso di delega	In ciascuno dei quattro passi, l'ultima riga [Received … from] indica il server che ha risposto
+nodnssec	Non richiede i record di firma DNSSEC	Usato con +trace per lasciare solo il percorso di delega
+timeout=secondi	Tempo di attesa per una risposta, predefinito 5 secondi	Chiedendo a 192.0.2.1 con +timeout=2 +tries=1, [connection timed out] dopo 2 secondi; senza opzioni, 15 secondi
+tries=volte	Numero di invii della query, predefinito 3	Impostato a 1 insieme a +timeout=2, ha interrogato una sola volta ed è terminato dopo 2 secondi
+tcp	Invia la query via TCP invece che via UDP	Con dig 9.18 sul server Debian 12, la fine della riga SERVER è passata da (UDP) a (TCP) e i record sono rimasti uguali

📎 Altre opzioni: secondo il manuale ufficiale

Opzione	Compito
-4	Interroga solo via IPv4
-6	Interroga solo via IPv6
-t tipo	Imposta il tipo di record da interrogare
-q nome	Imposta il nome da interrogare, per non confonderlo con altri argomenti
-p porta	Interroga sulla porta indicata invece che sulla 53
-b indirizzo	Imposta l'indirizzo IP di origine da cui parte la query
-f file	Esegue in ordine le query scritte una per riga in un file
+norecurse	Interroga con la richiesta di ricorsione (RD) disattivata
+dnssec	Richiede anche i record DNSSEC
+nssearch	Trova i name server autorevoli e mostra il record SOA di ciascuno
+nocmd	Mostra l'output senza le righe di versione e di opzioni iniziali
+nocomments	Mostra l'output senza righe di commento come l'intestazione di risposta e i nomi delle sezioni
+ttlunits	Mostra il TTL nelle unità s, m, h, d e w
+retry=volte	Numero di nuovi invii esclusa la prima query, predefinito 2

🔲 Simulatore del comando dig

Nel simulatore qui sotto puoi digitare dig tu stesso cambiando tipo di record, server DNS e opzioni di output.

Simulatore del comando digdig 9.16

[root@server work]#

Funziona solo nel tuo browser; le risposte arrivano da un DNS virtuale con valori di query reali, e ↑↓ richiama i comandi digitati prima.

🔢 FAQ & contenuti consigliati

Sui due server controllati, dig si trovava nel pacchetto bind-utils di AlmaLinux 9 e nel pacchetto bind9-dnsutils di Debian 12. Quindi si installa con [sudo dnf install bind-utils] sulla famiglia RHEL e con [sudo apt install bind9-dnsutils] sulla famiglia Debian. Entrambi i pacchetti installano anche nslookup.

Secondo il manuale ufficiale, dig legge le opzioni scritte nel file .digrc della cartella home e le applica prima degli argomenti della riga di comando. Con una riga +short in .digrc, [dig example.com] ha mostrato solo gli indirizzi IP; con -r il file .digrc non è stato letto e le righe dei record sono comparse per intero.

Con +tcp la query viene inviata via TCP. Con dig 9.18 sul server Debian 12, aggiungendo +tcp la fine della riga SERVER è passata da (UDP) a (TCP), e i record ricevuti erano gli stessi.

🔝 Comandi Linux

🔗 Contenuti consigliati

Propagazione DNS Tempo di propagazione DNS dopo il cambio dei name server: misurazioni per resolver e controllo DNSSEC Un articolo che ha registrato ogni 5 minuti le risposte di 7 resolver dopo il cambio dei name server e ha verificato perché DNSSEC va disattivato prima del trasferimento. Leggi l'articolo →

Disattivare DNSSEC per cambiare i name server (stato attivo)

Esempio di ricerca WHOIS di un dominio (naver)

Strumento · dominio Ricerca WHOIS del dominio · controllo dei nameserver Uno strumento di ricerca che, inserito un dominio, mostra subito nel browser dati di registrazione, name server e record DNS.

Controllare un record A con l'uso di base del comando host – come con il comando nslookup

Rete · DNS Comando host di Linux | comando di interrogazione DNS Il comando host, per trovare l'indirizzo IP di un nome host o convertire un indirizzo IP in nome host.

DNS · Concetti Name server e DNS: differenze & i 4 principali tipi di record DNS Un articolo che spiega in cosa differiscono name server e DNS e cosa contiene ciascuno dei quattro tipi di record DNS più usati.

🪐RiferimentiDocumentazione ufficiale / RFC

📡dig — manuale ufficiale di BIND 9 (ISC) 📡dig(1) — manuale di bind9-dnsutils su Debian 12 📡RFC 1035 — formato dei messaggi DNS e flag dell'intestazione (IETF) 📡RFC 4035 — DNSSEC e il flag AD (IETF) 📡RFC 7505 — Null MX per i domini che non ricevono posta (IETF) 📡RFC 8914 — Extended DNS Errors(EDE) (IETF) 📡RFC 2606 — nomi riservati example.com e .invalid (IETF)

ℹ️ Informativa sull'affiliazione
I contenuti di questo sito includono link di affiliazione. Se un visitatore acquista un prodotto o un servizio tramite uno di questi link, il sito riceve una commissione dal venditore. In questo processo l'importo pagato dall'acquirente^{(durante le promozioni l'importo scende↓)} non aumenta. Prezzi, sconti e disponibilità indicati si riferiscono al momento della stesura e possono differire da quelli reali: prima di acquistare verifica sempre presso il venditore. I prodotti vengono scelti e valutati secondo criteri propri, e le commissioni non influiscono sull'ordine di presentazione né sul contenuto delle valutazioni.