Resumen

  • El nombre Macrohosting conecta a través de LACNIC, CABASE y el sitio web del proveedor con Nicolas Lagunas Turczyn y una operación de hosting argentina. Las páginas públicas revisadas no identifican una contraparte incorporada separada ni un número fiscal, por lo que un comprador aún necesita la identidad contractual exacta.
  • AS265694 estaba originando visiblemente una asignación IPv4 de 1,024 direcciones a través de tres anuncios de ruta superpuestos el 15 de julio de 2026. Los 326 colectores IPv4 incluidos lo vieron, y las rutas observadas eran válidas RPKI; esta es una evidencia de red significativa, no una prueba de tiempo de actividad de aplicaciones, propiedad del servidor o calidad de respaldo.
  • Un cliente puede seleccionar hosting, VPS, correo electrónico, dominios y servicios gestionados a través de un portal de cuenta en vivo. Sin embargo, el texto de seguridad genérico, el texto de testimonio de muestra, una base de conocimiento pública vacía y una ruta de estado que lleva al inicio de sesión hacen que la capa de garantía pública sea más débil que la capa de pedido.
  • El registro argentino, los puntos de contacto en Buenos Aires y la presencia en AR-IX no establecen la residencia de datos. Las adquisiciones deben vincular cada servicio a una contraparte legal, instalación, red de origen, ubicación de respaldo, programa de soporte, objetivo de restauración y recurso antes de tratar la marca como garantía operativa.

El nombre se une a través de varios registros, pero no a un contrato completo

Laentrada del directorio de BTWcomienza con una cadena de identidad inusual: el nombre completo de una persona seguido de la marca Macrohosting entre paréntesis. Esa forma no es meramente una convención del directorio.El registro de LACNIC para AS265694nombra al registrante como Nicolas Lagunas Turczyn(MACROHOSTING), identifica a Nicolas Lagunas Turczyn como el contacto administrativo, técnico y de abuso, y registra la asignación del sistema autónomo el 31 de marzo de 2017.

Hay uniones útiles fuera del registro de números. Elsitio web de Macrohostingpublica una dirección de contacto en Buenos Aires y un número de teléfono que termina en 3147-0978. El número coincide con el número central en el registro de LACNIC, a pesar de las diferencias en el formato. CABASE, la cámara de internet argentina,lista a Lagunas Turczyn Nicolas (Macrohosting)entre sus miembros en hosting y housing. Juntos, esos registros respaldan una conclusión razonable de que la persona, la marca, el sitio web y el registro de red pertenecen a la misma superficie operativa.

Los límites son igualmente importantes. LACNIC está registrando la responsabilidad por los recursos de internet; no está certificando una empresa constituida, beneficiario final, condición financiera o autoridad para hacer cada promesa comercial en el sitio web. El aviso legal del sitio da el nombre de Macrohosting, dirección, teléfono y correo electrónico de contacto, pero la página revisada no menciona una forma legal, identificador fiscal o número de registro. El sitio web ahora da una dirección en Avenida de los Lagos, mientras que el registro de LACNIC da Avenida Gaona.

Un cambio de dirección, locales comerciales separados o un registro más antiguo podrían explicar la diferencia. La evidencia pública no elige entre esas explicaciones.

Eso significa que la marca es rastreable sin ser aún completa en términos contractuales. Un cliente empresarial debería pedir que el formulario de pedido y la factura indiquen el nombre legal, número fiscal, dirección de notificación y la persona autorizada para vincular al proveedor. También debería decir si Nicolas Lagunas Turczyn está contratando como individuo, a través de una empresa, o en nombre de otra entidad. Esto no es papeleo ajeno a la confiabilidad. La respuesta determina quién debe devolver datos, emitir créditos, responder a un aviso legal y financiar la restauración después de un incidente grave.

Un catálogo ordenable es evidencia de un servicio, no de cada promesa

El escaparate de Macrohosting es conciso. Ofrece hosting compartido con 20 GB de almacenamiento, cPanel, Imunify360 y SSL incluido, además de dos configuraciones de hosting más grandes descritas con núcleos virtuales, memoria, almacenamiento, CloudLinux y DirectAdmin. Los botones de pedido llevan a unportal de administración de clientesseparado que expone categorías para hosting web, VPS, correo corporativo, servicios gestionados, dominios, seguridad del sitio y soporte. Los clientes pueden elegir entre dólares estadounidenses y pesos argentinos, crear una cuenta, realizar un pedido y acceder a un área de soporte orientada a tickets.

Esta es una capa de automatización reconocible. La selección de productos, moneda, registro, pedido y acceso a la cuenta se han trasladado al software. Para una pequeña empresa que compra hosting web, esto puede eliminar varios intercambios manuales antes de que comience el servicio. También crea un registro del plan seleccionado y un canal para solicitudes posteriores. Por lo tanto, el catálogo es una evidencia más sólida que una página estática que solo dice que los servicios en la nube están disponibles.

Pero la automatización no resuelve lo que sucede después del pago. Las páginas públicas revisadas no indican un plazo de aprovisionamiento, política de contención de recursos, ventana de mantenimiento, programa de respaldo, objetivo de restauración o objetivo numérico de respuesta de soporte. Un conteo de núcleos virtuales dice cómo se empaqueta un plan, no cómo se programa el tiempo de CPU bajo carga. El SSL incluido dice poco sobre el manejo de fallos de renovación.

Los nombres de los productos de seguridad identifican componentes, pero no establecen configuración, monitoreo, responsabilidad de parches o compensación después de un incidente.

El portal también ofrece motivos de precaución. Su página de inicio dice que más de 35,000 clientes confían en el servicio y muestra una garantía de tiempo de actividad del 100 por ciento. Alrededor de esas afirmaciones hay descripciones genéricas de SiteLock, nombres de muestra y texto de testimonio lorem ipsum repetido. El área de anuncios públicos muestra el mensaje estándar agradeciendo al usuario por elegir WHMCS. Esos elementos parecen contenido de tema de proveedor inacabado en lugar de evidencia específica de la empresa.

No prueban que el servicio sea malo; significan que las afirmaciones afectadas no pueden usarse responsablemente para probar que es bueno.

Esta distinción es importante en la adquisición de software empresarial. Un sistema de facturación y cuentas funcional prueba que las transacciones se pueden automatizar. No prueba que las políticas operativas detrás de los botones estén completas. Los compradores deben solicitar una descripción del servicio que convierta cada característica visible en una obligación comprobable: cuándo estará disponible el recurso, qué límite aplica, cómo se mide el uso, qué registros se pueden exportar, qué historial de cambios se conserva y cómo una acción automatizada fallida llega a un operador humano.

AS265694 es la evidencia operativa más sólida

El registro de red es más concreto que el lenguaje de garantía. LACNIC asignó directamente170.78.136.0/22a Nicolas Lagunas Turczyn(MACROHOSTING) el 28 de septiembre de 2016. El bloque va de 170.78.136.0 a 170.78.139.255, un total de 1,024 direcciones IPv4. La misma persona nombrada figura como responsable administrativo, técnico y de abuso.

Para el 15 de julio de 2026, lavista de enrutamiento de RIPEstatmostraba a AS265694 originando activamente ese espacio de direcciones. El sistema era visible para todos los 326 pares IPv4 incluidos en la respuesta. RIPEstat contó tres anuncios IPv4, ningún anuncio IPv6 y dos vecinos observados. El historial de origen actual se remontaba al 1 de julio de 2017.

Las tres rutas necesitan una lectura cuidadosa. El operador anunció la cobertura 170.78.136.0/22 y las dos mitades más específicas, 170.78.136.0/23 y 170.78.138.0/23. Esas rutas se superponen; no suman 2,048 direcciones distintas. El espacio asignado y originado sigue siendo de 1,024 direcciones IPv4.El historial de prefijos de RIPEstatmostró los tres continuamente presentes durante la ventana de observación del 1 al 15 de julio. La validación de origen de ruta devolvió válida para el bloque de cobertura y ambos /23 bajo una autorización de ruta que permite longitudes hasta /24.

Esa es una evidencia valiosa. La red no está representada solo por un registro inactivo. Sus prefijos se estaban propagando ampliamente, y un control de autorización de origen estaba en su lugar. Un cliente puede monitorear el ASN y las rutas independientemente de la página de marketing del proveedor. Un informe de abuso también tiene una ruta de contacto con nombre en el registro de autoridad.

La evidencia aún tiene un límite. Una ruta visible no puede revelar si un sitio web, buzón de correo o VPS en particular utiliza estas direcciones. No mide pérdida de paquetes, latencia, capacidad disponible, disponibilidad del servidor o respuesta a incidentes. La validación RPKI autoriza el origen; no autentica cada ruta ni protege una aplicación de fallos. La ausencia de un anuncio IPv6 observado es relevante para un comprador que requiere IPv6 nativo, pero debe confirmarse con el producto solicitado en lugar de convertirse en una afirmación sobre cada red privada o de socios que el proveedor pueda usar.

La presencia en AR-IX añade una pista de interconexión local

Macrohosting también mantiene unperfil de red en PeeringDBpúblico. El registro describe AS265694 como una red empresarial con alcance sudamericano, tráfico mayoritariamente de salida y una política de peering abierta. Se actualizó en marzo de 2026. Su registro de intercambio lista un puerto IPv4 operativo en AR-IX CABASE, con una velocidad declarada de 10 Gbps y participación en el servidor de rutas.

Esa presencia en el intercambio ayuda a explicar el papel local de la red. Conectarse en AR-IX puede proporcionar una ruta directa a otros participantes en lugar de enviar cada paquete a través de tránsito ascendente. Combinado con la membresía de CABASE y las rutas activas, es una señal convincente de que Macrohosting participa en el ecosistema de internet de Argentina en lugar de simplemente revender un escaparate extranjero bajo un nombre local.

La información de PeeringDB son datos de directorio mantenidos por operadores e intercambios, sin embargo, no es una auditoría de tráfico. Un puerto de intercambio de 10 Gbps no significa que cada cliente reciba 10 Gbps, que el puerto no esté congestionado en horas pico o que todos los destinos lo utilicen. Tampoco dos vecinos de enrutamiento observados establecen fibra físicamente diversa, edificios separados o energía independiente. La pregunta de adquisición no es simplemente si hay más de una conexión nombrada.

Es si el servicio solicitado tiene rutas cuyos modos de falla son suficientemente independientes, monitoreados y cubiertos por un acuerdo de escalamiento.

Un programa de red útil nombraría el prefijo del servicio y el ASN de origen, el puerto del cliente o límite de conformación, disponibilidad de IPv6, upstreams primarios y alternativos, dependencias de intercambio, manejo de DDoS y la evidencia utilizada para medir la disponibilidad. También debería decir quién contacta a CABASE, un upstream o una instalación cuando la falla está fuera del equipo de Macrohosting. Los registros de recursos públicos identifican la red. El programa identificaría el servicio que el cliente realmente está comprando de ella.

La evidencia de red argentina no resuelve la ubicación de los datos

Casi todas las pistas de identidad pública apuntan a Argentina: el país LACNIC, los contactos en Buenos Aires, la membresía de CABASE, el alcance sudamericano de PeeringDB y la conexión AR-IX. Aún así, sería inseguro inferir que todos los datos de los clientes permanecen en Argentina.

Las páginas públicas revisadas no nombran un centro de datos, operador de instalación, ciudad para los servidores, sitio de respaldo o subprocesador en la nube. No dicen si el hosting compartido, VPS, correo electrónico y servicios gestionados usan la misma infraestructura. La presencia en el intercambio describe dónde se interconectan las redes; no localiza un disco. Una dirección IP originada localmente puede servir una carga de trabajo en un lugar mientras los datos de la cuenta, archivos adjuntos de tickets, DNS, telemetría de seguridad o copias de respaldo se procesan en otro lugar.

La escasa página de privacidad agudiza el problema. No ofrece una explicación pública de categorías de datos, procesadores, retención, transferencias internacionales o eliminación. Para un individuo que compra un sitio web de bajo riesgo, eso puede ser una razón para hacer una pregunta breve. Para una empresa que maneja datos de empleados, clientes o regulados, es una parte faltante de la especificación del servicio.

Por lo tanto, la localidad debe mapearse por clase de datos. El cliente necesita la ubicación primaria y de recuperación para archivos alojados, bases de datos, buzones de correo, instantáneas y copias de respaldo. También necesita ubicaciones y reglas de retención para la identidad de la cuenta, facturas, mensajes de soporte, registros de acceso, monitoreo y hallazgos de malware. Si un servicio de seguridad, panel de control, DNS o pago de terceros recibe datos, su función debe indicarse. Solo entonces un proveedor argentino y una red argentina pueden convertirse en una posición de residencia basada en evidencia.

El soporte existe como canal; la responsabilidad necesita términos de servicio

Macrohosting expone varias formas de iniciar una conversación. El sitio principal tiene un formulario de contacto y número de teléfono. El portal tiene un formulario de contacto público, registro e inicio de sesión, además de entradas de menú para tickets, anuncios, una base de conocimiento y estado de la red. Esos elementos muestran que el soporte al cliente es parte del servicio previsto, no una ocurrencia tardía totalmente ausente.

Lo que no muestran es el compromiso laboral detrás de la interfaz. La base de conocimiento no devolvió artículos públicos durante la revisión. La ruta de estado de la red llevaba a un inicio de sesión de cliente en lugar de un historial de componentes público. Las páginas revisadas no revelaron horarios de soporte, niveles de gravedad, objetivos de reconocimiento, objetivos de restauración, contactos de escalamiento o soluciones para interrupciones. Un botón de ticket puede organizar solicitudes, pero no puede por sí mismo garantizar que el ingeniero adecuado responda antes de que expire la ventana de recuperación del cliente.

Aquí es donde un proveedor más pequeño puede crear o perder valor frente a una alternativa de hiperescala. Un operador local puede ofrecer idioma directo, contexto local y acceso a alguien que entienda tanto el servidor como la red. Esas ventajas son operativas solo cuando las personas, los horarios y la autoridad son reales. El cliente debe saber quién vigila la plataforma fuera del horario laboral, quién puede cambiar una ruta, quién puede restaurar una copia de respaldo, quién puede aprobar el acceso de emergencia y quién se comunica cuando una dependencia falla.

La responsabilidad de las copias de respaldo merece su propia línea. Ningún documento público revisado establece que cada plan incluya copias de respaldo, con qué frecuencia se realizan, cuánto tiempo se conservan o si se prueba la restauración. La capacidad de almacenamiento en un plan no es una promesa de recuperación. Un comprador debe asumir que la responsabilidad sigue sin resolverse hasta que un pedido indique el punto de recuperación, tiempo de recuperación, ubicación de la copia, disposición de cifrado, período de retención y cadencia de prueba de restauración.

Convierta la huella pública en un paquete de garantía

Macrohosting tiene más sustancia operativa de lo que su escaso escaparate sugiere inicialmente. La persona y la marca aparecen en registros de recursos de autoridad. El bloque IPv4 está asignado directamente. El sistema autónomo tiene un origen de ruta longevo y globalmente visible, autorización de origen válida, dos vecinos observados y una entrada operativa en AR-IX. Esos son hechos útiles e inspeccionables de forma independiente.

El siguiente paso no es exigir un sitio web más grande. Es hacer que el registro comercial sea tan preciso como el registro de red. Antes de colocar una carga de trabajo de producción, un comprador debe obtener un documento que nombre la contraparte legal y vincule el plan seleccionado con su instalación, rango de direcciones, ASN de origen, modelo de upstream y límites de recursos del cliente. Debe definir mantenimiento, monitoreo, gravedad de incidentes, cobertura de soporte, escalamiento, restauración, créditos y asistencia para la terminación.

Un segundo programa debe mapear datos y recuperación. Debe localizar datos primarios, copias de respaldo, registros de cuenta, tickets y telemetría de seguridad; identificar subprocesadores; establecer reglas de retención y eliminación; y registrar una ruta de exportación y restauración probada. Un tercero debe asignar trabajo humano: quién parchea el sistema operativo, renueva certificados, vigila el agotamiento de recursos, responde a alertas de malware, cambia rutas y contacta a proveedores externos.

Ese paquete no reemplazaría el valor de la evidencia de red pública de Macrohosting. Dejaría que la evidencia haga su trabajo adecuado. AS265694 prueba un rol operativo visible en internet. El catálogo prueba que los servicios se pueden solicitar. Las superficies de contacto prueban que se pueden enviar solicitudes. La garantía operativa comienza cuando esos hechos se unen a respuestas ejecutables y específicas del producto sobre identidad, control, localidad, recuperación y respuesta humana.