Resumen

  • La página del registro mercantil estonio correspondiente al número 14476114 mostraba el nombre Puzl Cloud OÜ y listaba GPU Computing OÜ bajo el encabezado «Invalid names» en la consulta del 18 de octubre de 2026.
  • El objeto de organización de RIPE que lleva ese mismo número de registro, 14476114, seguía indicando GPU Computing OU, con fecha de última modificación del 13 de mayo de 2026.
  • El sistema autónomo AS57063 anunciaba el 18 de octubre de 2026 los mismos dos prefijos que dos semanas antes: 213.5.72.0/24 y 2001:67c:f74::/48.

Un número, dos nombres, ninguna contradicción

La ficha del registro mercantil estonio dedicada al número 14476114 no se lee como el perfil de una empresa. Tal como se recuperó el 18 de octubre de 2026, la página del registro mercantil estonio correspondiente al número 14476114 abre con un nombre, Puzl Cloud OÜ, seguido del número entre paréntesis, y más abajo incluye una línea cuya brevedad esconde su peso: bajo el rótulo «Invalid names», el registro consigna GPU Computing OÜ. Leído sin adornos, es un registro que informa al lector cuál de los nombres en circulación para esa persona jurídica pertenece al pasado y cuál ya no considera válido.

Se trata de una afirmación concreta y comprobable sobre un nombre. Es también lo único que establece el pasaje recuperado. Los campos que un extracto completo del registro mostraría de ordinario —si la inscripción está activa, bajo qué código de actividad tributa la sociedad, quiénes son sus administradores— no aparecían en el texto conservado, de modo que aquí no se afirman. Lo que importa para el argumento es más estrecho y más difícil de discutir: preguntado por 14476114, el registro responde Puzl Cloud OÜ y señala el otro nombre.

La base de datos de RIPE contesta lo mismo de otra manera. Consultada por AS57063 el mismo día, devuelve cuatro objetos, y uno de ellos es el objeto de organización ORG-GCO2-RIPE. Su atributo org-name sigue diciendo GPU Computing OU. Su país es EE, su reg-nr es 14476114 y su dirección corresponde a un edificio de Tallin, Tartu mnt 83-701. Su fecha de última modificación es el 13 de mayo de 2026, unos cinco meses antes de la consulta al registro y más de cinco años después de que el objeto se creara, el 9 de diciembre de 2020. La respuesta completa está en el registro de RIPE para AS57063.

Los dos documentos describen a la misma persona jurídica —el número de registro es idéntico— y le asignan nombres vigentes distintos. Ninguno es manifiestamente erróneo. Un objeto de registro deja constancia de una asignación, no de un estado societario en tiempo real; el registro estonio deja constancia de una persona jurídica, no de un registro de encaminamiento. Se les permite discrepar, y ese día discreparon.

El registro de encaminamiento nunca se indexó por el nombre

La parte del expediente que no derivó es la que transporta tráfico. El objeto aut-num de AS57063 tiene un as-name igual a PUZL-AS. Se creó el 2 de noviembre de 2021 y se modificó por última vez el 8 de noviembre de 2024. La identidad de encaminamiento del operador es, por tanto, una cadena derivada de «puzl» desde que el objeto existe, dentro de un registro anterior en dos años y medio a la última modificación del objeto de organización.

El objeto de rol cuenta la misma historia desde una fecha más temprana. GCO8-RIPE se llama GPU Computing OU, comparte la dirección de Tartu mnt y lleva un buzón de reporte de abusos en el dominio puzl.ee: es el dominio, no la razón social, lo que sostiene la capa de contacto. Sus fechas de creación y de última modificación son idénticas: 9 de diciembre de 2020, un segundo después de la creación del objeto de organización, que es el aspecto que tiene una única sesión de registro que produce varios objetos. Merece la pena retener el año 2020.

Cualquiera que haya sido la historia societaria posterior, la vía de contacto basada en el dominio ya existía antes de que se asignara el número de sistema autónomo.

El número tampoco ha cambiado de manos en ningún sentido visible. El 18 de octubre de 2026 el punto de servicio as-overview de RIPEstat devolvía el titular «PUZL-AS GPU Computing OU» y el valor announced true: una cadena que se lee exactamente como el as-name y el org-name unidos por un espacio, que es el aspecto que ofrece un servicio de síntesis cuando concatena dos campos que ya tiene en lugar de resolver una razón social vigente. El estado del propio punto de servicio era ok, la respuesta no estaba en caché y la ventana de consulta correspondía al 18 de octubre de 2026 a las 16:00 UTC: as-overview de RIPEstat para AS57063.

Quien se detenga en esa única superficie conocería el número de sistema autónomo, dos nombres a la vez y ningún desacuerdo. La contradicción solo se ve una capa más abajo, en los dos documentos de origen que sostienen los dos nombres.

Dos prefijos y un punto ciego declarado

La huella operativa en la misma fecha era pequeña, estable e idéntica a la de la quincena anterior. El punto de servicio announced-prefixes devolvía exactamente dos prefijos para AS57063: el prefijo IPv4 213.5.72.0/24 y el prefijo IPv6 2001:67c:f74::/48. Ambos llevan una única línea temporal continua del 4 de octubre de 2026 al 18 de octubre de 2026, y el valor latest_time de la respuesta es el 18 de octubre de 2026 a las 16:00 UTC. El detalle está en la respuesta announced-prefixes de RIPEstat.

Dos prefijos son una observación real y acotada, y el límite lo declara el propio servicio. La respuesta incluye un mensaje informativo que advierte de que los resultados excluyen las rutas de visibilidad muy baja, en concreto las que ven menos de diez pares completos de RIS. Esa frase hace mucho trabajo. Significa que el resultado de dos prefijos es lo que ve un punto de observación bien conectado, no un inventario completo de cuanto un operador pudiera anunciar por un camino más tenue. Quien trate los dos prefijos como el espacio de direcciones total del operador estará leyendo por encima de la salvedad que figura en el mismo documento.

Cuál es la función real de esos prefijos —si 213.5.72.0/24 lleva tráfico de clientes, infraestructura interna o un borde de servicio— no lo establece un anuncio. Un prefijo en la tabla global es la afirmación de que un origen es alcanzable, y nada más.

La única pregunta que los documentos no resuelven

La autorización de origen es la pregunta siguiente, y es la que falló. El punto de servicio de validación RPKI de RIPEstat para AS57063 no devolvió ningún cuerpo de respuesta aprovechable el 18 de octubre de 2026; la respuesta conservada registra un fallo de recuperación con extracto nulo y no contiene veredicto alguno: respuesta de validación RPKI de RIPEstat.

Conviene ser preciso aquí, porque es fácil confundir dos cosas distintas. Un servicio de validación que no devuelve resultado no ha dicho nada sobre si los prefijos están firmados. Ha dicho que la respuesta no pudo leerse. Tratar un punto de servicio ilegible como un prefijo sin firma, o como un prefijo limpio, es inventar un hecho en la dirección que el lector prefiera. El enunciado honesto es que la autorización de origen de AS57063 seguía sin leerse el 18 de octubre de 2026 y que el documento que la zanjaría —un resultado de validación que nombrara los certificados de recursos que cubren 213.5.72.0/24 y 2001:67c:f74::/48— no se obtuvo.

Queda un hilo suelto. El objeto aut-num lleva un atributo sponsoring-org que apunta a ORG-SDNS7-RIPE, un objeto de organización que no se consultó para este artículo. Una organización patrocinadora en una asignación es un hecho estructural sobre cómo se obtuvo el recurso, y es la clase de elemento que explica una asignación con más profundidad de la que jamás dará un campo de nombre. Su presencia está documentada; su identidad no.

Qué cuesta realmente la divergencia

La conclusión tentadora es que alguien fue negligente. Los documentos no lo sostienen, y encaja mejor una explicación más gris. Un objeto de registro se modifica cuando el operador tiene un motivo para modificarlo: un nuevo mantenedor, una dirección cambiada, una solicitud de recursos. Un cambio de razón social es un motivo para presentar una declaración ante un registro mercantil, que es una obligación legal con tasa y plazo. Nada en esa obligación crea el deber de tocar un objeto de RIR cuyo campo de nombre nadie está leyendo en ese momento. La desatención del campo de nombre es el estado por defecto, no una decisión.

Ese estado por defecto no lo paga el operador. Lo paga todo el que, aguas abajo, trata un nombre como si fuera una clave. Un registro de proveedores que cataloga una sociedad de nombre sugerente en materia de GPU y la busca por ese nombre no encontrará la ficha mercantil, porque el registro responde a otro nombre. Una contraparte que filtre una entidad contratante por su nombre comercial no hará coincidir el objeto de organización de RIPE, porque el número está y el nombre no. Un mapa de competidores construido con razones sociales arrastrará dos entradas, o ninguna.

La corrección barata es poco lucida y no depende de ninguno de los documentos no leídos. Indexar la ficha por el número de registro y por el número de sistema autónomo, que sobrevivieron ambos al cambio de nombre, y guardar el nombre como una observación fechada en lugar de como un identificador: esta entidad se llamaba X cuando se comprobó el día Y. El número es estable, el código es estable, y los dos prefijos se mantuvieron al menos durante la quincena observada. El nombre es el campo que se mueve, y debería tratarse como la columna menos autorizada de la fila, incluida la ficha del directorio de BTW dedicada a AS GPU Computing OU, que hereda el nombre anterior al cambio exactamente igual que lo lleva el objeto de registro.