Troubleshooting DNS: nslookup, dig, DoH

In breve: I problemi DNS sono tra le cause più frequenti e difficili da diagnosticare di outage - perché "il DNS funziona da me" non significa che funziona per i tuoi clienti. Ecco una panoramica di strumenti e procedure pratiche.

Problemi DNS più frequenti

• Registrazione del dominio scaduta - l'intero DNS smette di funzionare.
• Record A/AAAA errato - dopo migrazione del server si è dimenticato di aggiornare.
• CNAME / MX mancante - l'email non funziona, mentre il sito sì.
• TTL non preparato per cambi rapidi - le cache dei provider servono ancora dati vecchi.
• Errore DNSSEC - i validatori rifiutano record non firmati o mal firmati.
• Guasto Geo-DNS - il resolver di una certa regione riceve risposta sbagliata.

nslookup: il comando più semplice

Disponibile su tutti gli OS senza installazione. Usa il server DNS di default del sistema, ma si può specificare esplicitamente come secondo argomento.

$ nslookup epulz.io
Server:    127.0.0.53
Address:   127.0.0.53#53

Non-authoritative answer:
Name:      epulz.io
Address:   87.197.115.180

# Usare esplicitamente Cloudflare DNS
$ nslookup epulz.io 1.1.1.1

# Tipo specifico di record
$ nslookup -type=MX gmail.com 8.8.8.8
$ nslookup -type=TXT _dmarc.epulz.io 1.1.1.1

dig: query DNS dettagliata per Unix

dig (Domain Information Groper) è significativamente più dettagliato e flessibile. Parte del pacchetto bind-utils o dnsutils.

$ dig epulz.io

;; QUESTION SECTION:
;epulz.io.                      IN      A

;; ANSWER SECTION:
epulz.io.               300     IN      A       87.197.115.180

;; Query time: 12 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: ...

Campi chiave:

• TTL (300) = secondi in cui il resolver può cachare la risposta.
• ANSWER SECTION = il risultato.
• SERVER = quale resolver DNS ha risposto.
• Query time = durata - utile per il debug di DNS lento.

Comandi pratici

# Risposta breve (solo IP)
$ dig +short epulz.io
87.197.115.180

# Tutti i record
$ dig epulz.io ANY

# Trace dell'intera gerarchia DNS (dai root nameserver)
$ dig +trace epulz.io

# Reverse lookup
$ dig -x 87.197.115.180

# Resolver specifico
$ dig @8.8.8.8 epulz.io
$ dig @1.1.1.1 epulz.io
$ dig @9.9.9.9 epulz.io

# Validazione DNSSEC
$ dig +dnssec epulz.io

DNS-over-HTTPS (DoH): quando non hai UDP/53

In alcune reti (firewall aziendali, dati mobili con blocco) la tradizionale porta DNS 53 è bloccata. DoH impacchetta le query DNS in richieste HTTPS - passano ovunque funzioni 443.

# Endpoint DoH di Cloudflare
$ curl -s "https://cloudflare-dns.com/dns-query?name=epulz.io&type=A" \
       -H "Accept: application/dns-json" | jq

# Google DoH
$ curl -s "https://dns.google/resolve?name=epulz.io&type=MX" | jq

Un client DoH online con bella UI lo abbiamo anche su - nessuna installazione.

Procedura per "il dominio non funziona"

1. Controlla la registrazione. whois yourdomain.com o via il registrar. Se scaduta, nient'altro si può riparare.
2. Controlla i record NS. dig NS yourdomain.com @8.8.8.8. Vengono restituiti i nameserver responsabili del dominio? Combaciano con quelli del pannello del registrar?
3. Controlla il record A. dig yourdomain.com @8.8.8.8. Restituisce l'IP corretto?
4. Testa da rete esterna (dati mobili, VPN, strumento online). Tu stesso potresti avere dati vecchi in cache.
5. Controlla il TTL. Se hai appena cambiato un record, aspetta almeno il TTL originale (di default 1-24 ore).
6. Controlla DNSSEC. Se lo usi, la catena di firme può essere rotta. dig +dnssec yourdomain.com mostra il flag ad in caso di successo.

Propagazione DNS: quanto tempo richiede?

"Propagazione DNS" è un termine un po' fuorviante. Il DNS non si propaga verso di te - i tuoi resolver scaricano la risposta e la cachano secondo il TTL. Solo dopo la scadenza del TTL provano una nuova query.

Conseguenze pratiche:

• Pianifichi una migrazione? Abbassa il TTL a 60-300 secondi almeno 48 ore prima.
• Il vecchio IP resterà valido per alcuni client a lungo dopo il cambio. Non spegnere il vecchio server subito.
• I cloud provider (Cloudflare, AWS Route 53) hanno TTL veloce e cache invalidation, ma il client finale deve comunque aspettare il TTL del proprio resolver.

Conclusione

Il DNS è la colla infrastrutturale che tutti danno per scontata - finché smette di funzionare. Un monitoraggio regolare dei record DNS (A, NS, MX, il loro TTL e validazione DNSSEC) rivela il problema prima che un cliente lo segnali per telefono.

Monitoraggio DNS e scadenza WHOIS

ePulz.io traccia i record A/AAAA/MX/NS e la scadenza della registrazione del dominio. 7 giorni gratis.

Avvia monitoraggio →