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.
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
0
Cancella like
0
Amore
0
Buffo
0
arrabbiato
0
Sad
0
Wow
0