Sovy Cloud Services: el registro persiste, pero la operación

Summary

ARIN mantiene AS401110 como un registro activo bajo el nombre AS-SOVYCLOUD y lo vincula con Sovy Cloud Services / SCSL-51. Esa información acredita una identidad registral; por sí sola no prueba que exista hoy un servicio de nube accesible al cliente.
La evidencia contemporánea es débil. El 20 de julio de 2026, el RDAP de .cloud mostraba sovy.cloud disponible para registro, tres consultas DNS A devolvían NXDOMAIN y RIPEstat clasificaba AS401110 como no anunciado, sin prefijos ni vecinos visibles en sus vistas actuales.
PeeringDB aún describe a Sovy Cloud Services LLC como un NSP de alcance global, asociado a cinco instalaciones. Es una huella útil para reconstruir intención y presencia declarada, pero no confirma actividad actual, equipos, contratos, clientes ni continuidad en esos lugares.
La historia BGP evita una conclusión simplista: AS401110 sí originó seis prefijos entre 2024 y comienzos de 2025. La lectura prudente no es que Sovy Cloud Services esté definitivamente cerrada, sino que sus registros históricos ya no bastan como prueba de una operación pública vigente.

Tres relojes que no marcan la misma hora

La infraestructura de internet deja rastros con vidas útiles muy distintas. Un dominio puede desaparecer de DNS en cuanto vence o se elimina su delegación. Una ruta BGP puede dejar de ser visible en minutos. En cambio, un registro de recursos numéricos o una ficha de un directorio de interconexión pueden seguir describiendo una organización mucho después de que cambie su superficie operativa. Leer esas fuentes como si todas retrataran el mismo momento produce una certeza falsa.

Sovy Cloud Services muestra con especial claridad esa diferencia temporal. ARIN conserva un sistema autónomo real y activo en términos registrales. PeeringDB conserva un nombre, una clasificación, una política de alcance y cinco asociaciones con instalaciones. Esos datos tienen valor: identifican a la organización, permiten reconstruir lo que declaró sobre su red y demuestran que no se trata de una marca inventada a partir de una página efímera. Pero las comprobaciones frescas ofrecen otra imagen.

El dominio de la marca está disponible, no resuelve en las consultas A registradas y el ASN no presenta una huella pública actual en las vistas de RIPEstat examinadas.

La contradicción es solo aparente. Cada fuente responde una pregunta diferente. ARIN responde quién recibió el recurso y bajo qué identificador se mantiene. PeeringDB responde cómo quiso presentarse la red ante la comunidad de interconexión. DNS responde si el nombre consultado existe en ese momento dentro del sistema de nombres. BGP, a través de los colectores que alimentan RIPEstat, responde si las rutas del ASN llegan a una superficie de observación pública. Ninguna de esas respuestas sustituye a las demás.

Para un comprador de servicios de nube, esa separación importa más que una etiqueta binaria de activo o inactivo. La diligencia no consiste en encontrar una fila positiva en una base de datos y detenerse. Consiste en ordenar la evidencia por fecha, función y capacidad probatoria. En este caso, la identidad y la actividad histórica están bien sustentadas; la operación pública contemporánea no lo está.

ARIN acredita al titular registral, no una nube en funcionamiento

ARIN registra AS401110 con el nombre AS-SOVYCLOUD. El recurso aparece activo, fue registrado el 29 de mayo de 2024 y tuvo su última modificación el 30 de mayo de ese año. La entidad asociada es Sovy Cloud Services / SCSL-51, con domicilio en 25 First Ave. SW STE A, Watertown, Dakota del Sur 57201, Estados Unidos. Esta cadena ofrece una identidad verificable y una fecha concreta para la incorporación del ASN al registro.

El valor de esa prueba es preciso. Permite afirmar que AS401110 fue asignado a una entidad identificada como Sovy Cloud Services y que el registro no ha sido eliminado. También permite relacionar el nombre usado por la empresa con AS-SOVYCLOUD, el identificador que aparece en otras superficies técnicas. No permite afirmar que el ASN esté anunciando rutas hoy, que una plataforma acepte altas, que una instancia responda o que un contrato de cliente siga vigente.

La dirección tampoco es una prueba de infraestructura física. Es un domicilio registral. No identifica por sí sola un nodo de red, una sala operativa ni una ubicación desde la que se preste el servicio. La distinción puede parecer formal, pero evita que una dirección administrativa se convierta, sin respaldo, en un mapa técnico.

Los contactos anidados de ARIN añaden una señal de mantenimiento. Las funciones administrativa, técnica y de abuso utilizan direcciones de correo bajo sovy.cloud. El registro incluye observaciones de POC no validados tras no recibir respuesta desde el 7 de mayo de 2025. Ese dato debilita la confianza en la actualidad del canal publicado, aunque su alcance debe mantenerse limitado. No demuestra que cada buzón esté definitivamente fuera de servicio, ni que no existan contactos privados o posteriores por otra vía.

La combinación del dominio disponible y esas observaciones sí eleva el coste de verificación. Un cliente o una red contraparte no debería tratar el mero hecho de que ARIN muestre una dirección de correo como confirmación de que el canal funciona. Debería probar una ruta de contacto contemporánea y obtener una respuesta atribuible a la entidad. El registro proporciona el punto de partida; la respuesta actual es la prueba operativa.

El dominio es la señal pública más reciente

El 20 de julio de 2026, el RDAP del registro .cloud informó que sovy.cloud estaba disponible para registro. En la misma fecha, consultas DNS A efectuadas mediante el resolutor del sistema, Cloudflare 1.1.1.1 y Google 8.8.8.8 devolvieron NXDOMAIN. Las cuatro observaciones convergen: el nombre que PeeringDB todavía presenta como sitio de la red no estaba entonces delegado como un dominio registrado y resoluble.

Esta evidencia es más inmediata que una ficha histórica, pero tampoco debe sobrecargarse. NXDOMAIN para el nombre consultado no es un certificado de cese empresarial. Una organización puede cambiar de marca, operar un plano privado, mantener obligaciones contractuales fuera de un sitio público o utilizar otros canales que no figuren en el paquete. El RDAP y DNS tampoco responden si quedan clientes, datos almacenados o relaciones legales pendientes.

Sí responden una cuestión material para la diligencia: la dirección pública que une la identidad comercial, el sitio consignado en PeeringDB y los correos de contacto de ARIN ya no ofrece una superficie verificable bajo ese nombre. Para una marca de nube, perder el dominio no es un detalle cosmético. Dificulta comprobar documentación, estado del servicio, autenticidad de comunicaciones, soporte, políticas, avisos de incidentes y mecanismos de recuperación de cuenta. El riesgo no nace de asumir que todo eso ha desaparecido, sino de que ya no puede validarse por el canal que los registros siguen señalando.

El paquete documenta consultas A, no una prueba de entrega de correo ni una auditoría de todos los tipos de registro DNS. Por eso no corresponde declarar muertos los buzones administrativos, técnicos o de abuso. La formulación defendible es más estrecha: el dominio estaba disponible y el nombre devolvía NXDOMAIN en los tres resolutores registrados; al mismo tiempo, los contactos públicos seguían dependiendo de esa identidad de dominio. Esa discordancia exige una verificación fuera de banda antes de confiar en el canal.

También convierte la fecha en parte del hecho. Los dominios pueden registrarse de nuevo y las rutas pueden reaparecer. Una evaluación futura no debería copiar el resultado del 20 de julio como si fuera permanente. Debería repetir RDAP y DNS, conservar la hora de consulta y comprobar quién controla cualquier dominio que vuelva a activarse. La persistencia del nombre no garantiza continuidad de titularidad.

PeeringDB conserva una geografía declarada

La ficha de PeeringDB presenta AS401110 como sovy.cloud, Sovy Cloud Services y Sovy Cloud Services LLC. Lo clasifica como NSP, le asigna alcance global, recoge AS-SOVYCLOUD como IRR y señala sovy.cloud como sitio. Al mismo tiempo, muestra cero prefijos IPv4, cero prefijos IPv6 y cero conexiones a puntos de intercambio. La ficha principal cuenta cinco instalaciones.

Las asociaciones de instalaciones son específicas: Equinix SG1 - Singapore, Equinix SG3 - Singapore, Equinix HK2 - Hong Kong, Linxdatacenter (Moscow) y NewTelco Kiev. El conjunto dibuja la ambición geográfica que la red hizo pública, desde Asia hasta Europa oriental. Sirve para localizar dónde afirmó disponer de una relación relevante para interconexión. No prueba que esa relación siga vigente en julio de 2026.

PeeringDB es un directorio de gran utilidad precisamente porque permite a redes e instalaciones publicar información estructurada. Su fuerza está en la atribución y en la facilidad de comparación. Su límite es que una fila no equivale a una inspección contemporánea del lugar. La asociación no demuestra equipos encendidos, espacio contratado, capacidad disponible, autorización de acceso, tráfico, redundancia ni cargas de clientes. Tampoco permite afirmar que las cinco instalaciones estén inactivas. Solo muestra que las filas existen y necesitan corroboración actual.

La API netfac devuelve esas cinco asociaciones, mientras la API netixlan no devuelve filas de LAN de intercambio para el identificador de red 36371. La API pública de POC tampoco devuelve contactos públicos para ese identificador. Es una superficie peculiar: hay un mapa de instalaciones, pero no una conexión de IX ni un contacto público de PeeringDB que permita completar fácilmente la verificación desde el propio directorio.

La ausencia de filas netixlan no demuestra ausencia de tránsito ni de interconexiones privadas. Una red puede comprar tránsito, usar enlaces privados o mantener relaciones que no se publiquen en esa tabla. Del mismo modo, la ausencia de POC públicos no significa que no haya personas capaces de operar la red. Sí significa que PeeringDB, por sí solo, no ofrece hoy una cadena pública completa desde la ficha hasta un contacto y una conexión observable.

Para convertir cualquiera de las cinco asociaciones en prueba operativa haría falta una confirmación contemporánea e independiente. Un comprador podría pedir a Sovy Cloud Services que identifique qué servicio se presta desde cada ubicación, y después comprobar con la instalación o con documentación contractual vigente que la relación existe. La respuesta podría revelar que la huella sigue activa, que se redujo o que cambió. El directorio no permite elegir entre esas posibilidades.

La historia BGP demuestra que la red tuvo vida pública

La ausencia actual no borra la historia. RIPEstat registra que AS401110 originó seis prefijos en distintos intervalos entre finales de mayo o comienzos de junio de 2024 y febrero de 2025: 166.88.177.0/24, 2a12:8fc6:4011::/48, 81.161.230.0/24, 109.206.237.0/24, 136.0.121.0/24 y 23.27.222.0/24. No se trata, por tanto, de un ASN que solo existió como reserva administrativa sin llegar a aparecer en el enrutamiento observado.

Ese historial cambia el análisis. La pregunta no es si Sovy Cloud Services tuvo alguna vez una huella de red pública; la tuvo. La pregunta es qué ocurrió después y qué parte de aquella huella sigue bajo su control o respalda un servicio actual. El registro histórico aporta procedencia, no continuidad automática.

RIPEstat sitúa la primera observación de 2a12:8fc6:4011::/48 el 31 de mayo de 2024. Para el estado actual, ese prefijo IPv6 no aparece anunciado. También identifica 109.206.237.0/24 como el último prefijo IPv4 visto bajo AS401110, con fecha del 14 de febrero de 2025. La secuencia sugiere una fase pública relativamente concentrada en el tiempo, pero las fuentes no explican su motivo ni documentan una decisión empresarial.

No corresponde convertir la retirada de rutas en una narración causal. Una ruta puede cambiar por migración, renumeración, fin de una autorización, modificación de proveedor, consolidación, error, suspensión u otros motivos. El paquete no contiene contratos, comunicaciones internas ni avisos que permitan escoger una explicación. La diligencia responsable registra el cambio y deja abierta la causa.

La historia sí cumple otra función: impide confundir falta de visibilidad actual con inexistencia pasada. Si un antiguo cliente presenta una dirección, una configuración o un registro vinculado a alguno de esos prefijos, la cronología de RIPEstat puede ayudar a establecer cuándo se observó el origen bajo AS401110. No prueba qué servicio utilizó ese cliente ni quién era el usuario de una dirección concreta, pero sitúa el recurso dentro de un periodo de actividad pública.

Los prefijos también tienen una vida después del proveedor

El estado contemporáneo de dos recursos ilustra por qué no basta con reconocer una dirección antigua. 109.206.237.0/24, el último prefijo IPv4 visto bajo AS401110, aparece actualmente anunciado por AS16045 BULINFO-HOSTING Spektar AD en la vista de RIPEstat. El cambio de origen es un hecho técnico observable. No revela si hubo una transferencia, una reasignación, el final de un acuerdo, una nueva autorización o cualquier otra relación comercial.

La consecuencia práctica es clara: encontrar una dirección histórica de Sovy Cloud Services dentro de ese bloque no autoriza a atribuir su tráfico actual a la empresa. La procedencia debe fecharse. Un investigador, un responsable de seguridad o un cliente que revise registros antiguos debería comparar la hora del evento con la historia BGP, el origen vigente y los datos registrales aplicables en ese momento. El mismo prefijo puede contar historias distintas en fechas distintas.

El caso de 2a12:8fc6:4011::/48 es diferente. RIPEstat no lo muestra actualmente anunciado. Eso no lo convierte en prueba de cierre ni permite deducir el destino de su asignación o uso privado. Solo indica que no había una ruta pública visible en la comprobación. La diferencia entre “originado ahora por otra red” y “no anunciado ahora” debe conservarse; son estados técnicos distintos.

Para clientes que dependieron de direcciones permitidas en listas de acceso, registros SPF, túneles, copias remotas o reglas de confianza, los cambios de origen plantean una tarea de higiene. La autorización basada únicamente en una dirección antigua puede sobrevivir a la relación que le dio sentido. La recomendación no es asumir abuso, sino revisar si la identidad operativa que justificaba esa confianza sigue controlando el recurso. El paquete no documenta ninguna explotación indebida; documenta un cambio que vuelve necesaria la revisión.

El presente de AS401110 es una ausencia medida, no una inexistencia total

En la consulta de las 08:00 UTC del 20 de julio de 2026, el resumen de RIPEstat marcaba AS401110 como no anunciado. La vista de prefijos anunciados no devolvía prefijos actuales en su ventana reciente de dos semanas. La propia metodología advierte que rutas con visibilidad muy baja en alimentaciones completas de RIS pueden quedar excluidas, una salvedad que importa cuando se interpreta un cero.

La vista de estado de enrutamiento es igualmente nítida dentro de su alcance: cero prefijos IPv4 anunciados, cero /48 IPv6, cero vecinos observados y cero visibilidad actual IPv4 o IPv6 en RIS. La consulta de vecinos devuelve cero relaciones a la izquierda, a la derecha, únicas o inciertas en el momento más reciente disponible. En conjunto, las APIs no ofrecen una señal BGP pública contemporánea atribuible a AS401110.

Ese conjunto es más sólido que una sola captura porque varias vistas convergen. Aun así, sigue siendo telemetría de internet público. Los colectores no observan toda sesión privada, toda red interna, todo servicio aislado ni toda relación que no propague una ruta hasta sus puntos de medición. Tampoco ven una aplicación solo porque exista en una red ajena o detrás de un proveedor distinto.

Por ello, “sin rutas visibles” no significa “sin clientes”, “sin infraestructura” ni “sin servicio privado”. Significa que el identificador de red que los registros asocian a Sovy Cloud Services no estaba demostrando, mediante esas vistas públicas, un perímetro de enrutamiento vigente. Si la empresa opera ahora de otra manera, esa operación necesita pruebas diferentes: un dominio controlado, un endpoint verificable, documentación contractual, una relación actual con proveedores o instalaciones, o evidencia técnica atribuible a la nueva arquitectura.

La diferencia es esencial para evitar dos errores opuestos. El primero sería anunciar un cierre definitivo que las fuentes no sostienen. El segundo sería tratar la persistencia de AS401110 en ARIN como si neutralizara todas las señales frescas de ausencia. La posición razonable queda entre ambos: existe una identidad registral y una historia de operación, pero el grado de prueba sobre la superficie pública actual es débil.

Una jerarquía de evidencia para comprar nube con poca visibilidad

El caso permite construir un método de diligencia aplicable a proveedores pequeños sin reducirlos a la cantidad de información que publican. La primera capa es la identidad. Aquí entran el nombre legal o registral, la entidad responsable, el ASN y las fechas. ARIN ofrece esa capa para Sovy Cloud Services. Es necesaria para saber con quién se está tratando, pero no basta para evaluar la prestación.

La segunda capa es la historia operativa. Las rutas observadas demuestran que AS401110 participó en BGP y originó recursos concretos. Esta capa ayuda a distinguir experiencia real de una mera declaración. También permite construir una cronología. Su limitación es temporal: una ruta de 2024 o 2025 no responde qué funciona en julio de 2026.

La tercera capa es la prueba contemporánea. Incluye DNS, anuncios actuales, prefijos, vecinos visibles, endpoints, estado del servicio y contactos que responden. Sovy Cloud Services falla hoy en producir varias de esas señales públicas dentro del paquete: sovy.cloud estaba disponible y devolvía NXDOMAIN; RIPEstat no veía anuncios ni vecinos; PeeringDB no mostraba IX ni POC públicos. “Falla” describe el resultado de la comprobación, no un incumplimiento contractual que no ha sido evaluado.

La cuarta capa es la corroboración. Una asociación en PeeringDB debe contrastarse con la instalación o con documentación vigente. Un dominio que reaparece debe contrastarse con la entidad que lo controla. Un contacto debe probarse mediante una respuesta autenticable. Un prefijo debe compararse con su origen actual. La corroboración impide que una base de datos que se actualiza lentamente funcione como sustituto de la realidad presente.

La quinta capa es contractual y de continuidad. Antes de colocar una carga de trabajo, un comprador necesita saber quién responde, cómo se recuperan datos, qué ocurre al terminar el servicio, cómo se notifica un incidente y qué evidencia existe de que los recursos esenciales están bajo control. Estas preguntas no presuponen que Sovy Cloud Services incumpla nada. Son el trabajo mínimo cuando las superficies públicas dejan dudas que el registro no puede resolver.

Aplicar la jerarquía evita convertir el tamaño en un prejuicio. Un proveedor pequeño puede ofrecer un servicio sólido con una huella pública modesta si entrega pruebas actuales y verificables. A la inversa, una ficha extensa puede conservar asociaciones que ya no describen la operación. El criterio no es la cantidad de filas, sino su fecha, procedencia y conexión con el servicio contratado.

Qué debería demostrar Sovy Cloud Services para recuperar confianza pública

La primera prueba sería el control de una identidad digital estable. No tiene que ser necesariamente el antiguo dominio, pero cualquier sustituto debería relacionarse de forma inequívoca con Sovy Cloud Services, actualizar los contactos registrales y ofrecer un canal autenticable. Si sovy.cloud se registra de nuevo, la mera reaparición del sitio no demostraría continuidad: habría que verificar al titular y descartar que un tercero haya adquirido el nombre disponible.

La segunda sería una explicación fechada de la arquitectura actual. Si AS401110 ya no es el perímetro utilizado, la empresa podría identificar qué red presta el servicio y cómo se atribuyen las responsabilidades. Si el ASN volverá a anunciar rutas, las observaciones BGP deberían concordar con esa declaración. Si la operación es privada o depende por completo de terceros, el comprador necesita evidencia contractual y técnica que reemplace la visibilidad que antes aportaban las rutas.

La tercera sería corroborar las cinco instalaciones o corregir la ficha de PeeringDB. No se necesita publicar información sensible. Bastaría con distinguir asociaciones vigentes de históricas y explicar, a un nivel verificable, qué función cumple cada ubicación. Mantener una lista global sin una conexión de IX, un POC público o una confirmación contemporánea obliga a terceros a hacer un trabajo que la propia empresa podría simplificar.

La cuarta sería cerrar el circuito de contacto. Las observaciones de POC no validados y la desaparición del dominio crean incertidumbre sobre escalamiento técnico y de abuso. Una respuesta actual, firmada o verificable por un canal independiente, tendría más valor que la antigüedad del registro. Para un cliente, saber a quién acudir durante un incidente es parte de la continuidad, no una formalidad administrativa.

La quinta sería documentar la salida. Cuando la huella de un proveedor se reduce, el cliente debe poder recuperar datos, revocar credenciales, retirar dependencias de direcciones antiguas y confirmar la eliminación o conservación acordada. El paquete no dice que exista un problema de datos ni identifica clientes afectados. La recomendación nace de la brecha probatoria: cuando no hay una superficie pública verificable, el plan de salida debe descansar en documentos y pruebas propias, no en supuestos.

Qué deben revisar antiguos clientes y contrapartes

Quien haya utilizado Sovy Cloud Services no debería interpretar este análisis como evidencia de pérdida de datos o de indisponibilidad de una cuenta concreta. Debería usarlo como disparador para revisar dependencias. El primer inventario incluye dominios, credenciales, direcciones IP, reglas de firewall, destinos de copia, certificados, webhooks, túneles y canales de soporte vinculados a la marca.

Las direcciones merecen atención especial. Si una regla confía en 109.206.237.0/24 porque en otro momento fue observado bajo AS401110, el origen actual AS16045 BULINFO-HOSTING Spektar AD cambia el contexto. No demuestra una amenaza ni invalida toda dirección del bloque, pero elimina la base para tratarlo como si siguiera siendo inequívocamente una superficie de Sovy Cloud Services. La confianza debe volver a una identidad actual, no quedarse anclada a una atribución histórica.

Los contactos también deben verificarse por un canal que no dependa de la misma evidencia cuestionada. Enviar un mensaje y no recibir respuesta no bastaría para probar el estado de una empresa; recibir una respuesta tampoco bastaría si no puede autenticarse. La comprobación útil vincula a la persona o al canal con la entidad registral y con la responsabilidad sobre el servicio concreto.

Para nuevas compras, las señales públicas justifican detener la incorporación hasta obtener pruebas actuales. Detener no significa condenar. Significa pedir evidencia antes de aceptar una dependencia: demostración de control del servicio, términos de continuidad y salida, puntos de escalamiento, ubicación y responsabilidad de los recursos, y una prueba técnica de funcionamiento. Si la empresa puede proporcionarlas, el expediente cambia. Si no puede, el registro histórico no compensa la falta.

Un expediente que debe seguir abierto

La situación puede cambiar con rapidez. El dominio podría registrarse, AS401110 podría volver a anunciar un prefijo, PeeringDB podría actualizar sus asociaciones o surgir un contacto verificable. Cada cambio tendría que evaluarse como un hecho nuevo, no como confirmación automática de que todo lo anterior volvió a ser válido.

Hay cuatro indicadores públicos especialmente útiles para seguimiento. El primero es el estado RDAP y DNS de sovy.cloud, incluida la identidad del registrante cuando sea legítimamente accesible y la coherencia con Sovy Cloud Services. El segundo es la reaparición de rutas bajo AS401110 y su persistencia en más de una observación. El tercero es cualquier cambio en el origen de los seis prefijos históricos. El cuarto es la actualización de las filas de instalaciones, conexiones y contactos de PeeringDB.

La persistencia importa. Una ruta observada durante un intervalo corto puede ser una transición o una anomalía. Un sitio recién registrado puede pertenecer a otra persona. Una ficha actualizada puede seguir siendo una declaración sin corroboración. La diligencia debe combinar señales, repetir consultas y conservar fechas. El objetivo no es elevar una captura a veredicto, sino detectar cuándo varias fuentes vuelven a describir una misma operación.

También conviene mantener separada la evidencia pública de la privada. Un cliente puede disponer de facturas, tickets, acuerdos o telemetría que no aparecen aquí. Esos materiales podrían confirmar continuidad o documentar un problema concreto. Este artículo no los sustituye. Evalúa únicamente el paquete de fuentes definido y explica por qué, dentro de ese perímetro, la prueba actual es insuficiente.

La cronología cambia la carga de la prueba

Ordenar el expediente por fechas permite extraer más información sin inventar una causa. El 29 de mayo de 2024 se registró AS401110 y al día siguiente se modificó por última vez el registro de ARIN. El 31 de mayo RIPEstat observó por primera vez 2a12:8fc6:4011::/48. Otros cinco prefijos aparecen después en la historia de enrutamiento, y 109.206.237.0/24 fue el último IPv4 visto bajo ese origen, el 14 de febrero de 2025. La proximidad entre el alta registral y las primeras rutas es una señal coherente de puesta en marcha: la identidad administrativa y una actividad BGP observable coincidieron en el tiempo.

Esa coincidencia inicial es importante porque eleva el expediente por encima de una simple declaración comercial. Hubo un recurso registrado y hubo anuncios atribuidos a ese recurso. Sin embargo, la fuerza de esa prueba disminuye cuando se la usa para describir un momento posterior. Cada observación histórica acredita el intervalo en que fue vista; no se extiende por defecto hasta julio de 2026. El paso del tiempo no invalida el dato, pero cambia la pregunta que puede responder.

La siguiente fecha relevante procede de los contactos de ARIN. Las observaciones de POC señalan falta de respuesta desde el 7 de mayo de 2025. Esa anotación es posterior a la última visibilidad indicada para 109.206.237.0/24, pero el orden no demuestra que una cosa causara la otra. Tampoco demuestra que nadie atendiera asuntos técnicos por canales distintos. Sí muestra que, una vez reducida la huella pública de rutas, al menos parte del mecanismo registral de validación de contactos tampoco produjo una confirmación reciente.

El 20 de julio de 2026 concentra las comprobaciones más frescas. El RDAP de .cloud mostraba disponible sovy.cloud; tres resolutores devolvían NXDOMAIN; el resumen de RIPEstat marcaba AS401110 como no anunciado; las vistas de prefijos, estado y vecinos no aportaban una superficie BGP actual. Estas señales no son equivalentes, pero comparten fecha y apuntan a capas complementarias: identidad digital, resolución del nombre y visibilidad del sistema autónomo. Su convergencia pesa más para evaluar el presente que una asociación de instalaciones sin fecha de verificación operativa.

La cronología también ayuda a formular correctamente la incertidumbre. No hay en el paquete una fecha oficial de finalización, un aviso de migración, una declaración de cierre ni un documento que explique la retirada de rutas. Por eso no existe base para narrar una secuencia empresarial cerrada. Lo que sí existe es una secuencia probatoria: identidad y rutas visibles en 2024, última observación IPv4 en febrero de 2025, debilidad de validación de contactos desde mayo de 2025 y ausencia pública convergente en julio de 2026.

Esa secuencia desplaza la carga de la prueba. En 2024, alguien que quisiera demostrar actividad podía señalar rutas recién observadas junto con el ASN. En 2026, quien sostenga que la misma superficie sigue operativa necesita evidencia contemporánea que explique la discontinuidad. Podría ser un nuevo dominio controlado por la entidad, un perímetro de red distinto, una confirmación verificable de las instalaciones o documentación de un modelo privado. La posibilidad abstracta de cualquiera de esas explicaciones no equivale a su demostración.

El mismo criterio debería aplicarse si AS401110 reaparece. Un anuncio nuevo sería una señal relevante, pero no bastaría para concluir que se reanudó el mismo servicio, con los mismos responsables y las mismas condiciones. Habría que fecharlo, observar su persistencia, identificar el prefijo y comprobar que la identidad que lo presenta conserva una relación verificable con Sovy Cloud Services. La cronología protege tanto contra una acusación excesiva de cierre como contra una inferencia excesiva de continuidad.

Para compradores y contrapartes, el resultado es un expediente versionado, no una etiqueta permanente. Cada conclusión debe llevar la fecha de la fuente que la sostiene. “ARIN mantiene el ASN activo”, “RIPEstat observó estas rutas en 2024 y 2025” y “RIPEstat no veía anuncios el 20 de julio de 2026” pueden ser verdaderas a la vez. El error aparece cuando la primera frase se usa para borrar la tercera, o cuando la tercera se usa para negar la actividad documentada por la segunda.

De la coincidencia de nombres a una cadena de control

El nombre Sovy aparece de forma coherente en varias capas. ARIN vincula AS401110 con Sovy Cloud Services y SCSL-51; PeeringDB usa Sovy Cloud Services, Sovy Cloud Services LLC, sovy.cloud y AS-SOVYCLOUD; el IRR declarado repite ese identificador. Esta coincidencia reduce la ambigüedad sobre qué organización quiso presentarse detrás del ASN. No resuelve, sin embargo, quién controla hoy cada componente necesario para prestar un servicio.

Una cadena de control operativa empieza por la identidad, pero debe continuar hasta los recursos y los canales. Para una red pública, eso supone relacionar a la entidad con un ASN, el ASN con prefijos anunciados, los anuncios con vecinos o proveedores observables y esos recursos con endpoints o servicios que el cliente pueda atribuir. Para una plataforma de nube también importa un plano de contacto: dominio, autenticación, soporte y escalamiento que puedan verificarse sin depender únicamente de una ficha antigua.

En el expediente actual, la cadena se interrumpe en varios puntos. La identidad registral existe, pero AS401110 no mostraba rutas ni vecinos en las consultas actuales. PeeringDB conserva cinco asociaciones con instalaciones, pero no devuelve filas netixlan ni POC públicos para la red. El sitio y los contactos publicados dependen de sovy.cloud, mientras el dominio figuraba disponible y el nombre consultado devolvía NXDOMAIN. Cada ruptura tiene un alcance distinto; juntas impiden enlazar sin saltos la entidad registrada con una superficie de nube pública contemporánea.

El cambio de origen de 109.206.237.0/24 ofrece un ejemplo concreto de por qué la coincidencia histórica no basta. RIPEstat lo observó por última vez bajo AS401110 en febrero de 2025 y lo muestra actualmente originado por AS16045 BULINFO-HOSTING Spektar AD. La observación actual permite atribuir el anuncio de hoy a AS16045 dentro de esa vista. No permite saber por qué cambió, quién posee contractualmente el bloque ni qué relación comercial hubo entre las partes. La cadena de control debe detenerse donde se detiene la fuente.

Con 2a12:8fc6:4011::/48, el límite es diferente. El prefijo forma parte de la historia visible de AS401110, pero no aparece anunciado ahora. No hay otro origen actual que pueda compararse dentro del hallazgo descrito. La conclusión, por tanto, no es que otro operador lo controle, sino que la evidencia pública consultada no muestra una ruta vigente. Tratar ambos prefijos del mismo modo borraría una diferencia técnica material.

Las cinco instalaciones exigen una disciplina parecida. Que Equinix SG1 - Singapore, Equinix SG3 - Singapore, Equinix HK2 - Hong Kong, Linxdatacenter (Moscow) y NewTelco Kiev estén asociadas al net id 36371 demuestra que esas relaciones fueron declaradas en PeeringDB. No dice qué recurso estaba instalado, quién lo gestionaba, si había tráfico ni qué servicio dependía de él. Una corroboración útil tendría que unir una instalación concreta con una función actual y con una responsabilidad atribuible, sin exigir la publicación de detalles sensibles.

Esta forma de leer la evidencia evita confundir consistencia nominal con continuidad operativa. Varias bases pueden repetir el mismo nombre porque comparten una declaración histórica o porque una ficha no se actualizó. La repetición aumenta la confianza en la identidad del sujeto, pero no añade por sí sola una segunda observación del funcionamiento. Para sumar prueba operativa, las fuentes deben aportar señales diferentes y contemporáneas: control del nombre, anuncios persistentes, respuesta autenticable, confirmación de una relación o funcionamiento atribuible.

También permite hacer preguntas más precisas. En vez de preguntar de forma genérica si la empresa “sigue activa”, un comprador puede pedir qué entidad firma hoy el servicio, qué dominio y canal controla, qué red transporta el tráfico, cuáles de las ubicaciones declaradas cumplen una función vigente y cómo se demuestra la recuperación o salida. Cada respuesta puede contrastarse con la capa correspondiente. Una explicación coherente podría cerrar varios huecos; una nueva fila registral, aislada, solo cerraría el suyo.

El objetivo no es exigir que un proveedor pequeño publique toda su arquitectura. Es exigir que la confianza tenga una ruta verificable desde la identidad hasta la prestación. Esa ruta puede incluir pruebas privadas bajo acuerdo, siempre que sean actuales, atribuibles y suficientes para el riesgo asumido. Lo que no debería hacer un comprador es completar por imaginación los eslabones que faltan en el registro público.

En Sovy Cloud Services, el primer eslabón permanece claro y la actividad pasada también. Los eslabones actuales son los débiles: dominio, rutas, vecinos, contactos públicos y corroboración de instalaciones. Mientras no aparezca evidencia que vuelva a conectarlos, la descripción más exacta no es la de una empresa inexistente, sino la de una identidad histórica cuya superficie operativa pública no puede reconstruirse de extremo a extremo con las fuentes disponibles.

Conclusión: identidad duradera, operación por demostrar

Sovy Cloud Services dejó una huella técnica real. ARIN vincula AS401110 y AS-SOVYCLOUD con la entidad registrada como SCSL-51. RIPEstat conserva seis prefijos originados por el ASN durante 2024 y comienzos de 2025. PeeringDB documenta cómo Sovy Cloud Services LLC se presentó: un NSP global con asociaciones en cinco instalaciones. Esos datos sostienen identidad, intención e historia.

La fotografía del 20 de julio de 2026 es distinta. sovy.cloud estaba disponible y devolvía NXDOMAIN en tres consultas A. RIPEstat no veía AS401110 anunciado, no encontraba prefijos actuales y no observaba vecinos. PeeringDB no ofrecía conexiones de IX ni POC públicos. El último prefijo IPv4 visto bajo el ASN aparecía ahora originado por otra red, mientras el prefijo IPv6 destacado no estaba anunciado.

Ninguno de esos hechos prueba que Sovy Cloud Services esté definitivamente cerrada, que no conserve clientes, que las instalaciones listadas estén inactivas o que no exista una superficie privada. Juntos sí establecen un grado débil de prueba operativa pública. La carga de demostrar actualidad ya no puede recaer en registros creados durante una fase anterior.

La lección para compradores y operadores es sencilla, aunque no cómoda: la identidad registral, la historia de rutas y la prestación presente son categorías distintas. AS401110 demuestra que hubo una red observable. No demuestra por sí solo que hoy exista una nube Sovy accesible y respaldada por los mismos recursos. Hasta que aparezca evidencia contemporánea y corroborada, la posición prudente es conservar el expediente abierto, verificar cada dependencia y no confundir memoria de infraestructura con servicio en funcionamiento.

Sovy Cloud Services: el registro persiste, pero la operación pública exige pruebas nuevas