Resumen

  • En RFC 5731, clientTransferProhibited y serverTransferProhibited tienen un efecto preciso: el servidor debe rechazar las solicitudes para transferir el objeto de dominio.
  • El prefijo indica qué lado controla el estado, no la política que lo motivó, la autoridad humana, el plazo de revisión ni la protección del proceso capaz de retirarlo.
  • Para justificar una denegación hacen falta un recibo técnico fechado y un recibo decisorio separado; los controles de cuenta, actualización, borrado, renovación y DNS requieren pruebas propias.

El dato verdadero que se vuelve una conclusión falsa

El estado de transferencia no es decoración. RFC 5731 utiliza una obligación inequívoca: si está presente una de las dos prohibiciones, la petición de transferir el dominio debe ser rechazada. Un observador que lee el estado ha adquirido evidencia útil sobre el comportamiento actual del servidor frente a una acción concreta.

El problema aparece cuando ese dato recibe una historia sin fuente. «El titular lo protegió», «hay una investigación», «el registro detectó fraude» o «el dominio está seguro» pueden ser explicaciones posibles, pero no están codificadas en clientTransferProhibited ni en serverTransferProhibited.

La especificación permite añadir texto legible para describir la razón de un estado. No lo exige. Un objeto EPP conforme puede carecer de número de expediente, instrucción del titular, fecha de caducidad o constancia de una revisión. Esa ausencia no debilita la orden de rechazo. Demuestra que la explicación vive fuera del campo.

Es una separación sensata. El protocolo conserva un significado interoperable y comprobable. Las instituciones pueden aplicar políticas diferentes sin fingir que una palabra técnica lleva dentro toda la documentación jurídica, comercial y humana.

Los prefijos ubican al operador, no al motivo

Los estados con prefijo client pertenecen al cliente patrocinador, normalmente el registrador. Los que empiezan por server pertenecen al servidor EPP, normalmente el registro. RFC 5731 impide al cliente modificar un estado impuesto por el servidor y permite al servidor modificar o sustituir uno del cliente según su política local.

La diferencia es importante, pero no basta para atribuir una decisión. Un registrador puede bloquear automáticamente un nombre nuevo, actuar por petición del titular, proyectar una restricción temporal de política o contener un problema de cuenta. Un registro puede imponer la prohibición durante una controversia, un periodo de redención, un servicio solicitado por el titular u otra condición local. El prefijo responde dónde se ejerce el control; no responde qué expediente lo activó.

ICANN explica a los titulares que los códigos cliente son fijados por el registrador y los códigos servidor por el registro. Para retirar el primero se acude al registrador. Para retirar el segundo, el registrador puede tener que coordinarse con el registro, por lo que el proceso puede tardar más. Es una ruta de actuación, no una prueba causal.

La política contiene verbos que el estado omite

En el ámbito al que se aplica, la Política de Transferencia de ICANN define autoridad y procedimiento. Separa la autorización del titular, el envío de la orden por el registrador receptor, las obligaciones del registrador actual y los motivos permitidos para denegar. También exige comunicar la razón en los casos previstos.

Esos motivos tienen naturalezas distintas. Evidencia de fraude no equivale a una disputa razonable sobre la identidad del titular. Ciertos impagos no equivalen a una objeción expresa. Una orden judicial, un procedimiento de controversia, los primeros sesenta días tras un registro o transferencia y el bloqueo posterior a un cambio de titular obedecen a reglas y plazos diferentes.

La misma política muestra por qué «Registrar Lock» no puede usarse como explicación autosuficiente. El mero estado no permite denegar si el titular no ha recibido una oportunidad y un medio razonables para desbloquear antes de la solicitud. Cuando existe una objeción general expresa, importan el consentimiento informado y la ruta accesible para retirar el bloqueo.

El estado técnico y la decisión institucional son, por tanto, pruebas complementarias. El primero debe conservar el dominio, el valor exacto, la fuente, la hora y el estado que lo reemplazó. El segundo debe conservar la norma o contrato aplicable, quién pidió o impuso la restricción, qué autorización existía, cuándo empezó, cuándo se revisa o expira, cómo se notificó y quién puede levantarla.

Una insignia, tres tiempos

El servidor, la política y el observador llevan relojes distintos. El servidor conoce cuándo entró el estado en la base EPP autorizada. El expediente de política conoce cuándo nació la causa y cuándo debe revisarse. RDAP, Whois, el portal o el proveedor de monitorización conocen únicamente cuándo recuperaron y mostraron una vista.

Una respuesta pública puede estar almacenada en caché. El portal puede conservar un texto amable después de un cambio interno. El motivo puede caducar antes de que se quite su proyección técnica, o la proyección puede cambiar antes de que un agregador se actualice. Una captura de pantalla no demuestra más que la presentación de una interfaz en un instante.

RFC 5731 ofrece una prueba de coherencia que conviene automatizar: pendingTransfer no puede combinarse con ninguna prohibición de transferencia. La primera etiqueta dice que una acción de transferencia fue procesada y sigue pendiente; la segunda obliga a rechazar la solicitud. Si ambas aparecen juntas, hay que reconstruir fechas, cachés, fuentes mezcladas o fallos de presentación antes de acusar a un servidor o declarar un ataque.

Un bloqueo de transferencia no bloquea todos los cambios

El sustantivo «bloqueo» parece absoluto; EPP distingue cada verbo. Hay estados separados para impedir transferencia, actualización, borrado y renovación. Los estados hold afectan a la publicación de la delegación DNS. Un dominio puede no ser transferible y, sin embargo, quedar expuesto a cambios de cuenta o a la retirada del bloqueo por una credencial comprometida.

También puede ocurrir lo contrario: un producto comercial de registry lock puede exigir comprobación fuera de banda, aprobación dual, una credencial independiente o un retraso obligatorio. Son controles reales cuando el contrato y la operación los prueban. El token serverTransferProhibited no los garantiza solo por tener un nombre parecido.

La orientación de ICANN para registrantes describe el bloqueo de transferencia como una capa útil, no infalible. Recomienda además proteger la cuenta y considerar autenticación en varios pasos. Por eso una evaluación seria registra por separado acceso, privilegios, authInfo, estados de actualización y borrado, DNS, renovación y recuperación. Ninguna marca verde hereda la prueba de las demás.

El nombre de Hollenbeck también necesita límites

Scott Hollenbeck figura como autor de RFC 5730 y RFC 5731. Su perfil público en el IETF señala que participa desde mediados de la década de 1990, que presidió varios grupos de trabajo y que fue director del Área de Aplicaciones entre 2004 y 2006. La instantánea actual le atribuye 39 RFC.

Esa trayectoria sitúa una contribución técnica notable. No convierte a Hollenbeck en operador de un registro, responsable de una política concreta o decisor de un dominio particular. Su nombre prueba procedencia de la especificación; el cambio de estado necesita la procedencia de la institución que lo ejecutó. La atribución precisa protege ambos hechos.

Construir un expediente que pueda responder

El registro mínimo enlaza, sin fusionar, dos fuentes. Del lado técnico: dominio, código exacto, servidor o vista observada, instante, consulta o transacción cuando exista y siguiente estado. Del lado decisorio: versión de política, solicitante, rol responsable, evidencia de autorización, vigencia, revisión, notificación, excepción y mecanismo de salida.

Si hubo un intento de transferencia, se añade el recibo de la solicitud: fecha, tratamiento de la autorización, respuesta del servidor, estado pendiente si lo hubo, razón de denegación comunicada y resolución final. No hay que publicar contraseñas ni datos personales innecesarios. Sí hay que preservar la cadena que permite a una persona autorizada distinguir una protección legítima, un error, una disputa y una intrusión.

La objeción más fuerte es cierta: prohibir transferencias protege. En un servidor conforme, el estado detiene la orden. Los bloqueos por defecto y los servicios de registro bien diseñados aumentan la resistencia al secuestro de dominios. El error consiste en convertir ese efecto verdadero en una explicación que el código nunca dio.

El mapeo de Hollenbeck responde con exactitud: esta clase de solicitud será rechazada. La organización que activa el estado debe completar el relato: quién lo decidió, bajo qué autoridad, durante cuánto tiempo y mediante qué salida. El bloqueo impide el movimiento; la evidencia atribuible explica el porqué.

Fuentes