Resumen

  • Las fuentes públicas identificadas cubren la identidad de AS210328, sus posibles rutas, la delegación DNS de almazcloud.network, certificados, presencia web y señales de infraestructura.
  • Ninguna de esas fuentes fue recuperada en vivo durante esta investigación: no se deben presentar valores actuales, prefijos, respuestas DNS, certificados, respuestas HTTP ni operación de nube como hechos comprobados.

La investigación sobre una empresa de nube suele empezar por una asociación aparentemente sencilla: un nombre de dominio, un número de sistema autónomo y una promesa de infraestructura. Pero esos elementos pertenecen a capas distintas. Un registro administrativo describe cómo una organización o recurso aparece ante una entidad de registro. Una ruta observada en BGP indica que determinados colectores vieron un anuncio. Una respuesta DNS conecta un nombre con uno o más destinos en un momento concreto. Un certificado o una respuesta HTTP muestran otra parte del comportamiento de un punto final.

Ninguna de esas capas, por separado, demuestra que un cliente pueda contratar, aprovisionar y utilizar recursos de nube.

Para almazcloud.network y AS210328, la cadena que habría que probar es más exigente:

  1. que el registro de AS210328 identifica de forma coherente a un operador o entidad administrativa;
  2. que el ASN origina o participa en rutas observables, con prefijos y fechas concretas;
  3. que esos prefijos se relacionan con nombres, servidores o puntos finales de almazcloud.network;
  4. que esos puntos finales responden con una superficie técnica mantenida;
  5. que existe una función orientada al cliente, como un portal, una API, almacenamiento, máquinas virtuales, soporte o un flujo reproducible de provisión.

El primer eslabón puede contrastarse con el objeto aut-num de RIPE para AS210328 y con los objetos de organización, personas y roles que este referencie (objeto aut-num de RIPE). Los objetos de ruta de RIPE pueden mostrar declaraciones de prefijos cuyo origen indicado es AS210328, pero son declaraciones registrales, no observaciones directas de tráfico (objetos route y route6 de RIPE). RIPEstat ofrece fuentes distintas para el resumen del ASN, los prefijos anunciados, el estado de enrutamiento y los vecinos observados (resumen de AS210328; prefijos anunciados; estado de enrutamiento; vecinos BGP).

Esa separación importa porque un ASN asignado no demuestra que esté anunciando rutas ahora. Del mismo modo, un objeto route no demuestra que el prefijo sea visible desde todos los puntos de Internet. La cobertura de los colectores es parcial; los anuncios pueden cambiar, retirarse o ser visibles solo desde determinadas perspectivas. Una fecha de primera observación describe el corpus del observador, no necesariamente el primer día en que la red existió.

La corroboración independiente debería comparar los resultados de RIPEstat con agregadores y observadores que emplean metodologías diferentes. BGP.tools puede aportar una vista agregada de prefijos, upstreams, pares y seguridad de rutas (perfil de BGP.tools). BGPView puede ofrecer otra enumeración de prefijos (consulta de BGPView). CAIDA puede contextualizar el ASN mediante relaciones inferidas y métricas de topología, aunque esas relaciones no son contratos comerciales (registro de CAIDA AS Rank). Cloudflare Radar ofrece una perspectiva adicional sobre visibilidad y cambios de rutas, si el ASN dispone de un perfil con datos suficientes (perfil de routing de Cloudflare).

La segunda conexión es administrativa y técnica: ¿hay una relación verificable entre AS210328 y almazcloud.network? PeeringDB puede contener un nombre de red, sitio web, política de peering, instalaciones o intercambios declarados por el operador (consulta de PeeringDB). Esa información sería útil para establecer una conexión atribuida al operador, pero seguiría siendo voluntaria y potencialmente desactualizada. Una coincidencia de marca o de sitio web reforzaría la relación; no probaría por sí sola que el ASN opera una plataforma de nube.

El dominio introduce otra secuencia de comprobaciones. RDAP puede registrar el registrador, los estados, los eventos de registro y expiración y los servidores de nombres delegados (registro RDAP). Las consultas DNS de Google pueden mostrar, en el momento de la consulta, los servidores de nombres, registros A y AAAA y señales relacionadas con DS (consulta NS; consulta A; consulta AAAA; consulta DS). DNSViz puede ayudar a revisar la delegación y la cadena DNSSEC (análisis de DNSViz).

Pero una dirección A que no pertenezca a un prefijo originado por AS210328 no refutaría que el operador use un CDN, alojamiento externo o subdominios distintos para sus servicios. A la inversa, una dirección dentro de un prefijo asociado con el ASN no demostraría que allí se ejecuta una nube para clientes. La relación debe probarse con una consulta fechada, una atribución de origen y una observación del servicio que el cliente realmente utiliza.

Los certificados pueden aportar cronología y nombres de host. Certificate Transparency puede mostrar certificados emitidos para el dominio o sus subdominios, sus emisores y periodos de validez (búsqueda de Certificate Transparency). Censys puede complementar esa información con observaciones de hosts, direcciones, puertos y certificados cuando sus resultados estén disponibles (búsqueda de certificados en Censys). SSL Labs puede describir aspectos del servicio TLS (análisis de SSL Labs). Sin embargo, emitir un certificado no prueba que se haya desplegado, que el host siga activo o que el host esté controlado por el operador del ASN.

La presencia web requiere la misma disciplina. Una respuesta HTTP actual, una captura de URLScan o un registro de archivo web podrían documentar que una dirección respondió, cuándo lo hizo y qué contenido presentó (página de almazcloud.network; versión HTTP; búsqueda de URLScan; capturas del archivo web). Los datos pasivos de OTX y VirusTotal pueden revelar relaciones históricas entre dominios, nombres y direcciones (DNS pasivo de OTX; perfil de VirusTotal). Las búsquedas de GitHub y grep.app pueden descubrir referencias de código o configuración (búsqueda de GitHub; búsqueda de grep.app).

Ninguna de esas señales convierte automáticamente un dominio en una plataforma de nube. Para demostrar la operación orientada a clientes harían falta evidencias adicionales: una interfaz accesible, documentación técnica coherente, un flujo de autenticación, una API o consola, recursos que puedan aprovisionarse, condiciones de servicio, soporte y una correspondencia verificable entre la superficie pública y la infraestructura observada. Incluso una página comercial solo demostraría una afirmación del operador, no necesariamente la capacidad técnica que describe.

El expediente disponible tiene una limitación central. Las respuestas en vivo de los registros, APIs, resolvers, servicios de certificados y puntos HTTP no fueron recuperadas. La marca temporal de recuperación es nula para cada candidato. Por tanto, este artículo no afirma cuál es actualmente el titular de AS210328, qué prefijos anuncia, qué direcciones devuelve almazcloud.network, qué certificados están activos o si existe una consola operativa. Tampoco afirma lo contrario. “No recuperado”, “recuperado y negativo” y “observado positivamente” son estados distintos.

Esa diferencia evita dos errores simétricos. El primero es tratar una identidad administrativa como prueba de una operación comercial. El segundo es tratar la falta de una observación en este expediente como prueba de que la red, el dominio o el servicio no existen. La conclusión defendible es más limitada: las fuentes públicas permiten especificar una cadena de verificación, pero los materiales conservados aquí no contienen las observaciones actuales necesarias para cerrar esa cadena.

Para un comprador, regulador o socio técnico, la siguiente acción no es acumular nombres de fuentes, sino repetir las comprobaciones de forma sincronizada. Hay que conservar la hora UTC, la respuesta bruta, el hash del artefacto y la perspectiva del observador. Después se deben comparar el registro de AS210328, los objetos de ruta, los anuncios BGP, los servidores DNS, las direcciones resueltas, los certificados y las respuestas HTTP. Solo entonces puede preguntarse si existe una continuidad técnica hasta una función que un cliente pueda usar.

Hasta que esa continuidad sea demostrada, almazcloud.network y AS210328 deben describirse como una identidad y una hipótesis de operación que requieren verificación, no como una nube operativa ya probada.