Diagnosticare i problemi DNS in Windows e Linux

Quando un sito non si apre, un server non raggiunge un servizio o un'applicazione restituisce errori di connessione, il DNS viene spesso indicato come responsabile. A volte lo è davvero; altre volte il nome viene risolto correttamente e il problema si trova nel routing, nel firewall, nel servizio remoto o nel certificato TLS. Una diagnosi efficace deve quindi seguire un ordine preciso e separare la risoluzione dei nomi dalla connettività IP.

Che cosa deve fare il DNS

Il Domain Name System traduce nomi come www.example.com in informazioni utilizzabili dai client. I record più comuni sono:

• A: associa un nome a un indirizzo IPv4;
• AAAA: associa un nome a un indirizzo IPv6;
• CNAME: crea un alias verso un altro nome;
• MX: indica i server che ricevono la posta;
• TXT: contiene verifiche, criteri SPF e altri dati testuali;
• NS: identifica i server autoritativi della zona;
• PTR: realizza la risoluzione inversa da IP a nome.

La risposta può provenire dalla cache locale, dal resolver della rete aziendale, dal router, dal provider o da un resolver pubblico. Per questo due computer possono ottenere risultati diversi nello stesso momento.

1. Separare DNS e connettività

Inizia verificando la configurazione IP e il gateway. Su Windows:

ipconfig /all
ping 192.168.1.1
ping 1.1.1.1

Su Linux:

ip address
ip route
ping -c 4 192.168.1.1
ping -c 4 1.1.1.1

Sostituisci 192.168.1.1 con il gateway effettivo. Se non raggiungi il gateway, il DNS non è ancora il problema prioritario. Se raggiungi un IP esterno ma non un nome, la risoluzione DNS diventa invece il principale sospetto. Tieni presente che alcuni host bloccano ICMP: un ping fallito, da solo, non dimostra che un server sia offline.

2. Individuare i server DNS configurati in Windows

Il comando seguente mostra indirizzi, gateway, DHCP e server DNS di tutte le schede:

ipconfig /all

In PowerShell puoi ottenere una vista più mirata:

Get-DnsClientServerAddress
Get-DnsClient | Format-Table InterfaceAlias,ConnectionSpecificSuffix,RegisterThisConnectionsAddress

Controlla la scheda realmente utilizzata. VPN, Hyper-V, software di virtualizzazione e adattatori disconnessi possono aggiungere resolver o suffissi di ricerca e confondere l'analisi. In un dominio Active Directory, i client devono normalmente interrogare i DNS interni: sostituirli indiscriminatamente con resolver pubblici può impedire l'individuazione dei controller di dominio.

3. Interrogare il DNS in Windows

nslookup permette una verifica rapida usando il resolver predefinito:

nslookup www.example.com
nslookup -type=AAAA www.example.com
nslookup -type=MX example.com

Per confrontare la risposta con un resolver specifico:

nslookup www.example.com 1.1.1.1
nslookup www.example.com 8.8.8.8

Se il DNS aziendale fallisce e quello pubblico risponde, il problema può riguardare il resolver interno, il forwarding o una zona locale. Se entrambi restituiscono lo stesso indirizzo sbagliato, controlla la configurazione autoritativa e la propagazione.

PowerShell offre risultati strutturati:

Resolve-DnsName www.example.com -Type A
Resolve-DnsName example.com -Type NS
Resolve-DnsName example.com -Type SOA
Resolve-DnsName www.example.com -Server 1.1.1.1

Resolve-DnsName è particolarmente utile negli script perché restituisce oggetti PowerShell invece di testo da interpretare manualmente.

4. Controllare e svuotare la cache di Windows

Windows conserva risposte positive e negative. Visualizza la cache:

ipconfig /displaydns

Per eliminarla:

ipconfig /flushdns

Il flush è utile dopo una modifica DNS o quando una risposta errata è rimasta memorizzata, ma non corregge un record sbagliato sul server. Dopo aver svuotato la cache, ripeti la query e annota resolver, risposta ed eventuale errore.

Controlla inoltre il file locale:

C:\Windows\System32\drivers\etc\hosts

Una voce nel file hosts può prevalere sulla normale risoluzione. Non cancellare righe senza comprenderne lo scopo: software gestionali, ambienti di test o strumenti di sicurezza potrebbero averle aggiunte intenzionalmente.

5. Verificare DNS e resolver in Linux

Sui sistemi moderni con systemd-resolved usa:

resolvectl status
resolvectl query www.example.com

resolvectl status mostra i DNS globali e quelli associati alle singole interfacce. È importante con VPN e configurazioni split DNS, dove determinati domini vengono inviati soltanto a un resolver aziendale.

Esamina anche /etc/resolv.conf:

ls -l /etc/resolv.conf
cat /etc/resolv.conf

Su Ubuntu il file è spesso un collegamento gestito da systemd-resolved o da NetworkManager. Modificarlo manualmente può produrre un risultato temporaneo che viene sovrascritto al riavvio o al rinnovo DHCP. Correggi la sorgente della configurazione, per esempio Netplan, NetworkManager, DHCP o il profilo VPN.

6. Usare dig per interrogazioni precise

Su Ubuntu, dig è disponibile nel pacchetto dnsutils:

sudo apt update
sudo apt install dnsutils

Esempi fondamentali:

dig www.example.com A
dig www.example.com AAAA
dig example.com MX
dig example.com NS
dig example.com SOA
dig -x 203.0.113.10

Per ottenere soltanto il valore:

dig +short www.example.com A

Per interrogare un resolver specifico:

dig @1.1.1.1 www.example.com A
dig @8.8.8.8 www.example.com A

Nell'output completo osserva status, sezione ANSWER, server interrogato, tempo di risposta e TTL. Un NOERROR con sezione ANSWER vuota può significare che il nome esiste ma non possiede il tipo di record richiesto.

7. Interpretare gli errori DNS

• NXDOMAIN: il nome richiesto non esiste secondo il DNS interrogato;
• SERVFAIL: il resolver non è riuscito a completare la richiesta; tra le cause possibili ci sono errori DNSSEC, server autoritativi irraggiungibili o configurazioni incoerenti;
• REFUSED: il server ha ricevuto la query ma rifiuta di servirla;
• Timeout: nessuna risposta entro il tempo previsto; controlla servizio, firewall e raggiungibilità su porta 53;
• Risposta inattesa: verifica cache, split DNS, file hosts, CNAME e resolver effettivamente utilizzato.

Non confondere NXDOMAIN con un record A assente. Un dominio può esistere e avere record MX o TXT senza possedere un indirizzo IPv4.

8. Controllare la delega e i server autoritativi

Quando gestisci il dominio, interroga direttamente i name server:

dig example.com NS
dig @ns1.provider.example example.com SOA
dig @ns1.provider.example www.example.com A

Confronta le risposte di tutti i server autoritativi. Devono pubblicare dati coerenti e un seriale SOA aggiornato. Se un server restituisce il vecchio indirizzo e un altro quello nuovo, la zona non è stata sincronizzata correttamente.

Per seguire la catena dalla radice:

dig +trace www.example.com

+trace è utile per deleghe errate, ma il risultato può essere influenzato da reti che filtrano le query dirette. Confrontalo con una normale interrogazione ricorsiva.

9. TTL, cache e propagazione

Il TTL indica per quanto tempo una risposta può rimanere in cache. Dopo una modifica, alcuni resolver continueranno legittimamente a fornire il vecchio valore fino alla scadenza del TTL precedente. Parlare genericamente di propagazione può nascondere il problema reale: annota il vecchio TTL, interroga più resolver e verifica direttamente i server autoritativi.

Anche le risposte negative possono essere memorizzate. Se un nome è stato interrogato prima della sua creazione, un client potrebbe continuare a vedere NXDOMAIN per un certo periodo. Svuotare la cache locale aiuta soltanto sul dispositivo interessato; non elimina le cache dei resolver intermedi.

10. Verificare la porta 53 e il trasporto

Il DNS utilizza normalmente UDP 53, ma può passare a TCP per risposte grandi, trasferimenti di zona e altri casi. Un firewall che consente UDP ma blocca TCP può causare guasti intermittenti. Su Windows:

Test-NetConnection 1.1.1.1 -Port 53

Questo test verifica TCP. Su Linux:

dig @1.1.1.1 example.com A
dig +tcp @1.1.1.1 example.com A

Se UDP funziona e TCP no, esamina firewall locali, ACL di rete e policy del resolver.

11. DNSSEC e orologio di sistema

Una catena DNSSEC non valida può produrre SERVFAIL sui resolver che effettuano la validazione, mentre un resolver non validante potrebbe rispondere. Su Linux, gli strumenti BIND includono delv, progettato per interrogare e validare le risposte:

delv example.com A

Verifica anche data e ora:

timedatectl status

Un orologio molto errato può compromettere verifiche crittografiche e far sembrare il problema legato al DNS o a TLS.

12. Quando il DNS funziona ma il sito no

Se dig, nslookup o Resolve-DnsName restituiscono l'IP corretto, prova il servizio:

curl -I https://www.example.com

Su Windows:

Test-NetConnection www.example.com -Port 443

Un timeout sulla porta 443 indica probabilmente routing o firewall; connection refused suggerisce che l'host risponde ma il servizio non ascolta; un errore di certificato segnala invece un problema TLS, nome del certificato o virtual host. La risoluzione DNS può essere perfettamente corretta in tutti questi casi.

Procedura rapida e ripetibile

1. controlla IP, gateway e connettività verso un indirizzo esterno;
2. identifica il resolver realmente configurato sulla scheda attiva;
3. interroga il nome con il resolver predefinito;
4. confronta la risposta con un resolver noto e con il server autoritativo;
5. verifica tipo di record, TTL, CNAME e differenze tra IPv4 e IPv6;
6. controlla file hosts, cache locale, VPN e split DNS;
7. prova UDP e TCP sulla porta 53 quando sospetti filtraggio;
8. se l'IP è corretto, passa ai test della porta applicativa e di TLS.

Conclusione

La diagnostica DNS diventa molto più semplice quando ogni livello viene verificato separatamente. Windows mette a disposizione ipconfig, nslookup e Resolve-DnsName; Linux offre resolvectl, dig e delv. Il punto decisivo non è eseguire molti comandi, ma confrontare in modo ordinato configurazione locale, resolver ricorsivi, server autoritativi e servizio finale. Così si evita di svuotare cache o cambiare DNS alla cieca e si individua il componente realmente responsabile.