Migrare i DNS senza downtime: TTL, record da copiare e verifica con dig

Spostare i DNS di un dominio verso un nuovo provider o un nuovo server è un'operazione che si fa poche volte nella vita di un dominio, ma se si sbaglia la sequenza si rischiano ore di sito irraggiungibile o, peggio, email che spariscono nel nulla. Non serve nessuno strumento esotico: bastano il pannello DNS, dig da terminale e un po' di pazienza sui tempi di attesa. La parte che quasi sempre viene saltata è proprio l'attesa.

Abbassare il TTL prima, non durante

Il TTL (Time To Live) dice ai resolver quanto tempo tenere in cache un record prima di richiederlo di nuovo al server autoritativo. Se il record ha un TTL di 86400 secondi (24 ore) e lo si cambia senza preavviso, ridurre il TTL a 300 secondi va fatto bene prima del cambio, lasciando passare almeno un intero vecchio TTL dopo la pubblicazione autoritativa prima del cutover. In pratica: se il TTL attuale è di 24 ore, bisogna abbassarlo almeno 24-48 ore prima, non un'ora prima.

Più fonti tecniche indipendenti convergono sullo stesso intervallo. Un TTL di 60-120 secondi va impostato 24-48 ore prima dei cambi DNS pianificati, per preparare il sistema a una propagazione rapida durante migrazioni di server o cambi di provider di hosting. In alternativa, 24-48 ore prima della migrazione si modifica il record A (e ogni altro record che cambierà, come www e MX) impostando il TTL a 300 secondi.

Fase	TTL consigliato	Quando
Produzione stabile	3600-86400 s	Nessun cambio in vista
Pre-migrazione	300-600 s	24-48 ore prima del cutover
Durante la migrazione	300 s	Fino a conferma propagazione
Dopo, a stabilità confermata	3600 s o il valore originale	Appena verificato ovunque

Attenzione a non esagerare nell'altra direzione: valori di TTL molto bassi, sotto i 60 secondi, costringono i resolver a interrogare i nameserver autoritativi molto più spesso, aumentando il carico sull'infrastruttura DNS e potenzialmente la latenza di risoluzione per gli utenti finali.

L'elenco dei record da copiare

Prima di toccare qualunque TTL, va fatto l'inventario completo della zona attuale. I record che si dimenticano più spesso non sono A e CNAME, ma TXT e MX. Da controllare nell'ordine:

• A / AAAA: indirizzo IPv4 e IPv6 del sito, per dominio nudo e per eventuali sottodomini (www, app, api).
• CNAME: alias verso servizi terzi (CDN, piattaforme SaaS, strumenti di marketing).
• MX: server di posta, con le relative priorità numeriche.
• TXT: qui si concentra il rischio maggiore. Servono SPF (autenticazione mittente), i selettori DKIM (spesso uno per provider di posta), e il record DMARC su _dmarc.dominio.tld. Un errore su uno di questi tre non blocca il sito, ma fa finire le email in spam o le rifiuta del tutto.
• NS: se si cambia anche il provider DNS e non solo il server di hosting, vanno verificati per ultimi, dopo che tutta la zona è stata ricreata sul nuovo pannello.

Una nota tecnica che i tutorial generici spesso saltano: lungo una catena di CNAME la cache effettiva segue il TTL minimo tra tutti gli anelli della catena. Se un CNAME punta a un altro CNAME con TTL diverso, conta il più basso dei due.

Verificare con dig prima di spegnere il vecchio server

Il comando base per controllare un record è dig NOMEDOMINIO TIPO, ma per capire se la propagazione è completa bisogna interrogare resolver diversi, non solo il proprio:

dig A dominio.tld @8.8.8.8 +short
dig A dominio.tld @1.1.1.1 +short
dig A dominio.tld @9.9.9.9 +short

Se le query a Google DNS, Cloudflare DNS e Quad9 restituiscono tutte lo stesso risultato, il cambio si è propagato ai principali server DNS pubblici; se restituiscono risultati diversi, la propagazione è ancora in corso oppure la cache sta causando risposte diverse tra i server.

Per i record di posta e autenticazione, gli stessi comandi si ripetono sui tipi giusti:

dig MX dominio.tld +short
dig TXT dominio.tld +short
dig TXT _dmarc.dominio.tld +short

Un passaggio che vale la pena fare prima di dare per buona la propagazione: interrogare direttamente i nameserver autoritativi del nuovo provider, non solo i resolver pubblici. Dopo un cambio pianificato conviene interrogare ogni nameserver autoritativo direttamente e poi confrontare i resolver pubblici come 8.8.8.8, 1.1.1.1 e 9.9.9.9: se gli autoritativi concordano ma i resolver pubblici restituiscono ancora il vecchio valore, le loro cache non sono scadute. Risultati diversi tra resolver, però, non sono sempre un problema: GeoDNS, load balancing, split-horizon DNS e EDNS Client Subnet possono produrre intenzionalmente risposte diverse anche a propagazione completata, quindi non vanno scambiati automaticamente per un ritardo.

Per un controllo multi-location senza aprire terminali su server sparsi per il mondo, un qualunque strumento pubblico di DNS lookup con nodi in più continenti dà lo stesso tipo di risposta in un colpo solo: utile per una verifica rapida, ma il comando dig resta il riferimento quando serve capire perché un nodo vede ancora il vecchio dato.

Il periodo di coesistenza

Finché non si è certi che tutti i resolver che contano per il proprio pubblico vedano il nuovo indirizzo, il vecchio server va tenuto acceso e raggiungibile. Spegnerlo troppo presto è l'errore più comune: capita spesso di spostare il sito e vedere il nuovo IP funzionare per alcuni utenti, mentre una parte del traffico continua a raggiungere il vecchio server per ore, perché la cache del loro resolver non è ancora scaduta. La regola pratica è semplice: il vecchio server resta vivo almeno quanto il vecchio TTL più un margine di sicurezza, e si spegne solo dopo aver verificato da più resolver che il nuovo indirizzo è ovunque la risposta.

Ripristinare il TTL e checklist finale

Una volta confermata la propagazione, il TTL va riportato al valore di produzione normale (tipicamente 3600 secondi o il valore usato prima della migrazione): a stabilità confermata si riporta il TTL al valore normale, di solito 3600 secondi o quello standard usato in precedenza. Lasciarlo basso per sempre non è un errore grave ma inutile: comporta solo più query sui nameserver senza nessun beneficio.

Checklist prima di chiudere il ticket di migrazione:

• Le email in arrivo e in uscita funzionano sul nuovo server (non solo il webmail: anche SMTP autenticato da client esterni).
• SPF, DKIM e DMARC restituiscono lo stesso contenuto di prima della migrazione, verificati con dig TXT.
• Il certificato SSL sul nuovo server è valido per tutti gli hostname serviti (dominio nudo, www, eventuali sottodomini), non solo per quello principale.
• Il vecchio server resta raggiungibile per qualche giorno in più come rete di sicurezza, anche dopo aver ripristinato il TTL originale.
• Il TTL è stato riportato al valore di produzione e non è rimasto a 300 secondi per dimenticanza.