Proceso de transferencia de dominio desde una perspectiva técnica: Instrucciones completas

Describo la Proceso de transferencia de dominio técnicamente, paso a paso, desde el desbloqueo hasta la confirmación final en el registro. Así se planifican el código de autenticación, los procesos del PPE y el Actualización de DNS limpia, para que el sitio web y el correo electrónico sigan siendo accesibles.

Puntos centrales

• Desbloquear y compruebe los datos del propietario
• Código Auth Solicitud a tiempo
• EPP-Iniciar la transferencia con el nuevo registrador
• Actualización de DNS Prepárese con antelación
• Normas de los TLD y respetar los plazos

Preparación: desbloquear el dominio y comprobar los datos

Empiezo por el bloqueo de la transferencia: desactivo el Bloqueo del registrador en el portal del cliente para que el cambio sea posible. A continuación, compruebo los datos de contacto de WHOIS, especialmente el Correo electrónico del titular para las confirmaciones. Si los datos no coinciden, el proceso suele detenerse durante un tiempo innecesariamente largo. También documento la configuración actual para poder hacer comparaciones fiables más adelante. Por último, preparo listas de comprobación para no olvidar ningún paso técnico.

Estrategia de DNS antes de la salida

Antes de los movimientos productivos, plan Actualización de DNS activo para evitar fallos. Configuro una zona DNS idéntica con el nuevo proveedor y pruebo los registros A, AAAA, MX y CNAME. Si utilizas servidores de nombres externos, puedes mantenerlos durante el cambio y reducir así considerablemente el riesgo. Compruebo los valores de tiempo de vida (TTL) y los reduzco de forma selectiva para que los cambios lleguen más rápido a todo el mundo. Esta guía me ayuda a evitar errores con más detalle: Evite errores durante la transferencia, que repaso una vez antes de la salida.

Solicitar Auth-Code (EPP) de forma segura

Sin Código Auth no se ejecuta ni una sola transferencia. Solicito el código al registrador anterior en mi cuenta o lo pido al servicio de asistencia. Muchos códigos siguen siendo válidos durante unos 30 días, por lo que los utilizo rápidamente. En el caso de .de, puedo solicitar un código alternativo (AuthInfo2) a través del operador responsable en caso de problemas. Guardo el código de forma encriptada y nunca lo comparto a través de redes no seguras. Correo electrónico.

Iniciar la transferencia con el nuevo registrador

Inicio el cambio real con el nuevo proveedor, entro en el dominio y escribo el Código Auth correctamente. En segundo plano, los sistemas se comunican a través de EPP, el protocolo basado en XML para registros. El nuevo registrador envía la solicitud, el registro la comprueba e informa al antiguo proveedor. En el caso de los gTLD, suele haber un breve periodo de objeción, tras el cual el registro transfiere el dominio. Si desea leer el proceso completo de forma compacta, eche un vistazo a esta guía: Cambiar de registrador: Instrucciones, que me gusta utilizar como referencia rápida.

Proceso técnico en el registro

Para ayudarle a comprender el camino, resumiré los pasos técnicos en términos claros y expondré las Puntos focales sobre EPP y confirmaciones. En primer lugar, el nuevo registrador envía al registro la solicitud de transferencia con el dominio y el código de autenticación. A continuación se realizan comprobaciones de estado: Titularidad, bloqueo, plazos y posibles objeciones. El antiguo registrador puede estar de acuerdo o guardar silencio; la falta de respuesta una vez transcurrido el plazo suele significar la aprobación. Tras la aprobación, el registro asigna el dominio al nuevo registrador y actualiza los contactos, servidores de nombres y Estado.

Utilizar los códigos de estado del PPE de forma selectiva

He leído lo siguiente para las perchas Códigos de estado del PPE con coherencia porque indican claramente dónde hay un problema y qué medidas son necesarias:

• okTodo listo, ningún bloqueo activo. La transferencia puede comenzar.
• clientTransferProhibitedBloqueo del registrador activo. Cancelo el bloqueo de la cuenta.
• serverTransferProhibitedRegistro o bloqueo de política (por ejemplo, procedimiento/UDRP). Aclararé el motivo con Soporte.
• pendingTransferLa transferencia está en curso. Esperaré a la fecha límite o comprobaré los correos electrónicos de confirmación.
• redemptionPeriod / pendingDeleteDominio en ciclo de borrado. Las transferencias están bloqueadas; primero es posible la recuperación y luego la transferencia.
• clientUpdateProhibitedActualizaciones bloqueadas. Elimino bloqueos adicionales (bloqueo del registro) antes de realizar cambios.

Soy consciente de que los gTLD, además del Código Auth cada vez más del término TAC (Código de Autorización de Transferencia) - el principio sigue siendo el mismo: un token sensible y limitado en el tiempo que legitima la transferencia.

Bloqueos, normas de 60 días y rechazos admisibles

Planifico un margen de tiempo para las políticas que a menudo se pasan por alto. Tras el registro o la transferencia correcta, muchos registradores establecen un 60 días de bloqueo, durante el cual suelen rechazarse nuevas transferencias. Un cambio de registrante también puede desencadenar un periodo de bloqueo para los gTLD, a menos que se haya establecido previamente una exclusión voluntaria. Entre los motivos NACK admisibles del antiguo registrador figuran: bloqueos activos, falta de pago, conflictos de identidad o procedimientos judiciales. Si no se aplica ninguna de estas razones, no debería retrasarse una transferencia sin motivo. Por lo tanto, compruebe de antemano: ¿Pagado? ¿Desbloqueado? ¿Los contactos son correctos? Así evito bucles innecesarios.

Actualización de DNS sin fallos

Mantengo el sitio accesible volteando la zona DNS de forma controlada antes de ponerlo en marcha y cambiando el TTL inferior. Durante la distribución global (propagación), puede haber breves diferencias de resolución. Pruebo el objetivo desde varias redes y compruebo los registros A y MX con herramientas como dig o nslookup. Si es necesario, configuro temporalmente ambas infraestructuras en paralelo hasta que se hayan convertido todas las cachés. Si también quieres conocer detalles sobre las ventanas de tiempo, utiliza mi nota a continuación sobre el Duración.

Migración limpia de DNSSEC

Con DNSSEC Tengo en cuenta la entrada DS en el registro. Si cambia el servidor de nombres y, por tanto, la clave, tengo dos estrategias seguras:

• Conversión con un hueco: Elimino el DS del registro poco antes del cambio, espero a una actualización global (un TTL bajo ayuda), cambio a los nuevos servidores de nombres y luego configuro el nuevo DS. Esto evita SERVFAILs debidos a firmas incorrectas.
• Vuelco sin fisuras: Almaceno la nueva DNSKEY en paralelo (KSK rollover), la hago firmar y luego actualizo el DS. Sólo entonces elimino la clave antigua. Esto reduce los riesgos de validación con resolvers estrictamente validadores.

Registro de asistencia y proveedor CDS/CDNSKEY, la actualización del DS puede automatizarse parcialmente. Sin automatización, controlo la secuencia manualmente y registro los tiempos para poder volver a comprobarlos rápidamente en caso de fallos.

Servidores de nombres infantiles y registros de cola

Si el dominio utiliza sus propios servidores de nombres (p. ej. ns1.midominio.tld), existe Objetos de acogida/registros adhesivos en el registro. Aquí planifico por separado:

• Antes de la transferencia, añado IP adicionales de la nueva infraestructura a los objetos del host (pila dual, proveedor dual) para que la resolución funcione de forma fiable durante la fase de transición.
• Tras la transferencia, vuelvo a eliminar las IP antiguas en cuanto todas las cachés apuntan con seguridad a la nueva ruta.
• Compruebo si el nuevo registrador admite directamente la administración de los objetos de host; si no es así, coordino estrechamente el cambio con ambos soportes.

Esto evita que los dominios de mis servidores de nombres hijo se vuelvan irresolubles inesperadamente como resultado de la transferencia.

Especificaciones y plazos de los TLD

Dependiendo del final, los plazos y las aprobaciones cambian, así que miro con lupa los TLD. Los gTLD como .com o .net suelen utilizar un periodo de objeción de unos días antes de que el cambio entre en vigor. .de se mueve casi en tiempo real una vez que el código válido está disponible. Las extensiones de código de país (ccTLD) se comportan de forma diferente y siguen sus propias normas. El siguiente resumen clasifica los puntos más importantes y ayuda a la Planificación.

TLD	Proceso de transferencia	Características especiales	Código/confirmación	Comportamiento del servidor de nombres
.com / .net / .org	Solicitud a través del PPE, breve fase de oposición	La página antigua sigue siendo accesible con DNS-Preparación	Auth code obligatorio, el propietario recibe correos	Configurar una nueva zona de antemano o mantener servidores de nombres externos
...de...	Transferencia en tiempo real tras la introducción del código	Código alternativo opcional (AuthInfo2) posible	Auth code obligatorio, confirmación a menudo directamente en el proceso	La zona antigua puede ser cancelada, por lo tanto prepare la zona con el nuevo proveedor
ccTLD (varios)	Muy diferente, dependiente del registro	Pruebas o plazos parcialmente adicionales	A veces código, a veces otras versiones	Compruebe de antemano si quedan servidores de nombres externos

Liquidación, plazos y fases de vencimiento

Pierdo el Lógica de ampliación no fuera de la vista: Para muchos gTLD, una transferencia satisfactoria amplía el plazo en un año (hasta el límite máximo). Algunos ccTLD -incluido .de- no disponen de esta ampliación automática durante la transferencia. Si un dominio está a punto de expirar, puedo evitar sorpresas desagradables:

• No inicio las transferencias en el último momento. Si el dominio cae en el Grace- o Fase de rescate, Las transferencias suelen estar bloqueadas o sólo son posibles tras la recuperación.
• La renovación automática con el antiguo registrador puede dar lugar a facturas provisionales; tras una transferencia satisfactoria, éstas suelen anularse en el caso de los gTLD. Documento claramente las fechas.
• Tras el cambio, activo lo siguiente con el nuevo registrador Renovación automática de nuevo para que no queden huecos.

Programación y calendario TTL

Para los proyectos críticos, reservo una pequeña Plan Runbook Bien:

• T-7 a T-3 días: Duplique la zona, configure la supervisión (HTTP, MX, DNS). Reducir los TTL de los registros relevantes a 300-600 segundos.
• T-2 días: Comprobar Auth-Code, eliminar bloqueos, revalidar contactos.
• Día T-1: Ejecutar la última sincronización de zonas, aplicar el plan DNSSEC (eliminar DS o rollover).
• T (fuera de las horas punta): Inicie la transferencia, supervise los registros y el estado en ambos portales.
• T a T+1: Tras el éxito de la adquisición, repetir las pruebas, finalizar los DS/registros, desmantelar la antigua infraestructura de forma ordenada.
• T+2: Aumentar gradualmente los TTL, finalizar la documentación.

Evitar los escollos habituales

Evito los datos WHOIS obsoletos, porque los correos mal dirigidos son innecesariamente costosos. Tiempo. Un bloqueo de transferencia activo bloquea cada inicio, así que lo compruebo primero. Los valores TTL demasiado altos provocan una propagación larga, por lo que los reduzco de antemano. Diferentes niveles de zona con el antiguo y el nuevo proveedor provocan una resolución incoherente. Por eso compruebo meticulosamente los registros antes del inicio y documento cada uno de ellos. Enmienda.

Planificar el traslado del correo y el alojamiento por separado

La transferencia sólo afecta al registro, no a los archivos ni a los buzones de correo, y siempre lo tengo en cuenta. borrar. Migro el contenido web mediante SFTP o restauración de copias de seguridad y lo pruebo antes de ponerlo en marcha. Traslado los buzones mediante sincronización IMAP o exportación/importación para que no falte ningún mensaje. Transfiero SPF, DKIM y DMARC limpiamente a la nueva zona. Sólo cuando todo está en su sitio vuelvo a aumentar el TTL y hago una copia de seguridad del Estabilidad.

Reparto del correo y funcionamiento en paralelo

Pienso en particular en Correo electrónico-Flujos. Durante el cambio, los correos entrantes pueden terminar a veces en el antiguo MX y a veces en el nuevo MX, dependiendo del resolver. Así es como reacciono ante esto:

• Para grandes volúmenes, planifico una breve fase de congelación para los cambios de estructura de los buzones, de modo que no se pierdan turnos.
• Si es necesario, utilizo Doble entrega (temporalmente dos objetivos MX) o un relé central que sirva a ambos extremos posteriores, bien dosificados y controlados.
• Tras la transferencia, vuelvo a verificar SPF, DKIM y DMARC y compruebo la evaluación de los destinatarios mediante informes DMARC.

Comprobaciones de seguridad tras el cambio

Tras la migración correcta, activo el Prohibición de traslados otra vez. Configuro la autenticación de 2 factores en la cuenta del cliente y aseguro el historial de códigos de autenticación. Compruebo de nuevo los detalles de WHOIS para que la visibilidad y la protección de datos sean correctas. Rectifico inmediatamente los errores en DNSSEC, SPF o DKIM, porque los correos electrónicos sufren mucho en este caso. Por último, documento todos los pasos y guardo Copias de seguridad listo.

Revisión: Supervisión, renovación automática, auditoría

Compruebo el Renovación automática-y, si está disponible, establecer notificaciones antes de la expiración. Llevo a cabo una supervisión activa durante 24-48 horas del sitio web, los puntos finales de la API, MX, las comprobaciones SPF/DKIM y DNSSEC para detectar casos extremos en las cachés. Para las auditorías, archivo las capturas de pantalla, los archivos de exportación, los estados de zona y los eventos EPP (p. ej. pendingTransfer → ok) para que las investigaciones posteriores puedan documentarse claramente.

Privacidad, RDAP y canales de contacto

Con una Privacidad/Proxy Me aseguro de que los correos electrónicos de confirmación me lleguen (el reenvío funciona, el sistema de tickets no se filtra). Algunos registradores utilizan ahora canales de contacto basados en RDAP en lugar de WHOIS. Mantengo la coherencia de los correos electrónicos registrados y evito los cambios espontáneos de contacto poco antes de la transferencia para que no surta efecto el bloqueo de validación.

Dominios internacionalizados (IDN)

En IDNs Compruebo la ortografía y Punycode sistemáticamente en todos los sistemas. Compruebo los certificados (entradas SAN), las redirecciones y las aplicaciones que sólo aceptan etiquetas ASCII. Una transferencia no cambia nada, pero los errores tienden a aparecer durante la reorganización paralela del DNS.

Traslado y organización de pilas

Si transfiero varios dominios, los agrupo en Transferencias de pila con procedimientos idénticos: estrategia TTL estandarizada, tabla central de códigos de autenticación y plazos, vías de escalado claras. Doy prioridad a las zonas críticas (por ejemplo, proveedor SSO, MX) y garantizo una mayor supervisión. Esto me permite mantener una visión de conjunto y reducir los cambios de contexto en el equipo.

Solución de problemas: Cuando la transferencia se cuelga

Si el proceso se atasca, elaboro una clara Lista de. Compruebo el bloqueo, la validez del código, los correos del propietario y las entradas del servidor de nombres. A continuación, solicito los registros de estado al nuevo registrador y pido al antiguo proveedor que envíe sus comentarios al registro. En el caso de .de, solicito un nuevo código y reinicio el proceso. En caso de duda, hago una pausa en las conmutaciones productivas hasta que el DNS sea coherente y sin problemas está corriendo.

Brevemente resumido

Sostengo el Proceso de transferencia de dominio apretado: primero desbloqueo y compruebo los datos, luego guardo el código de autenticación y después inicio la transferencia EPP. Al mismo tiempo, configuro la zona DNS con el nuevo proveedor y reduzco el TTL. Durante los plazos, controlo los mensajes de estado y pruebo la resolución y el correo. Tras la transferencia, activo el bloque de transferencia, establezco comprobaciones de seguridad y vuelvo a aumentar el TTL. Si sigues esta secuencia, podrás trasladar dominios de forma controlada y mantenerlos a salvo. Accesibilidad.