Resumen

  • La investigación preservó fuentes para el registro de AS210328, la visibilidad de rutas, los prefijos anunciados, las relaciones de red, DNS, el sitio web y los certificados, pero los artefactos disponibles no contienen las respuestas actuales de esos servicios.
  • Por ello, no es defendible afirmar que el ASN anuncia rutas, que el dominio funciona o que existe un servicio de nube; tampoco es defendible concluir lo contrario.

La identidad administrativa y la operación visible son capas distintas

La comisión vincula al dominio almazcloud.network con AS210328. Esa asociación forma parte del contexto de investigación, pero no fue refrescada de manera independiente en la recuperación actual. Incluso una respuesta positiva del objeto aut-num de RIPE solo demostraría que existe una identidad de red registrada y mostraría sus atributos administrativos. No demostraría por sí sola anuncios BGP, tráfico de clientes ni prestación de servicios de nube. La fuente candidata para esa primera capa es el objeto de RIPE Database para AS210328: objeto aut-num de RIPE.

La segunda capa es la visibilidad de enrutamiento. RIPEstat ofrece consultas separadas para el estado de enrutamiento, los prefijos anunciados y los AS vecinos. Cada una respondería una pregunta diferente: si los colectores observan al ASN, qué espacio de direcciones le atribuyen y qué sistemas aparecen junto a él en las rutas. Esas mediciones serían temporales y dependientes de la cobertura de los colectores. Un resultado vacío no probaría que la red nunca opera; solo indicaría que esa vista no observó anuncios en el momento de la consulta.

Las consultas candidatas son el estado de enrutamiento de RIPEstat, los prefijos anunciados y los AS vecinos. En la recuperación preservada, sin embargo, no se obtuvieron sus cargas actuales ni valores con marca temporal. El hallazgo es una brecha de observación, no un resultado negativo.

DNS y web pueden probar continuidad, no necesariamente infraestructura propia

La tercera capa examina almazcloud.network. Una respuesta A de DNS podría mostrar si el dominio resolvía a una dirección IPv4 en el momento de la consulta. Una respuesta NS podría identificar la delegación y el operador DNS. Un sitio HTTPS recuperado podría aportar redirecciones, certificados, cabeceras, contenido, documentación o descripciones de producto. Certificate Transparency podría mostrar certificados emitidos para el dominio y sus subdominios.

Las fuentes preservadas para esas comprobaciones son la consulta A de Google Public DNS, la consulta NS de Google Public DNS, el sitio de almazcloud.network y la búsqueda de certificados en crt.sh. Ninguno de esos artefactos contiene una respuesta actual recuperada. Por tanto, no se puede afirmar que el dominio tenga o no tenga registros A, que mantenga determinados servidores de nombres, que el sitio responda, que existan certificados vigentes o que sus direcciones pertenezcan a AS210328.

Además, una web puede estar alojada en un proveedor externo, una CDN o una plataforma de terceros. Un dominio operativo demostraría presencia web, no necesariamente que el operador controle el ASN, posea la infraestructura subyacente o entregue cargas de trabajo de clientes. Del mismo modo, un certificado prueba control o autorización sobre un nombre en un momento determinado, pero no la existencia de una plataforma de nube.

La cuarta capa es la más difícil: demostrar el servicio

Para describir una nube operativa haría falta evidencia atribuible al sujeto y suficientemente actual. La evidencia podría incluir documentación técnica accesible, endpoints de servicio, interfaces de aprovisionamiento, rangos de direcciones relacionados de forma verificable, instalaciones anunciadas, registros de clientes o mediciones independientes de una plataforma en funcionamiento. Una entrada autogestionada en PeeringDB podría aportar declaraciones sobre política, instalaciones o contactos, pero seguiría siendo información declarada por el operador y no una medición independiente. La fuente candidata es la consulta de PeeringDB para AS210328.

La cadena probatoria debe ser explícita. Primero, debe establecerse qué identidad administrativa existe. Después, debe verificarse si esa identidad aparece en rutas observables. Luego, debe determinarse si el dominio, sus direcciones, certificados y servicios se conectan con esa identidad. Finalmente, debe demostrarse que lo observado corresponde a una oferta de nube funcional y no solo a una página corporativa, un dominio aparcado, un servicio de correo o infraestructura de terceros.

Qué puede decirse ahora

La evidencia preservada permite formular una conclusión limitada: el expediente contiene fuentes públicas adecuadas para investigar la continuidad y el despliegue de una posible identidad de red asociada con almazcloud.network y AS210328, pero la recuperación actual no conservó los valores de esas fuentes. No se verificó en este paso ningún valor actual de rutas, prefijos, vecinos, DNS, web, certificados, alojamiento o servicio de nube.

Esa limitación importa porque “no recuperado”, “recuperado con resultado negativo” y “observado positivamente” son estados distintos. Confundirlos convertiría una falla de recopilación en una afirmación sobre la operación de una empresa. También sería incorrecto conectar el dominio con el ASN sin una correspondencia independiente entre las capas. La investigación futura debería conservar cada respuesta con su hora de recuperación, fuente, punto de observación y relación exacta con el sujeto.

La pregunta pública útil no es si un número o un dominio existe en algún registro. Es qué combinación de observaciones fechadas demostraría que la identidad administrativa se convirtió en una red visible y que esa red respalda un servicio de nube atribuible. Hasta que esa combinación exista, la descripción más precisa es la de una hipótesis operativa pendiente de verificación.