Split DNS per VPN nel 2026: guida completa, sicurezza, casi pratici e configurazione passo passo

Cos’è lo Split DNS e perché è importante nel 2026

Definizione base e semplice metafora

Lo Split DNS è un approccio in cui diversi domini vengono risolti da server DNS differenti, e la direzione delle richieste verso questi server dipende da regole, profili VPN e politiche cliente. Immagina un portinaio alla porta: lascia entrare solo chi è atteso. I domini esterni vanno ai resolver pubblici, mentre i nomi interni dell’azienda arrivano ai server DNS privati aziendali. Il risultato? Una netta separazione dei mondi, meno fughe di dati, maggiore velocità e controllo che garantisce sicurezza. Sembra semplice, ma il diavolo sta nei dettagli, e nel 2026 di dettagli ce ne sono molti di più.

Perché questo approccio torna protagonista? Perché siamo passati di massa al cloud ibrido, abbiamo distribuito gli uffici, adottato Zero Trust, e aggiunto DoH, DoT e persino DNS-over-QUIC. Il DNS tradizionale e piatto non regge: o mostra troppo a Internet o rompe i nomi interni. Lo Split DNS offre la giusta via di mezzo. È come un semaforo a una complessa intersezione: corsia giusta, segnale corretto, nessuno taglia la strada. Inoltre, risparmia millisecondi, a volte minuti, soprattutto quando si debuggano catene di risoluzione complesse.

Come lo Split DNS funziona con la VPN

Attraverso la VPN creiamo un tunnel logico. Poi ci sono le regole: quale dominio si risolve attraverso il DNS aziendale e quale verso il resolver pubblico. Di solito configuriamo un inoltro condizionale per liste di zone e domini, per esempio corp.local, int.company, svc.cluster.local, indirizzandoli verso i DNS dell’ufficio o dell’hub cloud. Tutto il resto va al provider dell’utente o a un resolver DoH gestito e affidabile.

Un punto importante riguarda la policy client. Windows usa tabelle di regole (NRPT), macOS e iOS con profili di configurazione dirigono i domini verso resolver specifici, Android può parzialmente separare il traffico con DNS privato, mentre Linux con systemd-resolved gestisce il routing tramite domini divisi. Il risultato è chiaro: la VPN non deve trascinare tutto il traffico fuori, ma intercetta solo i domini necessari. Questo rende lo Split DNS comodo sia per la performance che per la privacy.

Qual è la differenza tra Split DNS e Split Tunneling

Confusione numero uno. Il Split Tunneling divide il traffico per subnet o applicazioni, bypassando parzialmente la VPN. Lo Split DNS divide solo la risoluzione dei nomi di dominio, mentre il percorso può essere qualsiasi, incluso un tunnel completo. Possiamo usare un tunnel VPN completo per la sicurezza, ma risolvere i domini esterni tramite DoH pubblico. Oppure dividere il traffico, ma far transitare tutto il DNS attraverso il resolver aziendale. Sono meccanismi indipendenti, spesso combinati.

Perché è importante? Perché puoi calibrare finemente l’equilibrio. Vuoi meno rischi di fuga dei nomi interni? Risolvili solo via DNS interni e lascia gli esterni su DoH attraverso il tunnel. Vuoi guadagnare velocità su YouTube o CDN? Permetti ai domini esterni di risolversi più vicino all’utente, lasciando tutto il sensibile rigorosamente dentro. La flessibilità è enorme e i guadagni spesso si misurano in decine di percentuali nel tempo di risposta.

Quando lo Split DNS non serve

Se non hai domini interni, nessuna zona privata, nessuna differenza tra nomi dentro e fuori, allora lo Split DNS ha poco senso. Di solito è raro nelle aziende, ma succede in piccoli team dove c’è solo un SaaS e nessun server interno. Un altro esempio: client leggeri rigorosamente isolati senza accesso a Internet — lì la risoluzione è tutta interna e non c’è nulla da separare.

Ma nella maggior parte delle organizzazioni vere del 2026 i nomi interni ci sono sempre. Active Directory, servizi Kubernetes, servizi in VPC e VNet, API private, portali interni, service discovery tramite Consul o Istio. Ovunque ci siano zone interne, lo Split DNS aiuta. Riduce risoluzioni errate verso l’esterno, protegge la privacy e offre un’esperienza utente trasparente: tutto funziona dietro le quinte, senza complicare la configurazione dei file hosts.

Architettura dello Split DNS: i mattoni fondamentali

Ruoli dei server DNS: interno, esterno e resolver

Nell’architettura Split DNS ci sono almeno due tipi di resolver: quelli interni (autoritativi per le zone private e spesso ricorsivi per gli host interni) e quelli esterni (resolver pubblici o autoritativi per le tue zone pubbliche). A volte c’è un terzo livello — resolver di frontiera in cloud che fungono da cache e distribuzione. Questo schema a livelli riduce latenza e carico sulla dorsale.

I DNS interni conoscono le tue zone private: per esempio corp.local, priv.company, internal.zone, svc.cluster.local. I resolver pubblici non ne sanno nulla e non devono saperlo. Il resolver ricorsivo di solito memorizza nella cache i risultati, mentre i server autoritativi danno la risposta finale. È fondamentale stabilire una netta separazione: le zone interne restano interne, quelle esterne non devono accidentalmente uscire senza controllo. Così otteniamo percorsi puliti, prevedibilità e controllo.

Zone, conditional forwarding, stub e forward

La classica applicazione dello Split DNS è il Conditional Forwarding, quando imposti una regola: se il dominio termina con .corp.local, manda le richieste a 10.10.10.10 e 10.10.10.11. Le zone forward sono perfette per integrare unità di business diverse o in M&A: team separati gestiscono le loro zone, ma una politica unica distribuisce le richieste correttamente. Le zone stub semplificano la delega: non copi i record ma indichi chi è autoritativo, e il resolver sa dove andare.

Perché è comodo? Eviti duplicazioni. Non devi inserire gli stessi record in posti diversi rischiando incoerenze. Nel 2026 la maggior parte dei DNS aziendali supporta forward, stub e modalità miste. Inoltre puoi aggiungere RPZ per filtrare contenuti dannosi e bloccare domini rischiosi al confine, senza intaccare le zone interne. Il risultato è un percorso logico e gestito per ogni nome.

Resolver sul client: ordine, cache e TTL

Il client è il nostro piccolo direttore d’orchestra. Decide a chi chiedere per primo, come gestire il TTL e per quanto mantenere la cache. Su Windows si regola con NRPT e priorità degli interface. Su macOS e iOS con profili di configurazione si definiscono server DNS e liste di domini. Android ha politiche con DNS privato e a volte MDM per app di gestione. Linux usa systemd-resolved, che sa fare routing per domini e interfacce — un compagno ideale per Split DNS.

La cache è importante. Non vuoi questionare ogni minuto al cloud per la stessa richiesta A. Ma attenzione: TTL troppo lunghi ostacolano aggiornamenti e migrazioni. Nel 2026 un TTL ragionevole è 30–300 secondi per servizi interni dinamici, 15–60 minuti per quelli stabili. Così non sovraccarichi i resolver e non blocchi i rilasci. Ricordati anche di abilitare la cache negativa, così NXDOMAIN non bombarderà il sistema continuamente.

DNS crittografato: DoH, DoT e DNS-over-QUIC

La crittografia DNS è ormai uno standard de facto. DoH, DoT e DNS-over-QUIC proteggono da spionaggio e manomissioni. Ma la VPN già cifra tutto. Serve doppia crittografia? A volte sì. Se vuoi proteggerti da spoofing DNS nella rete locale prima del tunnel, o forzare il client a risolvere i domini esterni solo tramite DoH affidabile, anche con VPN attiva. In tal caso abiliti DoH sul client, ma configuri con attenzione regole che evitino che i nomi interni escano fuori.

La cosa importante è evitare conflitti. Se il client forza DoH per tutte le richieste, può non vedere le zone private. La soluzione è la policy Split DNS che specifica chiaramente: i domini interni passano al resolver aziendale dentro il tunnel, quelli esterni via DoH a un provider approvato o resolver gestito. Nel 2026 molti MDM e app VPN client supportano questo nativamente, basta configurare bene le regole.

Scenari aziendali per l’uso dello Split DNS

Active Directory e zone interne

Se usi AD, lo Split DNS è quasi indispensabile nell’architettura. Domini come corp.local o ad.company.internal devono risolversi solo sui domain controller o sistemi affidabili interni. Il motivo è semplice: record SRV e LDAP sono critici per login, GPO e servizi. Se per errore escono, arrivano code di ticket e notti insonni. Lo Split DNS indirizza le richieste AD nei canali interni e previene problemi.

Inoltre AD richiede precisione: record PTR, CNAME corretti, GC e siti precisi. La separazione DNS facilita la diagnostica. Vedi quale zona è gestita da quali server e controlli la loro replica separatamente. Si riduce il tempo di ricerca problemi. Invece di cacciare su tutti gli host, vai subito nel punto giusto per la riparazione. Con lavoro remoto e connessioni ibride, è un vero risparmio di ore o giorni.

Ambientazioni ibride multi-cloud

AWS, Azure, GCP più on-premise: la realtà standard nel 2026. Ogni piattaforma ha le sue zone private o integra con DNS locale. Lo Split DNS traccia rotte tra di loro in modo trasparente: un servizio AWS risolve tramite Route 53 Private Hosted Zone, uno Azure tramite Private DNS, e i sistemi locali tramite BIND o DNS Windows. L’utente non nota nulla e tu gestisci tutto da un unico pannello politico.

Aggiungiamo Kubernetes. I nomi interni tipo svc.cluster.local devono risolversi solo nel cluster o tramite resolver aziendale che conosce l’indirizzo di CoreDNS. Il conditional forwarder aiuta a legare i mondi. È cruciale per service mesh e interazioni multi-cluster. Senza Split DNS rischi timeout imprevedibili e loop strani. Con lui hai direzione chiara e comportamento atteso.

Divisione per business unit e M&A

Quando un’azienda ne acquista un’altra, il problema principale sono collisioni di nomi e zone. Entrambe hanno internal.local, mail.internal, api.int e vecchi residui storici. Lo Split DNS con forward e stub zone aiuta a gestire il periodo di transizione con dolcezza. Deleghe temporanee, allineamento di policy e unificazione progressiva dello schema nomi. Gli utenti non si accorgono che sotto ci sono due mondi, perché hanno un resolver unico con regole integrate.

Dentro un gruppo è comodo dividere anche così: per esempio la sicurezza bancaria gestisce zone e filtraggio RPZ, RnD ha zone sperimentali con TTL brevi. Lo Split DNS imposta binari chiari senza ostacolare le squadre locali: è un equilibrio tra controllo e velocità. Più rapido è il business, più serve flessibilità ai margini e non un monolite rigido.

Filiali remote, SD-WAN e SASE

Le filiali usano SD-WAN e SASE, gli utenti in viaggio sono su LTE. Lo Split DNS permette di nominare un resolver per ogni scenario. In filiale c’è cache locale e forward verso hub. Nel mobile c’è un agente client che sa quali domini inviare nel tunnel e quali risolvere localmente via DoH. Offline temporaneo? La cache e la cache negativa aiutano ad aspettare la connessione.

In architetture SASE il resolver diventa un controller di policy. Controlla categorie domini, etichette di rischio, stati di minaccia, decide se permettere, inoltrare o bloccare. Lo Split DNS è la mappa: quali domini sono fidati, quali solo in tunnel, quali in quarantena. E tutto senza rompere l’abitudine dell’utente, che digita indirizzi, clicca link, e il sistema dietro sceglie senza intoppi la strada giusta.

Sicurezza e privacy: tenere il DNS sotto controllo

Fughe DNS: come individuarle e bloccarle

Una fuga DNS accade quando richieste per nomi interni o domini sensibili escono fuori posto, per esempio in rete esterna bypassando la VPN o verso resolver pubblici che registrano tutto. Verifichiamo in tre modi: log di sistema cliente, monitoraggio al gateway e test sintetici che confrontano risposte per liste di domini. Nel 2026 ci sono agenti accessibili che osservano il DNS passivamente e segnalano se la policy è violata.

Blocchiamo le fughe con regole e priorità. Impostiamo regole esplicite per zone private, disattiviamo resolver pubblici automatici su client, usiamo DoH/DoT verso resolver aziendali per difenderci da intercettazioni. Attenzione al Wi-Fi guest, dove attaccanti potrebbero iniettare DHCP falsi. Un client con Split DNS chiaro è immune: sa dove devono andare i domini e ignora suggerimenti falsi.

Filtraggio, RPZ e Zero Trust

RPZ (Response Policy Zone) è il filtro anti-tossine. Blocca phishing, malware e domini C2 a livello DNS, prima che l’antivirus intervenga. Abbinato allo Split DNS è uno strumento preciso: i domini interni possono bypassare il filtro se previsto, quelli esterni sono controllati e bloccati. Zero Trust aggiunge contesto: chi è l’utente, il profilo rischio, dispositivo usato. La decisione cambia su stesso dominio se scattano segnali di pericolo.

Non esagerare. Filtri troppo aggressivi causano falsi positivi, specialmente in ambienti DevOps e test con nomi dinamici. Buona pratica è whitelist per zone critiche, processi di esclusione chiari e monitoraggio rollback a 24–72 ore. Il filtraggio deve essere come la cintura di sicurezza: non fastidia ma salva in emergenza.

Privacy e minimizzazione dei log

Il DNS racconta la tua storia su Internet. Non dobbiamo conservare più del necessario. Minimizza dati personali: non loggare richieste intere se non serve, tronca IP a prefisso, conserva solo statistiche aggregate. Nel 2026 sempre più aziende adottano retention corta (7–30 giorni) per log grezzi, e storage lungo solo per gli aggregati. È sufficiente per indagini e trend, ma più sicuro per gli utenti.

Ricorda consenso e normative. Spiega nelle policy quali domini sono filtrati, quali no, e per quanto tempo si conservano i dati. Sembra burocratico? In parte sì, ma risparmia stress durante audit e aiuta a costruire fiducia nel team. Quando tutti conoscono le regole, lavorano più tranquilli e rompono meno il sistema per disattenzione.

DNSSEC, DANE e igiene della posta

DNSSEC firma le risposte, proteggendole da falsificazioni. Per le zone interne può essere eccessivo, ma per quelle pubbliche è ormai standard. DANE completa il quadro collegando i certificati al DNS. In combinazione con lo Split DNS dividi le responsabilità: internamente rapido e flessibile, esternamente rigido e firmato. Riduce i rischi MITM e automatizza controlli.

I record di posta SPF, DKIM e DMARC sono un altro capitolo. Assicurati che siano coerenti tra zone interne ed esterne. Se hai domini diversi per posta interna e esterna, lo Split DNS deve garantire che client e server vedano i record giusti. Altrimenti rischi problemi di consegna, perdita di reputazione e code intasate.

Configurazione passo passo dello Split DNS per stack popolari

Windows Server DNS e VPN IKEv2 o Always On VPN

Si parte dalle zone. In Windows DNS crea zone forward lookup interne per domini privati. Poi configura Conditional Forwarders verso server autoritativi di domini vicini in altri segmenti o cloud. Verifica la replica delle zone, imposta TTL ragionevoli e aggiungi PTR dove serve per AD e logging. Poi la policy client: con Group Policy distribuisci NRPT che manda i domini *.corp.local e *.svc.company ai DNS nel tunnel.

Per VPN IKEv2 o Always On VPN configura nel profilo gli indirizzi DNS aziendali e la lista dei domini. Attiva il filtraggio delle regole split-domain perché il client non risolva nomi privati sui resolver pubblici. Testa passo passo: prima zone interne, poi esterne, infine scenari misti, come un nome esterno che reindirizza a un reverse proxy interno.

BIND o Unbound con WireGuard e OpenVPN

BIND offre flessibilità, Unbound velocità e cache integrata. Crea una forward zone per domini privati e indica i server autoritativi. Per i domini esterni abilita la ricorsione, ma instradala verso il tuo DoH/DoT upstream o radici locali. In WireGuard aggiungi nel config liste di domini nel resolver client o usa script che aggiornano systemd-resolved con rotte per le zone necessarie. In OpenVPN usa push dhcp-option DOMAIN-ROUTE per indicare rotte di dominio, se supportato dal client.

Il controllo è la chiave. Usa dig o drill per nomi interni ed esterni. Confronta i tempi risposta con cache attiva e non. Valuta il carico sul resolver in picco. Attiva i log solo per la fase di rollout, poi abbassa il livello per non affogare negli eventi e mantenere i segnali importanti distinti dal rumore.

pfSense o OPNsense e DoT/DoH

pfSense e OPNsense hanno resolver e forwarder integrati. Puoi impostare Conditional Forwarding via GUI indicando zone private e indirizzi. Collega DoT per richieste esterne a provider di fiducia, e per traffico interno lascia UDP o TLS se richiesto dalla policy. Attiva cache e limiti ragionevoli. Configura Health Check: il resolver deve passare rapidamente a un upstream di scorta se il primario fallisce, per evitare timeout agli utenti.

Importante: se usi DoH sul client, assicurati che le regole non rompano i nomi interni. Spesso serve forzare eccezioni per le zone interne e percorsi DNS rigidi nel tunnel. Testa da reti diverse — router domestico, cellulare, Wi-Fi ospiti — per intercettare stranezze di rete prima che gli utenti se ne accorgano.

MikroTik, Conditional Forwarding e rotte

MikroTik con RouterOS da tempo funziona come forwarder e cache. Crea rotte statiche per zone private, indica resolver interni, abilita cache con limitazione TTL. Inserisci indirizzi di backup per garantire continuità in caso di caduta nodi. Se hai accesso ibrido, configura regole sull’interfaccia VPN cosicché il DNS per le zone interne viaggi sempre nel tunnel.

Verifica modifiche su piccoli gruppi pilota. La realtà è dura: router vecchi, software non standard. Meglio scoprire incompatibilità in pilotaggio che in produzione. Mantieni modelli di configurazione versionati: risparmi ore per recuperare rollback accidentali.

Piattaforme client e politiche

Windows 11 e 12: NRPT, priorità e DoH

Windows può indirizzare domini specifici a resolver definiti tramite NRPT. Usa GPO o MDM per distribuire regole: per *.corp.local, *.int.company e *.svc.cluster.local manda al DNS interno tramite indirizzi nel tunnel. Attiva Prefer DoH per resolver esterni se vuoi cifrare le richieste esterne; aggiungi eccezioni affinché i domini interni non escano via DoH. Controlla la priorità delle interfacce per dare precedenza al VPN per le zone necessarie.

Non dimenticare lo Split DNS con Always On VPN. Il client deve sapere quali richieste vanno nel tunnel. Nel 2026 i client gestiscono meglio scenari misti, ma piccoli conflitti restano. Logga durante la fase di rollout, usa test lab e checklist prima del rilascio ampio.

macOS e iOS: profili, per-app VPN e NetworkExtension

macOS e iOS usano profili di configurazione dove imposti lista domini e resolver, anche regole per per-app VPN. È comodo: puoi indirizzare app aziendali nel tunnel con DNS interno, mentre il browser rimane su DoH esterno. Fondamentale sincronizzare: se un’app ha un resolver proprio, verifica che non confligga col sistema.

Nel 2026 Apple ha migliorato lo stack DNS e la cache. Ricorda la logica di retry: se il resolver è lento, la macchina può passare ad altro profilo. Regola con cura timeout e priorità per evitare switch inutili. Ottimizza le liste domini: regole brevi e concise funzionano sempre meglio.

Android 14 e 15: Private DNS e MDM

Android permette di attivare Private DNS su DoT e gestire parzialmente regole con MDM. Se hai un agente aziendale, usalo per Split DNS: domini interni sul resolver aziendale, il resto via DoT a provider affidabile. Per-app VPN aiuta a separare traffico per applicazioni, importante in BYOD per non toccare app personali.

Testa device di vari produttori. Spesso interpretano gli standard in modo creativo. Politiche uguali su carta possono funzionare diversamente su modelli diversi. Pilota, raccogli feedback, correggi velocemente per evitare ondate di recensioni negative. E spiega ai collaboratori perché è importante: capendo i benefici aggiornano i profili più volentieri e rompono meno le configurazioni.

Linux: systemd-resolved e rotte per dominio

systemd-resolved è eccellente per Split DNS. Puoi assegnare resolver ad interfacce e domini, settare priorità, abilitare cache e cache negativa. Si integra con NetworkManager: quando la VPN si attiva applica le regole, si disattiva le rimuove. Su WireGuard puoi usare script per aggiungere rotte di dominio all’interfaccia in up.

Attenzione ai container e Kubernetes sull’host. Se avvii cluster dev o container pesanti, potrebbero usare resolver propri. Controlla che zone aziendali non finiscano nel nulla. Meglio impostare regole esplicite anche nell’ambiente container piuttosto che inseguire timeout strani di servizi che «magicamente si sistemano» dopo TTL.

Consigli pratici e checklist

Pianificazione domini e zone inverse

Parti da una mappa. Quali zone sono interne, quali esterne, dove sono autoritative, dove ricorsive. Definisci zone inverse per subnet chiave e crea PTR dove servono per logging e sicurezza. Evita TLD esotici per l’interno, usa zone private standard o sottodomini esistenti. Facilita le integrazioni e riduci collisioni.

Valuta come gli utenti digitano indirizzi. Se abituati a nomi brevi, mantieni suffissi di ricerca e liste Search Suffix. Ma non esagerare: troppi suffissi creano richieste e ritardi inutili. Equilibrio ideale è 1–3 suffissi per la maggior parte degli scenari, più regole chiare su quando usare FQDN.

Performance, cache e limiti

La cache è il tuo alleato se controlli TTL. Per servizi dinamici scegli TTL brevi e usa cache aggressiva ai margini: resolver di filiale alleggeriscono il carico centrale. Attiva anti-storm: limiti per nome e stop ai retry infiniti. Nel 2026 sono diffusi resolver elastici che scalano automaticamente e rientrano di notte.

Profilare i tempi è essenziale. Un DNS normale risponde in 20–40 ms per zone interne, 40–120 ms per esterne. Se vedi picchi da 300–500 ms indaga: cache sovraccarica, upstream in difficoltà, o conflitti DoH e VPN. Trova colli di bottiglia e mantieni SLO. Il DNS è anche una storia da SRE.

Monitoraggio, alert e SLO

Abilita tre livelli di monitoraggio: test sintetici su domini chiave, metriche dei resolver (QPS, NXDOMAIN, SERVFAIL, hit cache), e tracciamento sessioni utente per incidenti complessi. Configura alert non per ogni piccolo scarto, ma per deviazioni durevoli. Lascia sistema tollerare 10 minuti di picco prima di svegliare ingegneri in notte.

Crea dashboard: zone interne, esterne, errori per tipologia, percentili di latenza. Guarda p95 e p99, sono più veritieri della media. Insegna al team a leggere questi grafici. Una buona visualizzazione salva ore di riunioni. Veloce comprensione, rapido fix, rapido ritorno al business.

Documentazione, formazione e gestione cambiamenti

Scrivi regole in modo semplice. Quale zona dove, chi risponde di cosa, quali eccezioni ammesse e come formalizzarle. Nuovi arrivati e collaboratori trasversali devono capire in 10–15 minuti. Possibile se eviti gergo e vai al sodo. Un portale interno con istruzioni brevi fa miracoli.

Implementa change management: piccoli batch, rollout canary, rollback veloci. Controlla ogni modifica in pilota e registra risultati. Errori su Split DNS non sono letali ma molto fastidiosi. Evitarli è possibile con disciplina e non cambiamenti massivi simultanei.

Casi reali: cosa ha funzionato e cosa no

Banca con 30.000 dipendenti

La banca aveva tre zone AD, due zone private cloud e una vetrina pubblica su dominio separato. Gli utenti lamentavano ritardi fino a 1,5 secondi nei login client banking e CRM. Abbiamo introdotto Split DNS con forwarding per zone cloud, ottimizzato TTL a 120 secondi per servizi stabili e 30 per Kubernetes. Aggiunta RPZ per phishing. Risultato: p95 della risoluzione è sceso da 420 a 110 ms, i login sembrano immediati.

Cosa non ha funzionato subito? DoH troppo aggressivo lato client, che intercettava nomi interni su resolver pubblici. Corretto con politica di esclusioni e tutto si è stabilizzato. Lezione: non fidarti delle configurazioni di default, specialmente in ambienti eterogenei.

Startup multi-cloud con rilasci rapidi

Lo startup gestiva prod in AWS e test in GCP, con CICD che migrava zone ogni paio di settimane. Risolto con Split DNS e zone forward dinamiche automatizzate da Git. Sviluppatori avevano nuovi record in un minuto, utenti risolvevano correttamente sempre. Cache periferica risparmiava banda.

Un bug curioso su CDN e ECS: cache geoloc sbagliato per espansione EDNS. Risolto limitando ECS per certi domini. A volte la configurazione fine è magia. Conseguenza: consegna contenuti +12–18% più veloce sul p95.

Produzione e reti filiali

Stabilimenti, macchinari, SCADA e vecchi controller. Lo Split DNS ha evitato caos: nomi privati di sistemi fabbrica si risolvevano localmente e prevedibilmente. Resolver caching leggeri in ogni filiale, forwarding verso hub, TTL rigorosi. Se cadevano connessioni, la produzione girava lo stesso grazie alla cache.

Problema: vecchie stampanti, resolver inaspettati e switch intelligenti con DHCP proprio. Abbiamo disattivato distribuzioni esterne, migliorato il controllo e aggiunto monitoraggio portali per vedere da dove arrivavano richieste fuori posto. Dopo una settimana di pulizia la rete è diventata più silenziosa e i problemi rari.

Pubblica amministrazione e conformità

Privacy particolarmente rigorosa. Abbiamo diviso zone, implementato DNSSEC su domini pubblici, limitato log dati personali e definito tempi di conservazione chiari. Le richieste esterne andavano via DoH a resolver affidabili, quelle interne restavano nel perimetro VPN. Auditor contenti, utenti ignari — il complimento migliore.

Punto chiave: documentazione e ripetibilità. Senza regole chiare audit diventano drama. Con Split DNS mostri trasparenza: regole, monitoraggio, log, eccezioni. Tutto tranquillo, umano, senza misteri.

Errori comuni e come correggerli

Duplicazione record e split-horizon

L’errore più subdolo è avere due copie di stessi record in posti diversi. Oggi corrispondono, domani no, dopodomani utenti disperati. Soluzione: forward o stub invece di copia. Un’unica fonte autoritativa e routing giusto. Più facile da gestire e spiegare perché una risposta è quella e non un’altra.

Lo split-horizon non è male, ma richiede disciplina totale. Se dai risposte diverse a clienti interni ed esterni, tieni sotto controllo TTL e aggiorna contemporaneamente entrambe le parti. Altrimenti vengono casi strani: un utente mobile vede una cosa, un collega in ufficio un’altra. Confondono molto.

Ordine errato dei resolver sui client

Un altro trucco. Il client può chiedere prima al resolver pubblico e solo dopo a quello aziendale. Ne risulta che nomi interni «non esistono». Risolvi con priorità interfacce, regole NRPT e rotte dominio esplicite. Testa comportamento su ogni piattaforma. Non dare per scontato che «di default sia tutto intelligente».

Aggiungi diagnostica per supporto: checklist breve di 5–7 passi per capire dove è finita la richiesta. Riduce enormemente i tempi di risoluzione. Il team non disturba ingegneri con questioni di base e raccoglie fatti per aprire ticket corretti.

EDNS, ECS e sorprese CDN

Le estensioni EDNS ed ECS influenzano la geolocalizzazione della cache CDN. A volte fanno scegliere nodi meno vicini. Verifica se il resolver trasmette ECS e come. Per certi domini è meglio limitare ECS per stabilizzare la risposta. Il risultato sorprende spesso: latenza diminuisce, picchi spariscono, reclami calano.

Non temere di sperimentare su piccoli gruppi. Misura prima di implementare ampiamente. Le CDN amano «manipolare» le impostazioni, e una configurazione fine può dare +10–20% velocità se centrata sulle loro politiche.

Certificati, PTR e zone inverse

SSL e mutual TLS odiano il caos DNS. Se CN e SAN puntano a domini che a volte si risolvono in modo errato, ci sono errori handshake. Metti ordine: nomi interni solo con resolver interno, esterni externi. Mantieni PTR per sistemi chiave, altrimenti diagnostica e SIEM sembrano cruciverba senza indizi.

Molti dimenticano le zone inverse. Poi si chiedono perché analytics non quadra o audit marca tutto come «ospiti sconosciuti». Attiva PTR dove serve e imposta TTL ragionevoli. Piccolo dettaglio che salva nervi.

Tendenze 2026 e cosa adottare subito

ZTNA e perimetro definito da software

Zero Trust e SDP rivoluzionano l’accesso. Lo Split DNS diventa parte della policy contestuale: il resolver vede utente, dispositivo, app, rischio e decide dove indirizzare la richiesta e quale risposta dare. Passiamo dal semplice «chi chiedere» all’intelligente «perché e a chi rispondere».

Praticamente è: agente sul device, policy cloud, resolver gestito e filtrante, routing dinamico attraverso gateway ZTNA. Idea semplice, realizzazione complessa. Ma il controllo e la sicurezza guadagnano moltissimo. Parti in piccolo e scala col maturare del team.

DNS-over-QUIC e Encrypted ClientHello

QUIC accelera e rende la connessione più resistente alla perdita di pacchetti. DNS-over-QUIC è naturale evoluzione. Nel 2026 lo supportano sempre più client e resolver. Parallelamente cresce Encrypted ClientHello che nasconde i dettagli del handshake TLS. Per lo Split DNS è privacy extra: pochini metadati al perimetro, più difficile lo spionaggio.

Dove sta il problema? Compatibilità e diagnosi. Testa con cura. Attivare QUIC può impattare proxy o IDS vecchi. Però la tendenza è chiara: tra uno o due anni sarà il metodo dominante di cifratura per tanti scenari.

Resolver gestiti con AI integrata

I resolver gestiti nel 2026 fanno molto: autotuning TTL, caching adattivo, suggerimenti su zone problematiche e anomalie basate su machine learning. Notano se un dominio rallenta e propongono di abbassare TTL o cambiare upstream. O vedono se un subnet sovraccarica cache e consigliano di spostare il nodo.

Non è magia, ma quasi. L’importante è non perdere il controllo. Qualsiasi correzione automatica deve passare review di cambiamento, anche accelerata. Un errore sul resolver oggi = mezza giornata di caos domani. Vogliamo velocità, ma non sorprese. Suggerimenti intelligenti sì, soluzioni autonome con cautela e gradualità.

Regolamentazioni, compliance e dati

La privacy cresce come esigenza. Le aziende rivedono politiche di conservazione log, adottano pseudonimizzazione e separano metriche operative da dati personali. Lo Split DNS è dalla parte giusta: riduce gli «occhi inutili» e manda richieste sensibili solo a resolver affidabili. I log sono più puliti, il rischio fuga diminuisce e gli audit più facili.

Un consiglio quotidiano: documenta quali categorie di domini vanno dove, chi vede quali dati e cosa si logga. È noioso, ma salva durante incidenti. Rispondi velocemente a domande chiave e non perdi tempo a cercare informazioni caoticamente.

FAQ: l’essenziale in breve

Cos’è lo Split DNS in parole semplici

È una soluzione dove i domini diversi vengono risolti da DNS diversi secondo regole. I nomi interni vanno al resolver aziendale via VPN, quelli esterni a resolver pubblici o gestiti. L’utente vede solo «tutto funziona», tu controlli privacy, velocità e sicurezza.

In cosa lo Split DNS differisce dal Split Tunneling

Lo Split DNS divide solo la risoluzione DNS. Lo Split Tunneling divide tutto il traffico di rete. Possono essere usati separatamente o insieme. Per esempio, tunnel pieno per tutto il traffico, ma i domini esterni si risolvono via DoH e quelli interni via DNS aziendale.

Come capire se ho una fuga DNS

Segnali: nomi interni non si risolvono, risposte strane, login ad AD o portali aziendali rallentati. Controlla i log del resolver, esegui test sintetici e verifica chi risponde alle zone private. Se non è il DNS aziendale, hai una fuga.

Serve attivare DoH o DoT se ho già VPN?

A volte sì. DoH o DoT proteggono le richieste da manomissioni e intercettazioni prima del tunnel e dopo, se usi un resolver esterno. Ma devi escludere le zone interne per non rompere l’accesso ai servizi privati. È il bilanciamento tra sicurezza e compatibilità che fa la differenza.

Posso fare Split DNS senza permessi sui dispositivi client?

Parzialmente sì. Puoi configurare il resolver al perimetro e forzare inoltri. Ma l’ideale è una politica centralizzata client via MDM o Group Policy. Così le regole funzionano uguali e bypass accidentali si riducono al minimo.

Quali errori sono più frequenti

Duplicazione record invece di forward, priorità errata dei resolver sul client, TTL troppo lunghi, conflitti DoH con zone interne e monitoraggio insufficiente. Si corregge con disciplina, piloti, checklist e default sensati. E sì, non temere di semplificare quando puoi.