Migrazione DNS senza downtime: TTL, ordine dei passaggi e checklist per cambio di dominio e hosting

“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; done

I sottodomini ovviamente non si possono elencare così: aprire il pannello del vecchio provider e confrontare record per record.

Migliaia di record? Esporta la zona, non ricopiarla

Con zone grandi ricopiare a mano non conviene — ed è facile sbagliare. Le strade, in quest'ordine:

• Esportare il file di zona: molti provider offrono un export in formato BIND, e la maggior parte dei nuovi lo importa direttamente (ad es. Cloudflare “Import DNS records”, PowerDNS con pdnsutil load-zone esempio.it zona.txt).
• Trasferimento di zona (AXFR): se il vecchio provider consente un trasferimento verso il tuo IP, dig AXFR esempio.it @ns1.vecchio-provider.it scarica tutta la zona. Di solito è attivo solo per i nameserver secondari — vale la pena chiedere.
• Tramite API: strumenti come OctoDNS o DNSControl leggono la zona dal vecchio provider e la scrivono nel nuovo; poi puoi tenere la zona come file in Git.
• Non tirare a indovinare: con le query DNS non si possono elencare tutti i nomi sconosciuti. Senza export, AXFR o API resta solo l'elenco nel vecchio pannello.

Dopo l'import, confronta vecchio e nuovo prima di cambiare i nameserver:

for n in esempio.it www.esempio.it; do for t in A AAAA MX TXT CNAME CAA; do
  diff <(dig +short @ns1.vecchio-provider.it $n $t | sort) <(dig +short @ns1.nuovo-provider.it $n $t | sort) >/dev/null || echo "diverso: $n $t"
done; done

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 MX

Ordine 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 A

Resolver 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.