Migri un sito, tutto sembra a posto, e poi iniziano ad arrivare i messaggi. Alcuni visitatori vedono il nuovo sito, altri continuano a visitare quello vecchio e alcuni segnalano errori che non è possibile riprodurre.
Quando ciò accade, è facile dare la colpa all’host o alla migrazione stessa. Molto spesso, però, la vera causa è il DNS (non perché sia rotto, ma perché sta facendo esattamente ciò per cui è stato progettato).
Gli aggiornamenti DNS non avvengono tutti insieme. Si basano su livelli di caching e resolver esterni all’ambiente di hosting, motivo per cui le migrazioni possono risultare imprevedibili anche quando il sito è pronto.
Questa guida spiega cosa controlla effettivamente il DNS, perché la propagazione si comporta in modo diverso da persona a persona e come pianificare una migrazione in modo che il DNS sia uno step finale controllato, anziché una fonte di downtime o di confusione.
Cosa fa realmente il DNS
Il DNS risponde a una domanda molto specifica: dove deve puntare questo dominio?
Quando qualcuno inserisce il tuo dominio in un browser, il DNS traduce il nome in un indirizzo IP. Questo indirizzo IP indica al browser a quale server connettersi. Il DNS non carica le pagine e non si preoccupa di ciò che è in esecuzione sul server. Si limita a gestire la ricerca.
Per far sì che la ricerca funzioni in modo affidabile, il DNS è suddiviso in alcuni pezzi separati, ognuno con un ruolo chiaro.
- Registrar del dominio: il registrar è il luogo in cui il dominio viene acquistato e rinnovato. Non ospita il sito né controlla il traffico. Dal punto di vista del DNS, la sua responsabilità principale è quella di indirizzare il dominio verso i nameserver corretti.
- Fornitore DNS autoritario: è il servizio che archivia i tuoi registri DNS e fornisce la risposta finale quando Internet chiede dove il tuo dominio dovrebbe risolversi. Fornitori come Cloudflare o la tua piattaforma di hosting spesso svolgono questo ruolo.
- Server dei nomi: i server dei nomi indicano a Internet quale provider DNS è autorevole per il tuo dominio. Non contengono dati o configurazioni del sito web. Si limitano a indirizzare le query DNS al posto giusto.
- Record DNS (A, AAAA, CNAME): questi record definiscono la destinazione del traffico. I record A indicano un dominio a un indirizzo IPv4, i record AAAA indicano un indirizzo IPv6, e i record CNAME fanno da alias a un dominio.
.
Insieme, questi record decidono quale server raggiungono i visitatori quando caricano il tuo sito.
Altrettanto importante è ciò che il DNS non fa. Il DNS non serve file, non sposta database, non sincronizza i contenuti e non gestisce certificati SSL. Non tocca mai il tuo ambiente di hosting.
Una volta chiarito questo confine, il resto del processo di migrazione diventa molto più semplice da interpretare.
Cosa cambia durante la migrazione di un sito e cosa rimane invariato
Uno dei motivi per cui il DNS genera tanta confusione durante le migrazioni è che solo una piccola parte della configurazione cambia effettivamente. Il resto rimane esattamente com’era prima, anche se il sito stesso potrebbe spostarsi in un ambiente completamente nuovo.
Durante una tipica migrazione di un sito, di solito cambiano poche cose.
- L’indirizzo IP cambia quasi sempre perché il sito risiede ora su un server diverso. Questo è l’aggiornamento più comune legato al DNS e quello che in ultima analisi indica al traffico dove andare.
- Anche l’ambiente di hosting cambia. Questo include il server, l’infrastruttura e la piattaforma che gestisce il tuo sito. Sebbene questo influisca sulle prestazioni e sulla stabilità, è separato dal DNS e dovrebbe essere completamente pronto prima di qualsiasi aggiornamento DNS.
- In molti casi, cambiano specifici record DNS. I record A o AAAA vengono aggiornati per puntare al nuovo indirizzo IP. A volte vengono invece modificati i record CNAME, a seconda di come è configurato il sito.
.
Allo stesso tempo, diverse cose rimangono invariate.
- Il nome del dominio non cambia. I visitatori continuano a digitare lo stesso URL e non è necessario aggiornare nulla dell’indirizzo rivolto al pubblico.
- Anche i nameserver rimangono invariati, a meno che non si stia intenzionalmente cambiando provider DNS. La maggior parte delle migrazioni non richiede affatto un cambio di server dei nomi, anche quando cambia il provider di hosting.
.
Ecco perché il DNS è quasi sempre l’ultima fase di una migrazione. Prima si costruisce e verifica il nuovo ambiente, poi si aggiorna il DNS una volta che tutto è pronto per ricevere il traffico.
Trattare il DNS come un passaggio finale invece che come un compito iniziale riduce l’incertezza, limita l’esposizione e rende i tempi di inattività molto più facili da evitare.
La propagazione DNS e perché è imprevedibile
Propagazione DNS non significa che Internet sta “aggiornando” il tuo dominio tutto in una volta. Descrive il tempo necessario affinché le modifiche DNS vengano rilevate, memorizzate nella cache e riutilizzate in molti sistemi indipendenti.
Quando qualcuno visita il tuo sito, la sua richiesta non va sempre direttamente al tuo provider DNS. Di solito passa attraverso un recursive resolver, spesso gestito da un ISP, una rete aziendale o un servizio pubblico come Google o Cloudflare. Questo resolver chiede una risposta al provider DNS autorevole, quindi memorizza il risultato per un uso successivo.
Una volta che un resolver memorizza nella cache una risposta DNS, continua ad utilizzare quella risposta fino alla scadenza della cache. È qui che entra in gioco l’imprevedibilità. I diversi resolver memorizzano nella cache i dati DNS per periodi di tempo diversi. Alcuni rispettano con precisione i valori TTL. Altri applicano i propri limiti o riutilizzano i dati in cache più a lungo del previsto.
Inoltre, le cache dei browser e dei sistemi operativi possono memorizzare i risultati DNS a livello locale. Anche se il record DNS globale è stato aggiornato, il dispositivo di un utente può continuare a utilizzare una risposta più vecchia fino a quando la cache locale non si svuota o scade.
Questa cache stratificata spiega perché due persone in luoghi diversi possono vedere versioni diverse dello stesso sito nello stesso momento. Un resolver ha il nuovo indirizzo IP. Un altro punta ancora al vecchio server.
La regola comune delle “24-48 ore” semplifica eccessivamente ciò che accade in realtà. Molti utenti vedono gli aggiornamenti in pochi minuti. Altri potrebbero non vederli per molto tempo ancora, a seconda del comportamento del resolver e delle cache locali.
TTL e come aiuta ad evitare i tempi morti
Il TTL, o Time to Live, controlla per quanto tempo le risposte DNS vengono memorizzate nella cache prima che un resolver richieda nuove informazioni. Non obbliga gli aggiornamenti a essere più veloci, ma limita il tempo in cui le informazioni obsolete possono essere riutilizzate.
Ogni record DNS ha un proprio valore TTL, misurato in secondi. Se un record ha un TTL di 300, i resolver possono riutilizzare quella risposta per un massimo di cinque minuti prima di ricontrollare. Un TTL di 86.400 consente il caching per un giorno intero.
Ecco perché abbassare il TTL prima di una migrazione è importante. Se i resolver hanno già risposte DNS di breve durata, si aggiornano più frequentemente quando lei cambia i record. Questo riduce la finestra in cui i visitatori potrebbero essere inviati al vecchio server dopo il cambio.
Per la maggior parte delle migrazioni, un TTL compreso tra 300 e 600 secondi rappresenta un buon equilibrio. È abbastanza breve da limitare i ritardi di propagazione senza appesantire inutilmente l’infrastruttura DNS.
Un TTL troppo basso può causare problemi. TTL estremamente brevi non garantiscono aggiornamenti istantanei, e alcuni resolver ignorano valori insolitamente piccoli. Altri possono limitare le richieste o tornare comunque ai dati in cache. Abbassare il TTL all’ultimo minuto è un altro errore comune. Se le cache contengono già record di lunga durata, la modifica del TTL non li influenzerà fino alla scadenza delle cache.
L’approccio più sicuro è la tempistica. È consigliabile ridurre il TTL almeno 24 ore prima della migrazione, confermare che il nuovo valore è attivo e solo allora programmare la modifica del DNS.
La tempistica di una migrazione DNS sicura (passo dopo passo)
Una migrazione DNS senza problemi privilegia la sequenza rispetto alla velocità. Quando ogni fase avviene nell’ordine giusto, il DNS diventa un passaggio controllato anziché un gioco a incastro. Ecco come procedere con successo:
1. Preparare il nuovo ambiente di hosting
Configura completamente il nuovo sito prima di toccare il DNS. Ciò include l’installazione delle dipendenze, la configurazione della cache, l’impostazione dei reindirizzamenti e la verifica delle prestazioni.
Prova il sito utilizzando un URL temporaneo o un file hosts locale, in modo da poterlo visualizzare come se il DNS puntasse già al nuovo server. Assicurati che i certificati SSL siano pronti e validi, soprattutto se viene applicato l’HTTPS. Il DNS non dovrebbe mai essere la fase in cui si scoprono i problemi di configurazione.
Puoi regolare le informazioni DNS all’interno di MyKinsta, accedendo alla tua dashboard, cliccando su DNS e poi su Aggiungi il tuo primo nome di dominio.
2. Abbassare il TTL in anticipo
Riduci i valori TTL sui record DNS rilevanti con largo anticipo rispetto alla migrazione. Idealmente, fallo almeno 24 ore prima del passaggio previsto.
Dopo aver modificato il TTL, puoi confermare che il nuovo valore sia attivo utilizzando gli strumenti di ricerca DNS. In questo modo ti assicurerai che i resolver inizino a memorizzare nella cache le risposte a vita più breve, prima che avvengano i cambiamenti di IP.
3. Congelare le modifiche rischiose
Metti in pausa le modifiche dei contenuti, gli ordini di e-commerce e l’invio di moduli se il sito si basa su un unico database. Il DNS non sposta i dati, quindi le modifiche apportate al vecchio sito dopo l’istantanea della migrazione possono andare perse.
La maggior parte dei problemi di migrazione dei dati deriva dalla sovrapposizione di più scritture, non dai ritardi del DNS. Il congelamento delle modifiche elimina questo rischio.
4. Aggiornare i record DNS
Modifica solo i record che devono essere aggiornati, solitamente i record A, AAAA o CNAME che puntano al sito. Evita di modificare record non correlati durante la stessa finestra. Puoi regolare queste informazioni anche all’interno di MyKinsta. Nella stessa pagina DNS di prima, scorri in basso fino a Record DNS e seleziona Aggiungi un record DNS per aggiungere manualmente queste informazioni.
Ricontrolla gli indirizzi IP, i tipi di record e i nomi host per evitare conflitti. Una volta aggiornate, verifica le modifiche utilizzando interrogazioni DNS dirette piuttosto che il solo test del browser.
Puoi anche effettuare una scansione automatica dei record DNS cliccando su Avvia scansione sotto Scansione automatica.
5. Monitorare la propagazione in tempo reale
Segui la risoluzione DNS da più regioni per confermare che il traffico sta raggiungendo il nuovo server. Aspettati risultati contrastanti durante il rollout: è normale.
In questo caso, con “successo” non intendiamo che tutto si aggiornino istantaneamente. Quello che vogliamo è che il nuovo traffico si risolva costantemente verso la destinazione corretta, senza errori o interruzioni.
Seguendo questa sequenza, il DNS rimane prevedibile. Ogni fase limita il rischio, restringe l’incertezza ed evita i tempi morti causati da modifiche affrettate o sovrapposte.
Dove si verificano di solito i tempi di inattività e come prevenirli
Quando si verificano tempi di inattività durante una migrazione, la colpa è spesso del DNS. In pratica, la causa principale è solitamente un’altra.
I problemi DNS tendono ad essere semplici e binari: un record o punta al posto giusto o non lo fa. La maggior parte delle interruzioni deriva da lacune tra il DNS, l’hosting e l’applicazione stessa.
- Un punto di guasto comune è un indirizzo IP errato. Un singolo errore di battitura o un valore non aggiornato inviano il traffico al server sbagliato, che appare come un tempo di inattività, anche se il DNS sta risolvendo correttamente.
- I record DNS mancanti o incompleti causano sintomi simili. I record di posta, i sottodomini www o i record di verifica vengono talvolta trascurati durante le modifiche, causando interruzioni parziali o funzionalità interrotte.
- Il disallineamento SSL è un’altra causa frequente. Il DNS può puntare al nuovo server, ma il certificato non è installato o non copre ancora il dominio corretto. I browser bloccano quindi l’accesso, che viene percepito dagli utenti come un tempo di inattività.
- Anche il caching può giocare a tuo sfavore. I contenuti in cache o i reindirizzamenti possono ancora puntare al vecchio server dopo gli aggiornamenti DNS, soprattutto se i proxy inversi o i livelli CDN non sono allineati con il nuovo ambiente.
Il modo più affidabile per prevenire questi problemi è la sovrapposizione. Mantenere i vecchi e i nuovi ambienti attivi contemporaneamente, pienamente funzionali, fino a quando il traffico non si è chiaramente spostato. Quando entrambi i server possono servire le richieste in modo sicuro, la propagazione DNS diventa molto meno rischiosa.
Come l’hosting gestito riduce i rischi legati al DNS
L’hosting gestito può ridurre il rischio di migrazione assicurando che il nuovo ambiente sia completamente preparato prima delle modifiche DNS. La maggior parte delle piattaforme gestite fornisce URL di staging o temporanei, stack di server preconfigurati e controlli di prontezza SSL, in modo che il nuovo sito possa essere testato end-to-end mentre il vecchio sito continua a servire i visitatori.
Anche l’assistenza alla migrazione svolge un ruolo importante. I team esperti convalidano i record DNS, confermano l’assegnazione degli IP e si preoccupano di individuare le configurazioni errate più comuni che causano interruzioni. Invece di indovinare se un problema è a livello di DNS, SSL o applicazione, i problemi vengono identificati e risolti prima nel processo.
Kinsta struttura le migrazioni in modo che la sovrapposizione degli ambienti sia l’impostazione predefinita. Il vecchio sito continua a servire il traffico mentre il nuovo sito viene preparato e verificato. Quando avvengono gli aggiornamenti DNS, entrambe le parti sono pronte a gestire le richieste.
Miti sul DNS che causano panico inutile
Molto stress da migrazione deriva da idee sul DNS che sembrano ragionevoli ma non sono accurate. Chiarire questi miti rende più facile rispondere con calma quando le cose non si aggiornano all’istante.
“I cambiamenti DNS sono istantanei”.
Gli aggiornamenti DNS non vengono inviati a Internet in tempo reale. Vengono raccolti quando le cache scadono e i resolver aggiornano i loro dati. Anche una modifica perfettamente configurata si diffonde gradualmente.
“Se il sito non funziona, il DNS è rotto”
.
La maggior parte dei tempi di inattività della migrazione non è affatto causata dal DNS. Gli errori SSL, le configurazioni errate del server o i problemi delle applicazioni spesso appaiono come guasti DNS, perché gli utenti non riescono a caricare il sito.
“Svuotare della cache risolve la propagazione”
.
Svuotare la cache del browser può aiutare un singolo utente a vedere il nuovo sito, ma non cambia ciò che i resolver o gli ISP hanno memorizzato nella cache. La propagazione avviene secondo le loro tempistiche, non le tue.
“La modifica dei server dei nomi è necessaria per ogni migrazione”
.
La modifica del nameserver è necessaria solo quando si cambia fornitore di DNS. La maggior parte delle migrazioni di siti funziona perfettamente senza toccare i server dei nomi.
Se hai bisogno di apportare modifiche, puoi accedere ai server dei nomi di Kinsta in MyKinsta, alla voce DNS > Modifica dei server dei nomi presso il tuo registrar.
Il DNS raramente si comporta in modo imprevedibile perché è rotto. Si comporta in modo prevedibile secondo regole che sono facili da fraintendere. Conoscere queste regole elimina gran parte del panico che circonda le migrazioni.
Checklist post-migrazione: cosa fare quando il DNS è attivo
Una volta che le modifiche DNS sono state introdotte, il lavoro non è finito. L’obiettivo è ora quello di confermare che il traffico raggiunga in modo coerente il nuovo ambiente e che non ci siano errori silenziosi in background.
- Inizia confermando che il traffico sta raggiungendo il nuovo server: controlla i registri del server, i dati analitici o le dashboard dell’hosting per verificare che le richieste arrivino all’IP e all’ambiente corretto. Il traffico misto è normale all’inizio, ma dovrebbe orientarsi completamente verso il nuovo sito.
- Verifica SSL e reindirizzamenti: assicurati che i certificati siano validi per tutti i domini previsti e che i reindirizzamenti HTTP-to-HTTPS e legacy si comportino come previsto. Gli errori dei certificati o i loop di reindirizzamento spesso appaiono solo dopo l’arrivo del traffico reale.
- Monitora i log e le percentuali di errore: osserva i picchi di errori 404, 500, o le richieste bloccate. Questi segnali spesso rivelano problemi di configurazione mancati che non erano visibili durante i test.
- Una volta che il traffico si è stabilizzato, ripristina i valori TTL normali: i TTL più lunghi riducono il volume delle query DNS e migliorano l’efficienza del resolver. Questo passaggio viene spesso dimenticato, ma è importante per la stabilità a lungo termine.
- Rimuovi gli ambienti legacy in modo sicuro: non chiudere il vecchio server finché non hai la certezza che non riceva più traffico significativo. Una breve finestra di sovrapposizione impedisce che i guasti marginali si trasformino in interruzioni.
Questo passaggio finale trasforma un aggiornamento DNS riuscito in una migrazione pulita e stabile.
Il downtime durante la migrazione è solitamente facoltativo
I tempi di inattività durante la migrazione di un sito sono di solito il risultato di cambiamenti affrettati, di sovrapposizioni di responsabilità o di trattare il DNS come qualcosa che deve essere “sistemato” sotto pressione.
Le migrazioni più sicure privilegiano la preparazione rispetto alla velocità. L’hosting, la configurazione delle applicazioni e l’SSL vengono convalidati per primi. Il DNS viene aggiornato per ultimo, con aspettative realistiche sulla propagazione e la cache.
Con il giusto workflow e il giusto supporto, le migrazioni dei siti non devono essere stressanti o rischiose. E quando le modifiche DNS avvengono su un ambiente stabile e gestito, come i servizi di hosting gestito di Kinsta, i tempi di inattività diventano un ricordo del passato.
