Processo di trasferimento del dominio dal punto di vista tecnico: Istruzioni complete

Descrivo il Processo di trasferimento del dominio tecnicamente, passo dopo passo, dallo sblocco alla conferma finale nel registro. È così che si pianificano il codice di autenticazione, i processi EPP e il Aggiornamento DNS puliti, in modo che il sito web e la posta elettronica rimangano accessibili.

Punti centrali

• Sbloccare e controllare i dati del proprietario
• Codice di autorizzazione Richiesta in tempo utile
• PPE-Avviare il trasferimento con la nuova società di registrazione
• Aggiornamento DNS Preparare in anticipo
• Regole dei domini di primo livello e rispettare le scadenze

Preparazione: sbloccare il dominio e controllare i dati

Inizio con il blocco del trasferimento: disattivo l'opzione Blocco del registrar nel portale clienti in modo che la modifica sia possibile. Poi verifico i dati di contatto WHOIS, in particolare i dati di E-mail del titolare per le conferme. Se i dettagli non corrispondono, il processo si ferma spesso per un tempo inutilmente lungo. Documento anche la configurazione attuale, in modo da poter fare confronti affidabili in seguito. Infine, preparo delle liste di controllo per non dimenticare nessun passaggio tecnico.

Strategia DNS prima della partenza

Prima di effettuare spostamenti produttivi, pianifico il Aggiornamento DNS attivo per evitare guasti. Ho impostato una zona DNS identica con il nuovo provider e ho testato i record A, AAAA, MX e CNAME. Se si utilizzano server di nomi esterni, è possibile mantenerli durante il cambiamento, riducendo così notevolmente il rischio. Controllo i valori di time-to-live (TTL) e li abbasso in modo mirato, in modo che le modifiche arrivino più velocemente in tutto il mondo. Questa guida mi aiuta a evitare gli errori in modo più dettagliato: Evitare errori durante il trasferimento, che ho esaminato una volta prima dell'inizio.

Richiesta del codice di autorizzazione (PPE) in modo sicuro

Senza Codice di autorizzazione Non c'è un solo trasferimento in corso. Richiedo il codice al precedente registrar nel mio account o lo chiedo all'assistenza. Molti codici rimangono validi per circa 30 giorni, quindi li utilizzo prontamente. Per il dominio .de, in caso di problemi posso richiedere un codice alternativo (AuthInfo2) all'operatore responsabile. Conservo il codice in forma criptata e non lo condivido mai tramite un sistema non sicuro. E-mail.

Avviare il trasferimento con la nuova società di registrazione

Avvio la modifica vera e propria con il nuovo provider, inserisco il dominio e digito l'indirizzo Codice di autorizzazione correttamente. In background, i sistemi comunicano tramite EPP, il protocollo basato su XML per i registri. Il nuovo registrar invia la richiesta, il registro controlla e informa il vecchio provider. Nel caso dei gTLD, spesso è previsto un breve periodo di obiezione, al termine del quale il registro trasferisce il dominio. Se volete leggere la procedura completa in forma compatta, consultate questa guida: Cambiare la società di registrazione: Istruzioni, che mi piace usare come riferimento rapido.

Processo tecnico nel registro

Per aiutarvi a comprendere il percorso, vi riassumerò i passaggi tecnici in termini chiari ed esporrò il Punti focali su EPP e conferme. In primo luogo, il nuovo registrar invia al registro la richiesta di trasferimento con il dominio e il codice di autorizzazione. Vengono quindi eseguiti i controlli di stato: Proprietà, blocco, scadenze ed eventuali obiezioni. Il vecchio registrar può accettare o rimanere in silenzio; la mancanza di risposta dopo la scadenza di solito significa approvazione. Dopo l'approvazione, il registro assegna il dominio alla nuova società di registrazione e aggiorna i contatti, i server dei nomi e i dati del dominio. Stato.

Utilizzare i codici di stato PPE in modo mirato

Ho letto quanto segue per le grucce Codici di stato PPE perché indicano chiaramente dove c'è un problema e quali azioni sono necessarie:

• okTutto pronto, nessun blocco attivo. Il trasferimento può iniziare.
• clientTransferProhibitedBlocco del registrar attivo. Annullo il blocco dell'account.
• serverTransferProhibitedBlocco del registro o del criterio (ad es. procedura/UDRP). Chiarirò il motivo con l'assistenza.
• in attesa di trasferimentoIl trasferimento è in corso. Attenderò la scadenza o controllerò le e-mail di conferma.
• redemptionPeriod / pendingDeleteDominio in ciclo di cancellazione. I trasferimenti sono bloccati; prima è possibile il recupero, poi il trasferimento.
• clientUpdateProhibitedAggiornamenti bloccati. Rimuovo i blocchi aggiuntivi (blocco del registro) prima di apportare modifiche.

Sono consapevole che i domini di primo livello geografici, oltre alla Codice di autorizzazione sempre più dal termine TAC (Transfer Authorisation Code) - il principio rimane lo stesso: un token sensibile e limitato nel tempo che legittima il trasferimento.

Chiusure, regole dei 60 giorni e rifiuti ammissibili

Pianifico un buffer di tempo per le politiche che spesso vengono trascurate. Dopo la registrazione o il trasferimento con successo, molte società di registrazione impostano un tempo di Blocco di 60 giorni, durante il quale di solito vengono rifiutati ulteriori trasferimenti. Anche un cambio di registrante può far scattare un periodo di blocco per i gTLD, a meno che non sia stato stabilito in anticipo un opt-out. I motivi di NACK ammessi dal vecchio registrar sono: blocchi attivi, mancanza di pagamento, conflitti di identità o procedimenti legali. Se nessuno di questi motivi è applicabile, il trasferimento non dovrebbe essere ritardato per nessun motivo. Pertanto, verifico in anticipo: pagato? Sbloccato? I contatti sono corretti? In questo modo evito inutili loop.

Aggiornamento DNS senza errori

Mantengo il sito accessibile effettuando il mirroring della zona DNS in modo controllato prima di avviarlo e TTL inferiore. Durante la distribuzione globale (propagazione), possono verificarsi brevi differenze di risoluzione. Verifico l'obiettivo da diverse reti e controllo i record A e MX con strumenti come dig o nslookup. Se necessario, configuro temporaneamente le due infrastrutture in parallelo fino a quando tutte le cache non sono state convertite. Se volete conoscere anche i dettagli sulle finestre temporali, utilizzate la mia nota qui sotto sul sito Durata.

Migrare il DNSSEC in modo pulito

Con DNSSEC Tengo conto della voce DS nel registro. Se il server dei nomi e quindi la chiave cambiano, ho due strategie sicure:

• Conversione con uno scarto: Rimuovo il DS dal registro poco prima del passaggio, attendo un aggiornamento globale (un TTL basso aiuta), passo ai nuovi server dei nomi e poi imposto il nuovo DS. In questo modo si evitano i SERVFAIL dovuti a firme errate.
• Ribaltamento senza soluzione di continuità: Memorizzo la nuova DNSKEY in parallelo (KSK rollover), la faccio firmare e poi aggiorno il DS. Solo allora rimuovo la vecchia chiave. In questo modo si riducono i rischi di convalida con i resolver che convalidano rigorosamente.

Registro di supporto e fornitore CDS/CDNSKEY, l'aggiornamento del DS può essere parzialmente automatizzato. Senza automazione, controllo la sequenza manualmente e registro i tempi in modo da poterli controllare rapidamente in caso di guasti.

Server dei nomi dei bambini e record di colla

Se il dominio utilizza i propri server dei nomi (ad es. ns1.mydomain.tld), esistono Oggetti ospitanti/registri di colla nel registro. Sto pianificando separatamente:

• Prima del trasferimento, aggiungo ulteriori IP dalla nuova infrastruttura agli oggetti host (dual stack, dual provider) in modo che la risoluzione funzioni in modo affidabile durante la fase di transizione.
• Dopo il trasferimento, rimuovo nuovamente i vecchi IP non appena tutte le cache puntano con sicurezza al nuovo percorso.
• Verifico se la nuova società di registrazione supporta direttamente l'amministrazione degli oggetti host; in caso contrario, coordino la modifica con entrambi i supporti.

In questo modo si evita che i domini sui miei server dei nomi figlio diventino inaspettatamente irrisolvibili a seguito del trasferimento.

Specifiche e scadenze dei TLD

A seconda del finale, le scadenze e le approvazioni cambiano, quindi osservo con attenzione il TLD. I domini di primo livello .gTLD come .com o .net di solito prevedono un periodo di obiezione di alcuni giorni prima che la modifica diventi effettiva. Il dominio .de si muove quasi in tempo reale una volta che il codice valido è disponibile. Le estensioni con codice paese (ccTLD) si comportano in modo diverso e seguono regole proprie. La seguente panoramica classifica i punti più importanti e aiuta a capire come funziona il sistema. Pianificazione.

TLD	Processo di trasferimento	Caratteristiche speciali	Codice/conferma	Comportamento del server dei nomi
.com / .net / .org	Richiesta tramite PPE, breve fase di obiezione	La vecchia pagina rimane accessibile con la corretta DNS-Preparazione	Codice di autorizzazione obbligatorio, il proprietario riceve la posta	Impostare una nuova zona in anticipo o mantenere server dei nomi esterni
.de	Trasferimento in tempo reale dopo l'inserimento del codice	Possibile codice alternativo opzionale (AuthInfo2)	Codice di autorizzazione obbligatorio, conferma spesso direttamente nel processo	La vecchia zona può essere cancellata, quindi preparare la zona con il nuovo provider.
ccTLD (vari)	Molto diverso, dipendente dal registro	Prove o scadenze parzialmente aggiuntive	A volte codice, a volte altre release	Verificare preventivamente se i server dei nomi esterni rimangono

Fasi di regolamento, termini e scadenza

Perdo il Logica di estensione non è in vista: Per molti gTLD, un trasferimento riuscito estende la durata di un anno (fino al limite massimo). Alcuni ccTLD, tra cui .de, non prevedono questa estensione automatica durante il trasferimento. Se un dominio sta per scadere, posso evitare brutte sorprese:

• Non inizio i trasferimenti all'ultimo minuto. Se il dominio rientra nel Grazia- o Fase di riscatto, I trasferimenti sono spesso bloccati o possibili solo dopo il recupero.
• Il rinnovo automatico con la vecchia società di registrazione può portare a fatture intermedie; dopo un trasferimento riuscito, queste vengono spesso stornate per i gTLD. Documento chiaramente le date.
• Dopo la modifica, ho attivato quanto segue con la nuova società di registrazione Rinnovo automatico in modo che non ci siano spazi vuoti.

Programmazione e orario TTL

Per i progetti critici, metto da parte un piccolo Piano del Runbook destra:

• Da T-7 a T-3 giorni: Specchiare la zona, impostare il monitoraggio (HTTP, MX, DNS). Ridurre il TTL dei record rilevanti a 300-600 secondi.
• T-2 giorni: Controllare il codice di autorizzazione, rimuovere i blocchi, riconvalidare i contatti.
• Giorno T-1: Eseguire l'ultima sincronizzazione della zona, implementare il piano DNSSEC (rimozione di DS o rollover).
• T (al di fuori delle ore di punta): Avviare il trasferimento, monitorare i registri e lo stato in entrambi i portali.
• Da T a T+1: Dopo il successo dell'acquisizione, ripetere i test, finalizzare DS/registri, smantellare la vecchia infrastruttura in modo ordinato.
• T+2: Aumentare gradualmente i TTL, finalizzare la documentazione.

Evitare gli ostacoli più comuni

Evito i dati WHOIS non aggiornati, perché le e-mail errate sono inutilmente costose. Tempo. Un blocco del trasferimento attivo blocca ogni avvio, quindi lo controllo prima. I valori TTL troppo alti causano una propagazione lunga, quindi li abbasso in anticipo. Livelli di zona diversi con il vecchio e il nuovo provider portano a risoluzioni incoerenti. Per questo motivo controllo meticolosamente i record prima dell'avvio e documento ogni singolo record. Emendamento.

Pianificate separatamente il trasferimento della posta e dell'hosting

Il trasferimento riguarda solo il registro, non i file o le caselle di posta elettronica, e lo tengo sempre presente. chiaro. Migro il contenuto web tramite SFTP o ripristino del backup e lo collaudo prima di andare in onda. Trasferisco le caselle di posta elettronica utilizzando la sincronizzazione IMAP o l'esportazione/importazione in modo da non perdere alcun messaggio. Trasferisco SPF, DKIM e DMARC in modo pulito nella nuova zona. Solo quando tutto è a posto, aumento nuovamente il TTL ed eseguo il backup della zona. Stabilità.

Consegna della posta e funzionamento in parallelo

Penso in particolare a E-mail-Flussi. Durante la transizione, la posta in arrivo può finire a volte sul vecchio MX e a volte sul nuovo MX, a seconda del resolver. Ecco come reagisco:

• Per i volumi elevati, prevedo una breve fase di congelamento per le modifiche alla struttura della cassetta postale, in modo da non perdere i turni.
• Se necessario, utilizzo Consegna doppia (temporaneamente due obiettivi MX) o un relè centrale che serve entrambe le estremità posteriori, ben dosate e controllate.
• Dopo il trasferimento, verifico nuovamente SPF, DKIM e DMARC e controllo la valutazione dei destinatari utilizzando i rapporti DMARC.

Controlli di sicurezza dopo la modifica

Dopo l'avvenuta migrazione, attivo l'opzione Divieto di trasferimento di nuovo. Configuro l'autenticazione a due fattori nell'account del cliente e proteggo la cronologia dei codici di autenticazione. Ricontrollo i dettagli WHOIS per garantire la visibilità e la protezione dei dati. Correggo immediatamente gli errori di DNSSEC, SPF o DKIM, perché in questo caso le e-mail soffrono molto. Infine, documento tutti i passaggi e conservo Backup pronto.

Rielaborazione: Monitoraggio, rinnovo automatico, audit

Controllo il Rinnovo automatico-e, se disponibile, impostare le notifiche prima della scadenza. Eseguo un monitoraggio attivo di 24-48 ore per il sito web, gli endpoint API, i controlli MX, SPF/DKIM e DNSSEC per individuare i casi limite nelle cache. Per le verifiche, archivio schermate, file di esportazione, stati delle zone ed eventi EPP (ad es. in attesa di trasferimento → ok) in modo che le indagini successive possano essere chiaramente documentate.

Privacy, RDAP e canali di contatto

Con la funzione attiva Privacy/Proxy Mi assicuro che le e-mail di conferma mi raggiungano (l'inoltro funziona, il sistema di ticket non filtra). Alcune società di registrazione ora utilizzano canali di contatto basati su RDAP anziché su WHOIS. Mantengo coerenti le e-mail registrate ed evito di cambiare spontaneamente i contatti poco prima del trasferimento, in modo da non bloccare la convalida.

Domini internazionalizzati (IDN)

All'indirizzo IDN Controllo l'ortografia e Punycode in modo coerente in tutti i sistemi. Controllo i certificati (voci SAN), i reindirizzamenti e le applicazioni che possono accettare solo etichette ASCII. Un trasferimento non cambia nulla, ma gli errori tendono a insinuarsi durante la riorganizzazione parallela del DNS.

Trasferimenti e organizzazione delle pile

Se trasferisco diversi domini, li raggruppo in Trasferimenti in pila con procedure identiche: strategia TTL standardizzata, tabella centrale per i codici di autorizzazione e le scadenze, percorsi di escalation chiari. Do priorità alle zone critiche (ad esempio, provider SSO, MX) e garantisco un maggiore monitoraggio. Questo mi permette di mantenere una visione d'insieme e di ridurre i cambiamenti di contesto nel team.

Risoluzione dei problemi: quando il trasferimento si blocca

Se il processo si blocca, elaboro una chiara Elenco da. Verifico il blocco, la validità del codice, le e-mail del proprietario e le voci del server dei nomi. Richiedo quindi i log di stato alla nuova società di registrazione e chiedo al vecchio provider di inviare un feedback al registro. Nel caso di .de, richiedo un nuovo codice e riavvio il processo. In caso di dubbio, metto in pausa le commutazioni produttive fino a quando il DNS non è coerente e non si è verificato un errore. senza problemi sta correndo.

Riassumendo brevemente

Tengo il Processo di trasferimento del dominio stretto: prima sblocco e controllo i dati, poi salvo il codice di autenticazione, quindi avvio il trasferimento EPP. Allo stesso tempo, configuro la zona DNS con il nuovo provider e abbasso il TTL. Durante le scadenze, monitoro i messaggi di stato e verifico la risoluzione e la posta. Dopo il trasferimento, attivo il blocco del trasferimento, imposto i controlli di sicurezza e aumento nuovamente il TTL. Se vi attenete a questa sequenza, potete spostare i domini in modo controllato e mantenerli al sicuro. Accessibilità.