Resumen
- La identidad de registro público es real. Lavisión general del AS de RIPEstat para AS202019identifica a
BODEGA-HOSTING Eric Kelderman trading as Bodega ICT, y elobjeto aut-num de AS202019 en la base de datos de RIPEenumeraBODEGA-HOSTING, la organización ORG-BH128-RIPE, la organización patrocinadora ORG-ABTA6-RIPE, la política de importación/exportación con AS44854 y AS56393, y la creación el 23 de enero de 2026. - El registro de la organización también es específico. Una búsqueda en la base de datos de RIPE paraBodega ICTdevuelve ORG-BH128-RIPE, con el nombre de la organización
Eric Kelderman trading as Bodega ICT, la direcciónSakuralaan 13, Almere, el país NL, el correo electrónico[email protected], el contacto de abuso ACRO63211-RIPE y la última modificación el 13 de mayo de 2026. - El enrutamiento público actual está ausente. Elestado de enrutamiento de RIPEstat para AS202019no muestra anuncios IPv4 ni IPv6 visibles y ningún vecino observado el 12 de julio de 2026;los prefijos anunciados de RIPEstatdevuelve cero prefijos actuales. Sí muestra visibilidad histórica de IPv4, con primera aparición de 185.39.216.0/22 en 2015 y última aparición de 95.181.220.0/22 en 2022, antes del estado actual del objeto de registro de 2026.
- El único objeto actual de política de enrutamiento en la vista de consistencia de RIPEstat no está activo. Laconsistencia de enrutamiento AS de RIPEstatenumera 2001:678:11b0::/48 como presente en whois pero no en BGP, y enumera las políticas de importación/exportación de AS44854 y AS56393 como presentes en whois pero no en BGP.
- La calificación de evidencia es Negativa para la operación de red actual. Bodega ICT tiene una identidad de registro real, pero no hay visibilidad de ruta pública actual de AS202019, ningún prefijo de cliente visible actual, ninguna observación de vecino activo, ningún sitio de producto que se resuelva en sus dominios de identidad probables y ninguna evidencia pública de instalaciones, soporte, racks, respaldos o migración que respalde tratarlo como capacidad hospedada activa.
El nombre dice hosting, la tabla de enrutamiento dice que todavía no
La forma útil de interpretar HOSTING Eric Kelderman trading as Bodega ICT es separar la identidad de la operación. La capa de identidad es clara. Los registros de RIPE asocian AS202019 con BODEGA-HOSTING y con Eric Kelderman trading as Bodega ICT en los Países Bajos. El registro es reciente. Tiene estructura de patrocinio y mantenedores. Tiene una organización y dirección con nombre. Tiene políticas de importación y exportación. Tiene un prefijo IPv6 registrado en whois. Esos detalles son suficientes para que la entidad merezca ser rastreada en un directorio de infraestructura.
La capa operativa es mucho más débil. RIPEstat no ve que AS202019 anuncie nada el 12 de julio de 2026. No ve un prefijo IPv4. No ve un prefijo IPv6. No ve un vecino. La vista de prefijos anunciados está vacía. La vista de consistencia ve un /48 IPv6 en whois pero no en BGP. Esa combinación no es una red de hosting activa en la tabla de enrutamiento pública. Es una huella de registro y política que puede estar preparándose para el servicio, preservando una identidad o esperando activación.
Esa distinción importa porque las fallas de infraestructura se reparan en la capa operativa, no en la capa de nombres. Un objeto de registro puede enumerar un AS, pero una interrupción del cliente depende de las sesiones de ruta, los puertos de upstream, el acceso al router, la energía, los armarios, los servidores, el soporte y los contratos. Si el AS no es visible, un cliente no puede depender de él para la alcanzabilidad. Si los dominios visibles están alojados en otro lugar, la superficie web pública no prueba que Bodega ICT opere infraestructura de cliente detrás de AS202019.
La tentación en un programa de cobertura de empresas es tratar a cada titular de AS como un proveedor activo. Eso exageraría este caso. Bodega ICT puede convertirse en una red activa. Puede tener clientes privados o infraestructura no pública. Puede usar alojamiento de terceros mientras prepara su propio AS. Pero la evidencia pública disponible ahora no respalda la afirmación de que AS202019 esté transportando capacidad hospedada en producción.
La conclusión correcta es, por lo tanto, limitada: Bodega ICT tiene una identidad de recursos de numeración RIPE reciente, pero la internet pública actualmente no muestra que esa identidad esté entregando servicio enrutado. Los compradores deben solicitar evidencia de ruta actual, términos de servicio y prueba de instalaciones antes de tratar el nombre como un proveedor de hosting operativo.
RIPE identifica la entidad, pero no una plataforma en funcionamiento
Losdatos whois de RIPEstat para AS202019enumeran el aut-num 202019, nombre del ASBODEGA-HOSTING, organización ORG-BH128-RIPE, organización patrocinadora ORG-ABTA6-RIPE, importación desde AS44854, exportación hacia AS44854, importación desde AS56393, exportación hacia AS56393, contactos administrativos y técnicoseric800yERIC800, estado ASSIGNED, y creación el 23 de enero de 2026. Elobjeto aut-num de la base de datos de RIPEmuestra la misma estructura.
Elresultado de búsqueda de RIPE para Bodega ICTproporciona el registro de la organización. Nombra aEric Kelderman trading as Bodega ICT, da la dirección Sakuralaan 13, Almere, país NL, correo electrónico[email protected], contacto de abuso ACRO63211-RIPE, mantenedornl-eritap-1-MNT, creación el 20 de enero de 2026 y última modificación el 13 de mayo de 2026. Esta no es una entrada de directorio secundaria vaga. Es el objeto oficial de la base de datos de RIPE que ancla la identidad de recursos de numeración de la entidad.
Los objetos de política sugieren proveedores upstream previstos. AS44854 y AS56393 están listados en las políticas de importación y exportación. Lavista de consistencia de enrutamiento AS de RIPEstat para AS202019enumera esos pares como presentes en la política whois pero no en BGP. Esa es una señal útil del estado planificado. No es evidencia de conectividad activa en el momento de la consulta. La política puede existir antes de que los circuitos se activen, después de que se retiren o mientras las sesiones son demasiado limitadas para aparecer en la vista del colector público.
La misma vista de consistencia enumera 2001:678:11b0::/48 como presente en whois pero no en BGP. En otras palabras, hay al menos un objeto de ruta o asignación IPv6 en los datos del registro, pero no es visible como una ruta anunciada por AS202019 en la vista de RIPEstat. Para un cliente, la pregunta práctica es si IPv6 está activo, planificado, sin usar o asignado solo para servicio futuro. La respuesta pública el 12 de julio de 2026 es: no visiblemente enrutado.
Los datos históricos de RIPEstat añaden matices. La vista de estado de enrutamiento dice que AS202019 se vio por primera vez con 185.39.216.0/22 en 2015 y por última vez con 95.181.220.0/22 en 2022. Sin embargo, el objeto aut-num actual de RIPE se creó en enero de 2026. Los números de AS pueden ser reasignados, reutilizados, patrocinados de manera diferente o reinscritos con el tiempo. Eso significa que la visibilidad histórica de prefijos no debe tratarse como prueba de que la entidad Bodega ICT actual está transportando esas rutas antiguas.
La verificación operativa actual debe centrarse en la visibilidad presente, y esa visibilidad está vacía.
Los dominios apuntan a alojamiento de terceros, no a AS202019
La evidencia de los dominios refuerza el grado operativo débil. El dominiobodega.nlresuelve, pero la página web es un marcador de posición de alojamiento predeterminado: "Welcome to the home of bodega.nl" y "To change this page, upload your website into the public_html directory," con una fecha de creación mostrada en la página. Rutas como/hosting,/contact,/diensteny/ictdevolvieron respuestas 404 en las comprobaciones locales. Eso no es un sitio de producto activo para un proveedor de hosting. Es una página alojada por defecto.
El DNS debodega.nlapunta a infraestructura de alojamiento de terceros. El registro A en las comprobaciones locales era 185.104.29.66, el registro AAAA era 2a06:2ec0:1::111, los servidores de nombres eranns.zxcs.eu,ns.zxcs.beyns.zxcs.nl, y el destino MX eramail.bodega.nl. El registro SPF incluía el rango 185.104.29.0/24, la dirección 185.104.29.66, la dirección web IPv6 y el filtrado de correo de ZXCS. Esa evidencia apunta a infraestructura de alojamiento compartido estilo ZXCS, no a una plataforma de cliente AS202019 visible.
El dominio de identidad probablebodegaict.nltambién apunta lejos de AS202019. Las comprobaciones DNS locales mostraron registro A 2.57.91.91, registro AAAA 2a02:4780:84::32, servidores de nombresns1.dns-parking.comyns2.dns-parking.com, registros MX de Google e includes SPF para el correo de Hostinger y Google. Ese es un patrón común de dominio aparcado o alojado por terceros. Respalda la existencia de una superficie de correo electrónico e identidad. No respalda la afirmación de que Bodega ICT aloje su propio sitio público o servicios de cliente en su AS asignado.
Las variantes inactivas debodega-ict.nlno proporcionaron una superficie de sitio más fuerte en las comprobaciones DNS locales. Eso importa porque el sitio web propio de un pequeño proveedor es a menudo la primera prueba pública de los términos de servicio, el contacto de soporte, el menú de productos, la política de uso aceptable, el SLA, la página de estado, el portal de tickets y el lenguaje de migración del cliente. Aquí, la evidencia de dominio público da pistas de identidad y alojamiento de terceros, pero no una oferta de capacidad hospedada.
Esto no significa que Bodega ICT no tenga clientes. Muchos operadores pequeños atienden a clientes por referencia, contrato directo, portal privado o acuerdo de revendedor. Algunos mantienen su sitio público mínimo mientras operan infraestructura real. Pero la cobertura pública no puede asumir eso. Si el sitio visible es un marcador de posición y el AS asignado no está anunciando, la conclusión editorial tiene que ser conservadora.
Qué tendría que ser cierto para que hubiera capacidad hospedada
Para que Bodega ICT fuera un proveedor de capacidad hospedada activo en el sentido relevante para esta serie de cobertura, varias cosas tendrían que probarse. Primero, AS202019 u otro AS claramente identificado necesitaría originar prefijos relevantes para los clientes. Segundo, el proveedor necesitaría mostrar dónde se ejecutan realmente los servidores, el almacenamiento o la infraestructura virtual. Tercero, los clientes necesitarían soporte, respaldo, facturación y términos de migración. Cuarto, un comprador necesitaría saber si Bodega ICT controla la capa física o solo intermedia el servicio de otro host.
La evidencia pública actual no satisface esas pruebas. AS202019 no tiene prefijos visibles. Los dominios de Bodega usan superficies de alojamiento de terceros. Las páginas web públicas revisadas no describen niveles de producto, ubicaciones de centros de datos, canales de soporte, términos, historial de estado, copias de seguridad o derechos de exportación del cliente. Los registros de registro de RIPE no nombran una instalación. La vista de consistencia no muestra sesiones de upstream activas. PeeringDB y los directorios de rutas públicas no proporcionan un perfil de instalación o peering que pueda llenar el vacío.
Eso deja una distinción estrecha pero importante. Un AS inactivo o en preparación todavía puede ser evidencia útil para monitoreo futuro, porque le dice a los observadores qué recurso verificar si aparece un lanzamiento de servicio. No es evidencia útil para la dependencia actual del cliente. Un cliente que compra hosting hoy necesita una dirección que enrute, un canal de soporte que funcione, un límite de instalación o proveedor, y una respuesta por escrito sobre qué sucede cuando falla el equipo, el tránsito, el DNS, la facturación o las copias de seguridad. El objeto de RIPE puede ayudar a identificar a la parte a la que preguntar.
No puede responder las preguntas operativas por sí mismo.
El momento también importa. Si AS202019 se vuelve visible mañana, una instantánea de ruta aún sería evidencia temprana, no evidencia de madurez. El cliente necesitaría observaciones repetidas de rutas, una lista estable de prefijos, validación de origen de ruta donde corresponda, consistencia de vecinos de upstream, documentación del servicio y una prueba de restauración o exportación fuera de producción. Ese período de espera no es burocrático. Evita que el primer cliente de producción se convierta en la prueba que el proveedor debería haber reunido antes de vender capacidad crítica.
El mismo estándar debería aplicarse a los dominios. No se requiere una página pública funcional para cada servicio de infraestructura privado, pero un cliente crítico aún necesita una dirección de soporte, una ruta de abuso, una ruta de facturación, un canal de estado y una ruta de devolución de datos que no dependan de conjeturas. La evidencia de dominio de marcador de posición y aparcado puede coexistir con un servicio privado serio; simplemente significa que el paquete de diligencia debida privada tiene que tener más peso.
Las dependencias físicas siguen siendo las mismas que para cualquier servicio de hosting. Un servidor tiene que estar en una habitación. La habitación necesita energía y refrigeración. El router necesita conectividad de upstream. Alguien necesita acceso al armario. Alguien tiene que reemplazar el hardware fallado. Alguien tiene que responder a los informes de abuso. Alguien tiene que preservar los datos del cliente durante disputas de facturación o eventos de suspensión. Si Bodega ICT vende hosting de forma privada, estas responsabilidades existen incluso si no son visibles.
Si solo está preparando una identidad de red, es posible que esas responsabilidades aún no existan.
La ausencia de visibilidad de ruta pública es especialmente importante para el análisis de fallas. Si no hay ruta pública de AS202019, un cliente no puede monitorear AS202019 para la alcanzabilidad. Si un dominio de Bodega está alojado en infraestructura estilo ZXCS o Hostinger, los incidentes que involucren ese dominio pueden ser incidentes del host de terceros, no de la propia red de Bodega. Si los futuros servicios de cliente se trasladan a AS202019, los clientes necesitarán una revisión fresca de los upstreams, la validación de origen de ruta, la propiedad del prefijo, el soporte y la conmutación por error.
Por lo tanto, los compradores deben hacer preguntas simples antes de comprometerse con cualquier servicio hospedado bajo el nombre de Bodega ICT. ¿Qué AS transporta el servicio? ¿Qué prefijos son orientados al cliente? ¿Qué instalación alberga el equipo? ¿Quién es propietario del hardware? ¿Quién controla las sesiones de upstream? ¿Hay ROAs actuales? ¿Se prueban las copias de seguridad? ¿Cómo se exportan los datos? ¿Qué sucede si el proveedor suspende el servicio? El registro público no responde estas preguntas en este momento.
La política de enrutamiento sin sesiones activas no es resiliencia
El objeto aut-num de AS202019 enumera a AS44854 y AS56393 como pares de política. Eso es útil solo como una ruta prevista o documentada. No es una prueba de resiliencia. RIPEstat vio ambos en la política whois y ninguno en BGP para AS202019 en el momento de la consulta. Un proveedor puede mantener líneas de política listas antes de activar un circuito. Puede conservar la política después de que se retire una ruta. Puede planear usar esos upstreams más tarde. Ninguno de esos casos le da a un cliente alcanzabilidad actual.
Esta es la razón por la cual "dos ASNs nombrados en el registro" no debe describirse como multi-homing. El multi-homing significa capacidad activa o probada para continuar el servicio a través de más de un upstream. Requiere circuitos, configuración del router, filtros de upstream, autorización de origen de ruta, capacidad y procedimientos operativos. Una línea de política estática no puede transportar tráfico. No puede absorber una interrupción. No puede probar que un armario tenga un segundo camino.
El mismo principio se aplica al /48 IPv6. La presencia de 2001:678:11b0::/48 en whois indica preparación o asignación. No muestra que los servicios del cliente puedan usar IPv6. No muestra que el DNS, el DNS inverso, los firewalls, el monitoreo y el soporte al cliente estén listos para incidentes IPv6. Si un proveedor vende IPv6, los clientes deben probarlo desde múltiples redes y exigirlo en los términos del servicio.
La validación de origen de ruta no podría rescatar la calificación de evidencia. Sin ruta visible en BGP, la pregunta práctica no es si una ruta actual es válida o no. La pregunta práctica es si el proveedor tiene alguna ruta. Si AS202019 comienza a anunciar el /48 o un nuevo prefijo IPv4, las verificaciones de RPKI y políticas de ruta deben repetirse en ese momento. La respuesta actual es que los colectores públicos no ven una superficie de servicio AS202019 activa.
Este es el lugar correcto para ser estricto. Un negocio de hosting depende de la alcanzabilidad. Si la alcanzabilidad está ausente de la tabla de enrutamiento pública, entonces el artículo no debe calificar la red como media o fuerte meramente porque el objeto de registro esté limpio. El objeto de registro es un documento inicial. La tabla de enrutamiento es la evidencia operativa. Aquí, la evidencia operativa es negativa.
El riesgo del cliente es principalmente incertidumbre
El principal riesgo en torno a Bodega ICT no es que la evidencia pública muestre una mala red. Es que la evidencia pública no muestra una red actual. Eso cambia cómo un cliente debería pensar en el nombre. Puede que no haya un servicio hospedado orientado al cliente para comprar bajo AS202019 hoy. Puede haber servicio privado no visible para los colectores públicos. Puede haber una red en etapa inicial que se activará más tarde. Cada posibilidad tiene implicaciones diferentes.
Si el servicio aún no está activo, entonces la diligencia debida correcta es la preparación para el lanzamiento: propiedad del prefijo, activación de upstream, autorización de origen de ruta, contactos de soporte, comunicaciones de incidentes, términos de facturación y diseño de respaldo. Si el servicio es privado, entonces la diligencia debida correcta es una prueba específica del cliente: una ruta de prueba, traceroute, contrato, declaración de instalaciones, ejercicio de restauración y procedimiento de salida.
Si el servicio es reventa de terceros, entonces la diligencia debida correcta es el límite del proveedor: qué host, qué centro de datos, qué cuenta, qué derecho de soporte y quién preserva los datos si la relación termina.
Los dominios hacen la incertidumbre más visible. Quebodega.nlsea una página de marcador de posición significa que un cliente potencial no puede inspeccionar los términos del producto allí. Quebodegaict.nluse estacionamiento DNS y correo de Google/Hostinger señala una superficie de identidad, pero no una plataforma de infraestructura. No hay portal de tickets público, página de estado, SLA de soporte, catálogo de productos o guía de migración en las páginas verificadas para este artículo. Sin eso, el cliente no puede saber si el proveedor es un operador directo, una pequeña consultoría, un revendedor, una identidad inactiva o una red en preparación.
Esa incertidumbre no debe llenarse con suposiciones. El trabajo del artículo es identificar lo que respalda la evidencia pública. Respalda una identidad RIPE recién visible para Bodega ICT y un AS actualmente no anunciado. Respalda superficies de dominio alojadas por terceros. No respalda ninguna ruta de cliente AS202019 pública actual. Eso es suficiente para una nota de investigación vinculada al directorio, pero no suficiente para una calificación de infraestructura positiva.
El alojamiento de dominios es evidencia de dependencia, no de capacidad
La evidencia de dominio merece su propio tratamiento porque es fácil de malinterpretar. Un proveedor puede ejecutar un negocio de infraestructura serio mientras utiliza proveedores externos para su propio sitio web público, correo electrónico y DNS. Eso no es automáticamente débil. Un pequeño operador de red podría alojar deliberadamente su sitio público fuera de su propio AS para que los clientes aún puedan ver los avisos de soporte durante una interrupción. Podría usar el correo de Google u otro stack de correo SaaS porque la confiabilidad del correo es un problema operativo diferente del alojamiento de servidores de clientes.
Podría aparcar un dominio durante un cambio de marca o antes del lanzamiento completo de un servicio.
El problema en este caso no es que exista alojamiento externo. El problema es que el alojamiento externo es la única superficie pública visible. La página de marcador de posiciónbodega.nl, los servidores de nombres ZXCS vistos en las comprobaciones DNS locales y las referencias SPF al filtrado ZXCS muestran un dominio que está vivo pero que no opera como escaparate público de hosting. El patrón DNS debodegaict.nl, con servidores de nombres de estacionamiento DNS, registros MX de Google e includes SPF de Hostinger/Google, muestra un dominio de identidad y configuración de correo en lugar de una plataforma auto-operada. Esas son pistas útiles, pero no responden las preguntas de servicio que haría un cliente.
Eso importa porque las superficies de dominio público son donde los pequeños proveedores generalmente publican los controles que hacen comprensible su infraestructura: descripciones de productos, términos, ventanas de soporte, reglas de abuso, políticas de respaldo, páginas de estado y lenguaje de migración. Si están ausentes, el cliente debe recopilarlos de forma privada.
Un comprador debe preguntar si el dominio público de marcador de posición está intencionalmente sin usar, si existe otro dominio de servicio, si algún portal de cliente es privado y si la comunicación de soporte depende de los mismos proveedores externos utilizados para los dominios públicos.
Los enlaces DNS públicos también crean un límite de monitoreo. Sibodega.nlestá caído, la interrupción puede involucrar al host de terceros detrás de 185.104.29.66 o la configuración DNS del dominio, no a AS202019. Si el correo debodegaict.nlse retrasa, el problema puede involucrar el enrutamiento de correo de Google, la autorización de correo de Hostinger o el estacionamiento DNS, en lugar de una red operada por Bodega. A la inversa, si AS202019 se activa más tarde, un cliente podría ver problemas de ruta AS202019 mientras el sitio web público permanece accesible a través del alojamiento externo. Un plan de incidentes adecuado tiene que separar esas superficies.
La solicitud limpia de diligencia debida es, por lo tanto, un mapa de responsabilidades. ¿Qué dominios son de marketing público? ¿Qué dominios son de soporte? ¿Qué dominios son paneles de control de cliente? ¿Qué partes están alojadas por terceros? ¿Qué partes, si las hay, se ejecutan en AS202019? ¿Qué proveedor es responsable de la entrega de correo? ¿Qué canal de contacto sobrevive si la ruta propia del proveedor está caída? Sin esas respuestas, el tiempo de actividad del dominio no prueba la capacidad de infraestructura del cliente.
Cómo volver a probar AS202019 si entra en línea
La calificación debería cambiar si la imagen de la ruta pública cambia. La primera nueva prueba es simple: verifique losprefijos anunciados de RIPEstat para AS202019y elestado de enrutamiento de RIPEstat para AS202019. Si alguno comienza a mostrar prefijos actuales, registre la lista de prefijos, la hora de primera aparición, el recuento de direcciones visibles, el estado IPv4 versus IPv6 y el número de pares RIS que ven la ruta. Eso establece si el AS ha pasado del estado de registro al estado operativo.
La segunda nueva prueba es la diversidad de upstream. Verifique losvecinos ASN de RIPEstat para AS202019y compárelos con laconsistencia de enrutamiento AS de RIPEstat. Si AS44854 y AS56393 permanecen en whois pero solo uno o ninguno aparece en BGP, la evidencia pública aún no prueba el multi-homing. Si ambos aparecen en BGP, la siguiente pregunta es la diversidad física: si las dos rutas entran en la misma instalación, dependen del mismo patrocinador, usan la misma tela de intercambio o comparten la misma relación comercial.
La tercera nueva prueba es la seguridad de la ruta. Si 2001:678:11b0::/48 se vuelve visible, verifique lavalidación de origen de ruta de RIPEstat para AS202019 y 2001:678:11b0::/48. Si aparece un nuevo prefijo IPv4, verifique ese prefijo por separado. Un estado RPKI válido no probaría armarios ni copias de seguridad, pero mejoraría la garantía de enrutamiento. Desconocido sería una brecha de higiene. Inválido sería una preocupación operativa material.
La cuarta nueva prueba es la alineación del registro. Compare los prefijos activos con elobjeto AS202019 de la base de datos de RIPE, elregistro de organización de RIPE para Bodega ICTy elregistro de la base de datos de RIPE para 2001:678:11b0::/48. El propósito no es castigar pequeñas inconsistencias. Es entender si la ruta anunciada está vinculada a la misma organización, patrocinador y contactos en los que confiarían los clientes durante incidentes.
La quinta nueva prueba es la alineación del servicio público. Si el AS entra en línea perobodega.nlsigue siendo un marcador de posición ybodegaict.nlpermanece aparcado o alojado por terceros, la ruta probaría actividad de red pero aún no probaría una oferta de servicio hospedado. Los clientes aún necesitarían una página de producto, contrato, ruta de soporte y plan de migración. Si aparece un nuevo sitio de producto, sus afirmaciones deben contrastarse con los datos de ruta en lugar de aceptarse por sí solas.
Qué cambiaría la calificación
La forma más rápida para que Bodega ICT mejore la calificación de evidencia pública sería anunciar un prefijo relevante para el cliente desde AS202019 y mantenerlo visible a lo largo del tiempo. Un solo prefijo visible no probaría resiliencia, pero movería el caso de una huella solo de registro a una huella de red operativa. Si el 2001:678:11b0::/48 está destinado a estar activo, BGP visible, DNS inverso, validación de origen de ruta y documentación del servicio ayudarían.
Una página de servicio público también cambiaría la calificación. Debería decir si Bodega ICT vende alojamiento web, VPS, servidores administrados, consultoría, servicios de dominio, servicios de red o infraestructura privada para clientes. Debería enumerar canales de soporte, reglas de uso aceptable, términos de respaldo, derechos de cancelación y exportación de datos, y la entidad legal contratante. Una página de marcador de posición predeterminada no puede hacer ese trabajo.
La divulgación de instalaciones y proveedores sería lo más importante. Bodega ICT no necesita publicar identificadores de armario sensibles, pero los clientes deberían poder saber si los servicios se ejecutan en los Países Bajos, qué parte posee el hardware, si una empresa de hosting de terceros proporciona la plataforma física, si Bodega ICT controla el router y si existe alguna ruta de respaldo. Para un pequeño proveedor, los límites claros del proveedor pueden ser más valiosos que las vagas afirmaciones de independencia.
La prueba operativa completaría el cuadro. Un cliente debería poder ver una restauración de copia de seguridad reciente, un aviso de incidente de muestra, una ruta de escalamiento de soporte, un proceso de cambio de ruta, un proceso de exportación de datos y un proceso de cancelación que preserve los datos del cliente el tiempo suficiente para irse de forma segura. Estos son los detalles que convierten una pequeña identidad de hosting en un socio de infraestructura confiable.
Hasta que aparezcan esos cambios, la calificación responsable es Negativa para la operación de red actual. El registro es real. La operación no es visible públicamente. En la cobertura de infraestructura, esa diferencia es el punto.
Por qué Negativo no es un juicio de carácter
La calificación Negativa aquí es deliberadamente limitada. No dice que Eric Kelderman o Bodega ICT sea ilegítimo. No dice que la entidad no pueda operar una red más tarde. No dice que no haya servicios privados. Dice que la evidencia pública actual no muestra capacidad hospedada enrutada en vivo. Esa es una declaración diferente y más útil para los lectores de infraestructura.
Esta distinción importa porque los pequeños proveedores a menudo viven en estados de transición. Pueden registrar un AS antes de que el primer circuito esté listo. Pueden solicitar espacio IPv6 antes de que los servicios del cliente estén habilitados. Pueden probar la política de ruta con un patrocinador antes de mover el tráfico de producción. Pueden atender a clientes de consultoría sin publicar un catálogo de hosting completo. Pueden mantener su propio sitio web en un host de terceros porque es más simple o más resistente. Ninguna de esas opciones es automáticamente incorrecta.
Pero los clientes que compran infraestructura necesitan pruebas operativas, no explicaciones comprensivas. Si el servicio que se vende depende de armarios, tránsito y ventanas de reparación, el comprador necesita ver el límite del armario, el límite del tránsito y el límite de la reparación. Un AS inactivo no puede responder un ticket de soporte. Un sitio de marcador de posición no puede explicar la exportación de datos. Una línea de política whois no puede reemplazar un upstream fallido. Un dominio aparcado no puede probar que las copias de seguridad estén probadas. Esos no son juicios morales; son hechos operativos.
El mejor resultado sería una reevaluación futura con mejor evidencia. Si AS202019 comienza a anunciar 2001:678:11b0::/48, si se publica la autorización de origen de ruta, si AS44854 o AS56393 se convierten en vecinos visibles, si una página de servicio documenta el soporte y los términos del cliente, y si los dominios se integran en un modelo operativo claro, la calificación debería subir. Hasta entonces, el registro público se trata mejor como una identidad de infraestructura temprana o inactiva.
Las preguntas del comprador son inusualmente concretas
Si un comprador encuentra a Bodega ICT como un posible proveedor de hosting o servicios gestionados, la primera pregunta no debería ser el precio. Debería ser: ¿qué se vende exactamente bajo este nombre hoy? Si la respuesta es consultoría, el comprador necesita referencias, alcance y documentación de entrega. Si la respuesta es capacidad hospedada, el comprador necesita ver el dominio del servicio, la ruta de soporte, el límite de la instalación, el límite del upstream y el límite de la ruta. Si la respuesta es reventa, el comprador necesita conocer el proveedor subyacente y quién retiene los datos del cliente durante disputas o cancelación.
La siguiente pregunta es qué red transporta el servicio. Un cliente debe preguntar si se utiliza AS202019 en absoluto, si 2001:678:11b0::/48 está activo, si hay algún espacio IPv4 asignado y si las rutas aparecen en lavisión general de prefijo de RIPEstato en los colectores de rutas públicos. Si el servicio se ejecuta en un host de terceros, el proveedor debe decirlo directamente. No hay nada inherentemente malo en la reventa o el hosting gestionado por encima de otra plataforma, pero el riesgo del cliente es diferente al de comprar servicio en un AS controlado por el proveedor.
La pregunta de soporte debería ser igualmente explícita. El rol de abuso de RIPEACRO63211-RIPEy el objeto de personaERIC800son contactos de registro, no un servicio de atención al cliente. Un cliente debe preguntar por el horario de soporte normal, el soporte de emergencia, el manejo de abusos, la escalada de facturación, las reglas de preservación de datos y los objetivos de respuesta. Si el único contacto público es una dirección de correo electrónico, eso no es suficiente para infraestructura crítica.
La pregunta sobre la instalación debe formularse sin asumir la propiedad. ¿Bodega ICT posee servidores, alquila servidores, arrienda espacio de colocación, ejecuta máquinas virtuales en un host de terceros o proporciona consultoría en torno a la infraestructura de otra persona? Si existen servidores físicos, ¿dónde están, quién puede acceder a ellos, quién reemplaza el hardware y qué sucede fuera del horario de oficina? Si existe infraestructura virtual, ¿quién controla las instantáneas, las copias de seguridad, la política de firewall y las credenciales del cliente?
Estas preguntas deciden si el proveedor puede reparar el servicio o solo transmitir una solicitud a otro proveedor.
La pregunta del contrato debe cubrir la salida tanto como el tiempo de actividad. Un proveedor al que es fácil unirse pero difícil dejar crea un riesgo evitable. Los clientes deben exigir términos de exportación de datos, entrega de copias de seguridad, transferencia de DNS, transferencia de dominio, acceso a registros y cierre de cuentas.NIST SP 800-146es útil aquí porque trata la contratación de servicios en la nube como un problema de portabilidad y contrato, no solo como una elección tecnológica.NIST SP 800-145también es un recordatorio de que los servicios en la nube aún dependen de redes, servidores, almacenamiento y aplicaciones. Esas capas deben nombrarse antes de poder confiar en ellas.
Finalmente, el comprador debe preguntar cómo se mantendrá actualizada la evidencia pública. Si AS202019 entra en línea, ¿quién actualiza los objetos de ruta, quién publica ROAs y quién monitorea la visibilidad de la ruta? Elmaterial RPKI de RIPE NCCexplica el mecanismo de autorización de origen de ruta, yRFC 6811explica el modelo de validación. Un pequeño proveedor no necesita publicar cada detalle del router, pero debería poder explicar quién posee los cambios de ruta y cómo se corrigen los errores. Sin eso, incluso una futura ruta activa seguiría siendo solo una señal de garantía parcial.
El punto práctico final es el tiempo. Un AS nuevo o reactivado puede pasar de inactivo a visible rápidamente, y una página de producto pública puede aparecer antes de que la evidencia de ruta se ponga al día. Eso no significa que el primer cliente deba convertirse en el caso de prueba. Un comprador debe esperar una ventana de observación estable, repetir las verificaciones de ruta durante más de un día, confirmar que el DNS, el correo y los canales de soporte estén lo suficientemente separados como para sobrevivir a un incidente de infraestructura, y exigir una ruta de salida por escrito antes de almacenar datos de producción.
En un contexto de pequeño proveedor, la paciencia es un control. Permite al cliente ver si el proveedor está construyendo una superficie operativa duradera o solo una presencia temporal en el registro. Un mínimo sensato serían varios días consecutivos de origen de ruta visible, disponibilidad de la página de contacto, accesibilidad de soporte externo y una prueba exitosa de restauración o exportación fuera de producción antes de mover cualquier servicio crítico.
Cualquier cosa menos deja al cliente financiando el primer punto de prueba pública del proveedor, con datos de producción en riesgo antes de que la responsabilidad operativa esté clara. Ese riesgo es evitable.
La lectura operativa
HOSTING Eric Kelderman trading as Bodega ICT se lee mejor como una identidad de infraestructura registrada en RIPE cuya superficie de red pública activa aún no se ha materializado. El registro de AS202019 es específico y reciente, el registro de la organización nombra a Eric Kelderman trading as Bodega ICT, y las líneas de política nombran pares previstos. Pero RIPEstat no ve el AS anunciado, no ve prefijos actuales, no ve vecinos, y muestra el /48 IPv6 en whois pero no en BGP.
La evidencia de dominio visible es igualmente cautelosa.bodega.nles una página de alojamiento predeterminada en infraestructura que parece de terceros.bodegaict.nlresuelve a través de alojamiento aparcado/de terceros y correo de Google. Esas son superficies de identidad legítimas, pero no prueban una plataforma de hosting operada por Bodega. Tampoco dan a los clientes el detalle público de contrato, soporte o migración necesario para decisiones de infraestructura crítica.
Por ahora, Bodega ICT pertenece a una lista de monitoreo en lugar de a una lista corta de proveedores. Si AS202019 comienza a anunciar prefijos, si aparece un sitio de producto, o si la evidencia de instalaciones y soporte se vuelve pública, la evaluación debe revisarse. Hasta entonces, los compradores no deben inferir capacidad hospedada recuperable de la presencia de un objeto RIPE limpio. Los armarios, el tránsito y las ventanas de reparación solo se convierten en protección para el cliente cuando son visibles, contratados y probados.