Zero downtime migrando il DNS in cloud: il racconto della serata Modena Full Stack
C’è un momento di tensione che chiunque gestisca un dominio conosce bene: quello in cui si cambiano i name server e si resta a fissare il terminale, sperando che tutto continui a rispondere come prima. È il tema della serata di Modena Full Stack di martedì 21 luglio 2026, a cui Netframe ha partecipato come sponsor insieme al co-sponsor Webranking.
Sul palco Andrea Carratta con il talk Zero downtime migrando il DNS in cloud: il racconto di una migrazione DNS in cloud reale, partita da un pannello con record stratificati in una decina d’anni e nessuna documentazione, e arrivata a un’infrastruttura interamente descritta come codice su AWS Route 53 con Terraform. Il titolo della presentazione era già un programma: “Come ho smesso di sperare che il DNS andasse bene”.
Non era rotto. Era frammentato
Il punto di partenza non era un sistema guasto, ma un sistema frammentato. L’hosting su Vercel funzionava: deploy automatici, CDN, certificati SSL. Il problema era che ogni pezzo viveva in un silo diverso: DNS da una parte, hosting dall’altra, variabili d’ambiente gestite via interfaccia web. L’obiettivo della migrazione era chiaro: un solo provider, un solo strumento, controllo totale.
Prima ancora di toccare qualcosa, però, c’era una domanda a cui rispondere: che cosa sto davvero migrando? Un inventario onesto dell’esistente, prima di qualsiasi riga di codice.
Il costo di un singolo record sbagliato: 4 ore
A motivare il cambio di approccio è stato un episodio concreto: un record DNS configurato male, nessun log, nessun diff, nessun rollback. Solo il pannello del provider e la memoria. Risultato: 4 ore per ripristinare qualcosa che, con un git revert, sarebbe stata questione di un minuto.
Da qui il cambio di mentalità al centro del talk: il DNS è infrastruttura, non configurazione. Se il DNS non funziona, il sito non è raggiungibile, le email non arrivano, i certificati SSL non si validano. È il fondamento di tutto, eppure spesso è l’elemento meno controllato. La soluzione: trattarlo come codice versionato.
La migrazione in pratica: 150 record, zero downtime
La vera sfida non era scrivere Terraform: era trascrivere 150 record senza errori di copia e incolla. Qui è entrata in gioco l’intelligenza artificiale, tema ricorrente delle ultime serate della community come nel talk su LLM e AI Agent: Andrea l’ha usata per generare la struttura Terraform a partire dagli screenshot del pannello cPanel, con 144 record corretti su 150 al primo tentativo.
Il resto è metodo: Hosted Zone su Route 53 creata in parallelo alla zona esistente, confronto record per record e switch dei name server solo dopo verifica completa. Il risultato è una migrazione senza downtime e, soprattutto, senza dover affidare il successo dell’operazione alla fortuna.
Un file Git è lo stato completo del DNS
Il cuore dell’approccio Infrastructure as Code: ogni record descritto in un file .tf, ogni modifica con autore, data e motivazione, ogni cambiamento verificabile prima dell’applicazione con terraform plan. Il flusso finale è lineare: repository GitHub con trigger, AWS Amplify per build, deploy, CDN e SSL, Route 53 per il DNS. Un provider, un flusso.
Quando AWS fa da solo: la lezione sul drift
Non sono mancate le sorprese. Dopo il deploy su Amplify, i record DNS del dominio custom risultavano già aggiornati: Amplify li aveva creati in autonomia. Comodo, ma Terraform era fuori sync rispetto allo stato reale. La soluzione: terraform import e riallineamento dello stato. La lezione vale per qualsiasi ambiente: con i servizi managed bisogna aspettarsi automazioni non richieste, e il drift va verificato, mai presunto.
Prima e dopo la migrazione
| Prima | Dopo | |
|---|---|---|
| Tracciabilità | Nessuna | Git log completo |
| Rollback | Impossibile (o quasi) | git revert + terraform apply |
| Certificati SSL | Manuali | ACM automatico |
| Disaster recovery | Ricostruire a mano | terraform apply completo |
| SLA | Dipende dal provider | Route 53 (alta affidabilità) |
In sintesi: meno rischio (ogni modifica è verificabile prima e il rollback è sempre disponibile), pieno controllo (autore, data e motivazione di ogni change, nessuna configurazione nascosta o dimenticata) e più velocità (nuovi ambienti in minuti, un solo punto di gestione).
💡 Come iniziare, in sei passi
- Mappa l’infrastruttura attuale: cosa hai, dove è configurato, chi lo gestisce. Parti da un inventario.
- Identifica il primo elemento da controllare: DNS, hosting, variabili d’ambiente. Scegli quello con più rischio o meno visibilità.
- Scrivi il Terraform per quel singolo elemento: non tutto insieme, un pezzo alla volta. Init, plan, apply.
- Verifica il drift: usa
terraform planper misurare la distanza tra stato dichiarato e stato reale. - Estendi un elemento alla volta: ogni nuovo servizio è un nuovo modulo. Niente riscritture totali, evoluzione incrementale.
- Automatizza il workflow di review: branch preview, staging separato, cleanup automatico. Cambia come lavori, non solo cosa usi.
Una serata di community
Oltre allo speech, la serata è stata come sempre un’occasione per confrontarsi tra professionisti del territorio. E come ha ricordato lo stesso Andrea, a volte la parte più importante di un progetto non è scrivere codice, ma capire davvero il problema prima di iniziare. Un grazie ad Andrea Carratta per aver condiviso non solo le soluzioni ma anche i ragionamenti, gli errori evitati e quelli sfiorati, a Davide Muzzarelli per l’organizzazione e a tutta la community di Modena Full Stack.
Per Netframe sostenere questi appuntamenti come sponsor significa investire nel tessuto tech del territorio: perché tracciabilità, verifica prima del cambiamento e rollback sempre disponibile non valgono solo per il DNS, ma per qualsiasi infrastruttura IT fatta bene.