Cosa è successo?
Nella giornata del 18 novembre 2025, Cloudflare – uno dei principali fornitori di servizi internet (DNS, CDN, sicurezza) – ha subito un grave disservizio a livello globale. In pratica, moltissimi siti web e servizi online che si appoggiano a Cloudflare sono risultati irraggiungibili o hanno mostrato messaggi di errore per diverse ore. La stessa Cloudflare ha confermato di aver riscontrato un problema significativo sulla propria rete globale, il quale ha causato interruzioni diffuse su piattaforme importanti come X (precedentemente Twitter), ChatGPT e persino siti aziendali come quello di McDonald’s. In altre parole, una porzione notevole di Internet ha subito rallentamenti o blocchi a causa di questo incidente.
Cloudflare ha iniziato a investigare il problema intorno alle 11:48 UTC (ora di Greenwich) quando ha rilevato un “degrado dei servizi interni” che impattava vari clienti (fonte: cloudflarestatus.com). Nel corso delle indagini, l’azienda ha notato un insolito picco di traffico verso uno dei suoi servizi verso le 11:20 UTC, che ha sovraccaricato la rete generando errori per il traffico degli utent. All’inizio non era chiaro se questo picco fosse dovuto a un attacco informatico oppure a un malfunzionamento. In seguito, il team Cloudflare ha identificato la causa del problema intorno alle 13:09 UTC e ha iniziato a lavorare a una soluzione. Fortunatamente non si trattava di un attacco hacker, bensì di un bug interno: un errore latente in un loro servizio (legato al sistema di mitigazione dei bot malevoli) che, dopo una routine di aggiornamento di configurazione, ha iniziato a mandare in crash quel componente. Questo malfunzionamento si è poi propagato causando un degrado generalizzato della rete Cloudflare. In parole semplici, una modifica apparentemente innocua ha attivato un bug nascosto che ha fatto inceppare la “macchina” Cloudflare dall’interno.
Verso le 14:42 UTC Cloudflare ha comunicato di aver implementato un fix (cioè una correzione tecnica) e di ritenere l’incidente sostanzialmente risolto, iniziando la fase di monitoraggio per assicurarsi che tutti i servizi tornassero alla normalità. Da quel momento, nel corso del pomeriggio, la situazione è gradualmente migliorata: gli errori e la latenza (cioè i ritardi nelle risposte) sono andati diminuendo fino a tornare sui livelli normali. Infatti, attorno alle 17:14 UTC Cloudflare ha riportato che gli errori residui erano rientrati e i sistemi operavano regolarmente. Complessivamente, il disservizio principale è durato alcune ore – grosso modo dal mezzogiorno fino al tardo pomeriggio (ora UTC) – con effetti a catena su moltissimi servizi online in tutto il mondo.
Da questa vicenda, è emerso chiaramente quanto sia vasta la dipendenza dal network di Cloudflare: le ripercussioni si sono viste ovunque, da social network famosi a siti aziendali e applicazioni di uso quotidiano. Cloudflare stesso ha riconosciuto la gravità dell’accaduto, scusandosi per aver “tradito le aspettative” dei clienti e assicurando che verranno prese misure per evitare che un simile episodio si ripeta. In altre parole, anche un’azienda tecnologica all’avanguardia può incappare in un incidente capace di far tremare mezzo Internet, e la priorità adesso è imparare dall’errore per rafforzare l’infrastruttura.
Si ma... a cosa serve cloudflare? Come funziona un DNS?
Per capire il contesto, vale la pena spiegare brevemente cos’è il DNS (Domain Name System) e come funziona, in modo non tecnico. Il DNS è il sistema che traduce i nomi a dominio (come www.sitoweb.com) negli indirizzi IP dei server su cui risiedono quei siti. Si sente dire che “il DNS è come l’elenco telefonico di Internet” – ed è proprio così. Quando digiti l’indirizzo di un sito web nel tuo browser, ad esempio www.esempio.it, il tuo computer non conosce direttamente dove andare a prendere quella pagina. Ha bisogno dell’indirizzo numerico del server (un po’ come il numero di telefono corrispondente a un nominativo). Il DNS entra in gioco proprio qui: riceve la richiesta del tuo browser e cerca nei suoi “elenchi” l’IP giusto associato a esempio.it, dopodiché restituisce quell’informazione al tuo dispositivo. A quel punto il browser può connettersi all’indirizzo IP trovato e caricare il sito desiderato.
In pratica, senza DNS saremmo costretti a ricordare lunghe sequenze di numeri per ogni sito (ad esempio 192.0.2.1 invece di nomesito.com), il che sarebbe impossibile nell’uso quotidiano di Internet. I server DNS svolgono quindi un ruolo fondamentale: collegano il mondo “umano” dei nomi leggibili (i domini) con il mondo “macchina” degli indirizzi IP, permettendoci di navigare sul web in modo semplice. Esistono vari tipi di server DNS che collaborano in questo processo – dal resolver ricorsivo, ai root server, ai nameserver autoritativi – ma questo livello di dettaglio va oltre il nostro scopo qui. Per il lettore è sufficiente sapere che quando visiti un sito, dietro le quinte avvengono diverse query (domande) tra server DNS per trovare il percorso giusto, il tutto di solito in pochi millisecondi e senza che tu te ne accorga.
Cloudflare è un attore importante in questo sistema. Molti siti web usano Cloudflare come provider DNS autoritativo, il che significa che i record che dicono “il dominio X corrisponde all’indirizzo Y” sono ospitati sui server Cloudflare. Inoltre Cloudflare offre altri servizi collegati, come la distribuzione dei contenuti attraverso la sua rete globale (CDN) e protezione da attacchi DDoS. In parole semplici, Cloudflare instrada il traffico verso i siti dei suoi clienti usando i propri server DNS e la propria rete, aiutando sia a distribuire il carico (per evitare sovraccarichi sui server originari) sia a proteggere i siti da malintenzionati. Questo è fantastico per migliorare performance e sicurezza... finché tutto funziona. Ma se la rete Cloudflare ha problemi (come accaduto in questo caso), le richieste DNS possono non ottenere risposta o il traffico può non essere indirizzato correttamente. Di conseguenza, i browser degli utenti non riescono a raggiungere i siti, anche se i server originari di quei siti tecnicamente funzionerebbero. È un po’ come avere un numero di telefono corretto ma la centrale telefonica non riesce a smistare la chiamata: il risultato è che la chiamata (o nel nostro caso, la connessione al sito) non va a buon fine.
Era possibile evitarlo?
Di fronte a un blackout di questo tipo viene spontaneo chiedersi: si poteva evitare? Purtroppo, eventi di questa portata spesso sono difficili da prevedere o scongiurare al 100%. Cloudflare è nota per l’affidabilità della sua infrastruttura, eppure un singolo bug nascosto ha causato un effetto domino imponente. Anche le realtà tecnologiche migliori possono incorrere in incidenti imprevisti – la perfezione non esiste nei sistemi complessi. Dal punto di vista degli utenti e delle aziende clienti di Cloudflare, non c’era molto da fare per prevenire il disservizio, se non avere già predisposto in anticipo qualche piano alternativo (di cui parleremo tra poco). Chiunque utilizzi un unico provider per un servizio critico si espone inevitabilmente al suo singolo punto di fallimento.
Vale la pena notare che questo episodio di Cloudflare si inserisce in un periodo in cui diversi grandi provider hanno avuto blackout ravvicinati. Negli ultimi mesi del 2025 si sono visti problemi importanti anche su Amazon Web Services e Microsoft Azure. Gli esperti sottolineano come questi incidenti mettano in luce la fragilità dell’infrastruttura online, dato che tantissime aziende si affidano a pochi fornitori per far funzionare i propri servizi. In altre parole, Internet è molto centralizzato: se uno dei nodi principali cade, gli effetti a cascata possono essere enormi. Un’analogia potrebbe essere la rete elettrica: se un’unica grande centrale elettrica alimenta un’intera regione, un suo guasto lascerà al buio milioni di persone. Allo stesso modo, un problema su Cloudflare (o Google, Amazon, ecc.) può creare disagi diffusi per milioni di utenti.
In retrospettiva, Cloudflare ha ammesso che “il tempo di risoluzione è stato inaccettabile” e si è impegnata a fare in modo che ciò non riaccada. Tuttavia, al momento in cui il problema si stava verificando, evitarlo completamente era pressoché impossibile per gli utenti finali. Chi ospitava i propri servizi dietro Cloudflare poteva solo attendere che il provider sistemasse l’errore. Non c’era un bottone magico da premere per aggirare immediatamente il guasto – a meno di non aver già predisposto in precedenza un’infrastruttura ridondata con altri provider (cosa non comune, soprattutto per le realtà più piccole). Insomma, a posteriori possiamo dire che “è sempre facile parlare col senno di poi”. In quel momento, la stragrande maggioranza dei siti colpiti non ha potuto fare altro che restare offline finché Cloudflare non è tornata operativa.
Si poteva mitigare e ripristinare i servizi più in fretta?
Mitigare un disservizio significa ridurne l’impatto o la durata. Evitare del tutto l’incidente non era realistico, ma in alcuni casi era possibile limitarne gli effetti e recuperare più velocemente. La chiave qui è la preparazione e l’architettura dei sistemi: se un’azienda ha previsto misure di emergenza, può reagire prontamente quando un provider come Cloudflare ha problemi.
Nel nostro caso, in QTNOVA siamo riusciti a mitigare il problema rapidamente grazie alla flessibilità della nostra infrastruttura. Poiché gestiamo tutta la configurazione dei sistemi in modo codificato (infrastructure as code), avevamo la possibilità di spostare temporaneamente il DNS dei nostri servizi su un altro fornitore. In parole semplici: quando ci siamo accorti del blackout di Cloudflare, abbiamo modificato poche righe di configurazione per puntare i record NS verso un provider alternativo (che avevamo pronto), aggiornando così i riferimenti dei nostri domini. Questo ci ha permesso di far tornare raggiungibili i nostri servizi più in fretta (il tempo di propagazione dei record), senza dover aspettare passivamente la risoluzione completa da parte di Cloudflare, come noi altri servizi come Canva, nel giro di poco tempo sono tornati online. Una volta che Cloudflare ha risolto il suo incidente e tutto era tornato stabile, abbiamo riportato nuovamente il DNS su Cloudflare (sempre tramite una modifica di configurazione versionata). Grazie a questa manovra, l’interruzione per i nostri utenti è stata minima. Certo, non tutte le realtà hanno questa possibilità: serve pianificazione e una certa competenza tecnica per predisporre un piano B simile. Ma è un esempio concreto di come la resilienza può fare la differenza.
In generale, affidarsi a un unico fornitore per tutto può risultare comodo in tempi normali, ma diventa un tallone d’Achille in situazioni di crisi. Un approccio più resiliente è adottare la redundancy (ridondanza), ossia disporre di sistemi di riserva pronti a subentrare se qualcosa va storto.
Implementare queste strategie può essere complesso e costoso, ma aumenta decisamente la resilienza dei servizi online. Significa, in sostanza, non avere un singolo punto di cedimento. Nel caso specifico del DNS, che è un tassello fondamentale: se il tuo DNS autoritativo va giù, il tuo sito diventa irraggiungibile anche se i tuoi server sono perfettamente funzionanti. Per questo motivo, alcuni grandi siti (o realtà particolarmente attente alla continuità operativa) configurano sistemi DNS secondari o di emergenza. Tuttavia, per molte aziende piccole e medie una simile ridondanza non è sempre praticabile, e si tende ad affidarsi a un provider unico come Cloudflare confidando nella sua affidabilità.
In conclusione, l’incidente Cloudflare di oggi ci ricorda due lezioni importanti. Primo: anche i giganti del web possono cadere, e quando succede l’impatto si sente ovunque. Secondo: vale la pena valutare soluzioni di backup e piani di emergenza, proporzionati alla propria attività, per mitigare gli effetti di questi blackout. Nel nostro piccolo, aver potuto reagire rapidamente cambiando provider DNS ci ha permesso di evitare il peggio. Non sempre “è colpa del DNS” come recita ironicamente un vecchio detto tra informatici, ma quando davvero è colpa (o merito) del DNS, assicurarsi che questo anello della catena sia robusto può salvare la giornata.
Fonti:
- Cloudflare Status – Cloudflare Global Network experiencing issues (timeline ufficiale dell'incidente del 18/11/2025) cloudflarestatus.com
- Comunicazioni Cloudflare e aggiornamenti in tempo reale tomshardware.com
- Articolo CBS News “Reports of outages surge at X and other apps as Cloudflare says it's having widespread problems” (18 nov 2025) cbsnews.com
- Approfondimento Cloudflare: “What is DNS? | How DNS works”cloudflare.com
- Analisi post-incident (Medium) sulle strategie di resilienza dopo un outage DNS
Vuoi saperne di più? Lasciaci una mail qui sotto, ti ricontattiamo al più presto.