“Abbiamo solo cambiato provider – e ora non arriva più nessuna mail.” Quasi sempre la causa è un record dimenticato o un momento sbagliato. Con un ordine fisso dei passaggi si evita.
Tre tipi di “migrazione”
Nel linguaggio comune si chiama tutto “trasloco”, ma tecnicamente sono tre operazioni diverse:
1. Cambio di hosting: il sito ottiene un nuovo indirizzo IP. Il provider DNS resta; cambiano i record A/AAAA (ed eventualmente MX).
2. Cambio di provider DNS: cambiano i name server del dominio. La zona completa deve esistere presso il nuovo provider prima di cambiare la delega.
3. Cambio di registrar (trasferimento di dominio): il dominio passa a un altro registrar. I name server possono restare invariati.
Se si fanno più operazioni insieme, gli errori sono difficili da rintracciare. Meglio una dopo l'altra, a distanza di qualche giorno.
Abbassare il TTL in anticipo
Il TTL (time to live) stabilisce per quanto tempo i resolver conservano un record in cache. Se è impostato a 24 ore, dopo la modifica i resolver possono servire il vecchio IP fino a un giorno.
Quindi: abbassare il TTL dei record interessati (A, AAAA, MX, CNAME) almeno con l'anticipo pari al vecchio TTL – ad esempio a 300 secondi. Dopo la migrazione riuscita, rialzarlo.
Per il cambio dei name server questo vale solo in parte: la delega (record NS presso il registry del dominio di primo livello) ha di solito un TTL fisso, spesso di 24 ore o più, che non si può abbassare da soli. Name server vecchi e nuovi dovrebbero quindi dare le stesse risposte in quel periodo.
Copiare la zona per intero
Prima del passaggio tutto deve esistere presso il nuovo provider, non solo il sito:
A/AAAA per il dominio principale, www e ogni sottodominio, record MX con le priorità, record TXT (SPF, chiavi DKIM, DMARC, verifiche per Google, Microsoft, Search Console), CNAME (es. autodiscover), record SRV e CAA.
I record TXT per l'autenticazione e-mail sono i più dimenticati. Il risultato sono mail nello spam o messaggi rifiutati (vedi anche l'articolo su SPF, DKIM e DMARC).
Il vecchio provider spesso offre un'esportazione come file di zona. In caso contrario, si interrogano i tipi principali:
for t in A AAAA MX TXT CNAME NS CAA; do dig +noall +answer esempio.it $t; doneI sottodomini ovviamente non si possono elencare così: aprire il pannello del vecchio provider e confrontare record per record.
Testare prima del passaggio
Nuovo web server: con curl si può forzare un hostname su un IP senza toccare il DNS:
curl -I --resolve esempio.it:443:203.0.113.10 https://esempio.it/Nuovo name server: interrogare la zona direttamente lì prima di cambiare la delega:
dig @ns1.nuovo-provider.example esempio.it A
dig @ns1.nuovo-provider.example esempio.it MXOrdine dei passaggi il giorno della migrazione
1. Sincronizzare i dati un'ultima volta. Per negozi, forum e moduli, sospendere brevemente le scritture o risincronizzare subito prima del passaggio, altrimenti ordini o messaggi vanno persi.
2. Cambiare il DNS (indirizzo IP o name server).
3. Lasciare attivo il vecchio ambiente ancora 48-72 ore. I resolver con la vecchia cache altrimenti non trovano nulla.
4. Trattare l'e-mail a parte. Il contenuto delle caselle non si sposta con il DNS. Va trasferito separatamente (ad es. con una sincronizzazione IMAP). Solo quando le nuove caselle sono popolate, cambiare l'MX.
Verificare dopo la migrazione
dig +trace esempio.it
dig @1.1.1.1 esempio.it A
dig @8.8.8.8 esempio.it AResolver diversi mostrano fin dove si è propagata la modifica. Controllare anche: il certificato TLS funziona? Con Let's Encrypt (HTTP-01) la porta 80 deve essere aperta e ogni record AAAA esistente deve puntare al nuovo server. Redirect e www funzionano? Invio e ricezione di una mail di prova? Search Console e monitoraggio senza errori?
Errori tipici
Record AAAA dimenticato: gli utenti IPv6 continuano ad arrivare al vecchio server – e Let's Encrypt preferisce IPv6 per la validazione.
TTL non abbassato in tempo: il passaggio richiede un giorno invece di minuti.
Record CAA che consente solo la precedente autorità di certificazione, mentre il certificato del nuovo hosting arriva da un'altra.
Sottodomini e record speciali dimenticati: autodiscover, mail, shop, TXT di verifica.
Vecchio contratto disdetto troppo presto: durante la transizione entrambi i lati devono restare raggiungibili.
Checklist
- TTL abbassato a 300 secondi con almeno un vecchio TTL di anticipo?
- Zona completa presso il nuovo provider, inclusi MX, TXT, CAA, sottodomini?
- Nuovo server e nuovi name server testati in anticipo?
- Dati sincronizzati un'ultima volta, scritture brevemente congelate?
- Vecchio ambiente attivo ancora 48-72 ore?
- Caselle e-mail migrate a parte, poi MX cambiato?
- Dopo il passaggio: resolver, certificato, IPv6, redirect, mail di prova verificati?
- TTL rialzato?
Una migrazione pulita è meno magia che disciplina: preparare in anticipo, copiare per intero, testare prima del passaggio e poi controllare con pazienza.
Traduzione dall'originale tedesco.