Trasferire un dominio .it: AuthInfo, DNSSEC e le trappole che fanno smettere di funzionare la posta

Il trasferimento di un dominio .it da un registrar a un altro in sé è rapido. Quello che manda in tilt sito e posta, di solito, non è il trasferimento ma ciò che gli sta attorno: un blocco dimenticato, un DNSSEC attivo, una zona DNS che cambia mano senza che nessuno l’abbia copiata. Qui trovi i passaggi e le trappole, basati sulle Linee guida tecniche sincrone del Registro .it (versione 2.4, quella che ho consultato) e sulle pagine del Registro. Dove un dettaglio dipende dal registrar, lo dico.

Come funziona il cambio di registrar nel .it

Il Registro .it non tratta direttamente con il titolare: lavora con i registrar accreditati. Per cambiare registrar la richiesta la fa il nuovo registrar, per conto del titolare, e deve inserire il codice AuthInfo associato al dominio. Il titolare quindi deve prima ottenere questo codice e consegnarlo al nuovo registrar.

Una volta accettata la richiesta, il dominio passa nello stato pendingTransfer. Secondo le linee guida ci resta al massimo un giorno. In quel periodo il nuovo registrar può annullare, mentre il vecchio può approvare o rifiutare. Se nessuno interviene, la richiesta viene approvata automaticamente alla fine del periodo. Le linee guida precisano anche che il vecchio registrar può opporsi solo in presenza di un provvedimento notificato dalle autorità: non può bloccare il trasferimento a piacere.

Il codice AuthInfo

• Cos’è: la password che autorizza le operazioni sul dominio, inclusa la richiesta di cambio registrar. Il registrar la consegna al titolare alla registrazione.
• Dove si prende: dal registrar attuale. Molti la mostrano nel pannello del dominio, altri la inviano su richiesta.
• Se il registrar non risponde: secondo le pagine del Registro, il titolare può rivolgersi direttamente al Registro. Controlla su nic.it i recapiti e la modulistica aggiornati prima di scrivere, perché cambiano nel tempo.
• Formato: nelle linee guida l’AuthInfo ha da 8 a 32 caratteri. Se il codice viene rifiutato, copia e incolla con cura: spazi finali e caratteri scambiati sono la causa più banale.
• Dopo il trasferimento: spetta al nuovo registrar impostare un nuovo AuthInfo. Chiedi di non tenere in giro quello vecchio.

Cosa blocca un trasferimento

Le linee guida elencano gli stati in cui la richiesta viene respinta. I più comuni nella pratica:

• clientTransferProhibited: il blocco di trasferimento messo dal registrar. Spesso è attivo di default e si toglie dal pannello. Il registrar non dovrebbe usarlo per impedire al titolare di cambiare, salvo valide ragioni.
• pendingUpdate: il dominio ha una modifica ai nameserver o ai record DS in corso di validazione. Secondo le linee guida, in questo stato dura fino a 5 giorni e il trasferimento non è ammesso.
• inactive/clientHold e serverHold, pendingDelete, redemptionPeriod: domini sospesi, in cancellazione o in fase di recupero: non si trasferiscono.
• pendingTransfer: c’è già un trasferimento in corso.
• Codice sbagliato: l’AuthInfo deve coincidere con quello nel database del Registro.

Un caso tipico: due giorni prima del trasferimento qualcuno cambia i nameserver, il dominio entra in pendingUpdate e la richiesta del nuovo registrar fallisce senza una spiegazione chiara. Non toccare DNS e DS nei giorni precedenti.

DNSSEC e cambio registrar

Nel .it c’è una particolarità importante: i record DS, che collegano la zona firmata al Registro, devono essere trasmessi al Registro dal registrar via EPP, anche quando i nameserver sono gestiti da altri. Il registrar deve inoltre essere accreditato DNSSEC. Tu da solo non puoi pubblicare un DS nel Registro.

Le linee guida dicono cosa succede al cambio: è responsabilità del nuovo registrar aggiornare, se serve, i nameserver e i record DS associati al dominio. Per te significa che:

• Verifica che il nuovo registrar supporti DNSSEC prima di iniziare. Se non lo supporta, non potrà gestire il DS.
• Non lasciare un DS orfano. Se la zona viene firmata da un nuovo provider DNS con chiavi diverse e il vecchio DS resta nel Registro, i resolver che validano rispondono SERVFAIL e il dominio sembra irraggiungibile, posta compresa. Il sintomo è descritto in Nota operativa: DNS SERVFAIL.
• Se cambi anche il provider DNS, l’ordine sicuro è: togliere il DS, aspettare che la cache scada (almeno il TTL del record DS), spostare la zona, firmarla di nuovo e solo allora pubblicare il nuovo DS. Una prassi generale, non una regola del Registro; le procedure di dettaglio dipendono dal registrar.
• Se invece la zona resta dove sta e cambia solo il registrar, chiedi che il DS venga mantenuto o ripubblicato invariato, e controlla dopo.

Controllo rapido con dig DS tuodominio.it +short: deve mostrare il DS che corrisponde alle chiavi attualmente pubblicate dalla tua zona (dig DNSKEY tuodominio.it +short).

DNS e posta: dove si rompe davvero

Il trasferimento del dominio non è il trasferimento del DNS. Sono due cose distinte, ma molti registrar le vendono insieme e il cambio può portarsi dietro i nameserver. Le trappole:

• Zona non copiata. Se il nuovo registrar imposta i suoi nameserver di default con una zona vuota, spariscono A, MX, SPF, DKIM e DMARC. Il sito può restare in cache per un po’, la posta in ingresso comincia a rimbalzare. Prima di toccare qualsiasi cosa, esporta tutta la zona. Il metodo, con TTL e verifiche, è in Migrazione DNS senza downtime.
• Nameserver cambiati senza volerlo. Dopo il trasferimento controlla quali nameserver sono delegati. Il Registro verifica la configurazione: ne servono almeno due autoritativi che rispondano correttamente.
• Record dimenticati. Sottodomini poco usati, record TXT di verifica, DKIM con selettori secondari, record per servizi terzi. Il consiglio è confrontare le due zone riga per riga.
• Autenticazione della posta. Se SPF o DKIM spariscono, i messaggi finiscono in spam o vengono rifiutati. Come controllarli è in SPF, DKIM e DMARC spiegati, e il controllo DNS della posta mostra MX, SPF, DKIM e DMARC in un passaggio.
• Contatti. Dopo il trasferimento, le linee guida prevedono che i contatti vengano copiati con nuovi identificativi. Verifica che i dati del titolare siano corretti e che le email di comunicazione del registrar arrivino a una casella che esiste ancora: se la posta del dominio è la sola casella di contatto e il dominio non risolve, non vedrai gli avvisi.
• Scadenza e rinnovo. Evita di trasferire a ridosso della scadenza. Dopo il cambio controlla la nuova scadenza e il rinnovo automatico: qui non faccio ipotesi, dipende dal contratto del registrar.

Checklist finale

• Il dominio non è scaduto, né sospeso, né in pendingUpdate.
• Esporta e conserva la zona DNS completa (anche in forma di screenshot, se il pannello non esporta).
• Abbassa i TTL dei record principali alcune ore prima, se cambierà il DNS.
• Verifica se DNSSEC è attivo (dig DS) e se il nuovo registrar lo supporta.
• Togli il blocco di trasferimento e richiedi l’AuthInfo al registrar attuale.
• Decidi in anticipo se i nameserver restano gli stessi e comunicalo al nuovo registrar.
• Avvia il trasferimento in un giorno e orario in cui puoi monitorare, evitando venerdì sera.
• Dopo: controlla i nameserver delegati, la risposta di A, MX, TXT, il DS, e invia e ricevi una mail di prova da e verso caselle esterne.
• Verifica nuova scadenza, contatti del titolare e nuovo AuthInfo.
• Tieni attivo il vecchio servizio DNS e di posta finché tutto è confermato.

Il principio è lo stesso di ogni migrazione: cambia una cosa alla volta, ma prima di cambiarla sappi dove si torna indietro. Il codice AuthInfo e un’esportazione della zona sono i due documenti che ti servono sempre.