Il trasferimento di un dominio spaventa più di quanto dovrebbe, e la colpa è di come viene raccontato. Molti provider lo descrivono come un'operazione delicata da cui potrebbero derivare disservizi — il che è comodo per chi non vuole perdere un cliente, ma non è vero.
Ecco cosa succede davvero, per un .it.
Prima cosa: il trasferimento non tocca il sito
È il punto che elimina il novanta per cento dell'ansia. Trasferire un dominio cambia chi te lo fattura, non dove punta.
Il dominio ha, separatamente:
- un registrar, cioè il fornitore attraverso cui è registrato;
- dei nameserver, cioè chi risponde alle domande su di lui.
Il trasferimento cambia il primo. I secondi restano quelli che erano, e con loro restano identici il sito, la posta, i sottodomini e tutto il resto. Se non tocchi la zona DNS, non si accorge nessuno — clienti compresi.
Il disservizio arriva solo se, insieme al registrar, cambi anche l'hosting. Sono due operazioni distinte e conviene tenerle distinte, anche nel tempo.
Il codice authinfo
Per spostare un .it serve un codice di autorizzazione, chiamato authinfo. È la prova che chi chiede il trasferimento ha il diritto di chiederlo.
Due cose importanti su questo codice.
Va inviato al Registrante, non a chi lo chiede. Il regolamento del Registro è esplicito: l'authinfo si comunica all'indirizzo email del titolare risultante nei dati del dominio. Non al contatto tecnico, non all'agenzia.
Quindi l'email nei dati del dominio è più importante del nome. Se il Registrante è la tua azienda ma l'email è quella di chi ti ha fatto il sito, il codice arriva a loro. È il motivo per cui, prima di qualunque trasferimento, si verifica l'intestazione — e se l'email non è tua, la si corregge per prima.
Se il provider attuale non fornisce il codice, non sei bloccato: il Registro prevede una procedura per ottenerlo, ed è pensata esattamente per questi casi.
I tempi: 24 ore, non giorni
Qui il .it è più veloce delle estensioni internazionali, e la differenza è netta.
Una volta inviata la richiesta con l'authinfo corretto, il dominio entra in uno stato di trasferimento in attesa che dura al massimo ventiquattro ore. In quella finestra il vecchio registrar può rifiutare esplicitamente. Se non lo fa, trascorso il tempo, il Registro approva da solo e il trasferimento è completato.
Non serve che il vecchio provider dica di sì. Serve solo che non dica di no, e un rifiuto va motivato.
Per confronto: su .com e sulle altre estensioni internazionali le regole ICANN prevedono fino a cinque giorni, e il dominio è bloccato per sessanta giorni dopo una registrazione o un trasferimento recente. Il .it non ha quel blocco di sessanta giorni.
Quando un trasferimento viene rifiutato
I casi legittimi sono pochi e vale la pena conoscerli, perché sapere quali sono aiuta a capire quando un rifiuto è invece pretestuoso:
- il dominio è appena stato registrato o trasferito — c'è un periodo minimo prima di poterlo rispostare;
- c'è una disputa aperta sul nome;
- l'authinfo è sbagliato o scaduto;
- i dati del Registrante non corrispondono a quelli della richiesta.
Le fatture non pagate non sono nell'elenco. Un fornitore può avere ragione sul credito e comunque non avere titolo per trattenere il dominio: sono due questioni separate, e conviene dirlo con calma prima che diventi una lite.
La sequenza che uso
- Verifica dei dati del dominio. Chi è il Registrante, quale email risulta, presso quale registrar sta, quando scade.
- Correzione dell'email, se serve. È il passo che quasi tutti saltano e che decide tutto il resto.
- Sblocco del dominio presso il registrar attuale, se ha un blocco trasferimento attivo.
- Richiesta dell'authinfo, che arriva alla casella del Registrante.
- Avvio del trasferimento presso il nuovo registrar, con il codice.
- Attesa, al massimo un giorno.
- Verifica finale: nel whois compare il nuovo registrar, i nameserver sono rimasti quelli di prima, il sito e la posta rispondono come sempre.
- Rinnovo automatico e blocco trasferimento riattivati sul nuovo account, insieme al secondo fattore.
Il passaggio 7 è breve ma non si salta: è lì che si scopre, occasionalmente, che il vecchio provider aveva la zona DNS ospitata sui propri nameserver e che ora conviene decidere dove tenerla.
Il caso che complica tutto
C'è una situazione in cui la sequenza sopra non basta: quando il DNS è ospitato dal provider che stai lasciando. Non è raro, ed è logico — te lo davano insieme al resto.
In quel caso il trasferimento del registrar è comunque indolore, ma prima o poi quei nameserver spariranno, e con loro sito e posta. La soluzione è spostare la zona DNS prima del trasferimento, non dopo: si ricostruisce altrove, si verifica record per record, si cambiano i nameserver, si aspetta che tutto risponda dal nuovo posto, e solo allora si sposta il registrar.
Fatto in quest'ordine, non c'è un momento in cui qualcosa dipende da un fornitore che stai per lasciare.