Come risolvere DNS server not responding

Cosa significa l'errore

Ogni connessione inizia con una ricerca. Il tuo dispositivo invia il nome host a un resolver, di solito il tuo router, il tuo provider, oppure un servizio pubblico come 1.1.1.1, e aspetta un indirizzo IP. Se non arriva risposta entro il timeout, il sistema operativo riprova, tenta il server secondario e alla fine rinuncia. Windows allora esegue la sua risoluzione dei problemi, che segnala che il server DNS non risponde.

La formulazione punta al server, ma è in realtà un'affermazione su un percorso. Ciascuno di questi produce lo stesso messaggio: il resolver è giù, il resolver è attivo ma irraggiungibile dalla tua rete, un firewall blocca la porta 53, l'indirizzo configurato sul tuo adattatore è sbagliato, oppure il router nel mezzo ha smesso di inoltrare. Il silenzio appare identico in tutti e cinque i casi.

Distinguilo dai suoi vicini prima di iniziare. Un resolver che risponde "nome inesistente" ti dà NXDOMAIN, trattato in DNS_PROBE_FINISHED_NXDOMAIN. Un resolver che risponde lentamente ma correttamente è di nuovo un problema diverso, e ha la sua sezione più sotto. Questo errore è il caso in cui non torna indietro nulla.

Perché succede

• Il router ha smesso di inoltrare. I router consumer eseguono un piccolo forwarder DNS che si blocca più spesso del resto del dispositivo, quindi la rete sembra online e falliscono solo le ricerche dei nomi.
• Il server DNS configurato è sbagliato. Un indirizzo statico rimasto da una vecchia rete, oppure un server che è stato dismesso.
• Il resolver del provider sta avendo un'interruzione oppure è sovraccarico e scarta le richieste invece di rispondere.
• Un firewall o una suite di sicurezza blocca la porta 53. Alcuni prodotti intercettano il DNS loro stessi e falliscono in chiusura quando il proprio servizio non è in esecuzione.
• Una VPN è connessa a metà. Il tunnel ha spinto i suoi resolver interni sul tuo adattatore, poi è caduto, lasciando indirizzi raggiungibili solo dentro il tunnel.
• IPv6 è configurato ma non utilizzabile. Il sistema preferisce un resolver IPv6, non trova un percorso verso di esso, e aspetta il timeout prima di ripiegare.
• Il servizio Windows DNS Client è fermo oppure la sua cache è corrotta.
• Un malware o un'app indesiderata ha cambiato il resolver con un indirizzo che controlla, che poi scompare.
• La rete richiede un accesso tramite captive portal che non è ancora avvenuto, quindi ogni DNS in uscita viene inghiottito.

Come risolverlo

Capisci prima se la rete stessa è attiva, prima di toccare le impostazioni DNS. ping 1.1.1.1 non usa alcuna risoluzione dei nomi. Se fallisce anche questo, hai un problema di connettività, non un problema DNS. Se ha successo mentre ping example.com fallisce, il DNS è confermato come la parte rotta e si applicano i passaggi seguenti.

Windows

1. Svuota la cache e riavvia il servizio client:

   ipconfig /flushdns
   net stop dnscache
   net start dnscache

2. Guarda cosa sta usando il tuo adattatore: ipconfig /all | findstr /C:"DNS Servers"
3. Imposta invece un resolver pubblico: netsh interface ipv4 set dnsservers name="Wi-Fi" static 1.1.1.1 primary
4. Testa direttamente quello specifico server: nslookup example.com 1.1.1.1
5. Ripristina lo stack se nulla funziona, poi riavvia:

   netsh int ip reset
   netsh winsock reset

6. Deseleziona IPv6 sull'adattatore se la macchina non ha IPv6 funzionante, poi ritesta.

macOS

1. Svuota la cache: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
2. Leggi i resolver in uso: scutil --dns | grep nameserver
3. Sostituiscili: sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1
4. Torna a quello che distribuisce il DHCP: sudo networksetup -setdnsservers Wi-Fi empty

Linux

1. Controlla lo stato e svuota: resolvectl status, poi sudo resolvectl flush-caches
2. Interroga esplicitamente un server per vedere se risponde: dig @1.1.1.1 example.com +short
3. Cambia il resolver sulla connessione invece di modificare /etc/resolv.conf, che di solito è generato:

   nmcli con mod "Wired connection 1" ipv4.dns "1.1.1.1 1.0.0.1"
   nmcli con mod "Wired connection 1" ipv4.ignore-auto-dns yes
   nmcli con up "Wired connection 1"

4. Riavvia il resolver stub se è bloccato: sudo systemctl restart systemd-resolved

Router

1. Spegnilo e riaccendilo, e aspetta che il collegamento WAN torni attivo prima di testare.
2. Nella pagina di amministrazione, imposta i server DNS WAN su una coppia pubblica invece di "ottieni automaticamente" se il sospetto è il resolver del provider.
3. Aggiorna il firmware. I bug del forwarder DNS sono un motivo comune per cui un router va riavviato ogni poche settimane.
4. Escludilo come test: collega un telefono ai dati mobili e risolvi lo stesso nome. Se funziona lì, il guasto si restringe alla tua rete.

Browser

1. Chrome, Edge e Firefox possono inviare DNS su HTTPS a un proprio fornitore, indipendentemente dalle impostazioni di sistema. Se il browser fallisce mentre dig ha successo, disattiva il DNS sicuro nelle impostazioni sulla privacy del browser e ritesta.
2. Svuota la cache interna di Chrome su chrome://net-internals/#dns.

Quando la ricerca è lenta invece che rotta

Non ogni lamentela sul DNS è un guasto. Se le pagine alla fine si caricano ma si bloccano per un secondo o due prima che succeda qualcosa, il resolver sta rispondendo, solo in ritardo, e le correzioni sopra non cambieranno molto. Misuralo prima di indovinare:

dig example.com | grep "Query time"
dig @1.1.1.1 example.com | grep "Query time"

Qualsiasi valore a una o due cifre di millisecondi da una cache calda è normale. Diverse centinaia di millisecondi, o una cifra che cambia in modo selvaggio tra le esecuzioni, significa che il resolver è lontano, sovraccarico, oppure va in timeout sul suo primo server e ripiega su un secondo. Questa è una diagnosi diversa con correzioni diverse, illustrata in come risolvere una ricerca DNS lenta.

Controllalo dall'esterno

Tutto finora presuppone che il guasto sia vicino a te, il che di solito è vero. Confermalo prima di passarci un pomeriggio. Chiedi a un resolver che non ha nulla a che fare con la tua rete se il nome si risolve:

dig @8.8.8.8 example.com +short
dig @9.9.9.9 example.com +short
nslookup example.com 1.1.1.1

Una risposta da questi mentre il tuo resolver resta in silenzio dimostra che il dominio è a posto e il problema è dal tuo lato. Il silenzio da tutti loro sposta l'attenzione sui nameserver del dominio stesso, che potrebbero essere giù o irraggiungibili da parte di internet.

La raggiungibilità di un nameserver non è globale. Esegui il controllo di interrogazione DNS per inviare la stessa ricerca da postazioni in paesi diversi e confrontare le risposte affiancate. Quando alcune ubicazioni ottengono un risultato e altre vanno in timeout, stai osservando un problema di instradamento o di provider che riguarda una regione, non un record rotto, e nessuna quantità di svuotamenti sul tuo portatile te lo mostrerà.

Quando il tuo stesso nameserver ammutolisce

Un nameserver che ammutolisce mette giù un sito con la stessa completezza di un web server morto, e lo fa senza produrre una sola riga nel tuo log di accesso. Nessuno ti raggiunge per dirtelo, perché non può raggiungerti affatto. HostTracker esegue controlli pianificati da oltre 300 postazioni in 158 città su 13 tipi di monitor, così che un nome che smette di risolversi in una regione venga individuato dalle postazioni lì invece che da un'email di un cliente. Il resto di questa sezione è nel cluster risolvere, e se la domanda è se una recente modifica DNS ha raggiunto tutti, quella è come verificare la propagazione DNS.