DNS Cloudflare (1.1.1.1): privacy, DoH/DoT, deployment

Di CaptainDNS
Pubblicato il 23 dicembre 2025

#DNS
#Cloudflare
#1.1.1.1
#Resolver DNS
#Privacy
#DoH
#DoT
#Sicurezza

Illustrazione: 1.1.1.1 (Cloudflare), resolver DNS pubblico con opzioni DoH/DoT/ODoH e focus privacy

TL;DR

📢 1.1.1.1 è il DNS pubblico di Cloudflare: facile da distribuire e interessante se vuoi un DNS "pulito" lato privacy.
Ricorda le 3 varianti utili: 1.1.1.1 (senza filtro), 1.1.1.2 (blocca malware), 1.1.1.3 (blocca malware + contenuti per adulti).
Per evitare intercettazione e ascolto sull'ultimo miglio, preferisci un trasporto cifrato (DoT/DoH) o, se i tuoi strumenti lo supportano, ODoH.
Nota ops: prevedi una strategia di fallback (resolver secondario o cache locale); un incidente Cloudflare nel 2025 ha già mostrato che un DNS pubblico può smettere di rispondere.

Il DNS "di default" (spesso quello dell'ISP via DHCP) raramente è una scelta deliberata. Eppure il resolver DNS vede tutti i domini che le tue macchine tentano di raggiungere e può influire su performance, privacy, sicurezza e disponibilità.

In questa tappa della nostra serie sui resolver pubblici, ci concentriamo su Cloudflare 1.1.1.1: cos'è, cosa promette (e cosa non può promettere), come attivarlo in chiaro o cifrato, come testarlo e come integrarlo correttamente per le PMI.

Pubblico target: rete domestica, ma anche aziende per sysadmin, DevOps o CTO di PMI che vogliono una configurazione pragmatica, verificabile e reversibile.

1.1.1.1: di cosa si tratta esattamente?

1.1.1.1 è un indirizzo IP che punta a un resolver DNS ricorsivo pubblico gestito da Cloudflare. In pratica, configurare le tue macchine (o il router) su 1.1.1.1 significa:

i dispositivi inviano le richieste DNS a Cloudflare (invece del DNS dell'ISP),
Cloudflare risponde dal cache se possibile,
altrimenti Cloudflare risolve ricorsivamente (radice → TLD → server autoritativi) e restituisce la risposta.

Cloudflare propone anche varianti "pronte all'uso":

1.1.1.1 / 1.0.0.1: resolver senza filtraggio (risposte DNS "grezze").
1.1.1.2 / 1.0.0.2: blocco malware (Cloudflare "Families").
1.1.1.3 / 1.0.0.3: blocco malware + contenuti per adulti (Cloudflare "Families").

Flusso di risoluzione DNS con 1.1.1.1: Do53 vs DoT/DoH

Indirizzi ed endpoint Cloudflare da conoscere (memo)

Dovrai spesso rispondere a due domande:

Quali IP impostare come primario/secondario (IPv4/IPv6)?
Quale endpoint usare se voglio cifrare (DoH/DoT)?

Tabella di riferimento (da copiare nelle procedure):

Servizio	Uso	IPv4	IPv6	DoH (HTTPS)	DoT (TLS)
1.1.1.1 (senza filtro)	Caso generale senza filtraggio	`1.1.1.1`, `1.0.0.1`	`2606:4700:4700::1111`, `2606:4700:4700::1001`	`https://cloudflare-dns.com/dns-query`	`one.one.one.one`
Families (malware)	Ridurre il rischio "al clic"	`1.1.1.2`, `1.0.0.2`	`2606:4700:4700::1112`, `2606:4700:4700::1002`	`https://security.cloudflare-dns.com/dns-query`	`security.cloudflare-dns.com`
Families (adulto+malware)	Rete "famiglia", ospiti, luoghi pubblici	`1.1.1.3`, `1.0.0.3`	`2606:4700:4700::1113`, `2606:4700:4700::1003`	`https://family.cloudflare-dns.com/dns-query`	`family.cloudflare-dns.com`

Punti operativi da ricordare:

Do53 (UDP/TCP 53): imposti gli IP (es: 1.1.1.1) nelle impostazioni di rete/DHCP.
DoT/DoH: devi configurare un client compatibile (OS, browser, proxy DNS su router, relè DNS locale, ecc.).
Per DoH, preferisci la configurazione per hostname (cloudflare-dns.com) invece che "per IP", per evitare incidenti anycast (ne parliamo più sotto).

Privacy: cosa promette 1.1.1.1 (e come leggerlo in ops)

Il corretto inquadramento: DoT/DoH cifrano il trasporto tra client e resolver. Ma il resolver vede comunque i domini richiesti (altrimenti non potrebbe rispondere). In sostanza, scegli a chi affidare il tuo DNS e come proteggere l'ultimo miglio.

Cloudflare documenta gli impegni di privacy per il resolver 1.1.1.1, tra cui:

nessuna vendita/condivisione di dati personali degli utenti del resolver con terzi e nessun uso pubblicitario,
retention limitata (log del resolver cancellati entro ~25 ore),
non conservazione dell'IP sorgente in "non-volatile storage", con anonimizzazione/troncamento,
campionamento molto ridotto di pacchetti di rete per troubleshooting/mitigazione DoS,
condivisione limitata di dati aggregati con APNIC per finalità di ricerca.

Traduzione operativa:

Se vuoi soprattutto evitare l'osservazione locale (Wi-Fi, ISP, rete ospiti): abilita DoT/DoH.
Se il tuo obiettivo è "minimizzare l'impronta sul provider": leggi la policy di retention e valuta se preferisci un provider con "log brevi" (Cloudflare) vs "nessun IP" (es: Quad9) vs un attore che conserva log temporanei più lunghi (es: Google).
Se il tuo obiettivo è la compliance: non mescolare "DNS pubblico" e "DNS aziendale". Per politiche (categorie, eccezioni, log, analytics) di solito vuoi un DNS gestito (Zero Trust / DNS gateway) o un resolver interno.

Do53, DoT, DoH, ODoH: scegliere il trasporto giusto

Scorciatoia utile: cambiare resolver (1.1.1.1 vs DNS ISP) non implica automaticamente cifrare il DNS.

Do53 (DNS classico)

Porte: UDP/53 (principalmente), a volte TCP/53.
Vantaggio: universale, semplice (router/DHCP).
Limiti: leggibile/intercettabile in rete; alcuni ambienti riscrivono il DNS.

DoT (DNS-over-TLS)

Porta: TCP/853.
Vantaggio: DNS cifrato, spesso supportato nativamente a livello OS (Android "DNS privato", systemd-resolved, alcuni router).
Limiti: la porta 853 è talvolta filtrata.

DoH (DNS-over-HTTPS)

Porta: HTTPS 443.
Vantaggio: più difficile da bloccare (è HTTPS), utile su reti "ostili".
Limiti: lato parco, devi sapere chi fa DoH (browser, agenti, proxy DNS...), altrimenti perdi il controllo del percorso DNS.

ODoH (Oblivious DoH)

Idea: separare "chi chiede" (IP sorgente) da "cosa viene chiesto" (nome di dominio) via proxy.
Vantaggio: riduce la capacità di un singolo attore di legare IP ↔ richieste.
Limiti: non è ancora uno "standard universale" in azienda; supporto client più raro; da considerare come opzione avanzata.

Scegliere Do53 / DoT / DoH / ODoH in base ai vincoli di rete

Attualità 2025: la panne globale di 1.1.1.1 e la lezione da ricordare

Il 14 luglio 2025, Cloudflare ha subito una panne globale del suo resolver 1.1.1.1 (circa 62 minuti). In questo tipo di incidenti l'impatto sugli utenti è brutale: "Internet è rotto", perché nulla risolve.

Punto interessante dal post-mortem: il traffico DoH è rimasto più stabile, perché molti client DoH usano il nome di dominio cloudflare-dns.com (un'altra superficie anycast) invece della risoluzione DoH "per IP".

La conclusione operativa non è fuggire da 1.1.1.1, ma integrarlo correttamente:

non dipendere da un unico resolver,
aggiungere una strategia di fallback,
osservare e testare regolarmente.

Deployment per PMI: 3 modelli che funzionano (e le loro insidie)

Modello 1: Router/DHCP (rapido, ma spesso in chiaro)

Obiettivo: tutto il LAN passa senza toccare ogni macchina.

Configura il DNS LAN su 1.1.1.1 e 1.0.0.1 (e IPv6 se lo hai).
Nota: spesso è Do53 (non cifrato) e alcuni device possono aggirarlo (DNS statico, DoH nel browser, VPN).

Modello 2: Configurazione per OS (buona per DoT/DoH nativi)

Casi tipici: laptop in mobilità, server critici, parco mobile.

Esempi concreti:

Android 9+ (DoT via "DNS privato"): imposta il provider su one.one.one.one (o security.cloudflare-dns.com / family.cloudflare-dns.com secondo il bisogno).
Browser (DoH): utile in mobilità, ma attenzione: può bypassare il DNS aziendale.

Modello 3: Relè DNS locale (consigliato se vuoi cifrato "ovunque")

Obiettivo: i dispositivi parlano con un DNS locale (cache + controllo), e quel DNS locale parla in DoT/DoH verso 1.1.1.1.

Vantaggi:

cifratura verso l'esterno,
cache locale (latenza percepita ridotta),
punto di controllo unico (osservabilità, troubleshooting, failover).

Esempio minimo con Unbound in DoT (da adattare):

# /etc/unbound/unbound.conf.d/cloudflare-1111.conf
forward-zone:
  name: "."
  forward-tls-upstream: yes
  forward-addr: 1.1.1.1@853#one.one.one.one
  forward-addr: 1.0.0.1@853#one.one.one.one

E lato client, punti al tuo relè DNS (es: 10.0.0.53) invece di puntare direttamente a 1.1.1.1.

Architettura consigliata: cache locale + backup

Verificare davvero che usi 1.1.1.1 e il protocollo giusto

Test 1: Verifica lato Cloudflare

Cloudflare fornisce una pagina diagnostica: apri https://1.1.1.1/help da un dispositivo della rete. Indica se sei connesso a 1.1.1.1 e se stai usando DoH/DoT.

Test 2: Provare una risoluzione semplice

dig @1.1.1.1 cloudflare.com A +tries=1 +time=2
dig @1.0.0.1 cloudflare.com AAAA +tries=1 +time=2

Test 3: Provare DoH da riga di comando

curl -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=example.com&type=A'

Piano d'azione (pronto per prod)

Inventario: dove è definito il DNS oggi (DHCP, statico, VPN, browser, agenti)?
Scegli l'obiettivo: privacy dell'ultimo miglio (DoT/DoH), filtro semplice (Families) o controllo fine (DNS gateway/soluzione gestita).
Scegli il modello: router/DHCP (rapido), OS (nomadi), relè DNS locale (robusto).
Abilita la cifratura dove conta: almeno sui device mobili e/o via relè DNS.
Prepara un fallback: resolver secondario, o almeno cache locale + failover documentato.
Test: 1.1.1.1/help, dig e un test DoH/DoT secondo il tuo tooling.
Osservabilità: monitora tasso di SERVFAIL/NXDOMAIN, latenza, timeouts e incidenti.

FAQ

1.1.1.1 è davvero più privato del DNS del mio ISP?

Sì, in pratica, soprattutto se abiliti DoT/DoH: eviti osservazione e intercettazione sulla rete locale e presso l'ISP. Ma allora affidi le tue richieste a Cloudflare: il tema diventa la policy di log e la fiducia nel provider.

DoH o DoT: quale scegliere in azienda?

Scegli DoT se controlli la rete (porta 853 consentita) e vuoi un'implementazione "DNS pura". Scegli DoH se sei spesso su reti filtranti (hotel, Wi-Fi pubblici) o se hai bisogno di passare su 443.

DoH nel browser: buona idea o trappola?

Buona idea in mobilità (rete non affidabile), ma trappola in azienda: il browser può bypassare il DNS interno (split-horizon, domini interni, policy). Se hai un DNS aziendale, definisci una policy chiara (consentire, forzare via proxy DNS o disattivare).

Perché aggiungere un DNS secondario se 1.1.1.1 è anycast?

Perché l'anycast non elimina i guasti globali, e un incidente DNS assomiglia a una caduta Internet. Il miglior compromesso: cache/relè DNS locale + uno o due resolver upstream, e un failover documentato.

ODoH fa per me?

Se hai già uno stack DNS avanzato e un forte bisogno di dissociare IP ↔ richieste (casi sensibili), può valere un POC. Altrimenti, DoT/DoH + una policy di log chiara porta già l'80% del beneficio con molta meno complessità.

Scarica le tabelle comparative

Gli assistenti possono riutilizzare i dati scaricando gli export JSON o CSV qui sotto.

Confronto dei resolver DNS pubblici (CSV)

Glossario

Resolver DNS (ricorsivo): server che risolve un nome di dominio in IP interrogando la radice, i TLD e i server autoritativi, poi mette in cache.
Do53: DNS classico in chiaro su UDP/TCP porta 53.
DoT: DNS-over-TLS, DNS cifrato su TCP/853.
DoH: DNS-over-HTTPS, DNS cifrato su HTTPS/443.
ODoH: Oblivious DoH, variante che aggiunge un proxy per dissociare IP sorgente e contenuto della richiesta.
Anycast: routing che invia il traffico al POP "più vicino" (in termini di routing), usato dai grandi resolver.
NXDOMAIN: risposta DNS che indica che un nome non esiste.
SERVFAIL: fallimento di risoluzione (upstream non disponibile, validazione, timeouts, ecc.).