Che cos’è il DNS poisoning? Spiegazione del DNS cache poisoning

Il DNS cache poisoning (DNS spoofing) sfrutta le vulnerabilità del DNS e dei server. Scopri di cosa si tratta e come risolvere questo tipo di attacco informatico.

Un attacco di avvelenamento della cache DNS, noto anche come spoofing DNS , è una di quelle minacce di cui si parla meno rispetto al phishing o al malware. Ignorarla è l’errore peggiore che si possa commettere. Il DNS è alla base di quasi tutto ciò che avviene online. Pertanto, quando viene compromesso, le ripercussioni si diffondono rapidamente. Le conseguenze sono sempre drammatiche: la fiducia nei domini viene minata, l’autenticazione delle e-mail viene compromessa, la sicurezza del trasporto viene indebolita e la reputazione del marchio ne risente. 

Quando qualcuno altera il modo in cui i server di posta o gli utenti risolvono il tuo dominio, di solito si tratta di un caso di usurpazione d’identità, furto di credenziali, phishing o semplicemente di e-mail che smettono di arrivare. 

Ecco cosa succede realmente dietro le quinte e perché è così difficile da individuare.

Che cos’è il “DNS cache poisoning”?

Il compito principale del DNS è quello di tradurre i nomi di dominio in indirizzi IP. Il cache poisoning agisce proprio su questa fase di traduzione. Un malintenzionato invia dati DNS falsificati a un endpoint, a un browser o a un sistema. Pertanto, ogni volta che una vittima cerca di accedere a un determinato sito web, invece di arrivare al sito reale, viene reindirizzata altrove. Spesso si tratta di una pagina simile a quella originale, creata appositamente per raccogliere informazioni. 

Cache DNS assomiglia a un attacco man-in-the-middle. Un resolver riceve dati falsificati, li memorizza e inizia a fornire un indirizzo IP errato per un dominio che, a prima vista, sembra ancora legittimo. Da quel momento in poi, chiunque si affidi al resolver compromesso viene reindirizzato all’IP dell’autore dell’attacco, e ciò continua fino alla scadenza del record memorizzato nella cache. L’autore dell’attacco non ha nemmeno bisogno di intervenire direttamente sul server DNS. È sufficiente una sola risposta falsificata che finisca nella cache del resolver per reindirizzare tutti gli utenti a valle.
Vediamo un esempio di come ciò avvenga nella pratica.

Come funziona il DNS poisoning?

È una questione di tempismo. L’autore dell’attacco deve fare in modo che la risposta falsificata raggiunga il resolver prima di quella autentica. Ecco come si svolge il processo, passo dopo passo:

1. L'utente avvia una query DNS: Un browser o un'applicazione invia una query DNS a un resolver ricorsivo richiedendo l'indirizzo IP di un dominio (ad esempio, bank.com).
2. Il resolver controlla la propria cache: Se la risposta è memorizzata nella cache e rientra ancora nel suo TTL, il resolver la restituisce immediatamente. In caso contrario, inoltra la query a monte ai server DNS autoritativi.
3. L'autore dell'attacco inietta una risposta contraffatta: Prima che arrivi la risposta legittima e autorevole, l'autore dell'attacco invia una risposta DNS contraffatta contenente un indirizzo IP dannoso. Ciò è possibile indovinando o utilizzando un attacco di forza bruta per individuare l'ID della transazione e la porta di origine utilizzati nella query originale, una tecnica nota come attacco Kaminsky.
4. Il resolver memorizza il record contraffatto: Se la risposta falsificata dell’autore dell’attacco arriva per prima e corrisponde all’ID della transazione e alla porta previsti, il resolver accetta e memorizza nella cache l’indirizzo IP fraudolento.
5. Gli utenti vengono reindirizzati: Tutte le successive richieste relative a quel dominio, provenienti da qualsiasi utente che si colleghi al resolver compromesso, restituiscono l'indirizzo IP dell'autore dell'attacco, reindirizzandoli verso un sito fraudolento fino alla scadenza del TTL della cache o allo svuotamento manuale della stessa.

L’autore dell’attacco deve agire prima che scada il TTL dei dati memorizzati nella cache. Il DNS tradizionale non dispone di una validazione crittografica integrata, pertanto i resolver non possono confermare l’autenticità di una risposta a meno che non siano in atto il protocollo DNSSEC e pratiche di sicurezza per i resolver. Fino alla scadenza del record contraffatto, il resolver continua a fornire l’indirizzo IP falso agli utenti e ai sistemi interessati.

Come gli autori degli attacchi compromettono le cache DNS

Non esiste un unico modo per riuscirci. Gli autori degli attacchi ricorrono a una serie di tecniche collaudate per inserire record DNS falsificati nella cache di un resolver:

Perché gli attacchi di avvelenamento del DNS sono efficaci?

Il DNS è stato progettato pensando alla disponibilità, non all'autenticazione. Il protocollo originale non ha mai previsto un modo per verificare l'autenticità di una risposta. Pertanto, a meno che il DNSSEC non sia implementato e effettivamente convalidato, i resolver finiscono per fidarsi delle risposte semplicemente perché l'ID della transazione e la porta coincidono.

Nella pratica, tale divario crea diversi problemi:

• I record memorizzati nella cache diffondono dati errati su larga scala. Un resolver compromesso può fornire silenziosamente una risposta errata a migliaia di utenti, organizzazioni o resolver a valle, il tutto prima che scada il TTL.
• Gli utenti si fidano dei nomi di dominio che conoscono. Il browser continua a mostrare un URL che sembra corretto, quindi spesso non ci sono indizi visibili che qualcosa non vada, soprattutto quando il sito dell'autore dell'attacco è una copia visivamente molto simile a quello autentico.
• La visibilità sui resolver è solitamente limitata. La maggior parte delle organizzazioni non dispone di informazioni sufficienti sul comportamento effettivo dei resolver ricorsivi utilizzati da dipendenti, clienti o partner, il che rallenta il processo di rilevamento.
• La finestra di tempo tra richiesta e risposta è vulnerabile. È ristretta, ma non abbastanza. I resolver con un comportamento prevedibile o una randomizzazione insufficiente offrono agli aggressori proprio lo spazio necessario per vincere la corsa.

Rischi e conseguenze del DNS poisoning

L'avvelenamento della cache DNS è un classico classico: l’autore dell’attacco si spaccia per un dominio legittimo e induce gli utenti a visitare un sito fraudolento. Funziona particolarmente bene perché il DNS tradizionale non è mai stato progettato tenendo conto della convalida crittografica, quindi non esiste alcun meccanismo predefinito che filtri i dati errati presenti nella cache. Senza il protocollo DNSSEC, i resolver non hanno semplicemente alcun modo per distinguere una risposta legittima da una contraffatta.

Ecco perché è importante:

1. Fiducia nel marchio e fiducia dei clienti

Quando i clienti vengono reindirizzati dal tuo dominio legittimo a uno falso, non danno la colpa al DNS, ma a te. Questa associazione può minare silenziosamente la fiducia nel tempo, e il danno è ancora più grave in settori come quello finanziario, sanitario, dell’istruzione, della vendita al dettaglio e della pubblica amministrazione, dove l’integrità del dominio è direttamente legata alle relazioni con i clienti e alla conformità normativa.

2. Diffusione di malware

Quando utenti, dipendenti o sistemi automatizzati accedono a una destinazione controllata da un malintenzionato, spesso ne consegue l’installazione di malware. Da lì, il malware può diffondersi negli endpoint e nelle reti ed esfiltrare in modo invisibile dati sensibili, tra cui proprietà intellettuale, dati dei clienti e informazioni finanziarie, informazioni sensibili la cui perdita comporta costi elevati.

3. Furto di credenziali e frodi finanziarie

I siti fraudolenti vengono creati per raccogliere password, dati , credenziali aziendali: tutto ciò che gli utenti digitano viene raccolto. Da lì il passo è breve verso la compromissione degli account, transazioni non autorizzate e frodi che finiscono per colpire l’organizzazione o i suoi clienti.

4. Interruzione della sicurezza della posta elettronica e dei domini

I record DNS costituiscono la base su cui si fonda l’autenticazione delle e-mail. Pertanto, quando i dati DNS sono non autorizzati o errati, il problema non rimane circoscritto, ma si ripercuote sui record SPF, DKIM, DMARC, BIMI, MTA-STS e TLS-RPT, causando lacune nella visibilità, problemi di consegna, rischi di spoofing ed esposizione a violazioni di conformità. Una volta compromessa l’integrità del DNS, l’intera catena di autenticazione delle e-mail diventa inaffidabile.

5. Impatto sulla conformità e sulla risposta agli incidenti

Per le organizzazioni soggette alle normative PCI DSS, GDPR, HIPAA o ai quadri normativi governativi in materia di sicurezza informatica, un incidente di “DNS poisoning” può comportare un rischio concreto di violazioni normative. Inoltre, il carico di lavoro legato alla risposta agli incidenti non è facilmente gestibile. Quando i record DNS compromessi interessano contemporaneamente più domini, servizi o ambienti dei clienti, la procedura di ripristino si complica rapidamente.

Perché il DNS cache poisoning è importante per gli MSP e gli MSSP

Per gli MSP e gli MSSP che gestiscono più domini dei clienti, gli attacchi legati al DNS e le configurazioni errate possono rapidamente comportare costi operativi elevati. Un singolo dominio compromesso o configurato in modo errato può generare richieste di assistenza, reclami relativi alla consegna delle e-mail, timori di phishing e problemi di fiducia da parte dei clienti in tutto il portafoglio gestito. Il monitoraggio centralizzato dei domini, i report sull’autenticazione e l’accesso basato sui ruoli aiutano i fornitori di servizi a identificare i problemi più rapidamente e a gestire i domini dei clienti senza dover passare da uno strumento all’altro.

Esempi concreti di attacchi di avvelenamento del DNS

Sono stati osservati attacchi di tipo “DNS poisoning” in diversi settori e scenari di attacco. Gli esempi seguenti illustrano i modelli più comuni, le conseguenze e gli insegnamenti tratti:

Come individuare un attacco di avvelenamento della cache DNS

La maggior parte delle persone che vengono reindirizzate a causa di una cache DNS compromessa non se ne accorge nemmeno. È proprio questo che rende difficile individuare il problema dal punto di vista dell’utente, quindi il rilevamento spetta solitamente a chi monitora l’infrastruttura. Ecco alcuni aspetti da tenere d’occhio:

• Reindirizzamenti imprevisti dai siti web. Qualcuno digita un dominio che visita spesso e finisce in una pagina sconosciuta.
• Avvisi di mancata corrispondenza dei certificati SSL/TLS. Se il browser segnala un errore relativo al certificato, non ignorarlo. Di solito significa che la connessione non sta raggiungendo la destinazione prevista.
• Pagine di accesso simili. A prima vista la pagina sembra a posto, ma l'URL, il design o i dettagli del certificato presentano qualche piccola discrepanza. Vale la pena dare sempre un'occhiata più attenta.
• Risposte DNS che variano a seconda del resolver utilizzato. Esegui una query sullo stesso dominio tramite il resolver aziendale e poi tramite uno pubblico, ad esempio 1.1.1.1 o 8.8.8.8. Risposte diverse indicano che c'è qualcosa che non va.
• Voci insolite nei log DNS. Valori TTL anomali, origini delle risposte non conformi alle aspettative o un improvviso picco di query relative a un determinato dominio.
• Un calo del traffico senza una ragione evidente. Se i dati analitici o i tassi di autenticazione subiscono un calo senza una causa evidente, vale la pena controllare il DNS prima di escluderlo.
• Avvisi provenienti dal proprio stack di sicurezza. Non bisogna ignorare i segnali provenienti da strumenti SIEM, EDR o di monitoraggio della rete che segnalano attività DNS o connessioni a intervalli di indirizzi IP noti come dannosi.
• Anomalie nei rapporti DMARC. Un picco nei fallimenti di autenticazione può indicare che i record SPF, DKIM o DMARC associati al tuo dominio sono stati manomessi.

Cosa fare se si sospetta un attacco di tipo “DNS cache poisoning”

Inizia confrontando le risposte DNS fornite da diversi resolver, utilizzando il PowerDMARC DNS Record Checker o strumenti da riga di comando come nslookup e dig. A questo punto:

1. Svuotare la cache DNS sui sistemi interessati. Windows: ipconfig /flushdns. macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Linux: sudo systemd-resolve –flush-caches.
2. Passa a un resolver ricorsivo affidabile, come 1.1.1.1 o 8.8.8.8, mentre verifichi il funzionamento del tuo resolver principale.
3. Verifica i record DNS di ogni dominio critico, in particolare quelli che supportano SPF, DKIM, DMARC, MTA-STS, TLS-RPT e BIMI, utilizzando il PowerDMARC Domain Analyzer.
4. Verifica lo stato di convalida DNSSEC dei tuoi domini utilizzando lo strumento DNSSEC Checker di PowerDMARC.
5. Esaminare i rapporti aggregati DMARC alla ricerca di anomalie nell'autenticazione che potrebbero indicare un'interruzione a livello di DNS.
6. Avvisa gli utenti e le parti interessate coinvolti qualora l'incidente comporti la divulgazione delle credenziali o reindirizzamenti dannosi collegati al tuo dominio.

Strategie di prevenzione e mitigazione dell'avvelenamento del DNS

1. Implementare il protocollo DNSSEC laddove supportato

Il protocollo DNSSEC aggiunge firme crittografiche ai record DNS, consentendo ai resolver di verificare che una risposta provenga effettivamente dalla fonte autorevole corretta e non sia stata manomessa durante il percorso. Il DNS di per sé non autentica ancora le risposte in modo autonomo, ma il protocollo DNSSEC colma questa lacuna e riduce notevolmente la probabilità che risposte contraffatte riescano a passare inosservate. È possibile verificare la propria configurazione utilizzando il PowerDMARC DNSSEC Checker.

2. Mantenere aggiornati i resolver DNS e l'infrastruttura

Le vulnerabilità note del DNS vengono sfruttate costantemente, quindi rimanere aggiornati è più importante di quanto possa sembrare. Una gestione regolare delle patch, i controlli di configurazione e l’utilizzo di resolver ricorsivi affidabili e ben mantenuti contribuiscono tutti a ridurre la superficie di attacco. Due impostazioni che vale la pena ricontrollare sono la randomizzazione della porta di origine e l’entropia dell’ID di query. Entrambe rendono significativamente più difficile indovinare l’ID della transazione.

3. Utilizza resolver ricorsivi affidabili

Indirizza gli endpoint e le reti verso resolver incentrati sulla sicurezza come Cloudflare (1.1.1.1), Google (8.8.8.8) o Quad9 (9.9.9.9). Questi provider eseguono la convalida DNSSEC, supportano protocolli DNS crittografati (DoH e DoT) e filtrano attivamente i domini noti come dannosi, gestendo così gran parte del rischio senza richiedere alcuno sforzo aggiuntivo da parte tua.

4. Risolvere i record DNS configurati in modo errato o abbandonati

Record DNS obsoleti o configurati in modo errato, come voci DNS "dangling" , creano vulnerabilità che gli hacker non esitano a sfruttare, tra cui il takeover dei sottodomini, il che non fa che aggravare i rischi già insiti nel cache poisoning. Effettuare controlli regolari dei propri record DNS utilizzando il DNS Record Checker di PowerDMARC è di grande aiuto in questo senso.

5. Monitorare e potenziare i registri di autenticazione delle e-mail

SPF, DKIM, DMARC, BIMI, MTA-STS e TLS-RPT dipendono tutti dal DNS per funzionare. Una sola modifica non autorizzata alla zona DNS può compromettere silenziosamente l’autenticazione delle e-mail senza alcun avvertimento evidente, ed è proprio per questo che è necessario effettuare un controllo continuo piuttosto che una configurazione una tantum. Il Domain Analyzer di PowerDMARC è progettato per verificare lo stato completo dell’autenticazione in un unico passaggio.

6. Rafforzare la sicurezza del trasporto delle e-mail con MTA-STS e TLS-RPT

MTA-STS richiede che i server di posta utilizzino il protocollo TLS durante l’invio di messaggi al proprio dominio. Non impedisce direttamente il cache poisoning del DNS, ma riduce i rischi di attacchi di downgrade che spesso accompagnano la compromissione del DNS. Abbinatelo a TLS-RPT e otterrai visibilità sugli errori di consegna a livello di trasporto e sulle violazioni delle politiche, il che si rivela un segnale utile quando cerchi di capire se il DNS è all'origine di un'interruzione del servizio di posta elettronica.

7. Aggiornamento del software di sicurezza degli endpoint

Se un endpoint è già stato reindirizzato a un sito dannoso a causa di un attacco di tipo “DNS poisoning”, è necessario agire rapidamente. Aggiornare l’antivirus e il software di sicurezza dell’endpoint, quindi eseguire una scansione completa per individuare e rimuovere qualsiasi elemento che possa essersi installato autonomamente. Si tratta di una misura di natura reattiva, ma è un passo necessario per gli utenti finali e i team IT che devono far fronte a un incidente in corso.

Oltre a queste strategie, è utile avere a disposizione una serie di strumenti affidabili per l’analisi dei DNS e dei domini, al fine di effettuare verifiche continue. Il toolkit di PowerDMARC copre questo ambito grazie a DNS Record Checker, DNSSEC Checker, Domain Analyzer, MTA-STS Checkere TLS-RPT Checker.

In che modo PowerDMARC contribuisce a rafforzare la sicurezza dei domini e della posta elettronica

La sicurezza del DNS e l'autenticazione delle e-mail sono strettamente correlate. SPF, DKIM, DMARC, BIMI, MTA-STS e TLS-RPT dipendono tutti da record DNS accurati e affidabili. Se questi record mancano, sono configurati in modo errato o difficili da monitorare, le organizzazioni si trovano ad affrontare un aumento del rischio di spoofing, problemi di consegna e rischi di non conformità, tutti amplificati quando l'integrità del DNS è compromessa.

PowerDMARC offre ai team di sicurezza e agli MSP una piattaforma centralizzata per gestire l'autenticazione delle e-mail su più domini. La piattaforma garantisce report chiari, un rilevamento rapido dei problemi, servizi di autenticazione in hosting e strumenti per semplificare la gestione dei protocolli basati sul DNS, senza richiedere modifiche manuali al DNS per ogni aggiornamento.

• Monitoraggio e reportistica DMARC: visibilità sulle fonti di invio, sugli errori di autenticazione e sui tentativi di spoofing, comprese le anomalie che potrebbero indicare un’interruzione a livello DNS.
• SPF in hosting e gestione automatizzata dell'SPF: elimina i problemi legati ai limiti di ricerca dell'SPF e riduce la necessità di apportare modifiche manuali al DNS quando si aggiungono nuove fonti di invio.
• MTA-STS e TLS-RPTin modalità hosted: rafforzano la sicurezza del trasporto delle e-mail e forniscono reportistica su TLS e sui problemi relativi alle politiche.
• BIMI in hosting: contribuisce a migliorare la fiducia nel marchio e il riconoscimento nella posta in arrivo grazie alla gestione dei record BIMI e dei requisiti relativi ai certificati.
• Raggruppamento dei domini e accesso basato sui ruoli: elementi essenziali per le aziende e gli MSP che gestiscono più domini o portafogli clienti da un'unica piattaforma.
• Intelligence sulle minacce basata sull'intelligenza artificiale: identifica modelli di spoofing, fonti di invio non autorizzate e anomalie nell'autenticazione utilizzando dati in tempo reale provenienti dall'intera base clienti globale di PowerDMARC.

PowerDMARC offre inoltre un’assistenza specialistica a livello globale per aiutare i team di sicurezza, gli amministratori e gli MSP a configurare, monitorare e risolvere i problemi relativi ai record di autenticazione in tutta sicurezza. 

Inizia la tua prova gratuita di 15 giorni e ottieni una visione più chiara dello stato di autenticazione delle email del tuo dominio.

Domande frequenti sul DNS cache poisoning

Come si rileva il DNS poisoning?

Presta attenzione a reindirizzamenti imprevisti dei siti web, avvisi relativi ai certificati SSL/TLS, risposte DNS incoerenti tra i diversi resolver, voci insolite nei log DNS e anomalie nei report aggregati DMARC. Confrontando i risultati delle query con il PowerDMARC DNS Record Checker o con strumenti da riga di comando come dig e nslookup, è possibile verificare rapidamente se un resolver sta restituendo un indirizzo IP inaspettato.

Qual è un esempio concreto di “DNS poisoning”?

Una tecnica comune prende di mira gli utenti delle piattaforme di scambio di criptovalute: gli hacker compromettono un resolver DNS e reindirizzano gli utenti verso un sito di phishing visivamente identico, che raccoglie le credenziali e ottiene l'accesso ai portafogli. Un'altra tecnica consiste nella manipolazione a livello di ISP, in cui i resolver inseriscono risposte contraffatte per reindirizzare silenziosamente gli utenti verso pagine pubblicitarie o di avviso.

Qual è la differenza tra “DNS poisoning” e “DNS spoofing”?

Il “cache poisoning” del DNS consiste nell’inserire record falsificati nella cache di un resolver, in modo che le query restituiscano risultati dannosi fino alla scadenza del TTL. Lo “spoofing” del DNS è una categoria più ampia, che comprende il cache poisoning e altri metodi, come l’intercettazione del traffico DNS tramite un attacco “man-in-the-middle”. In pratica, i due termini vengono utilizzati in modo intercambiabile.

Il protocollo DNSSEC può impedire il DNS poisoning?

Sì, quando viene implementato e convalidato end-to-end. Il protocollo DNSSEC aggiunge firme crittografiche ai record DNS, quindi i resolver che convalidano tali firme sono in grado di individuare e respingere le risposte contraffatte. Funziona solo se sia il proprietario del dominio firma i record di zona sia il resolver li convalida. Un’implementazione parziale o configurata in modo errato può creare un falso senso di sicurezza.

MTA-STS impedisce l'avvelenamento della cache DNS?

No. MTA-STS impone la crittografia TLS per la consegna della posta e riduce il rischio di attacchi di tipo “downgrade”, ma non affronta direttamente il problema del “cache poisoning” del DNS. Se abbinato a TLS-RPT, aggiunge la segnalazione degli errori di consegna a livello di trasporto. Consideratelo come un controllo complementare per la sicurezza del trasporto delle e-mail, non come una difesa contro gli attacchi al DNS.

Perché la sicurezza del DNS è importante per l'autenticazione delle e-mail?

SPF, DKIM, DMARC, BIMI, MTA-STS e TLS-RPT dipendono tutti dai record DNS per funzionare. Se un malintenzionato riesce a manipolare le risposte DNS, questi controlli possono essere disabilitati o aggirati, aprendo la strada a casi di spoofing, phishing e problemi di consegna. L'integrità del DNS è fondamentale per una governance efficace della sicurezza della posta elettronica.

• Informazioni su
• Ultimi messaggi

Ahona Rudra

Esperto di sicurezza dei domini e della posta elettronica presso PowerDMARC

Ahona è la Marketing Manager di PowerDMARC, con oltre 5 anni di esperienza nella scrittura di argomenti di cybersecurity, specializzata in sicurezza dei domini e delle e-mail. Ahona ha conseguito una laurea in Giornalismo e Comunicazione, consolidando la sua carriera nel settore della sicurezza dal 2019.

Ultimi messaggi di Ahona Rudra (vedi tutti)

• Sicurezza del fax: una guida completa alla protezione dei documenti riservati nel 2026 - 30 luglio 2026
• Che cos’è un servizio di filtraggio delle e-mail? - 29 luglio 2026
• Spoofing delle e-mail: cos’è e come contrastarlo - 29 luglio 2026