Cloudflare Internal DNS è disponibile in versione generale dal 20 luglio 2026 e porta la risoluzione dei nomi privati nello stesso piano di controllo già utilizzato per DNS pubblico, networking e servizi Zero Trust. Per un’azienda con più sedi, utenti remoti e applicazioni distribuite tra data center e cloud, la novità può ridurre la frammentazione tipica dei sistemi DNS interni.
Non significa però che sia prudente spegnere subito i server DNS esistenti. Il DNS è una dipendenza critica: un errore su zone, viste o policy può rendere irraggiungibili applicazioni perfettamente funzionanti. La valutazione deve quindi partire dall’architettura reale, soprattutto quando sono presenti Active Directory, DHCP dinamico, VPN, reti industriali o applicazioni legacy.
Che cos’è Cloudflare Internal DNS
Il servizio combina due componenti distinti:
- Gateway Resolver, che riceve le richieste DNS, applica le policy e decide verso quale sorgente indirizzarle;
- Internal Authoritative DNS, che conserva e risponde per le zone e i record privati gestiti sulla piattaforma.
Cloudflare introduce inoltre tre oggetti operativi: le Internal Zones, che contengono i record delle risorse private; le DNS Views, che definiscono quale versione delle zone debba vedere un gruppo di utenti o dispositivi; e le Resolver Policies, che associano le richieste alla vista corretta.
In pratica, la stessa risorsa può avere risposte diverse a seconda del contesto. Un dipendente collegato dalla sede può risolvere gestionale.azienda.it verso un indirizzo privato, mentre un utente esterno riceve la risposta pubblica oppure nessuna risposta. È il principio dello split-horizon DNS, gestito senza mantenere copie manuali non sincronizzate della stessa configurazione.
Perché il DNS interno diventa difficile nelle aziende ibride
Una piccola infrastruttura parte spesso con un paio di server DNS locali. Poi arrivano una seconda sede, il lavoro remoto, Microsoft Azure o AWS, applicazioni SaaS con connettori privati, segmenti IoT e accessi tramite VPN. Ogni ambiente può introdurre un resolver, una zona privata e regole di inoltro differenti.
Il risultato è una catena difficile da documentare: il notebook remoto interroga un resolver della VPN, che inoltra alcune zone verso la sede e altre verso il cloud; la filiale utilizza un DNS locale diverso; il data center mantiene record che nessuno ha aggiornato. Quando una risposta cambia, capire quale sistema l’abbia generata richiede tempo.
Cloudflare dichiara che Internal DNS consente di amministrare DNS pubblico e privato tramite un unico controllo, una sola API e un audit trail comune. Le modifiche possono essere gestite da dashboard, API o Terraform e vengono propagate sulla rete globale del provider.
Come funziona una richiesta DNS
Una query raggiunge il Gateway Resolver, che valuta le policy configurate. Da quel punto può accadere una di tre cose:
- una regola associa la richiesta a una vista interna e la risposta arriva dalla relativa Internal Zone;
- una policy blocca la richiesta;
- nessuna regola interna corrisponde e la risoluzione continua sul percorso pubblico.
Le viste possono prevedere anche il fallback verso il DNS pubblico quando un nome non esiste nella zona interna. Questa flessibilità è utile, ma richiede test accurati: una configurazione permissiva può nascondere un record privato mancante facendo risolvere per errore l’indirizzo pubblico.
Il punto delicato: Active Directory non è una semplice zona DNS
In un dominio Windows, DNS partecipa direttamente al funzionamento di Active Directory. I record SRV permettono ai client di individuare domain controller e servizi; le zone integrate in AD supportano replica e aggiornamenti dinamici sicuri. Microsoft conferma che i record SRV sono utilizzati per localizzare i controller di dominio e che gli aggiornamenti dinamici protetti sono una caratteristica delle zone integrate in Active Directory.
Per questo non conviene migrare alla cieca la zona del dominio Active Directory verso un servizio autoritativo esterno. Un approccio prudente consiste nel mantenere Windows DNS autorevole per le zone AD e valutare Cloudflare per zone applicative separate, nomi di servizi, sedi o ambienti cloud. L’integrazione può poi essere realizzata tramite policy e inoltri, verificando il percorso di ogni query.
Prima di qualsiasi passaggio vanno censiti almeno record SRV, aggiornamenti DHCP, reverse zone, nomi usati da Group Policy, Kerberos, file server, stampanti, gestionali e applicazioni che dipendono da suffissi DNS specifici.
Connessioni supportate e utenti remoti
Secondo Cloudflare, Internal DNS può ricevere traffico attraverso Cloudflare One Client, precedentemente WARP, DNS over HTTPS, DNS over TLS, DNS tradizionale sulla porta 53, file PAC e Cloudflare WAN. Questo permette di servire utenti remoti, filiali e reti collegate con modalità differenti.
La disponibilità tecnica non sostituisce però la progettazione. Bisogna stabilire quale resolver utilizza ogni segmento, cosa succede quando il client o il tunnel non sono disponibili e se le applicazioni continuano a funzionare durante un’interruzione del collegamento verso il servizio.
Quando può avere senso per una PMI
La soluzione diventa interessante quando l’azienda presenta almeno una di queste condizioni:
- più sedi con DNS locali gestiti separatamente;
- utenti remoti che devono risolvere nomi privati tramite VPN o Zero Trust;
- workload distribuiti tra infrastruttura locale e più cloud;
- split-horizon mantenuto duplicando manualmente record e zone;
- necessità di audit centralizzato delle modifiche DNS;
- appliance DNS legacy prossime alla sostituzione.
Per un ufficio singolo con un dominio Active Directory semplice e nessun carico cloud privato, la migrazione potrebbe invece aggiungere complessità senza un beneficio proporzionato. Cloudflare indica inoltre la disponibilità del servizio per clienti Enterprise che utilizzano Cloudflare Gateway: prima di progettare il passaggio occorre verificare licenze, funzionalità comprese e costi complessivi.
Checklist prima di spostare il DNS privato
- Inventariare le zone, distinguendo dominio Active Directory, applicazioni, reverse zone e record temporanei.
- Mappare i resolver usati da sedi, VLAN, VPN, Wi-Fi ospiti, server e workload cloud.
- Individuare gli aggiornamenti dinamici generati da client Windows, DHCP e sistemi di provisioning.
- Registrare TTL, conditional forwarder e dipendenze prima di cambiare configurazione.
- Separare le zone AD dalle zone applicative che possono essere migrate con minore rischio.
- Definire DNS Views e Resolver Policies per sede, gruppo di dispositivi e tipo di accesso.
- Preparare un ambiente pilota con una zona non critica e un gruppo ristretto di client.
- Testare risoluzione positiva e negativa, fallback pubblico, VPN disconnessa e guasto del collegamento.
- Verificare i log e stabilire chi può modificare zone, viste e policy.
- Automatizzare con API o Terraform soltanto dopo aver validato il processo manuale e le approvazioni.
- Documentare il rollback, conservando configurazioni e resolver precedenti finché il collaudo non è concluso.
- Misurare l’esperienza reale da filiali e utenti remoti, non soltanto dal data center.
Errori da evitare
Spostare tutto in un’unica finestra
Una migrazione “big bang” rende difficile isolare la causa di un problema. È preferibile iniziare da una zona applicativa controllata e ampliare il perimetro progressivamente.
Confondere DNS con accesso alla risorsa
Risolvere correttamente un nome non garantisce che routing, firewall, identità e autorizzazioni permettano di raggiungere il servizio. Il test deve coprire l’intero percorso.
Dimenticare stampanti, NAS e apparati legacy
Molti dispositivi utilizzano DNS assegnati staticamente o non supportano i moderni protocolli cifrati. L’inventario deve comprendere anche endpoint non gestiti centralmente.
Usare la piattaforma come unico piano di emergenza
La centralizzazione semplifica la gestione ma concentra anche una dipendenza. Servono procedure documentate per indisponibilità del client, del tunnel o della connettività Internet.
Cloudflare Internal DNS sostituisce i server locali?
Non necessariamente. Può sostituire alcuni resolver e zone private oppure affiancare DNS esistenti in un modello ibrido. Nelle reti Windows è spesso più realistico conservare il ruolo di Active Directory DNS e spostare gradualmente le zone applicative e multi-sede.
La scelta deve essere coordinata con l’architettura di rete. Gli approfondimenti EP Consulting sul core di rete resiliente e MC-LAG e sui collegamenti privati multicloud mostrano lo stesso principio: centralizzare il controllo è utile soltanto se percorsi, ridondanza e responsabilità restano chiari.
Domande frequenti
Internal DNS è il servizio pubblico 1.1.1.1?
No. Utilizza l’infrastruttura e il Gateway Resolver di Cloudflare, ma gestisce zone e risposte destinate a risorse private secondo viste e policy aziendali.
È disponibile per tutte le versioni di Cloudflare?
Cloudflare dichiara che i clienti Enterprise con Cloudflare Gateway possono accedervi. Licenze e condizioni vanno verificate sul contratto specifico prima di avviare il progetto.
Può gestire lo split-horizon DNS?
Sì. Le DNS Views consentono di presentare contesti di risoluzione differenti riutilizzando zone condivise, mentre le Resolver Policies selezionano la vista corretta.
Bisogna eliminare subito Windows DNS?
No. In presenza di Active Directory, record SRV e aggiornamenti dinamici sicuri, una migrazione totale richiede un’analisi specifica. Il modello ibrido è spesso il punto di partenza più prudente.
Funziona per gli utenti fuori sede?
Sì, se il traffico DNS raggiunge il Gateway Resolver attraverso una modalità supportata e le policy assegnano la vista corretta. Va comunque provato il comportamento quando client o collegamento non sono disponibili.
Qual è il primo test consigliato?
Creare una zona applicativa non critica, una vista dedicata al gruppo pilota e una resolver policy limitata. Solo dopo aver verificato log, fallback e rollback si può estendere il perimetro.