Come verificare che una migrazione DNS sia andata bene

Migrare il DNS (cambiare provider, passare a una nuova configurazione dei nameserver o ristrutturare un grande insieme di record) comporta più rischi della maggior parte delle modifiche all'infrastruttura, proprio perché un errore non fallisce in modo rumoroso. Un record rotto semplicemente smette di risolversi in silenzio, oppure si risolve in qualcosa di sbagliato, e il primo segnale è spesso un ticket di assistenza e non un alert.

Prima della migrazione

• Esporta ogni record esistente dal provider attuale: un file di zona completo o equivalente, non solo quelli che ricordi di aver configurato.
• Abbassa i TTL dei record che cambieranno, con almeno un intero ciclo di TTL di anticipo.
• Annota i valori attuali di tutto: A/AAAA, CNAME, MX, TXT (compresi SPF/DKIM/DMARC) ed eventuali tipi di record meno comuni in uso.

Dopo la migrazione

1. Interroga direttamente i nuovi nameserver autorevoli per ogni record migrato e confronta ciascuna risposta con l'export fatto prima della migrazione.
2. Controlla A e AAAA in modo indipendente per ogni hostname che prima aveva l'uno o l'altro: è facile migrare una famiglia di indirizzi e dimenticare l'altra.
3. Verifica in modo specifico MX e i record di autenticazione della posta collegati: i guasti della posta dovuti a una migrazione DNS sono sproporzionatamente frequenti e sproporzionatamente dannosi.
4. Ricontrolla da più di un resolver, e idealmente da più di una posizione di rete, prima di dichiarare completata la migrazione.
5. Aspetta che trascorra la finestra del vecchio TTL, poi controlla di nuovo: un risultato pulito subito dopo il cutover non garantisce che tutti i resolver in cache nel mondo si siano già allineati.

Un lookup in blocco che copra l'intero elenco di hostname, eseguito una volta subito dopo il cutover e di nuovo quando la finestra del vecchio TTL è trascorsa, trasforma questo lavoro da un controllo manuale record per record in un unico passaggio ripetibile, e ti lascia un resoconto esportabile di cosa è stato verificato esattamente e quando.

Non smantellare il vecchio troppo presto

Il rimpianto più comune dopo una migrazione non è un record dimenticato, ma l'account o i nameserver del vecchio provider cancellati o dismessi lo stesso giorno in cui entrano in funzione i nuovi. Poiché una parte dei resolver nel mondo continua a lavorare con risposte in cache che puntano alla vecchia configurazione fino alla scadenza del loro TTL, tenere attivo il provider precedente (anche se nulla di nuovo punta più a lui) per almeno un'intera finestra del vecchio TTL dopo il cutover è un'assicurazione a basso costo. Se serve un rollback rapido, avere il lato vecchio ancora in grado di rispondere fa la differenza tra rimettere i nameserver com'erano in pochi minuti e ricostruire a memoria un file di zona sotto pressione.

Una prova generale intercetta la maggior parte dei problemi prima che siano reali

Quando il nuovo provider DNS lo consente, preparare in anticipo l'intera nuova zona (completamente configurata, ma non ancora delegata) e interrogarla direttamente, aggirando la normale delega, puntando esplicitamente uno strumento di test ai suoi nameserver o usando la funzione di anteprima del provider stesso, trasforma la verifica della migrazione da un trambusto successivo al cutover in un controllo precedente al cutover, senza alcun impatto sugli utenti se qualcosa non va. Qualsiasi record mancante, configurato male o semplicemente diverso da quello previsto emerge prima che un solo resolver reale lo abbia mai visto, e questo è un momento molto meno stressante per scoprire un errore rispetto a quando il cutover è già andato in produzione.