Trasferire un dominio: codice AuthInfo, tempi e regole .it

Trasferire un dominio è un'operazione di routine, finché non scopri chi gestiva davvero i DNS o che il cliente ha cambiato ragione sociale il mese scorso. I domini generici (.com, .net, .org e nuovi gTLD) seguono la Transfer Policy di ICANN, i .it il Regolamento e le Linee guida tecniche del Registro .it: conviene conoscere entrambi prima di promettere una data al cliente.

Cos'è il codice AuthInfo (o codice EPP)

L'AuthInfo, detto anche codice EPP o auth code, è una password legata al singolo dominio e conservata dal registro. EPP è il protocollo con cui i registrar comunicano con i registri, e la RFC 5731 definisce questa informazione di autorizzazione come lo strumento che abilita i trasferimenti: il nuovo registrar la inserisce nella richiesta e, se non corrisponde a quella memorizzata, il registro la respinge.

Chi ha il codice può avviare il trasferimento: trattalo come una password, perché la stessa RFC avverte che una divulgazione accidentale può portare a trasferimenti non autorizzati. E il codice spetta al titolare del dominio, non all'agenzia che lo gestisce. Per i gTLD, se il pannello non permette di generarlo, il registrar deve fornirlo entro 5 giorni di calendario dalla richiesta e non può negarlo solo per una controversia sui pagamenti.

Sblocco e regola dei 60 giorni

Molti registrar attivano il blocco di trasferimento (transfer lock), che nel registro compare come stato clientTransferProhibited: finché è attivo, ogni richiesta viene respinta. Si toglie dal pannello o lo si chiede al registrar, che per i gTLD ha gli stessi 5 giorni. Poi ci sono i blocchi temporali. Secondo la Transfer Policy di ICANN in vigore (versione del 21 febbraio 2024):

• il registrar può rifiutare un trasferimento richiesto entro 60 giorni dalla creazione del dominio;
• può rifiutarlo entro 60 giorni da un precedente trasferimento tra registrar;
• dopo un cambio del titolare, cioè una modifica sostanziale di nome o organizzazione o un cambio dell'email del registrante, deve applicare un blocco di 60 giorni, salvo opt-out scelto prima della modifica. L'opt-out è facoltativo: il registrar può offrirlo, non è obbligato.

Il registrar uscente può rifiutare anche per frode, dubbi fondati sull'identità del titolare o periodi precedenti non pagati, e deve rifiutare se è in corso una procedura UDRP; non può farlo perché il dominio è vicino alla scadenza o perché il titolare non ha risposto alla sua email.

Come si trasferisce un .com, passo per passo

1. Sblocchi il dominio e ottieni il codice AuthInfo dal registrar attuale.
2. Avvii il trasferimento presso il nuovo registrar inserendo il codice. Di solito il prezzo comprende un anno di rinnovo.
3. Il registro inoltra la richiesta al registrar uscente, che entro 24 ore deve inviare al titolare un'email di conferma.
4. Il registrar uscente può approvare subito, rifiutare per uno dei motivi ammessi o non fare nulla: se non risponde entro 5 giorni di calendario, il trasferimento viene approvato d'ufficio.
5. A trasferimento completato si aggiunge un anno alla scadenza esistente, con un tetto di 10 anni di durata residua complessiva.

In pratica un .com si sposta in un tempo che va da poche ore a 5 giorni: molti registrar mettono nell'email di conferma un link per approvare subito. Quell'email arriva all'indirizzo del titolare registrato, quindi verificalo prima, soprattutto se è una casella sul dominio stesso ospitata dal vecchio fornitore. Se il dominio è già scaduto, chiedi al nuovo registrar come sarà calcolata la nuova scadenza: contano anche le regole del singolo registro.

Trasferire un dominio .it: le regole del Registro

Il .it non segue la Transfer Policy di ICANN. Il Registro .it chiama il trasferimento «modifica del Registrar», con regole proprie:

• Il registrar comunica l'AuthInfo al titolare alla registrazione e a ogni successiva modifica. Se non lo trovi, chiedilo al registrar attuale: al Registro ci si rivolge solo se il registrar non è rintracciabile o si rifiuta di fornirlo.
• Le Linee guida tecniche non prevedono blocchi di 60 giorni. Il Registro verifica che l'AuthInfo sia corretto e che il dominio non sia in stati incompatibili, come clientTransferProhibited, pendingUpdate, pendingDelete, redemptionPeriod, clientHold, serverHold o revoked.
• Dopo la richiesta del nuovo registrar il dominio resta in pendingTransfer al massimo un giorno; se nessuno annulla o rifiuta, il Registro approva in automatico.
• Il registrar uscente può opporsi soltanto se ha ricevuto, per quel dominio, un provvedimento delle autorità notificato nelle forme di legge. Motivi commerciali non sono previsti.
• Registrar e titolare si possono cambiare con un'unica operazione: il vecchio titolare consegna l'AuthInfo al nuovo.
• A operazione conclusa, il nuovo registrar ti comunica l'esito e un nuovo AuthInfo.

Cosa succede alla scadenza di un .it trasferito

È il punto su cui si leggono più risposte contraddittorie. Secondo le FAQ di nic.it i .it hanno durata annuale, che decorre dalla registrazione oppure dall'ultima modifica, come un trasferimento. L'esempio ufficiale: un dominio registrato il 30 giugno 2013 e trasferito il 1° febbraio 2014 scade il 1° febbraio 2015. La scadenza quindi non si allunga di un anno come per un .com: riparte da un anno dalla data del trasferimento, e i mesi residui presso il vecchio registrar non si sommano.

Il Registro invita però a verificare anche la durata del contratto con il registrar, che è un accordo commerciale distinto: per questo le risposte cambiano a seconda di chi spiega. Per non pagare due volte lo stesso periodo, pianifica il trasferimento nelle settimane prima della scadenza e controlla se il vecchio registrar ti ha già addebitato il rinnovo.

gTLD e .it a confronto

DNS e posta durante il trasferimento

Il trasferimento cambia il registrar, non i nameserver: la delega presso il registro resta la stessa, e con lei sito e posta. Se i DNS sono su un servizio esterno, per esempio la zona gestita nel cPanel dell'hosting, non cambia nulla.

Il rischio concreto è quando i nameserver sono quelli del vecchio registrar, spesso inclusi con il dominio. A trasferimento concluso la zona può essere cancellata e con lei i record A, MX, SPF e DKIM: sito e posta si fermano. Per ridurre al minimo l'interruzione:

• copia prima la zona completa: A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC, record di verifica), SRV e CAA;
• ricreala sui nuovi DNS e confronta le risposte record per record interrogando i nuovi server;
• sposta i nameserver come operazione separata, prima o dopo il trasferimento, mai in contemporanea;
• se usi caselle o inoltri email del vecchio registrar, migra la posta prima: il servizio termina con il contratto;
• con DNSSEC attivo e un cambio di gestore DNS, coordina il record DS: se non corrisponde alle chiavi del nuovo gestore, i resolver che validano rispondono con un errore (SERVFAIL) e per i loro utenti il dominio smette di risolvere.

# Stato, registrar e scadenza (i campi cambiano da registro a registro)
whois esempio.it | grep -iE 'status|registrar|expire'

# Delega e record da conservare
dig NS esempio.it +short
dig MX esempio.it +short
dig DS esempio.it +short

# Stessa domanda ai nuovi DNS, prima di spostare la delega
dig @ns1.nuovo-dns.example MX esempio.it +short

Checklist per trasferire un dominio

1. Verifica chi è il titolare e che la sua email sia attiva e letta.
2. Per un gTLD, controlla data di creazione, ultimo trasferimento ed eventuali cambi del titolare negli ultimi 60 giorni.
3. Controlla la scadenza: per un .it pianifica il trasferimento nelle settimane prima; per un gTLD evita gli ultimi giorni.
4. Copia la zona DNS e decidi dove vivrà dopo il trasferimento.
5. Se cambi gestore DNS, sposta i nameserver come passo separato e aspetta che la modifica sia completata (per un .it, fino all'esito del controllo DNS del Registro).
6. Rimuovi il blocco di trasferimento (clientTransferProhibited).
7. Ottieni il codice AuthInfo e custodiscilo come una password.
8. Avvia il trasferimento presso il nuovo registrar e approva l'email di conferma, se la ricevi.
9. Verifica nel whois nuovo registrar, stato e scadenza.
10. Riattiva il blocco di trasferimento sui gTLD e, per i .it, conserva il nuovo AuthInfo.
11. Dopo qualche ora controlla sito, posta e record SPF, DKIM e DMARC; disdici i servizi rimasti presso il vecchio fornitore solo quando tutto funziona.

Se il codice viene rifiutato, di solito è stato rigenerato o copiato con spazi in più; se il trasferimento è respinto, il whois mostra quasi sempre il motivo: un blocco ancora attivo, i 60 giorni o, sui .it, un pendingUpdate. E se gestisci decine di domini di clienti e preferisci che qualcun altro segua codici, conferme e DNS, in lubemy possiamo occuparci noi del trasferimento, partendo da un controllo dello stato di ogni dominio.