Pubblicato il
Un caso reale di trasferimento di domini multipli non comincia dal codice di autorizzazione. Comincia da una domanda molto più concreta: cosa smette di funzionare se il trasferimento viene eseguito senza una mappa precisa? Per un'agenzia web con clienti attivi, la risposta può includere siti aziendali, caselle email, e-commerce, landing page e servizi collegati a record DNS poco documentati.
Il caso descritto è reale, con dati identificativi omessi. Il cliente era un'agenzia che gestiva 31 domini per 14 aziende, distribuiti tra quattro registrar e tre fornitori di hosting. L'obiettivo non era migrare subito siti e server: era centralizzare la gestione dei domini, ridurre i rinnovi dimenticati e avere un solo punto di controllo amministrativo. Una distinzione semplice, ma decisiva.
Caso reale trasferimento domini multipli: il contesto
Nel portafoglio erano presenti domini .it, .com, .eu e alcune estensioni tematiche. Dieci domini puntavano a hosting condivisi, sei a un cloud server, quattro a piattaforme esterne per l'invio email e gli altri erano domini difensivi o destinati a campagne future. Alcuni avevano il DNS gestito dal registrar di origine, altri da provider terzi.
Il rischio maggiore non era il trasferimento in sé. I registrar applicano procedure consolidate, ma ogni estensione ha regole, tempi e verifiche proprie. Il problema reale era la dipendenza tra dominio, zona DNS, posta e infrastruttura applicativa. Un cambio non pianificato dei nameserver, anche involontario, avrebbe potuto rendere irraggiungibile un sito o interrompere la ricezione delle email.
Per questo il progetto è stato impostato come un'attività di gestione infrastrutturale, non come una semplice pratica amministrativa. Prima si è consolidata la visibilità; solo dopo sono partite le richieste di trasferimento.
Prima del trasferimento: inventario e controlli DNS
Il primo passaggio è stato costruire un inventario unico. Per ogni dominio sono stati registrati registrar di provenienza, data di scadenza, stato del blocco trasferimento, contatto amministrativo, metodo di autorizzazione richiesto dall'estensione e responsabile interno. Non tutti i domini richiedono lo stesso codice o seguono la stessa procedura: trattarli come identici è un errore che rallenta il progetto.
Accanto ai dati amministrativi è stata creata una mappa tecnica. Per ogni dominio l'agenzia ha verificato i nameserver autorevoli e salvato la zona DNS esistente: record A e AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC, record di verifica per servizi esterni e sottodomini utilizzati dalle applicazioni.
Questa fase ha fatto emergere due criticità che non risultavano dalla documentazione iniziale. Un sottodominio usato per una piattaforma di e-learning puntava a un server non più gestito dall'agenzia. Inoltre, un dominio aveva record MX corretti, ma una regola di inoltro configurata presso il vecchio fornitore. Senza il controllo preventivo, il trasferimento avrebbe lasciato il servizio apparentemente attivo ma con una parte della posta non consegnata come previsto.
Il controllo DNS va quindi oltre la domanda “il sito si apre?”. Un dominio può rispondere correttamente nel browser e avere comunque servizi essenziali dipendenti da record meno visibili. Per un e-commerce, ad esempio, possono essere critici anche i record di verifica del gateway di pagamento, le integrazioni con gestionali o i sottodomini dedicati alle API.
Trasferire un dominio non significa migrare l'hosting
Nel caso analizzato, l'agenzia ha scelto di mantenere invariati i nameserver durante l'intera prima fase. È stata trasferita la registrazione del dominio, non il servizio DNS né l'hosting. Questa scelta ha eliminato il rischio di propagazione dovuto a modifiche simultanee e ha consentito di verificare ogni pratica senza toccare la produzione.
Non è sempre la scelta migliore. Se il DNS del vecchio registrar deve essere dismesso in tempi brevi, può avere senso migrare prima la zona presso il nuovo gestore. In quel caso occorre replicare tutti i record, controllare le risposte DNS e pianificare il cambio dei nameserver separatamente dal trasferimento. Fare entrambe le operazioni nello stesso momento è possibile, ma aumenta i punti di errore e rende più difficile individuare la causa di un problema.
Trasferimento di domini multipli: la sequenza che ha funzionato
I 31 domini non sono stati inviati tutti insieme. Il progetto è stato diviso in gruppi, partendo da due domini non critici. Il test ha permesso di confermare la corretta ricezione delle email di approvazione, verificare i dati dei contatti e misurare le tempistiche effettive delle diverse estensioni.
Dopo il test, sono stati trasferiti i domini senza servizi collegati, poi quelli con siti vetrina e infine i domini che gestivano posta aziendale, e-commerce o applicazioni. Ogni gruppo veniva sottoposto a una verifica prima della richiesta e a un controllo dopo il completamento.
La sequenza operativa è stata questa:
- verifica di scadenza, blocco trasferimento e dati del registrante;
- raccolta del codice di autorizzazione o della procedura equivalente prevista dal TLD;
- conferma che i nameserver e la zona DNS restassero invariati;
- invio della richiesta, monitoraggio delle email di conferma e annotazione dello stato;
- test finale di risoluzione DNS, sito web, invio e ricezione della posta.
La data di scadenza ha richiesto particolare attenzione. Un dominio vicino al rinnovo non va lasciato in una zona grigia tra vecchio e nuovo registrar. In base all'estensione e allo stato della pratica, può essere più prudente rinnovare prima oppure programmare il trasferimento con margine. La regola pratica è evitare che urgenza commerciale e trasferimento tecnico coincidano.
Un altro controllo utile riguarda le modifiche recenti ai dati del registrante. Alcune estensioni possono prevedere restrizioni temporanee dopo determinate variazioni. Non esiste una regola unica valida per tutti i TLD: occorre verificare le condizioni applicabili al dominio specifico prima di annunciare una data certa al cliente.
Il risultato: continuità operativa, non fortuna
L'intero portafoglio è stato completato in dieci giorni di calendario, con tempi diversi per le varie estensioni. Non sono stati registrati fermi di siti o della posta. Il risultato, però, non è dipeso da un trasferimento “senza rischi”: è dipeso dalla scelta di non modificare contemporaneamente DNS, hosting e configurazioni email.
Il beneficio più immediato è stato amministrativo. L'agenzia ha ottenuto una visione centralizzata di scadenze, rinnovi e responsabilità. Ha inoltre potuto assegnare ai clienti procedure più chiare per approvazioni e rinnovi, evitando che credenziali e notifiche restassero legate a ex collaboratori o caselle email non presidiate.
Il secondo beneficio è stato tecnico. L'inventario creato per il progetto è diventato la base per pianificare in un secondo momento le migrazioni di alcuni siti verso ambienti più performanti. Una volta separati dominio, DNS, hosting e posta, decidere se usare hosting NVMe, cloud server o un server dedicato diventa una scelta ragionata sulle esigenze del progetto, non una risposta d'emergenza a un disservizio.
Quando centralizzare e quando mantenere separati i servizi
Centralizzare i domini presso un solo fornitore semplifica rinnovi, fatturazione e supporto. Per freelance, PMI e agenzie con molti clienti, avere un pannello unico riduce il rischio operativo e rende più veloce la gestione quotidiana. Con CoolNetwork, dominio e infrastruttura possono essere gestiti nello stesso ambiente, mantenendo la possibilità di far crescere il progetto da un piano hosting a soluzioni cloud o dedicate.
Questo non significa che tutto debba essere accentrato a ogni costo. Un'azienda con architetture complesse, DNS anycast esterno, servizi email specialistici o requisiti di continuità molto elevati può scegliere di conservare alcuni componenti separati. Anche in questo scenario, il valore della centralizzazione dei domini resta concreto: responsabilità definite, date di rinnovo sotto controllo e procedure documentate.
La differenza la fa la documentazione. Un dominio non è soltanto un nome registrato: è il punto di ingresso a servizi che producono contatti, vendite, comunicazioni e lavoro quotidiano. Prima di avviare il prossimo trasferimento, costruisci una mappa affidabile di ciò che quel dominio governa. È il controllo più semplice da eseguire e quello che protegge meglio la continuità del tuo progetto.