Un trasferimento di nome di dominio mal preparato si traduce in email perse, un sito inaccessibile o un dominio bloccato in stato pendingTransfer per giorni. La procedura stessa è semplice sulla carta: sbloccare, recuperare il codice EPP, convalidare dal nuovo registrar. Ciò che crea problemi sono i dettagli tecnici che la maggior parte delle guide sorvola, in particolare la gestione della zona DNS durante il passaggio e le specificità legate alle estensioni nazionali.
Zona DNS e registrazioni da salvare prima del trasferimento di dominio
Il trasferimento sposta il controllo amministrativo del dominio, non la zona DNS stessa. Osserviamo regolarmente perdite di registrazioni MX o TXT dopo la migrazione, perché la zona ospitata presso il vecchio registrar non è stata duplicata presso il nuovo prima del passaggio.
Vedi anche : I vantaggi del marmo galala per esaltare i vostri progetti di ristrutturazione vicino a Vannes
Prima di qualsiasi operazione, esporta l’intera zona DNS. Controlla ogni tipo di registrazione: A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC), e eventuali registrazioni SRV. Se il tuo dominio utilizza DNSSEC, disattivalo prima di avviare il trasferimento: una registrazione DS orfana presso il registro provoca risoluzioni fallite finché il nuovo registrar non ha ripubblicato le proprie chiavi.
Ricrea tutte queste registrazioni presso il nuovo fornitore o su un servizio DNS di terze parti (Cloudflare, Route 53) prima di avviare il trasferimento. Una volta che la zona è pronta da entrambi i lati, il passaggio amministrativo non ha più impatto sulla risoluzione. Se stai cercando come trasferire un nome di dominio con Fireblog, troverai questa logica di preparazione DNS applicata passo dopo passo.
Ulteriori letture : Rispondere su Meetic senza pagare: trucchi per scambiare senza abbonamento
Codice EPP, sblocco e protezione WHOIS: i prerequisiti tecnici del trasferimento
Tre blocchi impediscono un trasferimento se non vengono rimossi nell’ordine corretto.
- Lo stato clientTransferProhibited (o registrar lock) deve essere rimosso dall’interfaccia del tuo attuale registrar. Finché è attivo, ogni richiesta di trasferimento viene rifiutata automaticamente dal registro.
- Il codice di autorizzazione EPP (o Auth-Code) è una password usa e getta legata al dominio. La sua durata di validità varia a seconda del registrar, a volte solo pochi giorni. Recuperalo nel momento in cui sei pronto ad avviare la procedura, non in anticipo.
- La protezione della privacy WHOIS deve essere disattivata temporaneamente. Molti registrar nascondono l’indirizzo email del titolare dietro un proxy. L’email di convalida del trasferimento viene inviata all’indirizzo WHOIS: se punta a un servizio di privacy che filtra o reindirizza male, la convalida fallisce silenziosamente.
Consigliamo di controllare il WHOIS pubblico del dominio dopo aver disattivato la protezione, per confermare che l’indirizzo email visualizzato sia quello che stai consultando. Un’email di convalida non ricevuta è la prima causa di trasferimenti abortiti.
Il blocco di sessanta giorni dopo modifica WHOIS
La politica ICANN impone un blocco di sessanta giorni dopo qualsiasi cambiamento di titolare sui gTLD (.com, .net, .org). Se hai recentemente modificato il nome o l’email del titolare nel WHOIS, il trasferimento verrà rifiutato per tutto questo periodo. Pianifica i tuoi aggiornamenti di contatti con largo anticipo rispetto alla migrazione, o effettuali dopo.
Trasferimento di dominio secondo l’estensione: gTLD, ccTLD e casi particolari
Gli articoli generalisti descrivono un processo universale. In pratica, ogni tipo di estensione obbedisce alle proprie regole di trasferimento.
Per i gTLD (.com, .net, .org), il processo è standardizzato dall’ICANN: codice EPP, richiesta presso il nuovo registrar, email di conferma, poi un periodo di cinque a sette giorni durante il quale il vecchio registrar può approvare o lasciare scadere la richiesta. L’approvazione esplicita da parte del vecchio registrar accelera la procedura.
I ccTLD (estensioni nazionali) seguono regole diverse. Il .fr, gestito dall’AFNIC, utilizza un codice di autorizzazione simile al codice EPP, ma la procedura di cambio di ufficio di registrazione passa attraverso una Domanda di Operazione Afnic (DOA). Il .uk funziona con un sistema di tag: chiedi al tuo registrar attuale di cambiare il tag IPS verso il nuovo fornitore, senza codice EPP. Il .de (DENIC) impone un Auth-Code ma con un processo di convalida distinto.
Queste differenze hanno un impatto diretto sui tempi. Un trasferimento di .com richiede generalmente meno di una settimana. Un ccTLD può richiedere diverse settimane se sono richiesti documenti d’identità o di residenza dall’autorità nazionale.
Email e certificato SSL dopo il passaggio
Il trasferimento di dominio non trasferisce il tuo hosting web né la tua posta elettronica. Se le tue registrazioni MX puntavano ai server del vecchio registrar, le tue email smetteranno di funzionare non appena la zona DNS verrà modificata. Controlla che i MX puntino al tuo fornitore di posta reale (Google Workspace, Microsoft 365, server dedicato) e non a un servizio legato al registrar uscente.
Per quanto riguarda l’SSL, un certificato Let’s Encrypt si rinnova automaticamente se la convalida DNS o HTTP è ancora funzionante. Un certificato a pagamento legato al vecchio host dovrà essere riemesso o trasferito. Controlla la data di scadenza e il metodo di convalida prima del trasferimento per evitare un passaggio a HTTP non sicuro.
Checklist di verifica post-trasferimento del nome di dominio
Una volta che il dominio è visualizzato presso il nuovo registrar, il lavoro non è finito. Notiamo che la maggior parte degli incidenti si verifica nelle quarantotto ore successive al passaggio, quando nessuno controlla più nulla.
- Confronta la zona DNS attiva con il tuo backup iniziale. Ogni registrazione A, MX, CNAME e TXT deve corrispondere esattamente.
- Invia un’email di prova verso e da ogni indirizzo legato al dominio per confermare il corretto funzionamento dei MX.
- Controlla la risoluzione DNSSEC se l’hai riattivata: uno strumento come DNSViz consente di individuare una catena di fiducia interrotta.
- Riattiva il blocco del dominio (clientTransferProhibited) e la protezione WHOIS presso il nuovo registrar.
- Controlla che il certificato SSL sia valido e che il tuo sito risponda correttamente in HTTPS senza errori di certificato.
Il trasferimento di un nome di dominio rimane un’operazione amministrativa, non tecnica nel senso stretto. Ciò che provoca le interruzioni è l’assenza di preparazione DNS a monte e l’oblio delle verifiche a valle. Prepara la zona prima, verifica tutto dopo: tra i due, il trasferimento stesso richiede solo pochi clic.