Resumen

  • El registro de AS210328, una posible ruta BGP, la delegación DNS, un certificado o una página web serían evidencias de capas diferentes; ninguna sustituye por sí sola a las demás.
  • El expediente de esta investigación no recuperó respuestas actuales de HTTP, DNS ni de los servicios de observación. La huella operativa independiente de almazcloud.network permanece, por tanto, indeterminada.

La identidad no es todavía una operación

El punto de partida es administrativo. Los registros de RIPE pueden mostrar si AS210328 sigue inscrito, qué nombre, organización, contactos, mantenedores o políticas aparecen asociados y cuándo se modificó el objeto. El registro RDAP y la búsqueda de la base de datos son fuentes adecuadas para esa pregunta, pero en esta ejecución no se recuperó su contenido actual: RDAP del AS210328 y búsqueda de RIPE Database.

Incluso una asociación explícita entre el ASN y AlmazCloud probaría una relación de registro, no que el sistema autónomo esté originando tráfico ni que la organización opere una plataforma para clientes. Los datos de contacto pueden estar desactualizados, protegidos por privacidad o mantenidos por un tercero. La primera conclusión debe ser estrecha: una identidad registrada es una condición administrativa, no una medición de actividad.

El siguiente eslabón es la intención de enrutamiento. Una consulta inversa de objetos route y route6 puede mostrar prefijos cuyo origen declarado es AS210328: objetos de ruta de RIPE. Pero un objeto IRR expresa una intención o autorización registrada. No demuestra que el prefijo se anuncie ahora. Para probar visibilidad independiente habría que contrastar esa intención con el resumen de RIPEstat, la lista de prefijos anunciados y el estado de enrutamiento.

La diferencia importa. Un ASN puede tener un objeto de ruta sin que exista una ruta visible en los colectores. También puede existir un anuncio sin que el objeto correspondiente esté en la base consultada. Un resultado positivo de RIPEstat sería una observación de routing en un momento concreto, no una prueba automática de que almazcloud.network sirve desde ese ASN ni de que hay clientes detrás de él.

Qué tendría que demostrar una huella de routing

La continuidad operativa comienza a ser plausible cuando varias observaciones independientes convergen. El estado BGP puede mostrar rutas y caminos observados por colectores: BGP State de RIPEstat. Los vecinos ASN pueden aportar indicios de tránsito, upstreams o adyacencias: ASN Neighbours. La historia de routing puede separar una red nunca observada de una red que anunció prefijos y después los retiró: historial de routing. Los cambios recientes pueden mostrar actividad, aunque una ráfaga de anuncios también puede ser inestabilidad y la ausencia de actualizaciones no implica inactividad: actualizaciones BGP.

La corroboración entre medidores reduce el riesgo de confundir una caché, una clasificación histórica o una diferencia de cobertura con una operación actual. BGP.Tools y el BGP Toolkit de Hurricane Electric ofrecen perspectivas independientes sobre prefijos, pares y upstreams. El expediente no contiene las respuestas actuales de esas páginas. Por ello, no es válido convertir la mera existencia de esas fuentes en una afirmación de que AS210328 anuncia hoy una red.

También hay una distinción entre aparecer dentro de un camino AS y originar el prefijo de destino. Un camino que contiene AS210328 no basta: hay que verificar su posición de origen, el prefijo exacto, la hora de observación y la presencia del mismo resultado en varios colectores. Para un proveedor cloud, además, habría que establecer qué función cumple el prefijo: frontend, tránsito, infraestructura de gestión, servicio de clientes o simplemente una relación histórica.

El dominio añade dependencias, no una respuesta única

El dominio introduce otra cadena. La consulta de ICANN puede establecer la situación registral, el registrador, los estados, las fechas y los servidores de nombres de almazcloud.network: lookup de ICANN. Eso no demuestra que el dominio resuelva hoy, que el sitio responda por HTTPS o que el ASN registrado controle el servicio que aparece bajo el nombre.

La respuesta A puede aportar direcciones IPv4, alias y TTL; la respuesta AAAA puede mostrar una superficie IPv6. Esas comprobaciones están separadas en Google Public DNS A y Google Public DNS AAAA. Para conectar el dominio con AS210328 habría que comparar las direcciones devueltas con prefijos actualmente originados por ese ASN. Si las direcciones pertenecen a otro operador, la explicación podría ser CDN, proxy inverso, alojamiento externo o una arquitectura de backend no visible desde el dominio. Ninguna de esas posibilidades puede resolverse aquí porque no se recuperaron las respuestas DNS.

Los registros NS muestran quién aloja la autoridad DNS; los MX pueden revelar una dependencia de correo; TXT puede contener políticas SPF, verificaciones de dominio o referencias a proveedores; CAA puede indicar qué autoridades están autorizadas a emitir certificados. Son piezas de una arquitectura, no pruebas equivalentes de prestación cloud: NS, MX, TXT y CAA. Una delegación a un proveedor externo no contradice que exista una operación propia, y un registro que permanezca publicado tampoco demuestra uso continuado.

Un segundo recorrido de la cadena DNS y un análisis DNSSEC podrían corroborar delegación, alias, validación y direcciones desde otras perspectivas: RIPEstat DNS Chain y DNSViz. Aun así, una cadena DNS válida no equivale a una respuesta HTTP, una sesión TLS correcta ni una aplicación disponible para clientes.

De la página web al servicio cloud

El sitio raíz sería el puente más visible entre nombre y producto, pero no necesariamente el más fuerte. Una captura de la página puede mostrar una descripción comercial, un formulario o una interfaz; no prueba que exista una plataforma de cómputo, almacenamiento, red virtual o flujo de facturación detrás. La fuente directa del sitio está identificada aquí: almazcloud.network. En esta investigación no se obtuvo su respuesta HTTP.

La transparencia de certificados puede aportar nombres de host y fechas de emisión; los servicios de Cert Spotter y crt.sh pueden ayudar a reconstruir una presencia histórica: Certificate Transparency en crt.sh y Cert Spotter. SSL Labs puede informar sobre una configuración TLS observada, mientras que urlscan, Internet Archive, Censys y Shodan pueden aportar huellas de exploración, capturas, histórico o exposición de servicios.

Pero cada fuente tiene una semántica distinta. Un certificado muestra que una autoridad emitió una credencial para un nombre, no quién opera el servicio ni si el servicio sigue disponible. Una captura histórica prueba que una respuesta existió en una fecha, no que el endpoint continúe funcionando. Un resultado de escaneo muestra una observación desde un punto y momento concretos, no necesariamente una oferta cloud para clientes. El expediente no recuperó los contenidos actuales de esas fuentes y, por tanto, no permite seleccionar entre presencia actual, rastro histórico, dependencia externa o ausencia de respuesta.

La prueba decisiva sería un flujo, no un logotipo

Incluso una cadena completa de registro, ruta, DNS, TLS y HTTP dejaría abierta la pregunta comercial. Para sostener que existe un servicio cloud habría que identificar una superficie funcional: por ejemplo, autenticación, creación de recursos, API, documentación operativa, soporte, límites de uso, facturación o evidencia de clientes. Cada elemento debe atribuirse a la fuente que realmente lo observa.

El mecanismo de continuidad que esta investigación propone es concreto: registrar la identidad administrativa; medir anuncios BGP y su origen; resolver DNS desde más de un punto; mapear las direcciones a sus prefijos y ASN; verificar TLS y HTTP; identificar la superficie de aplicación; y repetir las observaciones con marcas de tiempo. Un único resultado positivo prueba presencia en un instante. Una prueba fallida sólo demuestra que ese intento no obtuvo un resultado. La continuidad requiere observaciones repetidas y coherentes desde varias perspectivas.

El mismo principio evita dos errores opuestos. No debe llamarse “nube operativa” a una identidad administrativa adornada con un dominio. Tampoco debe llamarse “red inexistente” a un objeto que no pudo medirse en una ejecución sin respuestas actuales. La conclusión responsable es más limitada: las fuentes necesarias para comprobar la cadena están identificadas, pero la cadena no fue verificada aquí.

Qué se puede afirmar ahora

La investigación añade una estructura de prueba que no estaba en la cobertura anterior: separa la organización registral, la intención de routing, la observación BGP, la delegación DNS, la dirección de endpoint, la capa TLS/HTTP y el flujo de servicio. También identifica las dependencias que pueden romper una inferencia: un registro mantenido por terceros, un prefijo anunciado por otra entidad, un CDN, un proveedor DNS externo, certificados históricos o una página que no expone la infraestructura real.

Lo que no puede afirmarse con este expediente es igualmente importante. No hay una medición actual de prefijos, una respuesta DNS recuperada, una asignación comprobada entre las direcciones del dominio y AS210328, una respuesta HTTP verificada, una actividad reciente de certificados confirmada ni un endpoint cloud observado. La huella operativa independiente permanece indeterminada.

El próximo control útil no es repetir la afirmación de que AS210328 está registrado. Es ejecutar una medición fechada que publique, por cada capa, el resultado observado, la fuente, el punto de observación y la hora. Sólo entonces será posible decir si la identidad administrativa se convirtió en una operación de red; y sólo después de probar el flujo funcional podrá hablarse de un servicio cloud para clientes. La información sobre participantes y relaciones de red también puede contrastarse con PeeringDB, aunque esta fuente tampoco fue recuperada en vivo durante esta ejecución.