DNS_PROBE_FINISHED_BAD_CONFIG: cause e soluzioni

In breve: DNS_PROBE_FINISHED_BAD_CONFIG indica che Chrome non riesce a completare la risoluzione DNS con la configurazione disponibile. Verifica se l’errore riguarda un solo browser, un dispositivo, tutta la rete o un solo dominio; poi confronta resolver, DHCP, VPN, proxy, record autorevoli e DNSSEC. Cambiare DNS o svuotare cache è utile solo dopo aver localizzato il livello difettoso.

DNS_PROBE_FINISHED_BAD_CONFIG: che cosa indica

Prima di aprire un sito, il dispositivo deve tradurre il nome del dominio in un indirizzo IP. Chrome mostra questo codice quando la configurazione DNS o di rete non consente una risposta utilizzabile. Il browser non stabilisce automaticamente se la colpa sia del computer, del router, del resolver o della zona del dominio.

L’errore è diverso da un codice HTTP: la richiesta può non aver ancora raggiunto il web server. Per questo controllare plugin WordPress, cache della pagina o certificato TLS non è il primo passo, salvo che una verifica DNS dimostri che il nome risolve correttamente.

Definire l’ambito

Annota orario, rete e dominio esatto, compreso l’eventuale sottodominio. Provare contemporaneamente da browser diversi e da una rete esterna produce una baseline più utile di una sequenza di modifiche non documentate.

Confrontare resolver e risposte

Usa nslookup su Windows oppure dig su macOS/Linux per confrontare il resolver configurato con uno pubblico. Le prove sono di lettura e non modificano il DNS.

# macOS o Linux
dig esempio.it A
dig @8.8.8.8 esempio.it A
dig @8.8.8.8 esempio.it A +dnssec

# Windows
nslookup esempio.it
nslookup esempio.it 8.8.8.8

Registra status, Answer, server interrogato e tempi. NXDOMAIN significa che il nome non esiste secondo la risposta ricevuta; SERVFAIL segnala che il resolver non ha potuto completare la risoluzione, spesso per problemi di delega, server autorevoli o validazione DNSSEC; un timeout indica assenza di risposta o blocco del percorso.

Controllare DHCP, VPN, proxy e router

1. Verifica quali server DNS il dispositivo ha ricevuto via DHCP e che gli indirizzi siano sintatticamente validi.
2. Disattiva temporaneamente una VPN o un proxy soltanto per un confronto controllato; non lasciare disabilitate protezioni aziendali senza autorizzazione.
3. Controlla se il router risponde come resolver locale e se riesce a raggiungere il resolver upstream.
4. Rinnova la configurazione DHCP solo dopo averne annotato i valori correnti.
5. Prova rete cablata e Wi-Fi oppure una rete mobile per separare dispositivo e infrastruttura.

Portali captive, filtri parentali, software di sicurezza e malware possono intercettare le query. Se dns.google nel browser funziona ma le query dirette verso 8.8.8.8 non raggiungono il server previsto, la rete può bloccare o deviare UDP/TCP 53.

Controllare record, delega e DNSSEC

Se fallisce un solo dominio da reti e resolver differenti, esamina la catena autorevole: nameserver pubblicati dal registro, record NS della zona, record A/AAAA o CNAME e coerenza delle risposte tra tutti i server. Dopo un cambio DNS, seriali SOA differenti possono indicare server non allineati.

Con DNSSEC attivo, un record DS al registro deve corrispondere alle chiavi e alle firme correnti. Se la risposta riesce soltanto senza validazione, non disabilitare definitivamente DNSSEC come scorciatoia: correggi DS, DNSKEY, firme o scadenze, poi verifica da più resolver validanti.

Pulire cache solo quando serve

Dopo aver corretto il resolver o la zona, svuota la cache del browser e quella DNS del sistema operativo; riavvia il servizio di rete o il router soltanto se il livello interessato conserva la risposta. La cache autorevole e quella dei resolver rispettano il TTL e non vengono eliminate dal comando locale.

• Chiudi e riapri Chrome oppure usa una finestra pulita per il test.
• Su Windows usa ipconfig /flushdns in un prompt con i permessi previsti.
• Su macOS e Linux il comando varia per versione e resolver; verifica il servizio effettivamente attivo.
• Ripeti dig o nslookup e confronta la risposta, invece di valutare solo il caricamento della pagina.

Verificare la soluzione

• Il resolver configurato risponde con status coerente e indirizzo previsto.
• Resolver pubblici e server autorevoli non mostrano deleghe o seriali discordanti.
• La validazione DNSSEC riesce quando è prevista.
• Il sito funziona da almeno due reti e non soltanto dalla cache del browser.
• Dopo la scadenza del TTL non ricompare la risposta precedente.

Errori da evitare

• Cambiare subito record del dominio quando l’errore riguarda un solo dispositivo.
• Impostare resolver casuali senza annotare la configurazione DHCP originale.
• Confondere un timeout DNS con un errore HTTP del sito.
• Svuotare tutte le cache prima di salvare le risposte utili alla diagnosi.
• Disabilitare DNSSEC in modo permanente senza correggere la catena di fiducia.

Guide Xlogic correlate

• Errori DNS più comuni: come diagnosticarli e risolverli

Domande frequenti

Conclusione

DNS_PROBE_FINISHED_BAD_CONFIG si risolve più rapidamente restringendo l’ambito: browser, dispositivo, rete, resolver o dominio. Le risposte DNS confrontabili forniscono la prova; pulizia cache e cambio resolver diventano così interventi mirati e verificabili.

Fonti tecniche

• Google Public DNS — Troubleshooting