“È sempre colpa del DNS”: come un record vuoto ha bloccato Internet

1. AWS Region: una regione è un’area geografica in cui AWS ha concentrato un insieme di data center. Attualmente ci sono 38 regioni sparse in tutto il mondo, con altre in arrivo. Ogni regione è del tutto indipendente dalle altre. La prima regione, chiamata US-EAST-1, è stata creata nel 2006 in Virginia (U.S.A.).


2. Availability Zone (AZ): ogni regione è suddivisa in almeno tre AZ. Ogni AZ è composta da uno o più data center fisicamente separati, ma abbastanza vicini tra loro (entro 100 km) per essere collegati con cavi in fibra ottica ad altissima velocità e bassissima latenza. Gli utenti distribuiscono le loro applicazioni su più AZ; in questo modo, se una zona fallisce, l'applicazione continua a funzionare nelle altre.


3. Edge Location: sono centinaia di piccoli data center distribuiti in tutto il mondo, si trovano ancora più vicini agli utenti finali rispetto alle AZ. Non ospitano applicazioni complete, ma vengono utilizzati per:
   - caching di contenuti (servizio CloudFront): copie temporanee di immagini, video e pagine web vengono salvate vicino all'utente, che così li riceve rapidamente senza dover aspettare che arrivino dal data center principale;
   - ottimizzazione del traffico (AWS Global Accelerator): l’acceleratore instrada il traffico attraverso la rete privata di AWS anziché su Internet, migliorando le prestazioni;
   - servizi DNS (Route 53): traducono i nomi di dominio in indirizzi IP più velocemente; Route 53 funge anche da registrar di domini. Il nome Route 53 sottolinea che si tratta di un servizio di instradamento del traffico (route) che utilizza il protocollo DNS standard (porta 53).

Vediamo un semplice esempio di come funzionerebbe un ipotetico servizio di streaming video su AWS.

Supponiamo di trovarci a Milano e di volere guardare una serie TV su una piattaforma di streaming video.

La piattaforma ha distribuito la sua applicazione in più regioni AWS contemporaneamente: Europa (Milano), US-EAST-1 (Virginia), Asia Pacific (Tokyo), ecc. Il sistema di login, il database con il nostro profilo e le raccomandazioni personalizzate potrebbero essere gestiti dalla regione Europa (Milano), che è la più vicina a noi. Se l'applicazione fosse stata rilasciata solo in Virginia, ogni volta che facciamo login o cerchiamo un film, la richiesta attraverserebbe l'Atlantico, con la conseguenza di aumentare la latenza e di avere un servizio lento.

All'interno della regione Europa (Milano), l'applicazione viene distribuita su almeno tre Availability Zone diverse. Il database principale si trova in una AZ, mentre le altre AZ mantengono copie sincronizzate (repliche). Se ci fosse un blackout nel data center di una zona, il sistema passerebbe automaticamente a una delle altre zone e l'utente non si accorgerebbe di nulla.

Una volta scelto il film da guardare, il video non viene scaricato dal data center di Milano, ma, tramite Cloud Front, da una Edge Location ancora più vicina, magari proprio a Milano città. CloudFront è la CDN (Content Delivery Network) di AWS: la prima volta che qualcuno in Italia guarda quel film, il video viene copiato (messo in cache) nell'Edge Location italiana, così quando lo selezioniamo parte quasi istantaneamente.

Riassumendo, in questo scenario, il flusso che si genera quando vogliamo vedere un video sarebbe il seguente:

1. apriamo l'app della piattaforma di streaming, Route 53 identifica la nostra posizione geografica e ci indirizza automaticamente alla regione più vicina, cioè Europa (Milano);


2. effettuiamo il login e scegliamo il film; questa fase è gestita dalla Regione Milano distribuita su tre AZ. Un load balancer distribuisce automaticamente le richieste tra le diverse zone per bilanciare il carico e offrire una maggiore resilienza;


3. iniziamo a guardare il video scaricato tramite CloudFront da una Edge Location vicinissima, che ci garantisce la massima velocità possibile.

• VPN aziendale: crea un tunnel cifrato attraverso una rete pubblica, Internet;


• VPC peering: crea una connessione diretta sulla rete privata globale di AWS, senza mai transitare su Internet.

• database tradizionale: l'utente installa il software su un server, fisico o EC2, configura il server e gestisce backup, aggiornamenti, monitoraggio, ecc.


• DynamoDB (managed): AWS gestisce tutta l'infrastruttura sottostante; l'utente crea semplicemente una tabella, definisce la struttura dei dati e AWS si occupa automaticamente di provisioning, aggiornamenti, backup, ecc.

Riprendiamo l'esempio della piattaforma di streaming video e introduciamo l’utilizzo di DynamoDB.

Il fornitore del servizio di streaming ha creato le seguenti tabelle nel database DynamoDB nella Regione Europa (Milano):

• Utenti: memorizza i dati degli utenti della piattaforma, per esempio l’email, la password criptata, le preferenze linguistiche;


• Profili: memorizza i profili degli utenti, la cronologia delle visualizzazioni, ecc.;


• Preferenze: salva i film aggiunti ai preferiti, le valutazioni date, ecc.

Quando un utente effettua il login da Milano, l'applicazione di streaming interroga la tabella Utenti in DynamoDB Europa (Milano). I dati vengono recuperati velocemente perché il database è geograficamente vicino. Dal momento che i dati utente sono replicati su tre AZ diverse, se sorgesse un problema in una zona, DynamoDB continuerebbe a funzionare leggendo/scrivendo sulle tabelle nelle altre due zone.

Supponiamo inoltre che il fornitore del servizio di streaming utilizzi il servizio AWS DynamoDB Global Tables: in tal caso, le tabelle verrebbero replicate in automatico in più regioni, per esempio Milano, Virginia e Tokyo. L’utente che si spostasse da Milano negli Stati Uniti in Virginia, una volta effettuato il login troverebbe i suoi dati già disponibili nella regione us-east-1. Quindi, se aggiungesse un nuovo film ai preferiti, la tabella Preferenze verrebbe sincronizzata in tutte le regioni coinvolte.

dynamodb.<regione>.amazonaws.com

 dynamodb.us-east-1.amazonaws.com

1. l’applicazione (o il browser) chiede al resolver DNS locale l'indirizzo IP per dynamodb.us-east-1.amazonaws.com;


2. il resolver DNS locale inizia una ricerca nel sistema DNS: interroga i root server DNS che lo reindirizzano ai server che gestiscono il dominio .com che lo reindirizzano ai server che gestiscono il dominio amazonaws.com;


3. i server DNS globali reindirizzano la richiesta ai server autoritativi per amazonaws.com, che sono i server di Amazon Route 53;


4. Amazon Route 53 è il sistema che detiene l'informazione corretta, aggiornata e dinamica per l'endpoint di DynamoDB. Quindi è Route 53 che risponde al resolver DNS locale fornendo l'indirizzo IP del load balancer di DynamoDB più appropriato;


5. infine, il resolver invia l'indirizzo IP all’applicazione, che può connettersi e comunicare con DynamoDB.

• DNS Planner: pianifica come distribuire il traffico in tempo reale, infatti monitora lo stato e la capacità dei load balancer di DynamoDB e genera periodicamente nuovi piani DNS per ciascun endpoint del servizio. In un piano, DNS stabilisce quali load balancer devono ricevere il traffico e qual è la distribuzione del peso tra loro;


• DNS Enactor: applica il piano elaborato dal DNS Planner; opera in modo indipendente e ridondante su tre diverse AZ, ogni istanza in una zona controlla se ci sono nuovi piani emessi dal DNS Planner e per applicarne le modifiche invia le richieste di aggiornamento dei record DNS al servizio Route 53.

Ipotizziamo uno scenario di guasto e vediamo come reagirebbe il sistema appena descritto.

Alle tre del mattino nella regione Europe (Milan) (codice: eu-south-1) un intero rack di load balancer (LB) si spegne:

1. DNS Planner (entro 1-2 minuti):
   - rileva che 20 LB non rispondono ai controlli (health check);
   - calcola come redistribuire il traffico sui rimanenti LB;
   - pubblica un nuovo piano v1234 in cui non sono più presenti i 20 LB guasti e i pesi sono stati ricalcolati.

2. DNS Enactor (entro 30 secondi):
   - le tre istanze leggono il piano v1234;
   - aggiornano i record DNS in Route 53;
   - il traffico viene reindirizzato in automatico.

3. l'utente non ha rilevato un’interruzione del servizio ma solo una latenza un poco più alta per un paio di minuti; le sue query al database DynamoDB continuano a funzionare.

1. Un primo DNS Enactor inizia ad applicare un piano DNS (chiamiamolo Piano-100), ma deve riprovare più volte per via di insoliti ritardi nell’esecuzione. Quindi sta lavorando molto lentamente.


2. Nel frattempo, il DNS Planner continua a produrre nuovi piani più aggiornati (Piano-101, Piano-102, ecc.).


3. Un secondo DNS Enactor prende uno dei piani più recenti (per esempio il Piano-102) e lo applica rapidamente a tutti gli endpoint, compreso l'endpoint regionale di DynamoDB. Al termine attiva un processo di pulizia automatico per eliminare i piani vecchi, incluso il Piano-100.


4. Nello stesso momento in cui è eseguita la pulizia, il primo Enactor finalmente applica il Piano-100 all'endpoint regionale di DynamoDB, sovrascrivendo il piano più recente. Il Piano-100 era però già stato segnato per la cancellazione.


5. La conseguenza è la generazione di un record DNS vuoto per us-east-1.amazonaws.com, con la conseguenza che il DynamoDB della regione risulta irraggiungibile, non trovandosi il suo attuale indirizzo IP.

1. realizzare un failover automatico in caso di guasto DNS, in quanto non c’è modo di indicare nei PC e nei server l’indirizzo IP di un secondo DNS; inoltre, in AWS sono implementate delle policy, dette di routing failover, che permettono di instradare il traffico a un record principale (primario) e, se questo non è integro, a un record di riserva (secondario), il tutto gestito in automatico con il servizio Route 53. Anche queste policy non possono essere realizzate con Packet Tracer;


2. rappresentare il servizio DynamoDB, infatti DynamoDB non è un database su un server fisico bensì un servizio gestito da AWS e accessibile solo via API REST attraverso gli endpoint regionali come, per esempio,
   dynamodb.us-east-1.amazonaws.com. Quindi, DynamoDB non ha un indirizzo IP statico visibile.

1. la simulazione del failover con la sostituzione manuale dell’indirizzo del DNS primario con quello secondario quando si spegne il server DNS primario e la definizione di più record con lo stesso nome che puntano alla risorsa principale (per esempio un’istanza EC2 in una AZ) e alla risorsa di backup (per esempio un’istanza EC2 in un’altra AZ);


2. la simulazione del servizio DynamoDB con l’introduzione di un DB server che simula l’endpoint così da permettere al web server con l’applicazione web di raggiungere un database esterno per le query.

• AWS Regional Services: sono i servizi offerti a livello regionale, in particolare DynamoDB;


• Virtual Private Cloud (VPC): un cloud privato che creiamo per la gestione dell’applicazione web, utilizzando due Availability Zone (AZ1 e AZ2) connesse a un router (VPC-Router) che svolge la funzione di router virtuale del VPC. Collochiamo in AZ1 il server web che ospita l’applicazione web citata nel problema, in AWS sarebbe un’istanza EC2. In AZ2 replichiamo il server web così da aumentare l’availability dell’applicazione.

• Area 0 (Backbone): Internet Backbone + Client Network;


• Area 1 (Global Services): AWS Global Services (Route 53);


• Area 2 (Regional): AWS Region us-east-1 (DynamoDB + VPC).

Router>enable

Router#configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

Router(config)#router ospf 1

Router(config-router)#log-adjacency-changes

Router(config-router)#router-id 1.1.1.1

Router(config-router)#network 203.0.113.0 0.0.0.3 area 0

Router(config-router)#network 203.0.113.4 0.0.0.3 area 0

Router(config-router)#network 192.168.1.0 0.0.0.255 area 0

Router(config-router)#exit

Router(config)#exit

Router#copy running-config startup-config

Destination filename [startup-config]?

Building configuration...

[OK]

Router#

Router(config-router)#router-id 2.2.2.2

Router(config-router)#network 203.0.113.4 0.0.0.3 area 0

Router(config-router)#network 203.0.113.8 0.0.0.3 area 0

Router(config-router)#network 172.16.0.0 0.0.0.3 area 1

Router(config-router)#router-id 3.3.3.3

Router(config-router)#network 172.16.0.0 0.0.0.3 area 1

Router(config-router)#network 172.16.1.0 0.0.0.255 area 1

Router(config-router)#network 172.16.2.0 0.0.0.255 area 1

Router(config-router)#router-id 4.4.4.4

Router(config-router)#network 203.0.113.0 0.0.0.3 area 0

Router(config-router)#network 203.0.113.8 0.0.0.3 area 0

Router(config-router)#network 10.0.254.0 0.0.0.3 area 2

Router(config-router)#network 10.0.254.4 0.0.0.3 area 2

Router(config-router)#router-id 5.5.5.5

Router(config-router)#network 10.0.254.0 0.0.0.3 area 2

Router(config-router)#network 10.0.0.0 0.0.0.255 area 2

Router(config-router)#router-id 6.6.6.6

Router(config-router)#network 10.0.254.4 0.0.0.3 area 2

Router(config-router)#network 10.0.1.0 0.0.0.255 area 2

Router(config-router)#network 10.0.2.0 0.0.0.255 area 2

• show ip ospf neighbor → adiacenze OSPF


• show ip ospf interface brief → stato delle interfacce OSPF


• show ip route ospf → route apprese via OSPF


• show ip ospf database → database OSPF


• show ip protocols → protocolli di routing attivi

• ping 172.16.1.10 → test Route53-Service-Primary


• ping 172.16.2.10 → test Route53-Service-Secondary


• ping 10.0.0.30 → test DynamoDB


• ping 10.0.1.20 → test EC2-AZ1


• ping 10.0.2.20 → test EC2-AZ2

<html>

<head><title>EC2 Web Application</title></head>

<body style="font-family: Arial; padding: 20px;">

<h1>Cloud Web Application</h1>

<p>Status: <span style="color: green;">ONLINE</span></p>

<p>Private IP: 10.0.1.20</p>

<hr>

<p>Simulazione di un'istanza di AWS EC2 (Elastic Compute Cloud)</p>

<small>Availability Zone 1 (us-east-1a)</small>

</body>

</html>

<html>

<head><title>Database Service</title></head>

<body style="font-family: Arial; padding: 20px; background: #f0f0f0;">

<h1>DynamoDB Simulation</h1>

<p>Service: <span style="color: green;">RUNNING</span></p>

<p>Service Endpoint: dynamodb.us-east-1.aws.internal</p>

<p>Private IP: 10.0.0.30</p>

<hr>

<p>Simulazione del servizio AWS DynamoDB</p>

<small>Regional Service (us-east-1)</small>

</body>

</html>

• test DNS sulla risoluzione dei nomi di un dominio pubblico e del servizio www:
  
  
  
  • nslookup example.com
  
  
  • nslookup www.example.com
  
  
  
  


• test DNS sulla risoluzione dei nomi dei servizi interni:
  
  
  
  • nslookup ec2-webapp-az1.aws.internal
  
  
  • nslookup dynamodb.us-east-1.aws.internal
  
  
  
  


• test HTTP:
  
  
  
  • http://webapp.example.com
  
  
  • http://www.example.com
  
  
  • http://webapp-az1.example.com
  
  
  • http://webapp-az2.example.com
  
  
  • http://database.aws.internal
  
  
  
  

• spegnimento del server: nella scheda Physical clicchiamo sul pulsante Power; questa azione simula un crash completo del servizio DNS, equivalente a quanto è successo nell'interruzione di AWS di ottobre 2025, dove Route53 non si è spento fisicamente, ma il sovraccarico a cui è stato sottoposto ha reso le sue risposte così lente da generare un timeout come se il servizio non rispondesse;


• disabilitazione del servizio DNS: nella scheda Services selezioniamo DNS e clicchiamo su Off; il server continua a funzionare, ma non è in grado di risolvere i nomi, simulando così un guasto specifico del software DNS mentre l'hardware resta operativo.

• ping 172.16.1.10 → funziona, il server Route53-Service-Primary è acceso quindi risponde → la rete funziona, non è un problema di connettività;


• ping dns1.aws.internal → fallisce, il servizio DNS non risponde → il componente guasto è il DNS.

• ping 10.0.0.30 → funziona, il server DynamoDB-Service è acceso, quindi risponde → il database funziona;


• ping dynamodb.us-east-1.aws.internal → fallisce, il servizio DNS non risponde → anche l'applicazione non può usare i nomi DNS per raggiungere il database.

• spegnere il router Global Services (AWS-GS-Router) → i server Route53 non sono più raggiungibili, il DNS non risponde → le applicazioni non sono più raggiungibili anche se i server EC2 funzionano;


• spegnere il router della regione us-east-1 (AWS-Region-Router) → non è più possibile raggiungere l’applicazione web dall’esterno (dagli Internet-Client) → l'intera region us-east-1 diventa isolata e tutti i servizi nella regione non sono più accessibili da Internet;


• spegnere il router del cloud privato (VPC-Router) → le istanze EC2 nel VPC 10.0.1.0/22 non sono più raggiungibili → l'applicazione web non funziona, anche se il DNS e il database sono funzionanti → gli utenti ricevono errori di timeout o connection refused.

pip install dnspython

• check_dns_health(): verifica se un dominio viene risolto correttamente dal DNS; restituisce una tupla con i seguenti risultati:
  
  
  
  • success (bool): True se la risoluzione è riuscita;
  
  
  • response_time (float): tempo impiegato in secondi;
  
  
  • ips (list): lista degli indirizzi IP restituiti;
  
  
  • msg (str): descrizione del risultato.
  
  
  
  


• monitor_multiple_dns(): controlla la risoluzione di un dominio svolta da server DNS differenti; restituisce un dizionario con i risultati, dove la chiave è un server DNS e il valore contiene la seguente lista:
  
  
  
  • success (bool): True se la query è riuscita;
  
  
  • time (float): tempo di risposta in secondi;
  
  
  • ips (list): lista degli indirizzi IP ottenuti;
  
  
  • error (str): eventuale messaggio di errore.
  
  
  
  


• continuous_monitor(): svolge un monitoraggio continuo di un elenco di domini controllati con la funzione check_dns_health(), ripetendo i controlli a intervalli regolari. A ogni iterazione raccoglie i risultati della funzione di check e li restituisce subito grazie all’istruzione yield.
  In Python yield trasforma una funzione in un generatore restituendo i valori uno alla volta in real-time, anziché tutti insieme alla fine come avviene con l’istruzione return. Inoltre, congela e salva lo stato della funzione tra una chiamata e l'altra, rendendo così efficiente la sua esecuzione.

python .\dns_health_monitor.py

continuous_monitor(domains, interval=7, max_iterations=3)

• inserire un dominio inesistente;


• utilizzare server DNS fittizi;


• bloccare il server DNS locale e osservare il tempo in cui è stato rilevato il guasto dallo script.

• svolgere un’analisi comparativa di altri outage importanti per identificare eventuali elementi in comune;


• approfondire le architetture multi-cloud e le strategie di failover cross-provider;


• approfondire le metodologie di Chaos Engineering adottate dai principali fornitori di servizi SaaS per testare preventivamente la resilienza dei propri sistemi (Netflix è stato uno dei precursori, con la creazione di Chaos Monkey);


• analizzare l'impatto economico e sociale delle interruzioni infrastrutturali critiche.

• RFC 1035 “Domain names – Implementation and specification”


• AWS Post-Event Summaries https://aws.amazon.com/message/101925/


• Internet Outages Timeline https://www.thousandeyes.com/resources/internet-outages-timeline


• AWS Health, service history https://health.aws.amazon.com/health/status


• Site Reliability Engineering (SRE) by Google https://sre.google/


• Netflix - Chaos Monkey https://netflix.github.io/chaosmonkey/