NIST SP 800-81r3: cosa cambia con la nuova guida alla sicurezza DNS
Di CaptainDNS
Pubblicato il 21 marzo 2026
- Il NIST ha pubblicato lo SP 800-81r3 il 19 marzo 2026, primo aggiornamento della guida alla sicurezza DNS in 13 anni
- Cinque novità principali: Protective DNS, DNS cifrato (DoT/DoH/DoQ), Zero Trust, OT/IoT e logging forense
- Obbligatorio per le agenzie federali statunitensi (Executive Order Biden), documento di riferimento per la conformità NIS2 in Europa
- DNSSEC rafforzato con QNAME minimization, Compact Denial-of-Existence e migrazione verso ECDSA
- Impatto diretto sulla sicurezza email: SPF, DKIM e DMARC si basano sull'integrità del DNS
- Piano d'azione in 6 passi per raggiungere la conformità
Il 19 marzo 2026, il National Institute of Standards and Technology ha pubblicato la revisione 3 della Special Publication 800-81, la guida federale di riferimento per la messa in sicurezza del DNS. L'ultimo aggiornamento risaliva al 2013: tredici anni durante i quali il panorama DNS è stato trasformato. Esplosione del cloud, architetture Zero Trust, ransomware industrializzato, DNS cifrato (DoT, DoH, DoQ), diffusione massiccia dell'IoT. Il documento del 2013 non copriva nessuno di questi temi.
L'urgenza di questa revisione si legge nei numeri. Secondo i rapporti IDC e Infoblox, il 92% dei malware utilizza il DNS come canale di comunicazione con i propri server di comando (C2). Tra l'88 e il 90% delle organizzazioni ha subito almeno un attacco mirato alla propria infrastruttura DNS. Il costo medio per incidente supera 1,1 milioni di dollari. Nel 2024, la ricerca Infoblox "Sitting Ducks" ha rivelato oltre 800.000 domini vulnerabili al dirottamento, di cui 70.000 già compromessi. Nello stesso anno, la falla KeyTrap (CVE-2023-50387), una vulnerabilità DNSSEC rimasta latente per 24 anni, ha dimostrato che le fondamenta stesse necessitavano un rafforzamento.
Lo SP 800-81r3 copre 52 pagine e ristruttura completamente la dottrina attorno ai ruoli operativi DNS (resolver, server autoritativo, amministratore di zona) anziché alle famiglie di controlli SP 800-53. Gli autori: Scott Rose (NIST), Cricket Liu e Ross Gibson (Infoblox). Al di là del perimetro federale statunitense, questa guida diventa un riferimento internazionale. L'ENISA la cita già come documento di implementazione per la direttiva europea NIS2.
Il tuo dominio rispetta le raccomandazioni NIST?
13 anni di ritardo: perché questa revisione era urgente
Lo SP 800-81-2, pubblicato a settembre 2013, rifletteva un DNS ancora in gran parte in chiaro. DNSSEC esisteva ma restava agli albori. Il concetto di DNS cifrato non aveva ancora un RFC. Lo Zero Trust era solo un'idea accademica. L'IoT industriale non esisteva alla scala che conosciamo oggi.
Dal 2013, il panorama è cambiato radicalmente. Nel 2016, l'RFC 7858 ha standardizzato DNS over TLS (DoT). Nel 2018, l'RFC 8484 ha introdotto DNS over HTTPS (DoH). Nel 2022, l'RFC 9250 ha aggiunto DNS over QUIC (DoQ). Nel 2020, il NIST stesso ha pubblicato lo SP 800-207, il riferimento per la Zero Trust Architecture, senza mai aggiornare la guida DNS per integrare questa dottrina.
L'evoluzione degli attacchi ha reso l'obsolescenza insostenibile. L'attacco "Sitting Ducks", documentato da Infoblox nel 2024, sfrutta delegazioni DNS orfane per dirottare domini senza compromettere il registrar. Sugli 800.000 domini identificati come vulnerabili, 70.000 erano già stati dirottati da gruppi cybercriminali (Vacant Viper, Horrid Hawk, Vextrio). Nello stesso anno, la vulnerabilità KeyTrap (CVE-2023-50387) ha dimostrato che un singolo pacchetto DNS appositamente costruito poteva paralizzare un resolver DNSSEC per diverse ore, una falla presente nel protocollo dal 1999.
Sul fronte dell'adozione DNSSEC, i numeri ristagnano. Circa il 35% dei domini mondiali è firmato. Negli Stati Uniti, solo il 37% dei domini .gov dispone di una validazione DNSSEC completa. Lo SP 800-81-2 raccomandava già DNSSEC, ma senza fornire indicazioni operative sufficienti per raggiungere un dispiegamento di massa.
Altro cambiamento strutturale: la revisione 3 abbandona l'allineamento con le famiglie di controlli SP 800-53 (AC, SC, AU) per organizzare il documento attorno ai ruoli operativi DNS. Questa scelta riflette il feedback delle squadre infrastruttura: un amministratore di zona non ragiona in termini di controlli NIST, ma in termini di operazioni quotidiane (firma di zona, rotazione delle chiavi, configurazione del resolver).
I 5 pilastri del NIST SP 800-81r3
Protective DNS: il DNS come arma difensiva
Il Protective DNS (PDNS) è la novità più strutturante dello SP 800-81r3. Il concetto: trasformare il resolver DNS in un punto di filtraggio attivo, alimentato da flussi di threat intelligence, per bloccare le risoluzioni verso domini malevoli in tempo reale.
Il funzionamento si basa sull'integrazione di Response Policy Zones (RPZ), liste di blocco gestite da team di sicurezza e basi di threat intelligence. Quando una postazione di lavoro o un server tenta di risolvere un dominio identificato come malevolo (phishing, C2, esfiltrazione), il resolver PDNS intercetta la richiesta e restituisce una risposta di blocco o di reindirizzamento verso una pagina di avviso.
Lo SP 800-81r3 rende il Protective DNS una raccomandazione formale, e non più una semplice buona pratica. Questo cambiamento di status ha conseguenze dirette per le agenzie federali, che dovranno giustificare qualsiasi infrastruttura DNS priva di capacità PDNS.
La posta in gioco è considerevole: se il 92% dei malware comunica con la propria infrastruttura di comando via DNS, il PDNS taglia questo canale prima ancora che il malware possa operare. Il programma CISA Protective DNS è già dispiegato in diverse agenzie. Resolver pubblici come Quad9 (9.9.9.9) integrano nativamente capacità PDNS. Le soluzioni commerciali (Infoblox BloxOne Threat Defense, Cisco Umbrella, Akamai Enterprise Threat Protector) aggiungono livelli di analisi comportamentale e machine learning.
Lo SP 800-81r3 non prescrive un'implementazione specifica. Richiede che i resolver DNS delle organizzazioni dispongano di una capacità di filtraggio basata sulla reputazione dei domini, con aggiornamenti regolari delle fonti di threat intelligence.
La cifratura delle richieste entra nello standard
Lo SP 800-81r3 ufficializza la raccomandazione di utilizzare protocolli DNS cifrati per il traffico tra lo stub resolver (client) e il resolver ricorsivo. È una svolta rispetto alla revisione 2, che non copriva affatto l'argomento.
L'Executive Order di gennaio 2025 sul rafforzamento della cybersicurezza ha accelerato la formalizzazione. Impone alle agenzie federali di dispiegare il DNS cifrato entro 180 giorni. Lo SP 800-81r3 fornisce il quadro tecnico per questo obbligo.
Tre protocolli sono trattati. DNS over TLS (DoT), definito dall'RFC 7858, utilizza la porta dedicata 853 e un canale TCP/TLS. È il protocollo più maturo lato infrastruttura. DNS over HTTPS (DoH), definito dall'RFC 8484, transita sulla porta 443, mescolato al traffico HTTPS classico. È ampiamente diffuso nei browser (Firefox, Chrome, Edge). DNS over QUIC (DoQ), definito dall'RFC 9250, combina i vantaggi di TLS con il trasporto QUIC: nessun blocco in testa alla coda (head-of-line blocking), ripresa 0-RTT, migliore gestione della mobilità.
Lo SP 800-81r3 affronta anche la tensione tra cifratura e visibilità di rete. Il DNS cifrato impedisce l'ispezione del traffico DNS da parte degli apparati di rete tradizionali (firewall, IDS/IPS). Il documento raccomanda di combinare DNS cifrato e Protective DNS: la cifratura protegge la confidenzialità delle richieste sulla rete, mentre il resolver PDNS conserva la visibilità necessaria per il filtraggio.
DNSSEC rafforzato, non sostituito
Lo SP 800-81r3 conferma che DNSSEC resta la base dell'integrità DNS. Il DNS cifrato protegge la confidenzialità del trasporto, ma solo DNSSEC garantisce l'autenticità e l'integrità delle risposte. Le due tecnologie sono complementari, non intercambiabili. Cifrare una bugia non la rende vera: senza DNSSEC, un resolver non può distinguere una risposta autentica da una falsificata, nemmeno attraverso un canale crittografato.
La revisione 3 introduce tre avanzamenti per DNSSEC. Il primo è la QNAME minimization (RFC 9156): anziché inviare il nome di dominio completo a ogni server autoritativo nella catena di risoluzione, il resolver invia solo la parte necessaria per proseguire. Questo riduce le fughe di informazioni verso i server intermedi.
Il secondo è il Compact Denial-of-Existence, un'alternativa a NSEC3 per dimostrare l'inesistenza di un dominio. NSEC3 utilizza hash per evitare l'enumerazione di zona, ma resta costoso in termini di calcolo e banda. Il Compact Denial-of-Existence semplifica il meccanismo conservando la protezione contro l'enumerazione.
Il terzo è la migrazione algoritmica. Lo SP 800-81r3 raccomanda la transizione verso ECDSA P-256 (algoritmo 13) per le nuove zone e incoraggia la deprecazione progressiva di RSA. Le firme ECDSA sono più corte (64 byte contro 256 per RSA-2048), il che riduce la dimensione delle risposte DNS e attenua i rischi di amplificazione.
Le lezioni di KeyTrap sono integrate. Il documento sottolinea l'importanza degli aggiornamenti regolari dei resolver e del monitoraggio degli advisory di sicurezza legati a DNSSEC. Per comprendere nel dettaglio il funzionamento della validazione DNSSEC, consulta la nostra guida sulla catena di fiducia DNSSEC.
Zero Trust: il DNS come punto di controllo
Lo SP 800-207 (Zero Trust Architecture), pubblicato nel 2020, definisce i principi del "non fidarti mai, verifica sempre". Lo SP 800-81r3 integra il DNS in questa architettura posizionando il resolver come Policy Enforcement Point (PEP).
In un'architettura Zero Trust, ogni richiesta di accesso viene valutata in base al contesto: identità dell'utente, stato del terminale, posizione nella rete, orario. Il DNS interviene al primissimo stadio della comunicazione di rete. Prima che un terminale stabilisca una connessione TCP o TLS, risolve un nome di dominio. Il resolver diventa quindi il primo punto in cui una politica di accesso può essere applicata.
Lo SP 800-81r3 dettaglia come segmentare i resolver DNS per zone di fiducia. I terminali della rete interna utilizzano un resolver PDNS con politiche rigorose. I terminali ospiti o BYOD passano attraverso un resolver distinto, con restrizioni aggiuntive. I sistemi critici (OT, SCADA) dispongono di resolver dedicati, isolati dalla rete aziendale.
I segnali DNS vengono inoltre sfruttati per alimentare i sistemi SIEM e SOAR. Un picco di risoluzioni verso domini appena registrati (NRD), richieste DNS insolite (tunneling, esfiltrazione via record TXT) o un cambio improvviso di pattern di risoluzione possono attivare allarmi automatizzati.
OT/IoT: sicurezza DNS ai confini della rete
Per la prima volta, un documento SP 800-81 dedica una sezione agli ambienti di tecnologia operativa (OT) e all'Internet of Things. Lo SP 800-81r3 non lascia spazio ad ambiguità: le apparecchiature industriali e i dispositivi connessi rappresentano punti ciechi DNS nella maggior parte delle organizzazioni.
I vincoli sono concreti. Molti dispositivi IoT utilizzano stub resolver minimali, incapaci di validare DNSSEC o di negoziare una connessione TLS. I controllori industriali (SCADA, PLC) operano su reti segmentate con banda limitata e aggiornamenti software rari. Alcune apparecchiature supportano solo DNS in chiaro sulla porta UDP 53.
Lo SP 800-81r3 raccomanda un approccio a strati. Poiché i dispositivi stessi non possono cifrare né validare, la sicurezza si sposta sull'infrastruttura: resolver PDNS dedicati per i segmenti OT/IoT, gateway DNS che eseguono la validazione DNSSEC per conto dei client, logging centralizzato del traffico DNS proveniente da questi segmenti per rilevare comportamenti anomali. Il documento insiste sull'isolamento: un resolver OT non deve mai essere condiviso con la rete aziendale.
Questo pilastro riconosce una realtà che le guide precedenti ignoravano: in un mondo dove un sensore di temperatura compromesso può diventare il punto d'ingresso per un ransomware industriale, il DNS è spesso l'unico segnale osservabile.
Logging e forensics DNS
È la prima volta che un documento NIST della serie SP 800-81 dettaglia i requisiti di registrazione DNS. La revisione 2 menzionava brevemente l'argomento. La revisione 3 ne fa un pilastro a pieno titolo.
Lo SP 800-81r3 specifica cosa deve essere registrato a livello di resolver: ogni richiesta e ogni risposta, con i metadati associati. Come minimo: timestamp, indirizzo IP sorgente, QNAME (nome di dominio interrogato), QTYPE (tipo di richiesta: A, AAAA, MX, TXT), RCODE (codice di risposta: NOERROR, NXDOMAIN, SERVFAIL) e indicatori DNSSEC (AD flag, validation status).
Il documento raccomanda l'integrazione diretta dei log DNS in un SIEM. I casi d'uso forensi sono espliciti: ricostruire la catena di attacco tramite le risoluzioni DNS (un ransomware risolve sempre il dominio del C2 prima di scaricare il suo payload), rilevare l'esfiltrazione di dati via sottodomini DNS (il DNS tunneling codifica dati nelle richieste), identificare i domini di staging utilizzati prima di un attacco.
La conservazione dei log viene affrontata senza prescrivere una durata fissa. Lo SP 800-81r3 raccomanda di allineare la conservazione alla politica dell'organizzazione e ai requisiti normativi applicabili (FISMA, NIS2, PCI DSS).
Anche il Passive DNS (pDNS) è trattato. Si tratta di raccogliere le risposte DNS osservate per costituire uno storico di risoluzione. Questo storico permette di rilevare cambiamenti sospetti (un dominio legittimo che punta improvvisamente a un IP presso un hosting bulletproof) e di correlare indicatori di compromissione. Per implementare un monitoraggio continuo dei tuoi record DNS, consulta la nostra guida al monitoring DNS resiliente.
Cosa è cambiato rispetto alla revisione 2
La tabella qui sotto riassume le differenze tra lo SP 800-81-2 (2013) e lo SP 800-81r3 (2026).
| Tema | SP 800-81-2 (2013) | SP 800-81r3 (2026) |
|---|---|---|
| DNS cifrato | Non trattato | DoT, DoH, DoQ raccomandati |
| Protective DNS | Non trattato | Raccomandazione formale |
| Zero Trust | Anteriore al concetto | Integrazione SP 800-207 |
| DNSSEC | Indicazioni base | QNAME min., Compact DoE, migrazione algo |
| OT/IoT | Non trattato | Sezione dedicata |
| Logging | Citato brevemente | Requisiti dettagliati, SIEM |
| Struttura | Allineato SP 800-53 | Per ruoli operativi |
| Autori | Solo NIST | NIST + Infoblox |
Tre punti meritano di essere sottolineati. La co-redazione con Infoblox è inedita per uno SP 800-81: traduce la volontà del NIST di ancorare il documento nella realtà operativa piuttosto che nella teoria. La sezione OT/IoT riconosce che gli ambienti industriali hanno vincoli specifici (resolver embedded, banda limitata, impossibilità di dispiegare DNSSEC su alcuni dispositivi). La ristrutturazione per ruoli operativi facilita la lettura da parte dei team infrastruttura, che possono concentrarsi sulle sezioni che li riguardano direttamente.
Impatto normativo: chi è interessato?
Agenzie federali statunitensi
Per le agenzie federali, lo SP 800-81r3 è direttamente applicabile nel quadro del Federal Information Security Modernization Act (FISMA). Ogni agenzia deve allineare la propria postura DNS alle raccomandazioni del documento nel prossimo ciclo di valutazione.
L'Executive Order di gennaio 2025 rafforza questo obbligo. Impone il dispiegamento del DNS cifrato entro 180 giorni per tutte le agenzie del potere esecutivo. Lo SP 800-81r3 fornisce il quadro tecnico di riferimento per soddisfare questa esigenza.
L'impatto si estende ai fornitori cloud via FedRAMP. Ogni fornitore di servizi cloud che cerca un'autorizzazione FedRAMP dovrà dimostrare che la propria infrastruttura DNS rispetta le raccomandazioni dello SP 800-81r3. Questo riguarda AWS GovCloud, Azure Government, Google Cloud for Government e tutti i fornitori SaaS che trattano dati federali.
Anche la catena di approvvigionamento è coinvolta. I subappaltatori e prestatori delle agenzie federali dovranno allineare la propria postura DNS per conservare i contratti governativi. Lo SP 800-81r3 diventerà un criterio di valutazione nelle gare d'appalto federali.
Impatto della direttiva europea NIS2
La direttiva NIS2, in vigore da ottobre 2024, impone alle entità essenziali e importanti di implementare misure di sicurezza di rete proporzionate ai rischi. Il DNS è esplicitamente coperto dal perimetro della direttiva.
L'ENISA (Agenzia dell'Unione europea per la cybersicurezza) cita lo SP 800-81 come documento di implementazione di riferimento nelle sue guide tecniche. La pubblicazione dello SP 800-81r3 aggiorna questo riferimento. Le organizzazioni soggette a NIS2 potranno appoggiarsi allo SP 800-81r3 per documentare la propria postura DNS presso le autorità nazionali.
I settori interessati da NIS2 sono ampi: energia, trasporti, sanità, acqua, infrastruttura digitale, servizi finanziari, pubblica amministrazione, spazio, alimentazione, chimica, ricerca. Qualsiasi organizzazione di questi settori con più di 50 dipendenti o con un fatturato superiore a 10 milioni di euro è potenzialmente nel perimetro.
Le sanzioni NIS2 sono dissuasive: fino a 10 milioni di euro o il 2% del fatturato mondiale per le entità essenziali, 7 milioni di euro o l'1,4% per le entità importanti.
Organizzazioni private
Le imprese fuori dal perimetro federale o NIS2 non sono direttamente soggette allo SP 800-81r3. Ma il documento si impone come standard de facto attraverso diversi meccanismi indiretti.
Gli assicuratori cyber integrano sempre di più la postura DNS nei loro questionari di sottoscrizione. Un'organizzazione incapace di dimostrare capacità PDNS, un dispiegamento DNSSEC o una registrazione DNS potrà vedersi rifiutare la copertura o vedersi imporre premi maggiorati.
Anche la pressione della catena di approvvigionamento agisce. Se i tuoi clienti sono agenzie federali o entità NIS2, esigeranno dai propri fornitori una postura DNS allineata allo SP 800-81r3. Questa esigenza discende a cascata nell'intera catena di subfornitura.
La sicurezza email si basa sul DNS
SPF, DKIM e DMARC sono record DNS. Un resolver che valida l'indirizzo IP di un mittente confrontandolo con un record SPF si basa sull'integrità della risposta DNS. Se un attaccante avvelena la cache del resolver e sostituisce un record SPF falsificato, l'intera catena di autenticazione email crolla.
DNSSEC protegge da questo scenario. Firmando i record MX, SPF (TXT), DKIM (TXT) e DMARC (TXT), DNSSEC garantisce che il resolver validi dati autentici. Senza DNSSEC, un attaccante capace di effettuare un cache poisoning può usurpare l'identità email di un dominio, aggirare le politiche DMARC e inviare email fraudolente a nome dell'organizzazione bersaglio.
Lo SP 800-81r3 sottolinea questa dipendenza. Raccomanda di considerare la sicurezza email e la sicurezza DNS come un insieme inscindibile. Dispiegare DMARC con una politica p=reject senza attivare DNSSEC equivale a chiudere a chiave la porta d'ingresso lasciando la finestra aperta.
DANE (DNS-based Authentication of Named Entities) va oltre. Tramite record TLSA protetti da DNSSEC, DANE permette di autenticare il certificato TLS del server di posta destinatario. Questo elimina la dipendenza dalle autorità di certificazione terze e garantisce la cifratura end-to-end del trasporto SMTP.
MTA-STS costituisce un'alternativa quando DNSSEC non è ancora dispiegato sul dominio. Utilizza HTTPS per pubblicare una politica di trasporto sicuro. Lo SP 800-81r3 raccomanda entrambi gli approcci, con una preferenza per DANE quando DNSSEC è disponibile.
Verifica subito che i tuoi record di autenticazione email siano configurati correttamente con il nostro DMARC Checker.
Piano d'azione: 6 passi per adeguarsi
1. Eseguire l'audit dell'infrastruttura DNS esistente. Inizia con un inventario completo delle tue zone DNS, server autoritativi e resolver. Identifica le zone non firmate, i resolver senza capacità di validazione DNSSEC e i flussi DNS in chiaro. CaptainDNS può automatizzare questa verifica.
2. Dispiegare DNSSEC su tutte le zone. Firma ogni zona con DNSSEC privilegiando l'algoritmo ECDSA P-256 (algoritmo 13). Verifica che i DS record siano correttamente propagati al TLD. Pianifica una rotazione regolare delle chiavi (ZSK ogni 3 mesi, KSK ogni 12-24 mesi). Consulta la nostra guida passo passo per attivare DNSSEC per un dispiegamento senza interruzione di servizio.
3. Attivare il DNS cifrato. Dispiega DoT sui tuoi resolver interni per proteggere il traffico delle postazioni di lavoro. Per i lavoratori remoti, configura DoH affinché le richieste DNS transitino sulla porta 443, compatibile con la maggior parte delle reti pubbliche. Testa DoQ se il tuo resolver lo supporta, specialmente per gli ambienti ad alta latenza.
4. Implementare il Protective DNS. Valuta le soluzioni PDNS adatte alla tua dimensione: Quad9 come resolver pubblico filtrante, RPZ su un resolver interno (BIND, Unbound, PowerDNS Recursor) o una soluzione commerciale per le organizzazioni più grandi. Configura flussi di threat intelligence e definisci una politica di blocco (NXDOMAIN, reindirizzamento verso pagina informativa o sola registrazione in modalità osservazione).
5. Centralizzare i log DNS. Configura la registrazione su ogni resolver e server autoritativo. Esporta i log verso il tuo SIEM (Splunk, Elastic, Microsoft Sentinel) con i campi minimi raccomandati dallo SP 800-81r3: timestamp, IP sorgente, QNAME, QTYPE, RCODE, indicatori DNSSEC. Definisci regole di correlazione per rilevare il DNS tunneling, le risoluzioni verso domini NRD e i picchi di errori SERVFAIL.
6. Mettere in sicurezza la catena email. Verifica che i tuoi record SPF, DKIM e DMARC siano correttamente pubblicati e protetti da DNSSEC. Dispiega DANE (TLSA) sui tuoi server di posta se il tuo provider DNS supporta DNSSEC. Configura MTA-STS come misura complementare. Attiva TLS-RPT per ricevere report sui fallimenti di negoziazione TLS.
FAQ
Cos'è il NIST SP 800-81r3?
Il NIST SP 800-81r3 è la terza revisione della guida federale statunitense "Secure Domain Name System (DNS) Deployment Guide". Pubblicato il 19 marzo 2026 dal National Institute of Standards and Technology, sostituisce la revisione 2 risalente al 2013. Il documento copre la messa in sicurezza del DNS sotto tutti gli aspetti: DNSSEC, DNS cifrato (DoT, DoH, DoQ), Protective DNS, integrazione Zero Trust, registrazione e ambienti OT/IoT.
Lo SP 800-81r3 è obbligatorio?
È obbligatorio per le agenzie federali statunitensi nel quadro di FISMA e dell'Executive Order di gennaio 2025 sulla cybersicurezza. Per le organizzazioni europee, serve come riferimento di implementazione nel contesto della direttiva NIS2. Per le imprese private, costituisce uno standard de facto, sempre più richiesto dagli assicuratori cyber e dai committenti soggetti a obblighi normativi.
Cos'è il Protective DNS?
Il Protective DNS (PDNS) è un resolver DNS arricchito con capacità di filtraggio basate sulla threat intelligence. Blocca in tempo reale le risoluzioni verso domini identificati come malevoli (phishing, comando e controllo di malware, esfiltrazione di dati). Il meccanismo si basa su Response Policy Zones (RPZ) e flussi di intelligence sulle minacce aggiornati in continuo.
Qual è la differenza tra DoT, DoH e DoQ?
DNS over TLS (DoT) utilizza un canale TCP/TLS dedicato sulla porta 853. DNS over HTTPS (DoH) incapsula le richieste DNS nel traffico HTTPS sulla porta 443. DNS over QUIC (DoQ) utilizza il protocollo QUIC direttamente, combinando cifratura TLS e trasporto senza blocco in testa alla coda. DoT è il più maturo lato infrastruttura, DoH il più diffuso nei browser, DoQ il più performante in ambienti a latenza variabile.
DNSSEC è ancora raccomandato nel 2026?
Sì. Lo SP 800-81r3 riafferma DNSSEC come unica tecnologia che garantisce l'autenticità e l'integrità delle risposte DNS. Il DNS cifrato (DoT, DoH, DoQ) protegge la confidenzialità del trasporto, ma non verifica che la risposta provenga effettivamente dal server autoritativo legittimo. Le due tecnologie sono complementari. Lo SP 800-81r3 aggiunge raccomandazioni sulla QNAME minimization, il Compact Denial-of-Existence e la migrazione verso l'algoritmo ECDSA P-256.
Qual è il legame tra DNS e sicurezza email?
SPF, DKIM e DMARC sono record DNS. La validazione di un'email si basa sull'interrogazione di questi record da parte del server destinatario. Senza DNSSEC, un attaccante può avvelenare la cache DNS e sostituire record falsificati, aggirando così l'intera catena di autenticazione email. Lo SP 800-81r3 raccomanda di trattare la sicurezza DNS e la sicurezza email come un insieme inscindibile.
Quanto tempo serve per adeguarsi?
La durata dipende dalla maturità esistente. Un'organizzazione che dispone già di DNSSEC e di un resolver centralizzato può adeguarsi in 3-6 mesi. Un'organizzazione che parte da zero dovrà prevedere 6-12 mesi per un dispiegamento completo che copra DNSSEC, DNS cifrato, Protective DNS e registrazione. L'Executive Order di gennaio 2025 impone un termine di 180 giorni per il DNS cifrato nelle agenzie federali.
Lo SP 800-81r3 si applica alle PMI?
Lo SP 800-81r3 è rivolto alle agenzie federali statunitensi, ma le sue raccomandazioni sono pertinenti per qualsiasi organizzazione. Le PMI europee soggette a NIS2 (più di 50 dipendenti o 10 milioni di euro di fatturato nei settori coperti) devono documentare la propria postura DNS. Le PMI fuori dal perimetro normativo beneficiano comunque di un quadro strutturato per dare priorità ai propri investimenti in sicurezza DNS.
Glossario
- NIST: National Institute of Standards and Technology. Agenzia federale statunitense che pubblica gli standard e le guide di sicurezza informatica di riferimento per il governo federale.
- SP 800-81: Special Publication 800-81, guida NIST dedicata al dispiegamento sicuro del DNS. La revisione 3 (r3) è la versione pubblicata il 19 marzo 2026.
- DNSSEC: Domain Name System Security Extensions. Insieme di estensioni che aggiungono firme crittografiche alle risposte DNS per garantirne l'autenticità e l'integrità.
- DoT (DNS over TLS): protocollo di cifratura DNS definito dall'RFC 7858. Utilizza un canale TLS dedicato sulla porta TCP 853 tra il client e il resolver.
- DoH (DNS over HTTPS): protocollo di cifratura DNS definito dall'RFC 8484. Incapsula le richieste DNS nel traffico HTTPS sulla porta 443.
- DoQ (DNS over QUIC): protocollo di cifratura DNS definito dall'RFC 9250. Utilizza il trasporto QUIC per combinare cifratura e performance (nessun head-of-line blocking, ripresa 0-RTT).
- Protective DNS (PDNS): resolver DNS arricchito con capacità di filtraggio in tempo reale. Blocca le risoluzioni verso domini malevoli basandosi su flussi di threat intelligence.
- RPZ (Response Policy Zone): meccanismo DNS che permette di definire politiche di risposta personalizzate. Utilizzato dai resolver PDNS per bloccare o reindirizzare le richieste verso domini malevoli.
- QNAME minimization: tecnica (RFC 9156) che riduce la quantità di informazioni trasmesse ai server autoritativi intermedi durante la risoluzione. Solo la parte del nome necessaria per proseguire nella risoluzione viene inviata.
- Zero Trust: modello di sicurezza fondato sul principio "non fidarti mai, verifica sempre". Lo SP 800-207 del NIST ne definisce l'architettura di riferimento.
- NIS2: direttiva europea (2022/2555) sulla sicurezza delle reti e dell'informazione. In vigore da ottobre 2024, impone obblighi di cybersicurezza alle entità essenziali e importanti.
- FISMA: Federal Information Security Modernization Act. Legge statunitense che impone alle agenzie federali di implementare programmi di sicurezza conformi agli standard NIST.
