Protective DNS spiegato: come funziona e perché è importante
Published
Un ospite nella hall di un hotel tocca un link e la pagina inizia a caricarsi. Prima che il browser possa connettersi al sito web, il dispositivo dell'ospite deve individuare dove risiede quel sito su Internet. Quella ricerca silenziosa è un'opportunità per verificare se la destinazione debba essere consentita.
Il DNS protettivo aggiunge una decisione di sicurezza a questa procedura ordinaria. Può aiutare le organizzazioni a proteggere persone e dispositivi su reti condivise, ma funziona solo se il loro traffico utilizza il resolver gestito. Comprendere questa distinzione rende più semplice pianificare prestazioni, eccezioni, percorsi di bypass e privacy.
Indice dei contenuti
- Perché ogni visita a un sito web inizia con una risoluzione DNS
- Cosa fa il DNS protettivo nella fase di risoluzione del nome
- Come funziona l'applicazione delle policy in tutta la rete
- Impatto sulle prestazioni e miglioramenti misurabili nel caricamento delle pagine
- Casi d'uso reali in location ed enterprise
- Scegliere l'approccio giusto per la propria rete
- Misurare il valore del DNS protettivo oltre il conteggio dei blocchi
- Passi successivi per pianificare il rilascio del DNS protettivo
Perché ogni visita a un sito web inizia con una ricerca DNS
Il nome di un sito web è facile da ricordare per le persone. I computer hanno invece bisogno di un indirizzo di rete per connettersi. Il Domain Name System (DNS) fornisce la traduzione, proprio come un elenco telefonico che trasforma il nome di una persona in un numero da comporre.
Quando l'ospite tocca il link, il browser chiede a un resolver DNS l'indirizzo associato al nome del sito web. Il resolver cerca la risposta e la invia indietro. Il browser può quindi provare a connettersi alla destinazione. Il DNS non trasporta la pagina stessa, ma aiuta il dispositivo a trovare dove richiederla.
Questa sequenza crea un punto di controllo di sicurezza estremamente utile. Se il resolver riconosce un dominio richiesto come una minaccia nota, può rifiutarsi di fornire una risposta valida prima ancora che il browser si connetta. Un servizio DNS protettivo applica i criteri di sicurezza direttamente in questa fase di ricerca, anziché attendere il download di un file o un'azione sospetta sul dispositivo endpoint.
La distinzione pratica: il DNS aiuta un dispositivo a trovare una destinazione. Il Protective DNS aggiunge una decisione sulla riuscita della ricerca.
Questo è fondamentale soprattutto nei luoghi in cui molte persone e dispositivi condividono l'infrastruttura di rete. Un hotel può avere gli smartphone degli ospiti, i laptop del personale, i terminali di pagamento e i dispositivi dell'edificio connessi che utilizzano parti diverse della stessa rete globale. Un ufficio, un immobile residenziale o un luogo pubblico affrontano una sfida simile, sebbene gli utenti e i dispositivi siano differenti.
Il DNS protettivo può fornire un punto di controllo comune per queste ricerche, ma non costituisce un programma di sicurezza completo. Non protegge un dispositivo che evita il resolver gestito e non sostituisce la protezione degli endpoint, i controlli di accesso o un'accurata progettazione della rete. Le domande utili riguardano il modo in cui il resolver prende le sue decisioni, come un'organizzazione mantiene i dispositivi sul percorso previsto e quali evidenze dimostrano che il servizio è d'aiuto senza causare interruzioni.
Cosa fa il DNS protettivo nella fase di risoluzione dei nomi
Il protective DNS è un resolver ricorsivo che applica criteri di sicurezza. Un resolver ricorsivo gestisce le richieste per conto di un dispositivo, mentre il protective DNS applica regole per decidere se una destinazione richiesta debba ricevere una risposta DNS normale. Non si tratta solo di DNS reso più veloce o crittografato.
Segui una ricerca dall'inizio alla fine:
- Il dispositivo richiede un nome di dominio. Un browser, un'app o un altro processo necessita di un indirizzo prima di poter tentare la connessione a una destinazione nominativa.
- Il resolver controlla la richiesta. Confronta il dominio con i criteri configurati e le informazioni sulle minacce. Le implementazioni più avanzate possono anche verificare un indirizzo IP risolto, aiutando a valutare l'infrastruttura sottostante a un nome.
- Il resolver restituisce un esito. Se i criteri consentono la richiesta, il resolver fornisce una risposta. In caso contrario, il servizio può bloccare la risoluzione, restituire una risposta vuota o reindirizzare il client a una pagina di avviso. Il comportamento esatto dipende dal prodotto e dai criteri.
Alcune implementazioni cercano domini generati algoritmicamente (DGA), che i malware possono utilizzare per individuare le infrastrutture di comando e controllo. Pattern insoliti nei caratteri di un dominio, inclusa un'elevata entropia, possono fungere da segnale per un'ulteriore valutazione della policy. Questo tipo di analisi può integrare i feed di threat intelligence, ma le organizzazioni devono comunque convalidare il modo in cui il servizio scelto gestisce il rilevamento e le eccezioni.
Crittografia e autenticità non coincidono con una decisione sulla sicurezza
DNSSEC aiuta a verificare l'integrità e l'autenticità dei dati DNS firmati. DNS over HTTPS (DoH) e DNS over TLS (DoT) proteggono le query DNS in transito. Queste funzionalità sono importanti, ma non determinano autonomamente se un dominio esistente sia malevolo. Il DNS protettivo prende questa decisione di sicurezza direttamente sul resolver.
Per i team che esaminano i controlli sull'accesso web e sui servizi cloud, questa distinzione può affiancare indicazioni più ampie su come proteggere gli ambienti aziendali Microsoft 365. Il punto principale è evitare di considerare il trasporto crittografato o i dati autenticati come un sostituto di una decisione sul rischio della destinazione.
Come funziona l'applicazione delle policy in una rete
Un resolver può prendere una decisione valida per una singola richiesta e fallire comunque nel proteggere una rete se i dispositivi possono instradare il DNS attorno ad esso. La distribuzione su tutta l'infrastruttura riguarda quindi due elementi collegati: criteri di sicurezza coerenti e un percorso affidabile verso il resolver.
Un'architettura centralizzata invia le richieste DNS da più sedi a un servizio gestito. Questo semplifica l'applicazione di regole condivise e la revisione delle attività in tutte le sedi. Rende inoltre la disponibilità un requisito di sicurezza fondamentale. Se il resolver non è raggiungibile, l'accesso web ordinario e i servizi che dipendono dal DNS possono interrompersi anche se il resto della rete è perfettamente operativo.
Il servizio di DNS protettivo del governo degli Stati Uniti è diventato disponibile per le agenzie del Federal Civilian Executive Branch nel settembre 2022. Entro agosto 2024, oltre 104 agenzie avevano completato l'onboarding, generando una media di 1,6 miliardi di query DNS protette al giorno; il programma ha registrato un uptime del resolver del 99,999% (scheda informativa sul DNS protettivo di CISA). La lezione operativa è che la qualità del filtraggio e la disponibilità del servizio devono essere valutate insieme.
Applica l'identità senza moltiplicare le policy
Dipendenti, ospiti, residenti e dispositivi connessi non necessitano necessariamente delle stesse regole. Una rete può assegnare criteri differenti in base all'identità o al segmento di rete, ad esempio una rete per il personale, un WiFi per gli ospiti e una rete isolata per i dispositivi dell'edificio. L'obiettivo è adattare i criteri all'utente o al dispositivo mantenendo la gestione amministrativa semplice e scalabile.
I controlli di accesso aiutano a stabilire tale separazione, mentre il monitoraggio del traffico di rete può aiutare i team a investigare attività di rete insolite. Per una visione correlata di come il controllo dell'accesso alla rete si inserisce in un ambiente gestito, consultate queste soluzioni di network access control.
Chiudi deliberatamente le vie di aggiramento
Se un dispositivo può inviare DNS ordinario direttamente a un resolver esterno, il servizio protettivo potrebbe non vedere mai la richiesta. DoH e DoT creano un'altra sfida: la crittografia può proteggere le query in transito, ma un resolver non gestito può anche sottrarle ai criteri di sicurezza e alla visibilità dell'organizzazione.
Laddove sia richiesta l'applicazione delle regole, i team devono identificare i percorsi DNS diretti e le destinazioni DNS crittografate non autorizzate, per poi decidere come i controlli di rete, degli endpoint e del browser le gestiranno. Testa anche le eccezioni. I Captive Portal, i dispositivi mobili, l'IPv6 e le applicazioni con impostazioni di resolver proprie possono comportarsi in modo diverso rispetto a un laptop gestito su una rete aziendale. La policy funziona solo sui percorsi che l'organizzazione è in grado di governare.
Impatto sulle prestazioni e guadagni misurabili nel caricamento delle pagine
Un servizio di protective DNS non deve per forza rallentare la navigazione in modo visibile. L'impatto dipende meno dall'atto di filtraggio e più da scelte di progettazione pratiche: dove si trova il resolver, come memorizza in cache le risposte, come mantiene le connessioni e se i dispositivi lo aggirano.
Il DNS crittografato può aumentare i tempi di configurazione quando una connessione deve stabilire TCP, TLS o HTTP prima di inviare una query. Il riutilizzo di una sessione persistente evita di ripetere gran parte di tale configurazione. TLS 1.3, 0-RTT, il multiplexing HTTP/2 e QUIC possono anche ridurre il carico di connessione, secondo misurazioni indipendenti delle prestazioni del DNS crittografato. In condizioni di rete ottimali, la latenza di ricerca grezza può essere trascurabile, ma ciò non è garantito per ogni client o percorso di rete.
Testa la ricerca, non solo l'impressione
Un resolver vicino, ad alta disponibilità e con caching conforme agli standard aiuta a mantenere reattive le normali ricerche. Tuttavia, una singola cifra di latenza media può nascondere esperienze lente per un sottoinsieme di utenti, oppure quando il resolver deve recuperare una risposta non ancora presente in cache.
Misura la latenza di lookup p50, p90 e p99 separatamente per le cache fredde e calde. La mediana mostra un lookup tipico; i percentili più alti rivelano i casi più lenti che potrebbero influenzare maggiormente gli utenti. Mantieni la velocità di lookup distinta dal tempo di caricamento completo della pagina, poiché il DNS è solo una parte del percorso del browser.
Includi le condizioni che mettono in luce gli imprevisti
Esegui test dalle tipologie di reti e dispositivi usati dagli utenti, inclusi client mobili, IPv6 e Captive Portal. Verifica le applicazioni e i browser che potrebbero selezionare il proprio servizio DoH o DoT, poiché possono modificare sia l'instradamento che la visibilità delle richieste DNS.
DoQ, DNS over QUIC, è stato osservato nelle misurazioni distribuite come un approccio in grado di avvicinarsi alle prestazioni del testo in chiaro e di migliorare alcuni casi di caricamento della pagina rispetto a DoH. Considerate tali risultati come un motivo per testare le opzioni di trasporto nel vostro ambiente, non come la garanzia di un risultato specifico. L'obiettivo pratico è un resolver nelle vicinanze, una memorizzazione nella cache efficace, sessioni crittografate riutilizzabili e una struttura che non lasci aperti percorsi non gestiti.
Casi d'uso reali in strutture e aziende
Un'implementazione a livello nazionale mostra cosa può fare il DNS protettivo quando molte organizzazioni condividono un livello di sicurezza gestito. Nel Regno Unito, il numero di organizzazioni che utilizzano il servizio Protective Domain Name System è salito da 944 a 1.173 nel 2022, con un incremento del 24%. Nel corso di quell'anno, il servizio ha elaborato circa 0,55 mila miliardi di query DNS e bloccato 11 miliardi di richieste associate a destinazioni malevole, circa il 2% di tutte le query (riepilogo PDNS del NCSC del Regno Unito).
Tale scala illustra il valore di prendere una decisione prima ancora che venga tentata una connessione. Questo non dimostra che ogni richiesta bloccata si sarebbe trasformata in un incidente, o che il DNS da solo abbia fermato ogni percorso verso una minaccia. Per un operatore con più sedi, il confronto utile riguarda la capacità del servizio di applicare le policy in modo coerente, produrre telemetria operativa e gestire il volume e le eccezioni di quell'ambiente.
Considera come lo stesso punto di controllo si adatta a strutture diverse:
- Hotel e strutture residenziali: Separare l'accesso di ospiti o residenti da quello del personale e dei dispositivi dell'edificio. Un Captive Portal, un dispositivo più datato o il resolver crittografato preferito da un residente possono creare un'eccezione da pianificare.
- Aeroporti e stadi: Applicare una baseline comune nell'accesso pubblico ad alto turnover, mantenendo distinte le reti operative e del personale. Prestare attenzione ai dispositivi non gestiti e alle esigenze di connettività che richiedono un'eccezione documentata.
- Sanità e istruzione: Limitare l'accesso a destinazioni dannose senza bloccare i servizi legittimi utilizzati per l'assistenza, l'insegnamento o l'amministrazione. Fornire un percorso di revisione chiaro quando una policy blocca un elemento necessario per il lavoro.
- Retail e centri commerciali: Distinguere il traffico dei visitatori da casse, dispositivi del personale e altre apparecchiature operative. I team retail che pianificano l'accesso ospiti potrebbero trovare utili anche queste soluzioni WiFi per il retail nel valutare l'integrazione tra accesso e policy.
Una breve introduzione all'argomento può inoltre aiutare i team ad allinearsi su ciò che il livello DNS fa e non fa:
In ciascun contesto, il filtraggio DNS è un controllo parziale, non una garanzia di blocco di ogni minaccia. Un utente può raggiungere l'infrastruttura attraverso un altro resolver o un indirizzo IP diretto, e un'applicazione può utilizzare protocolli che non si affidano al percorso DNS dell'organizzazione. L'implementazione necessita di una gestione delle eccezioni e di un monitoraggio affiancati alla policy stessa.
Scegliere l'approccio giusto per la propria rete
Il protective DNS funziona a livello di resolver. Gli agenti sugli endpoint, le impostazioni del browser e i controlli di rete operano in punti diversi, quindi i team di solito scelgono una combinazione piuttosto che un singolo sostituto. Il mix ideale dipende da chi gestisce il dispositivo, da quale traffico la rete può vedere e da come dovrebbero essere gestite le eccezioni.
| Controllo | Utilizzo Ideale | Visibilità | Limitazione Comune |
|---|---|---|---|
| Protective DNS | Reti condivise, proprietà gestite e applicazione delle politiche DNS | Richieste DNS che passano attraverso il resolver | I resolver non gestiti e i percorsi non DNS possono aggirarlo |
| Agente endpoint | Laptop gestiti e dispositivi mobili che richiedono protezione fuori dalla rete | Attività visibile all'agente installato | La copertura dipende dall'installazione, dallo stato di salute e dalla gestione dell'agente |
| Criteri del browser | Browser gestiti in cui è possibile governare il resolver e le impostazioni di navigazione | Configurazione del browser e attività del browser selezionata | Non governa ogni applicazione o browser non gestito |
| Controlli a livello di rete | Reti segmentate e traffico che passa attraverso l'infrastruttura gestita | Flussi di rete rientranti nella copertura del controllo | Il traffico crittografato o esterno alla rete può limitare l'ispezione |
| Controlli di identità e accesso | Personale, ospiti, residenti e gruppi di dispositivi con esigenze di accesso distinte | Decisioni di connessione e accesso legate all'identità o al segmento | Una connessione consentita non valuta di per sé ogni destinazione |
Per i laptop gestiti, i controlli sugli endpoint e sui browser possono integrare le policy del resolver, in particolare quando i dipendenti lavorano fuori ufficio. La rete WiFi ospiti e i dispositivi BYOD sono più difficili da gestire tramite agent, rendendo più pratici i controlli a livello di rete, a condizione che l'organizzazione possa indirizzare il DNS verso il servizio prescelto. I dispositivi IoT e residenziali necessitano spesso di una segmentazione e di una policy che tenga conto delle opzioni limitate di gestione dei dispositivi.
Per i team che confrontano identità di rete, filtraggio e controlli rivolti agli utenti, i controlli gratuiti di DNS ed email di mailX possono rappresentare una risorsa utile insieme a una revisione più ampia dei controlli di accesso. Se gli ambienti di pagamento fanno parte dell'infrastruttura, considera anche l'impatto del design WiFi e dei requisiti di conformità PCI-DSS sulla separazione e sull'amministrazione della rete.
Purple Access combina opzioni di rete aperte, sicure e xPSK sugli access point esistenti, con onboarding tramite captive portal e assegnazione di rete basata sull'identità. Purple Shield aggiunge DNS protettivo e filtraggio dei contenuti con controlli basati su singole policy. Tali funzionalità possono affiancarsi ai controlli su endpoint e browser, ma non eliminano la necessità di definire l'applicazione del resolver, le eccezioni e il monitoraggio. Scegli gli strumenti in base ai percorsi e ai dispositivi che devi proteggere, quindi verifica che le loro policy funzionino insieme.
Misurare il valore del DNS protettivo oltre il conteggio dei blocchi
Il totale delle query bloccate indica che il resolver è intervenuto. Da solo, non dice se ha intercettato le richieste corrette, interrotto attività utili o ignorato il traffico che ha seguito un'altra rotta. Conta la decisione, ma misura il controllo.
Il workshop sul DNS della European Internet Industry Association ha registrato 2,3 milioni di segnalazioni di abusi riguardanti 780.000 domini unici nei sei mesi precedenti, con segnalazioni mensili in aumento da 220.000 a 380.000 (report del workshop). Queste cifre mostrano la portata degli abusi segnalati. Non stabiliscono tuttavia quanti incidenti un resolver abbia evitato, se un blocco fosse corretto o se il traffico interessato abbia raggiunto una destinazione tramite una VPN, un resolver alternativo, un indirizzo IP hardcoded o un protocollo applicativo crittografato.
Crea una scheda di valutazione basata su risultati ed eccezioni
Una valutazione efficace combina sicurezza, qualità del servizio e tempi di risposta operativi. Monitora se il resolver ha rilevato domini malevoli noti, la rapidità con cui i team gestiscono le segnalazioni di falsi positivi e se le modifiche ai criteri raggiungono tempestivamente le sedi interessate. Associa a queste metriche la disponibilità del resolver e la latenza media e di coda delle ricerche.
Misura anche i tentativi di aggiramento. Un basso numero di richieste bloccate può indicare che l'ambiente presenta scarsa attività malevola, oppure che i dispositivi non utilizzano il resolver protettivo. Correla gli eventi rilevanti con l'identità di rete, come un SSID, una VLAN, una sede o un gruppo utente, in modo che chi analizza i dati possa vedere dove si applica una policy e dove potrebbe nascondersi un'eccezione. Confronta l'attività DNS con i dati degli endpoint o degli incidenti anziché sostenere che ogni ricerca bloccata rappresenti un incidente evitato.
Tratta i log DNS come dati operativi sensibili
I log DNS possono rivelare le abitudini di navigazione, il che richiede particolare attenzione in contesti sanitari, scolastici, ricettivi e residenziali. Imposta limiti di conservazione, limita l'accesso in base al ruolo e mantieni i dati di telemetria di sicurezza separati dai dati di marketing degli ospiti. Stabilisci chi può indagare su un evento di sicurezza e di quali dati necessita prima di raccogliere log su larga scala.
Prossimi passi per pianificare il rilascio del Protective DNS
Inizia dal percorso di rete, non dalla dashboard. Mappa quali dispositivi utilizzano il resolver gestito, individua dove il DNS diretto o il DNS crittografato non autorizzato potrebbero aggirarlo e stabilisci come funzionerà l'applicazione dei criteri per i dispositivi non gestiti dall'organizzazione. Includi una procedura di gestione delle eccezioni per i servizi legittimi bloccati dai criteri.
Prima del rilascio, concordate in che modo il team valuterà sia la sicurezza che la qualità del servizio:
- Confermare l'uso del resolver: verificare i dispositivi gestiti, le reti guest e i dispositivi meno prevedibili come l'IoT.
- Testare il percorso di rete: laddove sia richiesta l'applicazione delle regole, esaminare il DNS diretto e i percorsi DNS crittografati non autorizzati.
- Misurare le prestazioni: confrontare la latenza delle ricerche a cache fredda e calda, inclusi i percentili più lenti.
- Definire la scheda di valutazione: monitorare la gestione dei falsi positivi, la disponibilità, la propagazione dei criteri, i tentativi di aggiramento e gli esiti degli incidenti.
- Stabilire le regole sulla privacy: definire i limiti di accesso e di conservazione dei log prima che inizi la raccolta su larga scala.
Per un'implementazione multi-sito, riunisci i team di rete e di sicurezza per mappare identità, segmenti di rete, percorsi dei resolver e le eccezioni richieste da ciascuna sede. Purple offre sessioni di progettazione guidate da ingegneri di rete per definire e convalidare i piani di deployment. Il DNS protettivo può rendere più difficili da raggiungere le destinazioni dannose attraverso il percorso di ricerca gestito, ma non sostituisce la sicurezza degli endpoint, la segmentazione della rete o la governance della privacy.
Purple Access supporta reti WiFi aperte, sicure e xPSK, con assegnazione di rete basata sull'identità e onboarding di ospiti o BYOD sugli access point esistenti. Per pianificare come tali controlli di accesso possano funzionare insieme al protective DNS nei tuoi siti, visita Purple Access.
