DNS - Croce e delizia di internet

Indice

I fatti

Oggi è il 22 ottobre 2025, in questa settimana abbiamo avuto due grossi down, uno ha impattato tanti servizi internet a livello globale a causa di un malfunzionamento in AWS (Amazon Web Services), l’altro ha impattato principalmente due operatori telefonici italiani, Fastweb e Vodafone.

Il minimo comune denominatore pare essere un malfunzionamento di quella che normalmente viene considerato il “pezzo” di infrastruttura meno problematico di tutti, ovvero il DNS.

In AWS più o meno alle 9 fuso orario italiano di lunedì 20 ottobre, i DNS che puntavano a database DynamoDB ed altri servizi (tra cui le Lambda) hanno cominciato a dare problemi nella region us-east-1 su alcune availability zone (spiegare nel dettaglio l’architettura di AWS richiederebbe un articolo a se, basti dire che in pratica sono stati impattati teoricamente 2 o 3 datacenter su qualche centinaio sparsi per il mondo), questo ha portato ad una serie di servizi interni di AWS e di conseguenza esterni ad AWS ma che utilizzano i loro servizi in quella region che hanno smesso di funzionare o hanno cominciato a funzionare molto male, citiamo tra gli altri Slack, Asana e diversi server di giochi. Solo tra i servizi interni di AWS si contano oltre cento componenti degradati o in down.

E mentre i team AWS stavano ancora sistemando le ultime code di richieste, un altro fronte si è aperto in Italia, infatti questa mattina Fastweb e Vodafone hanno avuto grossi problemi, rendendo inaccessibile principalmente ai loro clienti quasi tutta internet (alcuni siti continuavano a funzionare, come diversi social). Stando alla nota di Fastweb, ancora una volta si è trattato di problemi di DNS

Premessa

Ma facciamo un passo indietro, che cos’è un DNS? E perché è così importante il suo funzionamento?

DNS è l’acronimo di Domain Name System, in pratica è il servizio che permette di trasformare un nome in un indirizzo IP, in pratica quando digitate in un browser l’indirizzo https://www.martoranamarco.it, la prima cosa che il vostro computer fa è tradurre quel nome così bislacco per una macchina in qualcosa di più affine, ovvero un indirizzo IP, in questo caso diventa 54.78.227.231, o meglio ancora lo trasforma in una serie di 1 e 0 facilmente comprensibile per un computer. Non è quindi difficile capire quanto sia importante questo piccolo pezzo, un conto è ricordarsi “martoranamarco.it”, un altro è ricordarsi “00110110.01001110.11100011.11100111“.

A questo punto verrebbe da chiedersi cos’è in pratica un indirizzo IP, se già ho riassunto all’estremo il funzionamento del DNS, lo faccio ancora di più con l’indirizzo IP, in pratica lo possiamo vedere come un indirizzo classico di una città, dice al computer dove deve andare a chiedere i contenuti che sta cercando.

Punto debole sottostimato dalla routine

Dipendenza e centralizzazione

In sostanza (al netto delle cache locali o remote), tutto il nostro traffico dipende da un singolo servizio, tipicamente gestito dal nostro provider internet, ma nulla ci vieta di usare i DNS di Google (8.8.8.8 e 8.8.4.4), OpenDNS (208.67.222.222 e 208.67.220.220) o altri, ma il concetto non cambia, quando utilizziamo servizi internet nel 99% dei casi passiamo da uno di questi.

La configurazione di base di un DNS non è estremamente complessa, la si può vedere come una tabella con nome->IP e per questo si sottovaluta la sua importanza ed in molte architetture di servizi web non viene in alcun modo ridondata, per cui se ha un problema, muore istantaneamente tutto il servizio.

Sicurezza e manipolazione

La specificità di questo protocollo, crea anche una possibile falla di sicurezza, in gergo tecnico si chiama attacco Man In The Middle (MITM), in buona sostanza qualcuno si intromette nella vostra richiesta di “traduzione” del dominio in indirizzo IP e ne fornisce uno malevolo.

Questi ed altri attacchi al DNS possono essere evitati tramite l’implementazione del DNSSEC (Domain Name System Security Extensions)

Cosa ci insegnano questi casi

Il problema occorso da AWS ci insegna che non basta mettere i nostri servizi “sul cloud” per essere sicuri che questi siano resilienti di default, un errore che ho commesso anch’io in passato è il sottostimare la probabilità che un problema ad un cloud provider gigantesco come AWS, Google o Azure possa capitare e quindi non applicare le buone pratiche di resilienza e ridondanza.

In gergo tecnico quando tutto il traffico passa da un unico servizio non ridondato o per cui non è predisposto un “failover” (in pratica significa avere un sistema di riserva pronto a subentrare se il principale fallisce) si chiama singolo punto di rottura (o single point of failure) ed ogni sistemista o DevOps deve evitare che esista in un’architettura. Se anni fa con i sistemi fisici questo era estremamente costoso, è oggi relativamente semplice e non troppo costoso distribuire i servizi su più data center per mitigare i rischi. Farlo con i DNS rimane però una delle cose più difficili da fare nonostante la sua semplicità.

Il caso AWS unito al caso di Fastweb ci fanno capire quanto la rete sia estremamente interconnessa, verrebbe da rieditare il famoso proverbio sul battito di ali di una farfalla che provoca un ciclone dall’altra parte del mondo, si può dire che basta un DNS con dei problemi in un datacenter negli USA per bloccare totalmente la contabilità di un’azienda nell’entroterra sardo.

Conclusione

Possiamo dire che la rete come la conosciamo noi, si basa tutta sulla traduzione di nomi in numeri e sulle interconnessioni tra sistemi sparsi nel mondo. Basta un piccolo errore in questa dinamica di indirizzamento, nel cuore nascosto di Internet, per mandare tutto in tilt.

Quando Internet rallenta, ci ricordiamo che la nuvola è una geografia fatta di server, cavi e decisioni umane che può diventare fragile all’improvviso