Migrazione DNS su Cloudflare: la checklist che evita tre ore di blackout

La migrazione DNS su Cloudflare ha la reputazione di essere banale: importa la zona, punta i nameserver, attendi che si propaghi. Le squadre rimaste oscurate per tre ore hanno seguito esattamente questo copione. Il problema è che "banale" descrive il caso perfetto e la produzione raramente è perfetta.

Cosa non fa per te l'importazione automatica

Quando aggiungi un dominio a Cloudflare, la piattaforma interroga i server autorevoli del provider corrente e tenta di importare tutti i record nella zona. Il risultato è un elenco di record che sembra completo e quasi sempre lo è. Il "quasi" è il rischio.

I record di tipo TLSA, utilizzati per DANE (autenticazione dell'entità denominata DNS), spesso non vengono importati. Lo stesso accade con alcuni record SRV con configurazioni non standard, record CAA con più flag o valori insoliti e qualsiasi record fornito dal fornitore precedente tramite una risposta non standard. L'importazione di Cloudflare è un punto di partenza, non una garanzia di lealtà.

Il protocollo corretto è: dopo l'importazione, esporta la zona del provider corrente in formato BIND (la maggior parte dei provider lo offre) e confronta manualmente i due set di record. Strumenti come diff sul file di zona esportato rivelano ciò che è mancato durante l'importazione. Questo passaggio richiede venti minuti ed evita di scoprire, dopo il turn over dei nameserver, che il certificato email ha smesso di validarsi perché manca un record TLSA.

Proxy Cloudflare e servizi non HTTP

Cloudflare opera in due modalità per ciascun record A o AAAA: proxy (il traffico passa attraverso la rete Cloudflare, l'IP reale è nascosto) e solo DNS (risoluzione pura, senza intermediazione). I record MX importati sono solo DNS per impostazione predefinita, il che è corretto perché SMTP non passa attraverso il proxy Cloudflare.

Il problema si verifica con i record A che puntano a server di posta elettronica o a qualsiasi servizio diverso da HTTP/HTTPS. Un record A chiamato mail.exemplo.com che punta al server SMTP può essere accidentalmente sottoposto a proxy durante la configurazione, soprattutto se qualcuno sta rivedendo i record e abilitando il proxy batch. Il risultato è che il server di posta ora espone gli IP Cloudflare invece dell'IP reale e le connessioni SMTP esterne raggiungono un proxy che non sa cosa farne. L'errore non è immediato: alcuni client di posta riprovano, il timeout richiede alcuni minuti e il problema appare intermittente prima di diventare consistente.

Lo stesso accade con i database esposti tramite DNS. Un record A che si risolve in un server MySQL o PostgreSQL dietro il proxy restituisce l'IP Cloudflare. L'applicazione tenta di connettersi alla porta 3306 o 5432, il proxy rifiuta (non supporta queste porte per impostazione predefinita) e la connessione fallisce con un timeout. Il servizio sembra inattivo, ma il DNS "funziona" — punta semplicemente al posto sbagliato.

Prima di invertire i nameserver, esamina ciascun record A e AAAA e conferma la modalità corretta. La regola è semplice: se il servizio a quell'indirizzo non risponde esclusivamente in HTTP/HTTPS sulle porte 80 e 443, la modalità deve essere solo DNS.

TTL e finestra di propagazione

La propagazione del nameserver non è istantanea e il TTL dei record nel provider attuale determina il tempo impiegato dai risolutori di tutto il mondo per eliminare la vecchia cache. Se i tuoi record hanno un TTL di 86400 secondi (24 ore) - lo standard per molti provider - e attivi i nameserver adesso, alcuni risolutori continueranno a servire i vecchi record fino a 24 ore, indipendentemente da ciò che già dice Cloudflare.

La giusta strategia inizia due giorni prima della migrazione. Abbassa il TTL di tutti i record critici a 300 secondi (cinque minuti) sul provider corrente. Attendere il tempo equivalente al TTL originale: se le registrazioni erano a 3600 secondi attendere un'ora; se fossero a 86400, attendere 24 ore. Solo allora attiva i nameserver. Pertanto, quando si verifica la modifica, le cache in tutto il mondo scadono in un massimo di cinque minuti e tutti i problemi che si verificano durante la migrazione vengono risolti rapidamente: non sei bloccato ad aspettare che scadano le cache di 24 ore mentre si verifica l'incidente.

Questo passaggio viene spesso ignorato perché richiede una pianificazione anticipata. Chi arriva il giorno prima della migrazione e nota che i TTL sono a 86400 ha due opzioni: abbassare il TTL e attendere 24 ore prima di procedere, oppure accettare il rischio di una lunga finestra di propagazione. La seconda opzione è la strada più comune verso un blackout che dura più a lungo del dovuto.

DNSSEC: il dettaglio che trasforma la propagazione in fallimento di validazione

Se il dominio ha DNSSEC attivo presso il provider attuale, la migrazione dei nameserver senza gestire i record DS presso il registrar causa un errore di convalida su tutti i risolutori che controllano DNSSEC. Il risolutore riceve la notifica che il dominio utilizza DNSSEC (tramite il record DS presso il registrar), interroga Cloudflare, riceve firme firmate con chiavi Cloudflare e rifiuta la risposta perché le chiavi non corrispondono al DS che punta ancora al provider precedente.

La sequenza corretta prevede quattro passaggi intervallati da finestre di attesa. Innanzitutto, rimuovi i record DS dal registrar (non presso il provider DNS, presso il registrar in cui è registrato il dominio). In secondo luogo, attendere la scadenza del TTL dei record DS, in genere tra una e quattro ore, a seconda del registratore. Terzo, capovolgi i nameserver su Cloudflare. In quarto luogo, abilita DNSSEC nella dashboard di Cloudflare e aggiungi i nuovi record DS forniti dalla piattaforma al registrar. Saltare il periodo di attesa tra il primo e il terzo passaggio è la causa più comune di incidenti DNSSEC nelle migrazioni.

Come strutturare la migrazione per non improvvisare sotto pressione

La differenza tra una migrazione che termina in trenta minuti e una che si trasforma in un incidente di tre ore è quasi sempre organizzativa. I team che ottengono buoni risultati definiscono in anticipo chi convalida ogni passaggio, cosa configura il rollback e quali sono i criteri di successo prima di dichiarare completata la migrazione.

La sequenza operativa che funziona inizia con il confronto delle zone tra il fornitore attuale e Cloudflare, effettuato prima di qualsiasi pivot. I domini con SPF, DKIM e DMARC richiedono un'attenzione particolare: i record TXT possono contenere virgolette o concatenazioni che automatizzano la riformattazione dell'importazione, interrompendo la convalida anche se il contenuto appare corretto. I record SRV per servizi come SIP, XMPP o Minecraft richiedono il controllo manuale dei campi di priorità e peso.

Dopo che i server dei nomi sono stati trasferiti, il protocollo di verifica prevede tre comandi che devono essere eseguiti in sequenza. Il comando dig @1.1.1.1 +short exemplo.com NS conferma che Cloudflare è già autorevole per il dominio su quel risolutore. Il comando dig @8.8.8.8 +short mail.exemplo.com A verifica che il registro e-mail restituisca l'IP reale del server, non un IP Cloudflare. Un invio di prova di email da un indirizzo esterno entro i primi trenta minuti dal turnaround chiude il ciclo di verifica di base.