Vulnerabilità del DNS: 10 punti deboli comuni e come risolverli

Una vulnerabilità DNS è un punto debole nella configurazione, nell’hosting o nella gestione del DNS di un dominio che un malintenzionato può sfruttare, come ad esempio un resolver aperto, una firma DNSSEC mancante o un record CNAME dimenticato. La maggior parte di questi punti deboli deriva da configurazioni errate e record non aggiornati piuttosto che da difetti del software, il che significa che è possibile individuarli e risolverli prima che si verifichi un incidente.

Cosa sono le vulnerabilità del DNS?

Una vulnerabilità DNS è un difetto operativo, architettonico o di configurazione nell'implementazione del sistema dei nomi di dominio (DNS) che compromette la riservatezza, l'integrità o la disponibilità del traffico di rete.

Queste vulnerabilità si riscontrano in genere in quattro livelli operativi fondamentali:

Gestione del registrar e degli account: Credenziali condivise, mancanza di autenticazione a più fattori e blocchi del registro omessi che lasciano esposto il controllo dei vostri server dei nomi.
Server dei nomi autoritativi: Regole di trasferimento di zona troppo permissive, demoni del server non aggiornati, mancanza di limiti alla frequenza delle query o assenza di ridondanza dei provider.
Resolver e trasporto: Resolver ricorsivi accessibili dalla rete Internet pubblica, trasmissione non crittografata tramite UDP in chiaro o ID di transazione con randomizzazione inadeguata.
Record DNS: Voci CNAME orfane che puntano a infrastrutture dismesse, catene crittografiche DNSSEC mancanti o record di posta elettronica e certificati assenti.

È importante distinguere le vulnerabilità dagli attacchi. Una vulnerabilità è il difetto o l’errore di configurazione sottostante presente nel proprio sistema. Un attacco è lo sfruttamento deliberato di tale punto debole da parte di un soggetto malintenzionato. Comprendere questa distinzione consente ai team di sicurezza di eliminare i punti deboli prima che gli attacchi DNS possano concretizzarsi.

10 vulnerabilità comuni del DNS

Le dieci vulnerabilità di sicurezza riportate di seguito rappresentano i difetti più comuni riscontrati nelle implementazioni DNS aziendali.

1. Risolutori DNS aperti {#open-dns-resolvers}

Un resolver ricorsivo aperto è un server DNS connesso alla rete Internet pubblica che risolve le query ricorsive per chiunque, anziché limitare la risoluzione ai soli client locali autorizzati.

Cosa consente: Gli aggressori falsificano l'indirizzo IP di origine della vittima e inviano query a resolver aperti, generando enormi carichi di risposta che sovraccaricano la vittima in un attacco di attacchi DDoS DDoS di amplificazione DNS distribuiti.
Come verificare: Eseguire una query sull'indirizzo del server pubblico da una rete esterna:

dig @<your-server-ip> example.com

Se il server restituisce una risposta contenente il flag ra (ricorsione disponibile), il tuo resolver è vulnerabile alla ricorsione pubblica non autorizzata.
Soluzione: Disattivare completamente la ricorsione sui server autoritativi oppure limitarla a intervalli di indirizzi IP e sottoreti attendibili utilizzando gli elenchi di controllo degli accessi (ACL) secondo le nostre migliori pratiche di sicurezza DNS.

2. DNSSEC mancante o non funzionante

Il protocollo DNSSEC (Domain Name System Security Extensions) utilizza firme crittografiche per verificare l'autenticità dei dati DNS. Operare senza DNSSEC, oppure consentire che le configurazioni crittografiche ignorino i record RRSIG scaduti o i record DS non corrispondenti presso il registrar, comporta che le risoluzioni rimangano non verificate.

Cosa consente: Senza verifica crittografica, i resolver ricorsivi possono accettare pacchetti di risposta contraffatti iniettati dagli aggressori lungo il percorso di rete, causando il l'avvelenamento della cache e al reindirizzamento del traffico.
Come verificare: Verifica la catena crittografica del tuo dominio utilizzando il nostro strumento gratuito basato su browser strumento di verifica DNSSEC, oppure scopri come le firme associano i record nella nostra guida introduttiva su DNSSEC.
Soluzione: Firmare i file di zona, pubblicare i record Delegation Signer (DS) corrispondenti presso il proprio registrar di dominio e implementare procedure automatizzate di rotazione delle chiavi per prevenire interruzioni della convalida.

3. Trasferimenti senza restrizioni di zona (AXFR)

Il trasferimento completo asincrono (AXFR) è un meccanismo di protocollo progettato per sincronizzare i dati della zona tra i server dei nomi primari e secondari. Un trasferimento di zona senza restrizioni consente a qualsiasi utente su Internet di richiedere e scaricare l'intero file di zona.

Cosa comporta: Fughe di informazioni di ricognizione. Gli avversari ottengono una mappa completa della vostra superficie di attacco digitale, che rivela le convenzioni di denominazione interne, i server di staging, i gateway VPN e i sottodomini non elencati.
Come verificare: Prova a eseguire una query di trasferimento di zona direttamente sul tuo server dei nomi autoritativo:

dig AXFR example.com @ns1.example.com

Un server sicuro risponde con Trasferimento non riuscito oppure rifiuta la connessione. Se il comando restituisce un elenco completo dei record, le impostazioni di trasferimento sono attive.
Soluzione: Limitare le richieste AXFR esclusivamente agli indirizzi IP espliciti appartenenti a server dei nomi secondari autenticati tramite liste di controllo degli accessi (ACL) rigorose.

4. Record DNS non risolti

Un record DNS "dangling" si verifica quando una voce nella propria zona (ad esempio un record CNAME, A o NS) punta a una risorsa cloud esterna, a un host web o a un bucket di archiviazione che è stato dismesso o eliminato senza che sia stato rimosso il corrispondente puntatore DNS.

Cosa consente: Gli autori delle minacce identificano il nome del target abbandonato, configurano quella stessa risorsa sulla piattaforma del provider (come AWS, Azure, GitHub Pages o Heroku) e ne assumono il controllo in un' presa di controllo del sottodominio.
Come verificare: Esporta la tua zona utilizzando il nostro completo strumento di ricerca dei record DNS e verifica che ogni endpoint esterno, destinazione CNAME e host cloud rimanga attivamente rivendicato dalla tua organizzazione.
Soluzione: Adottare protocolli automatizzati di dismissione per eliminare i record DNS corrispondenti ogni volta che l'infrastruttura cloud o i servizi web di terze parti vengono dismessi.

5. Scarsa sicurezza degli account dei registrar

I registrar di domini gestiscono le deleghe dei server dei nomi di primo livello per i tuoi domini. Proteggere il portale del registrar con credenziali a fattore singolo, caselle di posta amministrative condivise o non attivare i blocchi di protezione a livello di registrar crea un punto singolo di errore.

Cosa consente: Gli aggressori compromettono le credenziali di accesso del registrar, modificano le deleghe dei server dei nomi autoritativi e reindirizzano tutto il traffico web e di posta globale verso un'infrastruttura dannosa in un devastante di dirottamento DNS .
Come verificare: Accedi alla console del tuo registrar per verificare se è in uso l'autenticazione a più fattori basata su hardware o su app sia applicata sia applicata a tutti gli account amministratore e se i flag "Registry Lock" o "Registrar Lock" siano attivi.
Soluzione: Rendere obbligatoria l'autenticazione a più fattori per tutti gli accessi ai registrar, applicare i codici di stato "Registry Lock" ai domini critici e istituire un sistema di accesso aziendale dedicato basato sui ruoli.

6. Server DNS e controlli di accesso configurati in modo errato

Le installazioni predefinite dei software presentano spesso impostazioni di accesso troppo permissive, interfacce amministrative accessibili da Internet e banner con le informazioni sulla versione visualizzati in risposta a semplici richieste di sondaggio.

Cosa consente: Gli aggressori individuano il software del server e i livelli delle patch tramite query sui banner come version.bind, individuano le vulnerabilità non corrette e sfruttano i controlli di accesso deboli per manipolare i parametri di configurazione. Consulta la nostra guida introduttiva su cos'è un server DNS per comprendere le linee guida operative di sicurezza.
Come verificare: Interrogare la stringa di identità del server da un terminale:

dig version.bind CHAOS TXT @ns1.example.com

Un server protetto nasconde queste informazioni o restituisce una risposta generica.
Correzione: Nascondere le stringhe relative alla versione del server, limitare l'accesso alle interfacce di gestione alle VPN amministrative, implementare la limitazione della frequenza di risposta (RRL) e applicare il principio del privilegio minimo in tutti i file di configurazione.

7. Punto singolo di errore nell'hosting DNS

Ospitare tutti i server dei nomi autoritativi presso un unico provider DNS, oppure implementare i server dei nomi all’interno dello stesso sistema autonomo (AS) fisico, comporta una pericolosa fragilità operativa.

Cosa comporta: Un attacco DDoS mirato, un'interruzione del servizio da parte del provider o un errore di routing disabilitano completamente i tuoi server dei nomi autoritativi, rendendo i tuoi siti web, le API e la posta elettronica aziendale del tutto irraggiungibili, come dimostrato durante la diffusa interruzione del servizio Dyn del 2016.
Come verificare: Controlla i record NS del tuo dominio per verificare se i tuoi server dei nomi risolvono su blocchi di rete distinti e sistemi autonomi indipendenti.
Soluzione: Implementare un'architettura DNS secondaria con doppio provider, distribuendo la risoluzione autorevole su due servizi DNS separati e geograficamente distanti.

8. Traffico DNS non crittografato

Le query e le risposte DNS tradizionali transitano sulla porta 53 tramite UDP e TCP in chiaro. In assenza di crittografia, ogni ricerca di dominio è leggibile dalle reti locali, dai provider di servizi Internet e dagli operatori di transito.

Cosa consente: Intercettazione lungo il percorso, profilazione degli utenti e manipolazione lungo il percorso, in cui gli aggressori della rete intercettano le query in chiaro e restituiscono risposte fraudolente.
Come verificare: Controllare le impostazioni degli endpoint e dei router per verificare se le risoluzioni vengono instradate tramite DNS over HTTPS (DoH), DNS over TLS (DoT) o DNS over QUIC (DoQ) anziché tramite la porta UDP 53 non crittografata.
Risoluzione: Configurare i resolver locali, gli endpoint e i forwarder in modo da imporre l'uso della crittografia di trasporto moderna utilizzando i protocolli crittografici standard TLS.

9. Software DNS non aggiornato

I demoni DNS come BIND, Unbound, PowerDNS e Windows Server DNS richiedono una manutenzione regolare tramite patch. L'utilizzo di versioni obsolete di questi demoni espone le reti a vulnerabilità note documentate nei database CVE pubblici.

Cosa consente: Esecuzione remota di codice, corruzione della memoria e attacchi basati sulla complessità algoritmica che bloccano i server dei nomi, come la vulnerabilità KeyTrap (CVE-2023-50387) nei motori di convalida DNSSEC o il vettore di avvelenamento della cache DNS SAD (CVE-2020-25705).
Come verificare: Confrontare le stringhe di compilazione dei daemon in esecuzione con gli avvisi di sicurezza dei fornitori e iscriversi ai feed di notifica dei principali sviluppatori di software DNS.
Soluzione: Mantenere programmi di applicazione delle patch regolari, isolare i servizi DNS all'interno di container con restrizioni o ambienti operativi minimi e verificare che le build siano conformi alle versioni di sicurezza più recenti.

10. Mancanza di registri relativi alla sicurezza e alla posta elettronica

La mancata pubblicazione dei record di sicurezza “affirmative” nel file di zona DNS espone il dominio al rischio di emissione non autorizzata di certificati e di spoofing delle e-mail in uscita.

Cosa permette di fare: Senza un record CAA, qualsiasi autorità di certificazione pubblica può emettere certificati SSL/TLS per il tuo nome di dominio. Allo stesso modo, omettendo le politiche SPF, DKIM e le rigide DMARC consente agli spammer di inviare messaggi fraudolenti spacciandosi direttamente per il tuo marchio.
Come verificare: Verifica le tue attuali configurazioni di sicurezza utilizzando il nostro strumento di verifica CAA, verifica le tue politiche di autenticazione con il nostro strumento di verifica dei record DMARC, oppure esegui una valutazione completa tramite l’ analizzatore di domini.
Soluzione: Pubblicare record CAA restrittivi che specificano gli emittenti di certificati autorizzati e applicare il DMARC con p=reject su tutti i domini e sottodomini dell'organizzazione.

Rischi per la sicurezza del DNS: quanto ti costano queste vulnerabilità

Non risolvere le vulnerabilità del DNS comporta rischi diretti per l'azienda in ambito finanziario, operativo e normativo.

Tempi di inattività e perdita di ricavi: Le configurazioni con un unico fornitore e i rischi di amplificazione non mitigati favoriscono l'insorgere di interruzioni che mettono fuori servizio le operazioni web e le piattaforme commerciali.
Intercettazione delle credenziali e reindirizzamenti fraudolenti: il cache poisoning e il dirottamento DNS reindirizzano i visitatori verso server simili, progettati per raccogliere le credenziali di accesso aziendali.
Esfiltrazione dei dati aziendali: I resolver senza restrizioni e i forwarder configurati in modo errato consentono agli aggressori di aggirare i firewall ed esfiltrare i dati interni.
Falsificazione del marchio e compromissione delle e-mail aziendali: L'assenza dei record SPF, DKIM e DMARC consente agli hacker di ingannare clienti, partner e dipendenti con e-mail contraffatte.
Generazione fraudolenta di certificati: L'omissione dei record CAA aumenta la probabilità di creazione di certificati TLS non autorizzati, vanificando i presupposti di sicurezza del trasporto.
Carenze nell’audit e sanzioni normative: Le risorse DNS non gestite violano spesso i requisiti di controllo obbligatori previsti dagli standard SOC 2, ISO 27001 e PCI DSS.

La tabella seguente riassume in che modo le vulnerabilità più comuni nella configurazione del DNS si ricollegano direttamente ai vettori di attacco informatico che esse rendono possibili:

Vulnerabilità DNS individuata	Vettore di attacco abilitato
Resolver ricorsivi aperti	Attacchi di amplificazione e riflessione DNS
DNSSEC mancante o non convalidato	Avvelenamento della cache DNS e spoofing
Trasferimenti in zona senza restrizioni (AXFR)	Ricognizione della superficie di attacco e individuazione della rete interna
Record CNAME e A non associati	Appropriazione indebita di sottodomini e usurpazione di identità degli account
Account di registrar non protetti	Dirottamento DNS e reindirizzamento dei domini
Controlli permissivi sull'accesso ai server dei nomi	Sfruttamento del server e manipolazione non autorizzata delle zone
Provider di hosting con un unico server dei nomi	Interruzione totale del servizio in caso di guasti dei fornitori
Traffico in chiaro sulla porta UDP 53	Intercettazione lungo il percorso e manipolazione non autorizzata delle query
Versioni obsolete del demone DNS	Attacchi denial-of-service da remoto e sfruttamento dei server
Record CAA e DMARC mancanti	Emissione non autorizzata di certificati SSL e spoofing dei domini in uscita

Come verificare la presenza di vulnerabilità DNS nel proprio dominio

L'esecuzione di un audit strutturato su tutto il proprio parco domini consente di individuare eventuali configurazioni errate prima che gli aggressori le individuino:

Esegui una scansione di base del dominio: Inserisci il tuo dominio Apex nel nostro strumento gratuito di analisi dei domini per verificare il tuo stato di sicurezza complessivo e individuare eventuali configurazioni mancanti.
Verifica la tua catena DNSSEC: Verifica le tue chiavi root e delegate con il nostro strumento di controllo DNSSEC per assicurarti che le firme siano valide e che le chiavi non siano scadute.
Test authoritative zone transfer restrictions: Execute dig AXFR example.com @<nameserver> against every authoritative host to confirm that public zone dumping is rejected.
Verifica i permessi di ricorsione: Eseguire una query sui server autoritativi dall'esterno dell'intervallo di indirizzi IP aziendale per assicurarsi che la risoluzione ricorsiva sia disabilitata.
Verifica la presenza di puntatori pendenti nei record della zona attiva: Esportare tutte le voci pubblicate utilizzando il nostro strumento di ricerca dei record DNS e verificare che ogni risorsa cloud esterna e ogni destinazione CNAME rimangano valide.
Verifica i certificati e le protezioni delle e-mail: Verifica le autorità di certificazione autorizzate con il nostro strumento di verifica CAA e conferma le politiche di applicazione con il nostro strumento di verifica dei record DMARC.
Verificare le impostazioni di sicurezza del registrar: Verificare gli elenchi di accesso amministrativo, confermare l'attivazione dell'autenticazione a più fattori e assicurarsi che i blocchi del registro rimangano abilitati.

Un audit una tantum dell'infrastruttura offre una panoramica dello stato attuale, ma per garantire una visibilità costante è necessario un monitoraggio continuo della sicurezza DNS, in modo da individuare eventuali scostamenti in tempo reale.

Come risolvere le vulnerabilità DNS

Per risolvere le vulnerabilità del DNS è necessario dare priorità alle configurazioni amministrative e strutturali ad alto impatto:

Proteggere il livello di gestione: Applicare l'autenticazione a più fattori sui portali dei registrar di dominio e dei DNS cloud, assegnare ruoli con privilegi minimi e abilitare immediatamente le protezioni di blocco del registrar.
Limitare l'esposizione della rete: Limitare i trasferimenti di zona esclusivamente agli indirizzi IP secondari designati, disabilitare la ricorsione sui server autoritativi e implementare la limitazione della frequenza.
Eliminare i record orfani: Eliminare i record CNAME, A e NS non più utilizzati che puntano a infrastrutture abbandonate o ad applicazioni cloud di terze parti non più in uso.
Implementare la verifica crittografica: Firmare le zone con DNSSEC, verificare i record DS del registrar e applicare una rigorosa autenticazione delle e-mail tramite DMARC, SPF e DKIM.

Per consultare il nostro processo completo di rafforzamento della sicurezza amministrativa, leggi le linee guida ufficiali del NIST sulla sicurezza del DNS.

Domande frequenti

Qual è la vulnerabilità DNS più comune?

La vulnerabilità DNS più comune è rappresentata da una configurazione errata. Impostazioni troppo permissive, quali resolver ricorsivi aperti, trasferimenti di zona non autenticati, record "dangling" dimenticati e controlli di accesso amministrativo inadeguati, sono all’origine di un numero di incidenti di sicurezza di gran lunga superiore rispetto agli exploit software “zero-day”.

Qual è la differenza tra una vulnerabilità DNS e un attacco DNS?

Una vulnerabilità DNS è una debolezza intrinseca, un errore di configurazione o una lacuna architettonica all’interno del sistema di dominio. Un attacco DNS è il tentativo attivo da parte di un malintenzionato di sfruttare tale vulnerabilità per rubare dati, reindirizzare il traffico o causare interruzioni del servizio.

La porta 53 rappresenta un rischio per la sicurezza?

La porta 53 non è di per sé dannosa; è la porta standard per il DNS su UDP e TCP. Tuttavia, lasciare la porta 53 aperta alle query ricorsive provenienti dal pubblico in generale trasforma il server in un resolver aperto, vulnerabile agli attacchi di amplificazione e alle ispezioni.

Con quale frequenza dovrei eseguire un audit del DNS per individuare eventuali vulnerabilità?

È opportuno verificare costantemente le configurazioni DNS. Sebbene le verifiche manuali delle autorizzazioni dei registrar e dei file di zona debbano essere effettuate almeno una volta al trimestre, si raccomanda di ricorrere al monitoraggio automatico per individuare immediatamente eventuali modifiche non autorizzate ai record, certificati in scadenza e nomi host non associati non appena si verificano.

Parole finali

Le vulnerabilità del DNS offrono agli aggressori vie di accesso per intercettare il traffico, sferrare attacchi denial-of-service e falsificare i marchi aziendali. Poiché la maggior parte dei problemi di sicurezza del DNS deriva da disattenzioni amministrative di routine e da scostamenti nella configurazione, piuttosto che da exploit di codice zero-day, un controllo proattivo e una manutenzione costante riducono significativamente la superficie di attacco complessiva.