Prologo – L’età dell’oro del ping felice

C’era un tempo in cui Internet era un luogo semplice.
I computer parlavano tra loro, i server rispondevano con calma, e i sysadmin sapevano ancora cosa significava zone file.
Poi arrivarono i “cloud”, i “microservizi”, e i “framework zero-trust orchestrati da intelligenze artificiali quantistiche con dashboard in 4K”.
E noi, ingenui, ci convincemmo che la complessità fosse sinonimo di progresso.

Peccato che sotto quella patina di innovazione pulsasse ancora lui: il DNS.
Il nonno burbero di Internet.
L’unico che, da quarant’anni, tiene insieme il tutto con un sorriso stanco e un dito sul pulsante “Non rispondere”.

Negli ultimi mesi, il vecchio DNS ha deciso di ricordarci la sua importanza, nel modo che preferisce: spegnendo il mondo.
Prima Amazon, poi Microsoft, poi a ruota tutti gli altri.
Un solo nome che non si risolve, e all’improvviso le banche, le smart TV e perfino le app del sonno smettono di funzionare.
Sì, anche i letti “intelligenti”.
È il paradosso dell’era digitale: siamo connessi a tutto, ma basta un DNS che starnutisce e torniamo all’età della pietra (senza neanche il modem 56k a consolarci).

Capitolo I – Il giorno in cui le nuvole si oscurarono

Il 20 ottobre 2025, Amazon Web Services - la cattedrale del cloud - ha vissuto il suo piccolo Armageddon.
Un bug nel sistema di gestione DNS interno ha scatenato un effetto domino degno di un film catastrofico: server muti, API sorde, dashboard in tilt.
Tutto iniziò, pare, con una “routine di sincronizzazione” di DynamoDB.
Una parola magica che nella lingua del cloud significa: “Nessuno sa cosa è successo, ma ha fatto rumore.”

In pochi minuti, Internet è diventata una landa silenziosa.
Siti inaccessibili, pagamenti bloccati, logistiche in coma.
Persino i frigoriferi connessi, poveri illusi, hanno perso la capacità di segnalare che il latte era finito.

Amazon ha dichiarato: “Un problema di risoluzione DNS interno ha impattato alcune regioni.”
Alcune.
Tipo quasi tutte quelle che contano.
E mentre gli ingegneri pubblicavano diagrammi di root cause analysis degni di un trattato zen, il mondo scopriva che l’intera infrastruttura globale dipende ancora da un file di testo con dei nomi dentro.

Ma non è la prima volta.
Nel 2021, 2023, 2024 e poi ancora 2025 - puntuali come le tasse - AWS si è trovata inginocchiata davanti al dio DNS.
E ogni volta, la risposta ufficiale è sempre la stessa:

“Abbiamo implementato nuove misure per evitare che accada di nuovo.”

Sì. Certo. Fino al prossimo record sbagliato.

Perché, in fondo, la resilienza del cloud funziona un po’ come l’immortalità di un personaggio dei fumetti: serve solo finché lo sceneggiatore decide che deve morire per la trama.

Capitolo II – Microsoft e il balletto dei nomi perduti

Non poteva mancare all’appello l’altra metà del cielo: Microsoft.
A ottobre 2025, anche Azure ha deciso di mostrare al mondo quanto è facile trasformare una nuvola in un buco nero.

Teams? Morto.
Outlook? Silenzioso.
SharePoint? Scomparso.
Persino Xbox, che non c’entra nulla, ha fatto scena muta.

Un “errore di configurazione nel servizio Azure Front Door” - così lo chiamano.
Un dettaglio che, tradotto in lingua umana, significa: qualcuno ha toccato la riga sbagliata e ora miliardi di dollari non sanno dove andare.

In quelle ore, il mondo del lavoro ha riscoperto il silenzio.
Niente riunioni su Teams, niente notifiche su Outlook.
È stato il giorno più produttivo della storia moderna.

Poi, dopo otto ore di caos e tre comunicati ufficiali, Microsoft ha rassicurato tutti:

“Il problema è stato identificato e mitigato.”
Ecco, “mitigato” è la parola magica del cloud: significa “non abbiamo risolto niente, ma ora sembra andare”.

Il bello è che questi blackout non sono nuovi.
Nel 2021, nel 2023, nel 2024 - sempre lo stesso copione.
Ma la lezione non arriva mai.
Perché, come ogni bravo manager digitale, c’è sempre un PowerPoint pronto a spiegare che la colpa è “di un comportamento imprevisto del sistema”.
Il sistema, guarda caso, si comporta male solo quando lo tocchi.

Capitolo III – DNS: l’anello debole del potere

E qui arriviamo al cuore del problema.
Il DNS non è solo un meccanismo di traduzione dei nomi.
È l’infrastruttura di fiducia dell’intero mondo digitale.
È il filo sottile che lega ogni mail, ogni login, ogni pagamento.
Eppure, lo trattiamo come la suocera del protocollo TCP/IP: fastidiosa, ma inevitabile.

Nato negli anni ’80 per semplificare la vita, oggi il DNS è diventato un paradosso vivente:
deve essere decentralizzato, ma lo gestiscono in cinque.
Deve essere affidabile, ma è la causa del 70% dei disservizi globali.
Deve essere sicuro, ma lo sfruttano tutti - dagli Stati alle botnet.

Il DNS è la chiave di tutto e, insieme, il suo punto di rottura.
Perché chi controlla il DNS, controlla il traffico.
E chi controlla il traffico, controlla la realtà.
Non serve un’arma nucleare: basta un resolver con la tosse.

E non è solo un problema di blackout.
Il DNS è anche la superficie di attacco più antica e sottovalutata del web.
Ricognizione, poisoning, takeover, tunneling, amplification - un vocabolario di disastri che suona familiare a chiunque abbia passato una notte a inseguire pacchetti UDP per scoprire chi stava esfiltrando dati sotto forma di richieste a suspicious.domain.ru.
Da decenni lo diciamo: il DNS è come una finestra aperta.
Ma no, tutti a parlare di Zero Trust e Threat Hunting.
Poi qualcuno scopre che il malware comunicava via DNS e, sorpresa, “non l’avevamo considerato nel modello di rischio”.

Il risultato è che ogni volta che il DNS decide di starnutire, il mondo prende un raffreddore.

Capitolo IV – Do Not Serve: la vendetta del semplice

Alla fine, la sigla DNS potrebbe davvero voler dire “Do Not Serve”.
Non per ironia, ma per autodifesa.

Perché il DNS, poveretto, non ne può più.
Da decenni sopporta abusi, sovrastrutture, container, proxy, overlay network, orchestratori, microservizi, API gateway, e altre invenzioni del marketing tecnologico.
Lui era nato per dire “questo nome corrisponde a questo numero”.
Punto.
Ma poi gli abbiamo chiesto di fare geo-routing, load balancing, autenticazione, content distribution, failover e magari pure il caffè.

E quando qualcosa va storto - perché va sempre storto - tutti puntano il dito:

“È colpa del DNS.”

Eh, grazie.
Se chiedi a un citofono di fare anche da centralino, non puoi lamentarti se a un certo punto smette di rispondere.

Così, quando Microsoft e Amazon cadono, il DNS non si ribella: si prende solo un giorno libero.
Una piccola vacanza per ricordarci chi comanda davvero.
Un modo elegante per dire:

“Ve lo dicevo. Non toccate.”

Ma voi niente.
Continuate a mettere AI sopra, a impacchettare query in JSON, a cifrare tutto tranne il buon senso.
Poi, quando il DNS vi pianta in asso, fate la faccia stupita.
E scrivete report con frasi tipo:

“Abbiamo riscontrato un problema temporaneo di risoluzione.”

Sì, temporaneo. Come l’umanità.

Capitolo V – Il paradosso della complessità

Il DNS era nato per togliere allo smemorato il compito di ricordare numeri. Semplice, elegante, pratico.
Poi qualcuno ha pensato: «E se lo rendessimo intelligente?» E da lì il catalogo esplose: DNS dinamici, DNS over HTTPS, DNSSEC, Anycast, GeoDNS, DNS-as-a-Service, DNS basato su policy, DNS analytics, DNS che parla con le API e DNS che si arrabbia se non riceve i badge di accesso del giorno. Tutto molto moderno, bellissimo sui diagrammi di architettura e sui keynote - molto meno utile quando serve risolvere un dominio alle tre del mattino.

La complessità ha una virtù: ti fa sembrare competente. E un difetto: moltiplica i punti di rottura. Trasformiamo un piccolo lookup in una sinfonia orchestrata dove ciascuno strumento è un microservizio con la sindrome del primadonna. Se uno si offende, ritira il violino e la sinfonia si ferma.

Il paradosso sta tutto qui. Per proteggersi, abbiamo aggiunto strumenti; per scalare, abbiamo aggiunto astrazioni; per automatizzare, abbiamo aggiunto bot che scrivono record a mezzanotte. Ogni nuova soluzione porta con sé una nuova superficie di errore. L’automazione che promette di eliminare l’errore umano spesso rende l’errore umano più devastante perché lo replica all’infinito. Un’operazione sbagliata su una pipeline CI/CD non è più un singolo pasticcio: è un virus che si propaga in tutte le zone.

E poi c’è il marketing, che chiama tutto «resilienza». Resiliente, oggi, significa «abbiamo un bel piano di crisi con grafici colorati»; il sistema però, se gli togli il nome, risponde «NXDOMAIN» e manda tutti a casa. È divertente - se non fosse tragico.

Capitolo VI – Quando il cloud cade, cade tutto

Parliamo chiaro: il cloud non è una scatola magica che contiene la resilienza per definizione. È un ecosistema di fornitori, API, router, load balancer e DNS. Un ingegnere con esperienza ti dirà: «Il cloud non cade, si sposta il problema». Ma la verità è che quando il DNS fallisce, il problema non si sposta: si manifesta su tutto.

I microservizi, ad esempio, svolgono il proprio lavoro con disciplina militare purché riescano a trovare gli endpoint. Le API si chiamano reciprocamente con fiducia cieca. I database si replicano tramite endpoint logici, i certificati TLS fanno handshake con nomi che qualcuno deve risolvere. Se quel nome non viene risolto, il servizio “degrada” fino a sparire. Non c’è degradazione elegante: è blackout.

E la cosa peggiore? I controlli di stato e i sistemi di alerting spesso dipendono dagli stessi percorsi che stanno monitorando. Quando il DNS fallisce, non solo il servizio è down: anche la spia che dovrebbe dirti che il servizio è down è down. È un cortocircuito informativo che lascia intere squadre a fissare console vuote, a produrre ticket misteriosi e a scrivere aggiornamenti ufficiali con cui difendere la propria reputazione.

Quindi sì: quando il cloud cade, cade tutto. Ma non per miracolo. Per la semplice ragione che abbiamo permesso alla gestione dei nomi di diventare il singolo punto logico da cui dipendono centinaia di sistemi.

Capitolo VII – Il culto dell’oscurità: «Ma è tutto su Azure»

La fede nel cloud ha assunto dimensioni cultuali. C’è il devoto AWS, il fedele Azure, il convertito Google Cloud. I manuali di migrazione recitano come prediche: «Lift and shift», «modernize», «serverless», «infrastructure as code». E su questi principi si costruiscono budget, karriere e conferenze.

Ma il culto ignora la radice: il DNS. Ci si fida delle API di un provider come di un altare, e poi si scopre che l’altare è montato su una tavola marcia. È una commedia degli equivoci: chiedi resilienza geografica e ti rispondono con una casella di controllo; attivi il failover e preghi che i TTL si comportino; aggiungi un provider di fallback e speri che la rotazione Round Robin non faccia scherzi.

L’illusione è dolce perché salvifica: sposti la responsabilità, riduci team, prometti economia e poi, quando succede il guaio, leggi il comunicato con quel linguaggio perfetto e inattaccabile: «Problemi temporanei di risoluzione». Chiunque abbia lavorato nel weekend davanti a un monitor l’ha già sentita: è la nenia consolatoria che copre il panico operativo.

Eppure la soluzione non è tornare a un mondo on-prem (non è quella la morale). La soluzione è far convivere il nuovo con il vecchio con rispetto e disciplina: non puoi mettere il nome del tuo business nelle mani di un processo che non ha procedure di rollback leggibili a occhio umano.

Capitolo VIII – Gli dèi del Cloud e la nemesi dell’umiltà

L’arroganza del cloud ha un effetto collaterale: l’arroganza cognitiva. I designer di architettura usano termini altisonanti, fanno disegni con frecce colorate e promettono che «tutto è gestito». Ma la gestione è un atto, non uno slogan commerciale.

La nemesi arriva con la semplicità: un record CNAME che punta al nulla, un cambio di routing che non si propaga, un sistema di sync che fallisce in modo silenzioso. Queste sono le cose che i diagrammi non raccontano, e che i manager non considerano nelle slide. E quando arriva la tempesta, il sistema ti restituisce la tua superbia sotto forma di timeout.

Gli dèi del cloud (gli architetti, i manager, i vendor) preferiscono parlare di inaffidabilità come se fosse una disavventura passeggera. Ma nella vita pratica, l’umiltà è più efficace. Rispettare TTL, testare rollback, verificare propagation windows, eseguire esercitazioni reali: non sono attività glamour, ma funzionano. Il problema è che la cultura premia l’innovazione visibile - non la manutenzione invisibile.

Capitolo IX – L’antico sapere del sysadmin

Esiste una specie mitologica: il sysadmin notturno. Vive a cavallo di dig e tcpdump, con i log come sacre scritture. Sa che flush cache non è una formula magica ma un rito. Sa che /etc/resolv.conf è sacro perché è il punto dove il mondo reale incontra il regno dei nomi.

Questo antico sapere non è nostalgia. È competenza operativa. È l’arte di fare cose banali in modo eccellente: documentare, annotare, testare, imparare dai piccoli guasti. La generazione che ha inventato il DNS aveva il senso pratico di chi ha dovuto riparare i cavi con il nastro isolante; oggi molti preferiscono cambiare l’endpoint e chiamarlo "feature".

Gli esercizi pratici che un tempo erano pane quotidiano - prove di failover, simulazioni di propagation, piano di rollback per record DNS critici - sono rari come i voli diretti per certe capitali. Ma quando manca quel training, il primo guasto diventa emergenza nazionale.

Capitolo X – DNS e controllo: la tentazione autoritaria

Il DNS non è neutro: è uno strumento politico perché determina visibilità. Non è un caso che regimi e piattaforme abbiano visto nel meccanismo di risoluzione un modo relativamente semplice per limitare l’accesso a contenuti sgraditi. Blocchi DNS, filtri nazionali e whitelist di provider diventano strumenti di controllo: togli la risoluzione e il contenuto non esiste più, almeno per chi usa quel resolver.

Ma c’è una doppia beffa. Mettere il controllo nelle mani di pochi (o dello Stato) non isola solo i malintenzionati: isola tutti. E quando la configurazione sbaglia, il controllo si trasforma in autodenuncia. La censura tecnica diventa blackout tecnico e la collettività paga il conto.

Il vero dibattito non è se bloccare o non bloccare, ma come farlo senza creare punti di fragilità che, se mal gestiti, mandano in crisi servizi essenziali. Il DNS è potente ed è anche fragile: non sono due affermazioni mutualmente esclusive, sono la cruda realtà.

Capitolo XI – La lezione dimenticata

Se c’è una lezione che ricorre in tutti i blackout è sempre la stessa: le basi contano. Mentre continuiamo a parlare di intelligenza artificiale e automazione, il mondo reale ricorda che un record sbagliato rompe ciò che abbiamo impiegato anni a costruire. Creiamo sistemi sofisticati e poi ci indignamo perché non reggono a un semplice lookup.

È triste ma vero: non serve inventare altro se non imparare a fare bene ciò che già esiste. Manutenzione, esercitazioni, procedure chiare, fallback testati, rotazione dei provider, auditing delle deleghe, controllo dei registrar. Non è un romantico ritorno al passato: è una presa di responsabilità per il futuro.

Abbiamo bisogno di responsabilità tecnica non come slogan, ma come pratica quotidiana. Di documentazione leggibile, di persone autorizzate e reperibili, di processi che siano comprensibili anche da chi deve intervenire alle 2:00.

Capitolo XII – “It’s always DNS”

Gli ingegneri lo sanno e lo ripetono come un mantra. Ogni problema, prima o poi, riconduce al DNS. È diventata una battuta triste: se non sai da dove partire, prova dal DNS. E molte volte funziona. Perché il DNS è il filo che unisce il tessuto della rete: quando si rompe, le toppe non tengono.

La saggezza non è tecnica, è culturale. È riconoscere che la complessità non equivale a sicurezza. È accettare che alcune cose richiedono cura artigiana - e che la tecnologia migliore è spesso quella che si prende cura dei dettagli più banali.

Epilogo – L’arte di non servire

Forse il DNS è solo stanco. Forse preferisce fare una pausa per ricordarci che la tecnologia non è solo marketing ma mestiere. Ogni volta che un grande provider pubblica il comunicato «problema temporaneo di risoluzione», pensate a quella frase come a una confessione collettiva: abbiamo trascurato qualcosa di fondamentale.

Non è uno sfogo anti-cloud. È un invito a ricominciare dalle basi, con meno dogmi e più praticità. Il cloud può essere grande, utile e potente. Ma non diventa immortale per decreto. È umano, costruito da umani e perciò soggetto agli stessi errori umani. E l’errore umano, quando riguarda il DNS, ha un’acustica così grande che si sente dall’altra parte del pianeta.

Quindi la prossima volta che qualcuno proclama

«abbiamo migrato tutto sul cloud, siamo pronti per il futuro»

potete rispondere con cortese sarcasmo:

«Sì, ottimo. Speriamo solo che il DNS non abbia piani per il weekend».

Appendice - Tipi di attacchi e vettori sul DNS

(Premessa: molte interruzioni si verificano indipendentemente da attacchi; errori di configurazione, bug o automazioni mal progettate cascano comunque senza male intenzionato. Detto questo, il DNS è anche una superficie d’attacco reale e sfruttata. Qui sotto i principali vettori, in forma divulgativa).

Prefazione: ricordate che spesso i servizi “vanno giù” perché i sistemi sono fragili, non necessariamente perché qualcuno attacca. Tuttavia, l’elenco qui sotto è utile per capire le minacce che sfruttano quella fragilità.

1. Ricognizione DNS (reconnaissance)
   • Scansione di zone (zone walking, zone transfers se non protetti) per scoprire record, sottodomini, TTL lunghi e punti di contatto. È il passo iniziale di molte campagne.
2. Cache poisoning (avvelenamento della cache)
   • Inserimento di risposte DNS false nella cache dei resolver per reindirizzare traffico verso host controllati dall’attaccante. Può facilitare phishing e furto di credenziali.
3. DNS spoofing / man-in-the-middle
   • Attacchi che forzano client o resolver a ricevere risposte false (ad esempio tramite compromissione della rete locale o del resolver).
4. DNS amplification / reflection DDoS
   • Uso di server DNS aperti per amplificare il traffico verso una vittima; tecniche molto usate per attacchi volumetrici.
5. Query flood e resource exhaustion
   • Inondare resolver o authoritative server con richieste per esaurire CPU/RAM/banda e rendere il servizio indisponibile.
6. Subdomain takeover (hijacking)
   • Registrare risorse cloud o servizi lasciati “dangling” (CNAME puntato a risorsa rimossa) per ospitare contenuti o phishing sotto un sottodominio apparentemente legittimo.
7. DNS tunneling e covert channels
   • Usare richieste DNS per esfiltrare dati o per comunicazione C2 (command and control), sfruttando il fatto che molte reti lasciano passare il traffico DNS.
8. Registrar/Provider compromise
   • Compromettere l’account del registrar o del provider DNS per cambiare deleghe, reindirizzare il traffico o rimuovere record critici.
9. DNSSEC bypass / misconfigurations
   • Errori nell’implementazione di DNSSEC (o assenza di DNSSEC) che rendono possibile spoofing o che generano problemi di risoluzione se configurato male.
10. DNS-based phishing e typosquatting
    • Registrare domini simili o usare record che rendono il phishing più credibile; spesso combinato con campagne email mirate.
11. Misconfigurazioni e automazione difettosa
    • Pipeline CI/CD che scrivono record errati, sincronizzazioni che replicano errori, job schedulati che propagano inconsistenze: sono spesso la causa di outage non malevolo.
12. DNS log tampering e privacy abuse
    • Uso delle informazioni di log DNS per profilare utenti o per rimuovere tracce di attività malevole; rischio per la privacy e per le indagini.
13. Anycast-related pitfalls
    • Anycast migliora resilienza e latenza, ma introduce complessità: problemi di routing o di bilanciamento possono isolare regioni o causare comportamenti incoerenti della cache.
14. Resolver poisoning via compromised IoT / botnet
    • Botnet che sfruttano dispositivi IoT per manipolare resolver locali o inviare richieste malevole, alterando la qualità delle risposte o saturando la banda.
15. Supply-chain e vulnerabilità delle implementazioni (BIND, Unbound, PowerDNS ecc.)
    • Bug nelle implementazioni DNS possono essere sfruttati per esecuzione remota, escalation o avvelenamento della cache.

Appendice B – Ma se non succede, succede davvero? E se succede, non è successo?

Ogni tanto, quando il web italiano si sveglia in silenzio, qualcuno osa chiedere: «È caduto Internet?»
La risposta, immancabilmente, è: «No, tranquilli, non è successo niente».
E infatti, non è mai successo niente. Solo che non si aprono i siti, non funzionano le app, la PEC rimbalza, lo SPID si blocca, le banche si spengono, e le smart-TV guardano nel vuoto come mucche davanti a un treno. Ma no: ufficialmente, non è successo.

Poi, però, nei giorni successivi, spunta un comunicato sobrio: “Problema di risoluzione DNS risolto”.
E noi, veterani del TCP/IP, sorridiamo amari:

“Eccolo. È successo. Ma non è successo.”

Prendiamo il 22 ottobre 2025, quando Fastweb ha regalato al Paese una mattinata di archeologia digitale. Un terzo degli italiani, letteralmente, ha rivissuto l’emozione di un modem senza tono.
La rete c’era, la luce del router era verde, la fibra correva: mancava solo una piccola cosa - il DNS.
Quel giorno, il traduttore universale della rete ha deciso di prendersi ferie. Risultato: i siti non si aprivano, le app non parlavano, i clienti guardavano i dispositivi con lo stesso sguardo con cui si fissa un tostapane rotto.
L’azienda, composta ma lapidaria, ha poi dichiarato che “un problema di risoluzione DNS ha temporaneamente impedito l’accesso ai servizi”. Temporaneamente, sì. Dalle dieci del mattino all’ora di pranzo. Una temporaneità che ha ricordato l’eternità.
E così, per qualche ora, l’Italia ha scoperto che si può vivere anche senza Internet, ma non senza un DNS funzionante.

Solo due giorni prima, il 20 ottobre 2025, il mondo aveva già dato spettacolo.
Amazon Web Services - la divinità globale del cloud, la madre di tutte le infrastrutture - aveva inciampato su un bug altrettanto modesto: un sistema automatizzato di gestione DNS interno che ha deciso di “ottimizzare” i record fino a cancellarli.
Risultato: blackout mondiale.
Banche, piattaforme, servizi pubblici digitalizzati, e un numero imbarazzante di frigoriferi smart si sono trovati a fissare il vuoto come in un film di fantascienza distopica.
In Italia, l’effetto si è sentito eccome: siti lenti, app mute, utenti che chiedevano “ma è colpa di Aruba?”. No, stavolta era colpa del cielo stesso.
AWS ha poi comunicato di aver individuato “un difetto latente nel sistema automatizzato di gestione DNS”.
Tradotto in linguaggio umano: ci si è dimenticati che l’automazione va supervisionata.

E per completare il quadro, il 29 ottobre 2025 Microsoft Azure ha voluto partecipare alla rassegna “Chi ha spento Internet questa settimana?”.
Un aggiornamento di routine al servizio Azure Front Door - quello che instrada e bilancia il traffico globale - ha confuso le deleghe DNS di mezzo pianeta.
Da Teams a Outlook, da SharePoint a Xbox, tutto ha smesso di funzionare per ore, compresi alcuni servizi italiani che poggiavano sulle API Azure.
Come sempre, il comunicato ufficiale è stato un capolavoro di understatement:

“Identificato un errore di configurazione che ha impattato la risoluzione DNS.”

In parole povere: abbiamo chiesto al DNS di aprire una porta, e lui ha risposto “chi? io?”.

Tre eventi in dieci giorni.
Tre variazioni sullo stesso tema.
Tre dimostrazioni che non serve un cyber-attacco russo, un blackout elettrico o un meteorite: basta un resolver che decide di non rispondere e l’intero sistema-Paese - o l’intero pianeta - si ferma.

Eppure, in ogni caso, la conclusione è sempre la stessa:

“Tutto risolto, nessun dato compromesso, nessuna violazione, nessuna anomalia residua.”

Perché se c’è una cosa che la comunicazione digitale ha perfezionato, è l’arte di dire che un disastro non è mai davvero accaduto.
Un blackout non è mai “caduta della rete”: è “temporanea interruzione dei servizi”.
Un DNS impazzito non è “il cervello che ha perso la memoria”: è “anomalia nella risoluzione”.

Così, alla fine, rimane l’interrogativo esistenziale da prima pagina:
Ma se non succede, succede davvero? E se succede, non è successo?
E nel dubbio, il DNS - sornione - sorride e risponde:

“NXDOMAIN.”

Appendice C – Archeologia del Nome (ovvero: quando il DNS era giovane e già stanco)

Se pensate che i disastri del 2025 siano un’anomalia moderna, vi sbagliate di secolo.
Il DNS cadeva anche quando il cloud era un sogno e la parola “resilienza” significava solo “riaccendere il modem”.

Già nel 2010, per esempio, alcuni provider italiani avevano un curioso concetto di ridondanza: due server DNS primari, entrambi nello stesso rack.
Una notte di manutenzione “programmata” - e per “programmata” intendiamo “decisa al bar dopo cena” - lasciò offline migliaia di clienti business.
La causa ufficiale: “intervento tecnico in corso”.
La causa reale: il tecnico in corso non sapeva dove fosse il file di zona.

Nel 2013, diversi domini della Pubblica Amministrazione sparirono per ore dal web a causa di un errore nella propagazione del DNS centrale di AgID.
La transizione verso un nuovo registrar “più efficiente” aveva avuto un piccolo effetto collaterale: decine di domini .gov.it senza record validi.
I siti non rispondevano, le email rimbalzavano, e la comunicazione ufficiale fu una delle più oneste della storia digitale italiana:

“Siamo a conoscenza del problema e stiamo lavorando per risolverlo.”

In traduzione libera: non chiedeteci quale problema, perché ancora non l’abbiamo capito.

Arriviamo al 2016, l’anno del grande blackout di Telecom Italia (ora TIM).
Un errore di configurazione nei resolver DNS di rete fissa rese inaccessibile la maggior parte dei siti per circa due ore.
Il traffico c’era, ma i nomi non si risolvevano.
Il call center impazzì.
Qualcuno suggerì che fosse un attacco hacker, altri un cavo tagliato.
Alla fine, la spiegazione fu più banale: un aggiornamento software dei server DNS che “non era andato come previsto”.
Che tradotto, significa che era andato esattamente come previsto da chiunque conosca gli aggiornamenti software.

Nel 2018, a finire nel registro degli incidenti fu Aruba, il principale registrar italiano.
Un cambio di configurazione nella gestione DNS dei domini in hosting provocò disservizi a catena per migliaia di siti e caselle PEC.
Ironia suprema: molte di quelle caselle servivano per comunicazioni “ufficiali” tra enti pubblici.
Quella mattina, lo Stato non riusciva a scriversi da solo.

Sempre nel 2018, Poste Italiane ebbe un curioso blackout del portale e dei servizi digitali: la causa dichiarata fu un problema “di rete”, ma dietro le quinte si parlò di un errore nel routing DNS interno, amplificato da cache scadute.
C’è qualcosa di poeticamente ironico nel fatto che il portale “PosteID” sia rimasto senza identità per ore.

Nel 2020, in piena pandemia, l’Italia scoprì lo smart working… e il suo tallone d’Achille.
In un giorno già teso per il traffico Internet, WindTre sperimentò un malfunzionamento DNS che mandò offline decine di servizi.
Risultato: milioni di lavoratori bloccati, migliaia di call su Teams sospese, e un’intera nazione che riscopriva il significato di “connessione instabile”.
La rete c’era, ma mancava la voce.
Come una commedia goldoniana ambientata nel cloud.

Nel 2021, Cloudflare e Fastly - due giganti su cui poggiano molti siti italiani - regalarono due episodi di pura umiltà tecnologica.
Nel primo caso, un bug nel sistema di routing DNS portò offline migliaia di domini a livello globale (Italia inclusa).
Nel secondo, un aggiornamento di configurazione fece collassare temporaneamente l’intera rete di distribuzione contenuti.
Da noi, i giornali titolarono “Internet in tilt”.
Ma la verità è che “Internet” era lì: erano solo i nomi a non ricordarsi più chi erano.

Nel 2022, alcuni enti pubblici locali - Comuni, Regioni, Camere di Commercio - si trovarono improvvisamente con i domini irraggiungibili.
Causa: rinnovi non completati, record DNS scaduti, deleghe dimenticate nei cassetti.
Nel caso più celebre, un dominio .gov.it di una Regione risultava “non trovato” per due giorni perché nessuno aveva confermato via PEC (inaccessibile) l’avvenuto rinnovo.
La PEC che non poteva confermare la PEC: un’invenzione tutta italiana.

E poi c’è il 2024, l’anno dell’AGICOMica.
Il sistema PiracyShield, pensato per bloccare siti “illegali”, iniziò a produrre effetti collaterali degni di una commedia dell’assurdo: interi domini “innocenti” bloccati per errore, servizi CDN oscurati, provider costretti a fingere di non sapere nulla.
Non era un guasto DNS in senso tecnico, ma un perfetto esempio di abuso funzionale del DNS: usare la risoluzione dei nomi come martello per ogni chiodo - e per molti che non erano nemmeno chiodi.
Il risultato? DNS nazionali impegnati in un’imitazione mal riuscita del Muro di Berlino.

E così arriviamo al 2025, e tutti sembrano stupiti che il DNS sia ancora il protagonista dei disastri digitali.
Ma la verità è che il DNS non è mai cambiato: siamo noi che continuiamo a chiedergli cose che non può (e non vuole) fare.
Lui nasce per tradurre, non per giudicare, censurare o sopportare CI/CD ansiosi.
E ogni volta che decide di prendersi una pausa, il mondo intero scopre quanto poco ha imparato.

Postfazione breve (ma vera)

Il DNS è il più longevo dei protocolli nonostante noi.
Sopravvive da quarant’anni a incidenti, bug, riforme e persino ai manager.
Lo abbiamo visto funzionare su PDP-11, su smartphone e ora nei data center quantistici.
Ogni epoca crede di averlo capito, e ogni epoca lo fa cadere nello stesso modo.

Così, ogni volta che un comunicato stampa parla di “problema temporaneo di risoluzione”, sappiate che dietro quella frase c’è una storia d’amore e disprezzo lunga quattro decenni.
E la morale, ancora una volta, è la stessa di sempre:

Chi dimentica il DNS è condannato a risolverlo.

Appendicite – Cronologia minima dei disastri DNS italiani (2010–2025)

(Ovvero: breve storia di un errore ripetuto con passione)

2010 – L’era dei rack unici e dell’ottimismo configurato male

C’era un tempo in cui “ridondanza” significava avere due server DNS nello stesso armadio.
Un gestore nazionale di rete decise di fare manutenzione notturna e spense, con gesto sicuro, anche l’alimentazione del rack.
La mattina dopo, clienti business offline e prime pagine di Repubblica.it e Corriere Tecnologia che parlavano di “problema ai server DNS”.
Il comunicato ufficiale fu un classico: “Aggiornamento pianificato con temporanea interruzione dei servizi.”
Tradotto: abbiamo spento tutto insieme, e non sapevamo che i DNS non si rigenerano per miracolo.

2013 – Il giorno in cui la Pubblica Amministrazione dimenticò il proprio nome

Durante la migrazione dei domini governativi verso il nuovo registrar gestito da AgID, decine di siti istituzionali .gov.it scomparvero.
Ne parlarono Il Sole 24 Ore – Nòva e Agenda Digitale.
La causa? Propagazione DNS incompleta e deleghe scadute.
Ministeri e agenzie risultarono irraggiungibili per ore: gli indirizzi c’erano, i nomi no.
AgID comunicò che “era in corso un aggiornamento programmato”.
Forse era programmato, ma non dai sistemi DNS.

2016 – Il blackout nazionale di Telecom Italia: quando i nomi non si risolsero più

Febbraio 2016. Il bollettino La Stampa Tecnologia e ANSA Digitale segnalano “problemi di rete diffusi per TIM e Alice ADSL”.
La causa, scoprirono poi i tecnici, era un aggiornamento fallito sui resolver DNS principali.
Per un paio d’ore, il web italiano parlava solo in cifre senza traduzioni.
Le chiamate ai call center si moltiplicarono come query senza risposta.
Il messaggio finale: “Servizi pienamente ripristinati.”
Ma non la fiducia.

2018 – Il grande silenzio della PEC: quando l’Italia non riuscì a scriversi

Primavera 2018. Migliaia di domini in hosting presso Aruba diventano irraggiungibili, e la PEC - simbolo di affidabilità - smette di funzionare.
Ne parlano La Repubblica Affari & Finanza e Il Giornale Tech.
Causa: aggiornamento errato del sistema DNS del registrar, con propagazione parziale dei record MX e A.
Effetto collaterale: i messaggi ufficiali della Pubblica Amministrazione che non possono comunicare neanche tra loro.
Un blackout elegante, burocraticamente coerente.

2020 – Lo smart working e l’attesa del DNS

Aprile 2020. Con l’Italia in lockdown e milioni di persone connesse in remoto, WindTre registra un ampio disservizio Internet.
Titoli di SkyTG24 Tech24 e Wired Italia: “Problemi DNS rallentano la rete nazionale.”
La rete c’è, ma le richieste DNS non trovano risposta.
Le piattaforme di lavoro remoto diventano contemplative, le VPN introspettive.
La morale del giorno: lo smart working non è smart se il DNS è in ferie.

2022 – La PEC che non poteva confermare la PEC

Estate 2022. Diversi domini istituzionali .gov.it risultano irraggiungibili per giorni.
Segnalazioni su Il Foglio Digitale e Cybersecurity360 – Digital360 Group.
Causa: mancato rinnovo dei record DNS e dimenticanza di alcune deleghe presso il nuovo registrar pubblico.
In un caso emblematico, la conferma del rinnovo non arrivò perché la PEC di contatto era anch’essa fuori uso.
Una perfetta tautologia digitale: la posta certificata non certifica se stessa.

2024 – PiracyShield e il blocco creativo del DNS

Primavera 2024. Il sistema PiracyShield, supervisionato da AGCOM e sviluppato per bloccare siti pirata, colpisce “per errore” domini legittimi, CDN e blog innocenti.
Ne scrivono Agenda Digitale, Il Fatto Quotidiano Tech, e SecurityOpenLab (rubrica “AGICOMica”).
Causa: automatismi di blocco DNS senza controllo umano e liste propagate con troppa allegria.
Effetto collaterale: mezzo web italiano oscurato per eccesso di zelo.
Un classico esempio di “quando la cura è più letale della malattia”.

2025 – L’anno in cui il DNS decise che ne aveva abbastanza

Autunno 2025.
Tre casi in meno di dieci giorni.
20 ottobre – blackout globale di Amazon Web Services con ripercussioni in Europa e Italia.
22 ottobre – disservizio nazionale Fastweb, con un terzo degli italiani senza accesso ai siti.
29 ottobre – crollo di Microsoft Azure, che manda offline Outlook, Teams e servizi cloud correlati.
Ne parlano ANSA Tecnologia, Wired Italia, Il Post, CorCom e Il Fatto Quotidiano.
In tutti i casi, il verdetto è identico: “problema di risoluzione DNS”.
O, come dice qualcuno in sala macchine: “Il DNS ci ha ricordato chi comanda.”

Epilogo dell’appendicite (diagnosi non risolta)

Il DNS non ha mai chiesto di essere un eroe.
Voleva solo tradurre nomi in numeri e vivere in pace.
Ma lo abbiamo trasformato in guardiano, giudice e filtro di Internet.
E ora, ogni volta che decide di non rispondere, si prende la scena come una diva offesa.
Così, a ogni blackout, ci ritroviamo qui a scrivere lo stesso necrologio tecnico con parole nuove.

Non c’è bisogno di un attacco, basta una dimenticanza.
E il resto, come sempre, è “temporaneamente irrisolto”.

Avviso ai lettori

Questo articolo è stato scritto durante un raro momento in cui il DNS sembrava funzionare.
Qualora, al momento della lettura, vi accorgeste che qualche link non si apre, qualche dominio non si risolve o qualche servizio “non risponde”, non allarmatevi: non è un problema di connessione, è un problema di fede.

Il DNS non è cattivo, solo incompreso.
Da quarant’anni si limita a tradurre nomi in numeri, e per tutta risposta lo abbiamo caricato di responsabilità cosmiche: dalla censura alla sicurezza, dalla privacy alla sovranità digitale.
Ogni tanto, per legittima difesa, si concede una crisi mistica.
Non chiamiamola “interruzione di servizio”: è introspezione protocollare.

Se un giorno troverete su tutti i siti il messaggio

“Impossibile risolvere il nome del server”,
ricordatevi che non è la fine del mondo.
È solo il DNS che si prende un momento per riflettere su dove ha sbagliato l’umanità.

Nel frattempo, ringraziate i tecnici notturni che ancora sanno usare dig e non hanno sostituito la documentazione con un webinar.
E tenete sempre a mente una semplice regola:

chi dimentica il DNS è condannato a risolverlo - a mano.

Firmato,
Il DNS
(stanco di essere incolpato, ma troppo educato per rispondervi con un NXDOMAIN)