Il ritardo di propagazione DNS è il divario tra la modifica di un record e il momento in cui ogni visitatore vede effettivamente il nuovo valore, e quel divario può variare da cinque minuti a due giorni interi. Se hai appena migrato l'hosting, cambiato i provider di posta o puntato il tuo dominio verso nuovi server dei nomi, vuoi una risposta diretta su cosa accelera questo processo e cosa non puoi assolutamente toccare. Un'impostazione decide la maggior parte dell'attesa: il TTL. Tutto il resto, comportamento del resolver, memorizzazione nella cache dell'ISP, tempistiche del registro, rimane fuori dal tuo controllo, non importa quanto spesso aggiorni la pagina.
Cosa causa ritardi nella propagazione DNS
La propagazione DNS non è un singolo evento che accade ovunque contemporaneamente. Poiché i dati DNS vengono memorizzati nella cache su più livelli per velocità, ogni modifica deve farsi strada attraverso migliaia di resolver ricorsivi, server ISP e dispositivi degli utenti finali prima di raggiungere tutti. Ogni resolver, dal router di casa al tuo ISP, memorizza una risposta DNS per un periodo prestabilito e continua a servire quella risposta memorizzata invece di chiedere di nuovo al server autorevole. Quel periodo memorizzato ha un nome.
Il TTL, time to live, è un numero in secondi allegato a ogni record DNS che dice ai resolver ricorsivi per quanto tempo possono riutilizzare la risposta memorizzata nella cache prima di controllare nuovamente con il nameserver autorevole. Un record impostato su un TTL di 3600 può essere trattenuto da un resolver per un'ora; uno impostato su 86400 può essere trattenuto per un giorno intero. Quel singolo numero è il motivo per cui lo stesso cambiamento può sembrare istantaneo per un visitatore e invisibile per un altro per ore.
C'è una difficoltà anche qui. Alcuni resolver ignorano semplicemente un TTL basso, e alcuni resolver ISP applicano il proprio pavimento di caching minimo, comunemente 300 secondi, indipendentemente da ciò che pubblichi. Quando un dispositivo interroga il tuo dominio, chiede a un server DNS di caching la risposta, quel server memorizza la risposta per tutto il tempo indicato dal TTL, e durante quella finestra non tornerà indietro per controllare gli aggiornamenti. Non puoi forzare quel server a controllare in anticipo.
Abbassare il TTL prima di una migrazione: l'unica leva che controllate
Il TTL viene impostato in anticipo, il che significa che è l'unica parte di questo processo che puoi effettivamente pianificare. Una riduzione graduale funziona meglio di un singolo calo nel giorno della migrazione. Una pianificazione ampiamente utilizzata si presenta così:
Sette giorni prima del trasferimento, verifica il TTL di ogni record critico (A, MX, CNAME e simili) e limita qualsiasi valore superiore a 24 ore. Tre giorni prima, riduci quel valore a 3600 secondi, ovvero un'ora. Tra 24 e 48 ore prima del passaggio, riducilo ulteriormente a 300 secondi, ovvero cinque minuti, il che offre la propagazione più veloce e realistica durante lo switch effettivo.
L'attesa conta quanto il numero. Il vecchio TTL più lungo deve scadere dalle cache prima che quello nuovo, più breve, abbia effetto ovunque, quindi il preavviso non è facoltativo. Eliminare il TTL un'ora prima del passaggio è troppo tardi per aiutare. Apporta la modifica effettiva solo una volta che quel TTL basso ha avuto il tempo di diffondersi.
La posta merita una voce separata, poiché un record MX rotto significa messaggi rimbalzati, non un caricamento lento della pagina. Abbassate il TTL sui record MX ben 48 ore prima della migrazione per dare alla propagazione abbastanza tempo. Confermate che il nuovo server di posta funzioni effettivamente prima di toccare qualsiasi record DNS che punti a esso. Cambiate i record MX durante una finestra di traffico genuinamente tranquilla, solitamente durante la notte o nel fine settimana.
Una volta che il nuovo server è stabile, annulla l'impostazione temporanea. Riporta il TTL a 3600 secondi o più una volta confermato che tutto funziona, poiché un TTL più lungo offre prestazioni migliori giorno dopo giorno e il valore breve è utile solo attorno al momento del passaggio. Lasciarlo breve in modo permanente aggiunge carico e dipendenza dai tuoi server DNS autorevoli senza alcun vantaggio continuo.
Cosa sbaglia la gente sulla propagazione DNS
La parola stessa causa la maggior parte della confusione. Nulla viene effettivamente spinto attraverso internet; le cache dei resolver scadono semplicemente in base al TTL impostato dall'amministratore di zona, e nessun meccanismo trasmette la tua modifica ovunque. L'unico modo affidabile per confermare che una modifica è live è controllarla contro uno strumento multi-resolver, resolver per resolver, anziché fidarti del tuo browser.
La cifra "24 a 48 ore" viene trattata come una legge della fisica, e non lo è per le modifiche ordinarie ai record. Quel numero risale ai primi giorni del DNS commerciale, quando i registrar applicavano abitualmente TTL di 24 ore e alcuni resolver ISP aggiungevano il proprio ritardo sopra. Con un moderno TTL di 300 secondi impostato con largo anticipo, la maggior parte delle modifiche ai record si chiarisce in pochi minuti, non giorni.
Le modifiche ai nameserver sono la vera eccezione e il TTL non aiuta qui come fa per i record ordinari. La modifica dei nameserver aggiunge un ulteriore livello di propagazione al registro stesso, e le variazioni dei record dei nameserver possono richiedere fino a 48 ore perché i registri aggiornano i propri file di zona secondo i propri tempi, non i tuoi. Tale ritardo esiste perché i record dei nameserver provengono dai nameserver radice, che comunemente assegnano un TTL di due giorni interi, 172,800 secondi, causando ai resolver di ovunque di mantenere la vecchia delega per così tanto tempo.
Gli ISP aggiungono un'ulteriore variabile che non potete verificare dalla vostra scrivania. Alcuni provider ignorano completamente le impostazioni TTL pubblicate e aggiornano i propri record memorizzati nella cache solo ogni due o tre giorni. Se una modifica sembra completa su ogni checker pubblico ma un visitatore colpisce ancora il vecchio server, il resolver dell'ISP solitamente ne è la causa, non la vostra configurazione.
Cosa significa questo in pratica
Prima di toccare qualsiasi cosa, elenca ogni record legato al servizio che stai spostando: A, AAAA, CNAME, MX e qualsiasi record TXT per SPF o DMARC. Nota il TTL corrente su ognuno, perché quella cifra è la tua tempistica reale, non un'ipotesi. Quarantotto ore prima della migrazione, abbassa il TTL sui record A, AAAA e CNAME che intendi cambiare a 300 secondi. Lascia stare i record che non stai toccando.
Cambia l'indirizzo IP e i server dei nomi come eventi separati piuttosto che contemporaneamente, poiché combinarli rende molto più difficile capire quale livello sia ancora obsoleto. Mantieni il vecchio server o la casella di posta attiva per l'intera durata del vecchio TTL, in modo che chiunque sia ancora su una risposta memorizzata nella cache non si trovi in un vicolo cieco. Questa semplice abitudine elimina la maggior parte di ciò che le persone chiamano interruzione durante una migrazione.
Controlla lo stato con uno strumento creato appositamente, non con il tuo browser. La rete di resolver pubblici di Google, 8.8.8.8, è una delle più grandi al mondo ed è generalmente conforme al TTL, il che la rende un punto di riferimento affidabile. Se la tua connessione mostra ancora la vecchia risposta dopo la scadenza del TTL, un riavvio del router o il passaggio a un resolver pubblico come Google Public DNS spesso rileverà lo stato della cache aggiornato più velocemente che aspettare il tuo ISP.
Una volta confermata la stabilità del cutover tra i resolver, aumenta nuovamente il TTL a un valore di produzione e vai avanti. L'intero processo premia la pazienza nella fase di configurazione, non l'urgenza nel giorno stesso. Una migrazione pianificata con 48 ore di anticipo con un TTL di 300 secondi quasi sempre batte una corsa all'ultimo minuto.
