1 14/04/2026 9 min

Se vuoi usare 1.1.1.1 come DNS su Windows 11 o Windows 10, la modifica si fa in pochi minuti e non richiede strumenti particolari. La parte delicata non è cliccare il punto giusto, ma capire quale interfaccia stai cambiando, come verificare che il resolver sia davvero in uso e come tornare indietro senza lasciare la macchina in uno stato ambiguo.

Qui sotto trovi la procedura pulita per rete Ethernet e Wi-Fi, più i controlli per capire se il sistema sta usando il DNS Cloudflare, se c’è un override del router o se stai lavorando dentro un ambiente aziendale con policy che sovrascrivono tutto.

Quando ha senso impostare 1.1.1.1 su Windows

1.1.1.1 è un resolver pubblico molto usato per ridurre la dipendenza dai DNS del provider, migliorare la consistenza delle risposte e avere un comportamento generalmente prevedibile. Non risolve problemi di connettività di base, non accelera magicamente la linea e non bypassa eventuali blocchi di rete a monte. Se il problema è il link verso Internet, il DNS è solo uno dei livelli da controllare.

In pratica, ha senso quando vuoi: sostituire i DNS del router, evitare resolver lenti o instabili, uniformare la configurazione tra PC diversi o testare se un problema è legato alla risoluzione dei nomi. Se invece sei in dominio Active Directory o in una rete gestita, prima verifica che non ci siano policy di gruppo o profili MDM che riscrivono i DNS a intervalli regolari.

Indirizzi DNS da usare

Per una configurazione base IPv4, usa questi due indirizzi:

DNS preferito: 1.1.1.1
DNS alternativo: 1.0.0.1

Se vuoi configurare anche IPv6, gli equivalenti sono:

DNS preferito IPv6: 2606:4700:4700::1111
DNS alternativo IPv6: 2606:4700:4700::1001

Se la tua rete non usa IPv6 in modo corretto, evitare di inserire indirizzi IPv6 a caso è una scelta sensata: un set IPv6 sbagliato può introdurre timeout o comportamenti strani nella risoluzione. Se non sei sicuro, configura prima l’IPv4 e verifica il risultato, poi passa all’IPv6.

Metodo grafico su Windows 11

Su Windows 11 il percorso più semplice passa dalle impostazioni di rete dell’interfaccia attiva. Il nome delle voci può cambiare leggermente tra build diverse, ma il flusso è quello.

  1. Apri Impostazioni.
  2. Vai su Rete e Internet.
  3. Seleziona Wi-Fi oppure Ethernet, in base alla connessione che usi.
  4. Clicca sulla rete o sulla scheda attiva.
  5. Trova Assegnazione server DNS e premi Modifica.
  6. Imposta il tipo su Manuale.
  7. Attiva IPv4 se vuoi cambiare i DNS IPv4.
  8. Inserisci 1.1.1.1 nel DNS preferito e 1.0.0.1 nel DNS alternativo.
  9. Salva con OK o Salva.

Se usi anche IPv6, attiva il relativo interruttore e inserisci gli indirizzi IPv6 di Cloudflare. In molte reti domestiche basta IPv4; su reti moderne con dual stack conviene testare entrambi, ma solo dopo aver verificato che l’IPv6 sia realmente operativo.

Un dettaglio pratico: Windows può mantenere una cache DNS locale. Dopo la modifica, la navigazione potrebbe sembrare identica per qualche secondo anche se il resolver è cambiato. Per evitare falsi positivi, svuota la cache o apri una nuova sessione di test.

Metodo grafico su Windows 10

Su Windows 10 il percorso è molto simile, ma spesso il punto di ingresso è il Pannello di controllo o la pagina classica delle proprietà dell’adattatore. È ancora il metodo più lineare quando vuoi modificare un singolo profilo di rete senza toccare il resto del sistema.

  1. Apri Pannello di controllo.
  2. Vai su Rete e Internet e poi su Centro connessioni di rete e condivisione.
  3. Clicca Modifica impostazioni scheda.
  4. Fai doppio clic sulla connessione attiva, ad esempio Ethernet o Wi-Fi.
  5. Apri Proprietà.
  6. Seleziona Protocollo Internet versione 4 (TCP/IPv4) e clicca Proprietà.
  7. Attiva Utilizza i seguenti indirizzi server DNS.
  8. Inserisci 1.1.1.1 e 1.0.0.1.
  9. Conferma con OK fino a chiudere tutte le finestre.

Se vuoi configurare anche IPv6, nella stessa finestra ripeti il passaggio sul protocollo IPv6. Su Windows 10 il percorso classico resta utile anche quando l’interfaccia moderna di Windows 11 non è disponibile o quando devi dare istruzioni a un parco macchine misto.

Verifica da terminale: controllare che il DNS sia davvero cambiato

La verifica è la parte che evita i classici “l’ho impostato ma non funziona”. Su Windows puoi controllare la configurazione attiva e la cache con pochi comandi PowerShell o Prompt dei comandi.

Per vedere i DNS assegnati all’interfaccia:

ipconfig /all

Cerca la scheda di rete attiva e la riga Server DNS. Se la modifica è andata a buon fine, dovresti vedere 1.1.1.1 e 1.0.0.1 per IPv4, oppure gli equivalenti IPv6 se li hai configurati.

Per svuotare la cache DNS locale e forzare nuove query:

ipconfig /flushdns

Per interrogare esplicitamente il resolver e capire se risponde:

nslookup example.com 1.1.1.1

Se il comando restituisce un indirizzo IP e tempi di risposta normali, il resolver è raggiungibile. Se invece vedi timeout, risposte incoerenti o un server diverso da quello impostato, il problema potrebbe essere a livello di rete, di policy locale o di NAT del router che intercetta le query.

Su PowerShell puoi controllare i DNS della scheda con un comando più leggibile:

Get-DnsClientServerAddress | Select-Object InterfaceAlias, AddressFamily, ServerAddresses

Qui l’attenzione va all’InterfaceAlias: se hai più schede, VPN o virtual adapter, potresti avere configurato la scheda sbagliata. È un errore comune quando si lavora su laptop con Wi-Fi, Ethernet e client VPN attivi nello stesso momento.

Configurazione via PowerShell: utile per test e automazione

Se devi applicare la modifica in modo ripetibile, PowerShell è più affidabile del click-through. Ti serve soprattutto quando vuoi allineare più PC o quando devi fare troubleshooting con un rollback immediato.

Prima individua il nome esatto dell’interfaccia:

Get-NetAdapter

Poi imposta i DNS IPv4 sulla scheda corretta:

Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses 1.1.1.1,1.0.0.1

Se l’interfaccia si chiama diversamente, sostituisci Wi-Fi con il nome reale. Questo è il punto dove molti sbagliano: il nome visualizzato può essere diverso da macchina a macchina, quindi non copiare il comando alla cieca.

Per verificare l’effetto della modifica:

Get-DnsClientServerAddress -InterfaceAlias "Wi-Fi"

Se vuoi tornare ai DNS automatici del router o del DHCP, il rollback è altrettanto semplice:

Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ResetServerAddresses

Questo è il modo più pulito per fare test controllati: applichi, verifichi con nslookup o Get-DnsClientServerAddress, poi rollback se il comportamento non è quello atteso.

IPv4, IPv6 e ordine di priorità

Windows può avere impostazioni DNS separate per IPv4 e IPv6. In una rete dual stack, il sistema può preferire l’una o l’altra famiglia in base alla risposta del percorso, del sito e della reachability. Se cambi solo IPv4 ma lasci IPv6 puntare altrove, potresti vedere risultati incoerenti: alcune query passeranno da 1.1.1.1, altre da un resolver diverso.

Per questo, quando fai troubleshooting serio, conviene controllare entrambe le famiglie. Se non hai IPv6 end-to-end, meglio disabilitare temporaneamente il test su quella famiglia o lasciarla invariata fino a quando non hai evidenza che sia in uso. Non c’è nessun vantaggio nel complicare il quadro se il tuo obiettivo è solo stabilizzare la risoluzione dei nomi su IPv4.

Quando il DNS sembra cambiato ma non lo è

Ci sono tre casi tipici in cui la modifica sembra inutile:

  • Il browser usa un resolver interno o Secure DNS / DoH configurato altrove.
  • Il router distribuisce DNS diversi via DHCP e la scheda sta ancora usando quei valori.
  • Una VPN o una policy aziendale sovrascrive la configurazione locale.

Il modo più rapido per distinguere questi casi è confrontare tre punti: configurazione della scheda, risposta di nslookup e comportamento reale del browser. Se nslookup verso 1.1.1.1 funziona ma il browser continua a usare un altro resolver, il problema è probabilmente nel livello applicativo o nel profilo DoH del browser, non nel DNS di Windows.

Su Chrome, Edge e Firefox può esserci un DNS sicuro attivo. In quel caso la risoluzione può ignorare in parte il resolver impostato a livello OS. Non è un errore di Windows: è proprio un layer diverso. Se stai facendo test di rete, conviene disattivarlo temporaneamente o sapere esattamente quale resolver sta usando il browser.

Controllo del router: il punto che molti saltano

Se la rete domestica distribuisce DNS del provider o del router, la modifica sul PC dovrebbe comunque prevalere se hai impostato i server manuali sulla scheda. Però alcuni router, soprattutto in scenari con DHCP particolare o captive portal, possono interferire. Se il risultato non torna, entra nel pannello del router e verifica se la LAN distribuisce DNS custom, se c’è una funzione di parental control o se la rete guest applica policy diverse.

In un contesto di troubleshooting, la regola è semplice: prima conferma il DNS lato client, poi controlla il router, poi il browser. Saltare direttamente alle ipotesi sulla macchina Windows porta spesso a perdere tempo su un problema che è altrove.

Verifica funzionale: non basta vedere l’IP del resolver

Vedere 1.1.1.1 in ipconfig /all non basta. La verifica utile è una query reale e una navigazione minima. Un buon controllo pratico è questo:

nslookup microsoft.com 1.1.1.1

Se ricevi una risposta con indirizzi e tempi coerenti, passa a un test applicativo: apri un sito che non hai già in cache oppure usa un browser in finestra privata. Se il problema era un DNS lento o instabile, dovresti notare meno attese in apertura e meno errori di risoluzione intermittenti.

Se invece il sito continua a non risolversi, il DNS non è il colpevole principale. A quel punto il controllo va spostato su connettività, gateway, proxy, firewall locale o blocchi lato rete. Cambiare DNS non risolve un link fisicamente assente.

Rollback pulito: tornare ai DNS automatici

Il rollback dovrebbe essere sempre disponibile quando tocchi la connettività. Su GUI basta rientrare nelle proprietà della scheda e ripristinare l’assegnazione automatica dei server DNS. Su PowerShell il comando più diretto è quello già visto con -ResetServerAddresses.

Se vuoi verificare che il ritorno all’automatico sia andato a buon fine, usa di nuovo:

Get-DnsClientServerAddress | Select-Object InterfaceAlias, AddressFamily, ServerAddresses

Quando il DHCP è la sorgente attesa, i server DNS visualizzati dovrebbero tornare a quelli distribuiti dal router o dal server di rete. Se invece restano indirizzi statici, c’è ancora una configurazione locale o una policy che sta imponendo il valore.

Note operative per chi gestisce più PC

In ambienti con più workstation conviene standardizzare il metodo: o tutto via policy, o tutto via script, o tutto via configurazione manuale documentata. Mischiare GUI, DHCP e profili VPN senza una traccia chiara produce differenze difficili da diagnosticare. Se il tuo obiettivo è uniformità, PowerShell con controllo dell’interfaccia è il punto di partenza più solido.

Se invece vuoi fare una prova rapida su una sola macchina, la GUI resta la strada più semplice. L’importante è annotare sempre quale scheda hai toccato, perché su notebook moderni il nome della connessione può cambiare in base a docking station, Wi-Fi e adattatori virtuali.

In sintesi: imposta 1.1.1.1 e 1.0.0.1 sulla scheda corretta, svuota la cache, verifica con nslookup e controlla che nessun layer superiore stia annullando la modifica. È una procedura semplice solo se la misuri bene; altrimenti rischi di inseguire un falso problema di DNS mentre il guasto è altrove.