Transferir un dominio entre registradores: elegibilidad y conservación de servicios

Delimitar el cambio entre seis funciones

Identifica el registro del TLD, los registradores actual y receptor, el titular, el operador DNS autoritativo, el alojamiento web y el proveedor de correo. Escribe qué debe permanecer y qué requiere otra decisión. Una empresa puede cumplir varias funciones sin que sus contratos, autoridad y evidencias de aceptación sean intercambiables.

La política gTLD publicada de ICANN asigna al titular registrado la autoridad para aprobar la transferencia. Cambiar derechos del titular o datos materiales de contacto es otro proceso. Antes de corregir un contacto, establece las consecuencias con el registrador responsable; no trates esa edición como requisito inocuo.[1]

Empezar con una ficha de transferencia en blanco

En cada fila anota fuente fechada/localizador ____, responsable ____, estado/bloqueo ____ y revisión siguiente ____. Usa referencias privadas autorizadas; no pongas códigos, contraseñas ni documentos de identidad innecesarios en la ficha compartida.

Si la autoridad o elegibilidad crítica es desconocida, el resultado es HOLD. Ni el margen de fechas ni un sitio aparentemente sano compensan esa falta. Mantén visible la evidencia pendiente; las filas de servicios favorables no autorizan transferir.

Fechar la política y clasificar las restricciones

El 14 de octubre, ICANN mostraba la actualización del 21 de febrero de 2024, obligatoria como máximo el 21 de agosto de 2025. El encabezado conserva el aplazamiento de la aplicación de la exigencia del formulario de autorización (FOA) al registrador receptor. La adopción de 47 recomendaciones por la Junta el 7 de junio de 2026 ordena implementarlas; Transfer Policy Review aparece en la cola de implementación. Adoptar no hace vigentes procedimientos de reemplazo propuestos. Revisa la versión aplicable antes de actuar.[1][2][3]

En la política gTLD publicada, los casos de registro inicial o transferencia reciente en I.A.3.7 permiten denegar; los supuestos legales, de controversia o cambio de titular de I.A.3.8 obligan a denegar. II.C trata el bloqueo por cambio material, la exclusión previa y las disposiciones acotadas de retiro, incluida la nota 7. Quitar un clientTransferProhibited ordinario no demuestra que desaparecieron todas las restricciones. No impongas una espera universal de 60 días ni prometas retirar cualquier bloqueo.[1]

Siguen siendo necesarias la autorización, las notificaciones y la evidencia de finalización específicas de los proveedores. Las disposiciones condicionales de cinco días naturales sobre asistencia y respuesta del registro son obligaciones concretas, no duración total garantizada. Solicitud o comprobante de pago no confirman el cambio. Esta guía no proporciona un guion universal de correos o códigos.[1]

Documentar por separado la conservación de servicios

Por dependencia: responsable y fuente actuales ____, conservar o migrar aparte ____, evidencia de aceptación y operador ____, decisión de espera o reversión ____. Son seis filas; la cuestión contractual importa tanto como los ajustes previstos.

La guía de Cloudflare del 24 de abril de 2026 exige su DNS autoritativo para su servicio de registrador. La página .nl de SIDN ilustra contratos y coordinación con un nuevo registrador que admita DNSSEC. Estos ejemplos acotados pueden reabrir el plan de conservación; no son requisitos universales. Un operador competente debe elegir la secuencia DNS/DS pertinente. No copies una receta de desactivar DNSSEC a toda transferencia.[4][5]

Paper Lantern Workshop: fechas antiguas no bastan

Los siete campos de entrega y seis filas de conservación son distintos de este resumen ficticio de seis filas. Los 37/29 días son margen de calendario, no pronóstico, duración de bloqueo ni SLA; los dos días no son plazo de política. Si B exigiera su DNS, fallaría el supuesto de mantenerlo y haría falta un plan DNS separado. No se atribuye esa aceptación ficticia a ningún proveedor.

Separar el derecho de la admisión del proveedor

La política gTLD publicada no convierte el vencimiento por sí solo en causa general de denegación; importan restricciones reales y condiciones de períodos impagados. Cloudflare exige aparte renovar el dominio vencido con el registrador actual como requisito. Un caso próximo al vencimiento o con estado cambiado necesita su decisión de estado/renovación y evidencia exacta antes de continuar. No se garantiza recuperación, transferencia gratuita ni año adicional incondicional.[1][4]

Exigir evidencia separada de cambio y servicios

Entrega la decisión acotada de elegibilidad, referencias privadas de autoridad, instrucciones fechadas, ficha de siete campos y registro de seis dependencias. La evidencia posterior autorizada debe distinguir solicitud aceptada, registrador cambiado y aceptación de cada servicio por su operador. Paper Lantern sigue en HOLD. Esta guía no ejecuta el cambio ni promete DNS, TLS, correo o enlaces ininterrumpidos.