Comando dig in Linux: leggere record DNS, stato e TTL

dig interroga un server DNS e mostra i record restituiti insieme allo stato della risposta. Serve per diagnosticare la risoluzione dei nomi e confrontare risposte DNS; un risultato vuoto in formato breve, però, non dimostra da solo che il dominio non esista.

DNS significa Domain Name System: associa nomi a informazioni come indirizzi e server di posta. Un record A contiene un indirizzo IPv4, AAAA un indirizzo IPv6, MX informazioni sul recapito della posta e TXT dati testuali. Devi quindi scegliere il tipo pertinente alla domanda, invece di aspettarti che una singola interrogazione mostri tutti i dati del dominio.

Sintassi e scelta del server

dig [@DNS server] name [record type] [option]

È una sintassi descrittiva: parentesi, spazi nei segnaposto e parole come name non si copiano letteralmente. Nella forma reale il server si indica con @ seguito dal nome o dall'indirizzo, poi si specificano nome da cercare e tipo. Controlla dig -v, dig -h e man dig per la versione installata; qui si usa dig di BIND 9.

Senza un server esplicito, su Linux dig consulta normalmente /etc/resolv.conf. Nel risultato completo verifica anche SERVER, cioè il server che ha risposto. Se ometti il tipo dopo un nome, la ricerca è normalmente di tipo A; eseguire dig senza alcun argomento è un caso diverso, che consulta i record NS della radice.

Per confrontare due server, ripeti la stessa domanda mantenendo nome e tipo e cambiando soltanto il valore @server. Sostituisci il segnaposto con il server previsto dal tuo ambiente. Il comando consulta il server scelto e non cambia la configurazione DNS del computer.

Esempi per indirizzi e posta

Leggere i record A

dig example.com A

Cerca lo stato nell'intestazione e i record pertinenti nella ANSWER SECTION. Gli indirizzi effettivi possono cambiare; il comando non prova che un sito web risponda su quegli indirizzi. Per gli indirizzi IPv6 scegli invece il tipo AAAA.

Interrogare i record MX

dig example.com MX

Leggi preferenza e nome del server di posta nella risposta, se presenti. Non cercare il risultato fra i soli record A: sono domande diverse. Anche una risposta MX non costituisce una prova di consegna di un messaggio o di funzionamento del servizio di posta.

Ottenere un risultato breve

dig +short example.com A

È pratico per una consultazione rapida, ma omette il contesto diagnostico. Se non vedi indirizzi, ripeti la domanda nel formato completo del primo esempio e leggi stato, domanda e sezioni. Nei programmi automatici non trattare una stringa vuota come prova certa di dominio inesistente.

Leggere nome, TTL, classe, tipo e valore

Per concentrarti sui record della risposta:

dig +noall +answer example.com A

+noall disattiva la visualizzazione delle sezioni e +answer riattiva la risposta. Questo è uno schema illustrativo; indirizzo e TTL non sono una misura del DNS attuale di example.com:

example.com. 300 IN A 192.0.2.10

La riga si legge da sinistra: nome del record, TTL, classe, tipo e valore. Il punto finale in example.com. indica un nome assoluto. 300 è il TTL (Time To Live), espresso in secondi; IN è la classe Internet, A il tipo IPv4 e l'ultimo campo l'indirizzo.

Il TTL è legato alla conservazione del record in cache, non al tempo impiegato per rispondere. Il valore può diminuire quando interroghi una cache e non impone che tutti i resolver del mondo aggiornino la risposta nello stesso istante. Server diversi possono inoltre fornire risposte diverse secondo la vista DNS o le politiche applicate.

192.0.2.10 è un indirizzo di documentazione, non un indirizzo da copiare nella configurazione reale del tuo dominio. Se l'output è vuoto, togli le opzioni che nascondono le sezioni: da questa vista ridotta non puoi distinguere le principali cause.

Opzioni e forme principali

La ricerca inversa -x consulta dati PTR: non garantisce che il nome ottenuto torni allo stesso indirizzo con una ricerca A o AAAA. +trace segue la delega DNS a partire dalla radice; non è una traccia dei router di rete come traceroute. Se lo combini con @server, quel server riguarda l'interrogazione iniziale dei server della radice, non tutte le tappe.

Distinguere risposta vuota, errore e percorso del browser

1. Ripeti la domanda senza +short o +noall. Controlla che nome e tipo nella domanda siano quelli voluti.
2. Leggi lo stato. NXDOMAIN segnala un nome inesistente nella risposta ricevuta; se esistono alias, considera anche il nome finale della catena. NOERROR non garantisce la presenza del tipo richiesto: una risposta negativa senza dati pertinenti viene chiamata NODATA.
3. Distingui un errore restituito dal server, come SERVFAIL, da un timeout senza risposta utile. Un output breve vuoto non basta a separarli. Leggi anche le sezioni di autorità: una risposta senza record richiesti può avere un contesto diverso da una delega.
4. Confronta il server effettivo e la cache con la risoluzione usata dall'applicazione. /etc/hosts, cache locali, proxy o un resolver differente possono spiegare perché un browser si comporti diversamente.

dig interroga DNS direttamente e non riproduce l'intero percorso di risoluzione di ogni applicazione. Anche il codice di uscita va interpretato correttamente: per BIND dig, 0 indica una risposta DNS ricevuta e comprende NXDOMAIN, quindi non certifica che il record richiesto esista.

Quando confronti un cambiamento, conserva nome, tipo, server e risposta completa. Una differenza di cache o di vista non dimostra da sola che la configurazione sia errata; valuta dove si trova il client che riscontra il problema e quale risposta dovrebbe ricevere.

Domande frequenti

Perché dig e il browser sembrano dare risultati diversi?

dig mostra la risposta del server DNS interrogato. Il browser può usare una cache, un proxy o un altro percorso di risoluzione; inoltre ricevere un indirizzo e riuscire a collegarsi al servizio sono verifiche diverse. Confronta nome, tipo, server e indirizzo realmente usati.

Documentazione di riferimento

Il manuale ufficiale dig di BIND 9 descrive sintassi e codici di uscita. La RFC 2308 sulle risposte DNS negative distingue NXDOMAIN e NODATA; la RFC 5737 sugli indirizzi IPv4 di documentazione definisce l'intervallo dell'esempio.