Diagnosticare i problemi DNS in Windows e Linux

Procedura per separare errori DNS, rete e HTTPS usando nslookup, Resolve-DnsName, dig, resolvectl e test mirati.

Diagnosticare i problemi DNS in Windows e Linux

Procedura per separare errori DNS, rete e HTTPS usando nslookup, Resolve-DnsName, dig, resolvectl e test mirati.

Prima la rete, poi il nome

Controlla IP, gateway e rotta predefinita. Prova il gateway reale e un IP esterno, sapendo che ICMP può essere bloccato. Un ping riuscito verso un IP e fallito verso un nome suggerisce un problema di risoluzione, ma non lo dimostra da solo. Annota nome completo, tipo A/AAAA, orario, rete e messaggio esatto. A è IPv4, AAAA IPv6, MX posta, NS delega, CNAME alias, TXT dati testuali e PTR risoluzione inversa.

Resolver Windows

Con ipconfig /all identifica la scheda attiva, DNS e suffissi; VPN e domini Active Directory possono usare server interni e split DNS. nslookup interroga un server DNS ma bypassa la cache locale, il file hosts e alcune regole del client: non riproduce sempre il comportamento dell’applicazione. Resolve-DnsName offre controlli più mirati; -DnsOnly -NoHostsFile separa intenzionalmente la risposta DNS dal file hosts. Non sostituire alla cieca i DNS aziendali con un resolver pubblico.

ipconfig /all
nslookup www.example.com
nslookup -type=AAAA www.example.com
nslookup www.example.com 1.1.1.1
Resolve-DnsName www.example.com -Type A
Resolve-DnsName www.example.com -Server 1.1.1.1 -DnsOnly -NoHostsFile

Cache e file hosts

Controlla la cache con ipconfig /displaydns o Get-DnsClientCache. ipconfig /flushdns e Clear-DnsClientCache la svuotano sul solo PC, non correggono record autoritativi o cache dei resolver intermedi. Controlla C:\Windows\System32\drivers\etc\hosts e le regole VPN senza eliminare voci necessarie. Ripeti la query annotando server e risultato.

ipconfig /displaydns
ipconfig /flushdns
Get-DnsClientCache
Clear-DnsClientCache

Resolver Linux

Su sistemi con systemd-resolved, resolvectl status elenca DNS per collegamento e domini instradati; resolvectl query mostra la risoluzione del client. Controlla /etc/resolv.conf, che può essere gestito da systemd-resolved, NetworkManager o DHCP: modifica la sorgente della configurazione, non un file generato che verrà sovrascritto.

ip address
ip route
resolvectl status
resolvectl query www.example.com
ls -l /etc/resolv.conf

Confrontare con dig

dig interroga il DNS e rende visibili status, ANSWER, TTL e server interrogato; come nslookup non equivale sempre al percorso di risoluzione dell’applicazione. Confronta resolver predefinito e uno scelto, senza usare un resolver pubblico per giudicare una zona privata. NOERROR con ANSWER vuota può indicare che manca il tipo di record richiesto, non che il nome non esiste. +trace mostra la delega, ma può fallire in reti che filtrano query dirette.

sudo apt update
sudo apt install dnsutils
dig www.example.com A
dig www.example.com AAAA
dig @1.1.1.1 www.example.com A
dig example.com NS
dig example.com SOA
dig +trace www.example.com

Errori e autoritativi

NXDOMAIN indica nome inesistente nella vista interrogata; SERVFAIL una risoluzione fallita, per esempio a causa di DNSSEC o autoritativi; REFUSED un rifiuto; timeout una risposta assente. Verifica i server NS effettivi e interroga ciascun autoritativo con il suo nome reale, confrontando A/AAAA e seriale SOA. I nomi ns1.provider.example e ns2.provider.example sono segnaposto, non server pubblici utilizzabili.

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

TTL e cache negativa

Dopo una modifica, i resolver possono tenere il vecchio dato fino alla scadenza del TTL precedente. Anche NXDOMAIN può essere memorizzato temporaneamente. Prima di chiamarla “propagazione”, verifica i record direttamente sugli autoritativi, confronta più resolver e annota TTL e timestamp. Un flush locale non svuota le cache altrui.

Porta 53 e applicazione

DNS usa comunemente UDP 53 e anche TCP 53. Test-NetConnection -Port 53 prova una connessione TCP: non misura UDP. Con dig confronta la query predefinita con +tcp; un successo TCP non certifica il funzionamento DNS applicativo e viceversa. Quando A/AAAA sono corretti, prova porta 443 e HTTPS: firewall, routing, servizio e certificato TLS sono problemi distinti dal DNS.

# PowerShell: tests TCP, not UDP
Test-NetConnection 1.1.1.1 -Port 53
Test-NetConnection www.example.com -Port 443
# Linux: compare default DNS transport and TCP
dig @1.1.1.1 example.com A
dig +tcp @1.1.1.1 example.com A
curl -I https://www.example.com

DNSSEC e conclusione

Se soltanto resolver che validano DNSSEC restituiscono SERVFAIL, verifica catena e delega con delv e controlla anche l’orologio. Raccogli risultati ripetibili prima di svuotare cache o cambiare DNS; mantieni separati resolver del sistema, query diretta, server autoritativi e servizio finale.

delv example.com A
timedatectl status

Fonti

Microsoft Resolve-DnsName: https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname ; Microsoft DNS troubleshooting: https://learn.microsoft.com/en-us/troubleshoot/azure/dns/troubleshoot-dns ; BIND DNSSEC: https://bind9.readthedocs.io/en/stable/dnssec-guide.html .

Share

What's Your Reaction?

Like Like 0
Cancella like Cancella like 0
Amore Amore 0
Buffo Buffo 0
arrabbiato arrabbiato 0
Sad Sad 0
Wow Wow 0