Resumen
- La identidad del registro público es real. Lavisión general de AS para AS202019de RIPEstat identifica
BODEGA-HOSTING Eric Kelderman que opera como Bodega ICT, y el objeto aut-num de AS202019 en la base de datos de RIPEAS202019 aut-num entidadlistaBODEGA-HOSTING, organización ORG-BH128-RIPE, organización patrocinadora ORG-ABTA6-RIPE, política de importación/exportación con AS44854 y AS56393, y 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 organización
Eric Kelderman que opera como Bodega ICT, direcciónSakuralaan 13, Almere, país NL, correo electrónico[email protected], contacto de abuso ACRO63211-RIPE y ú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 o IPv6 visibles ni vecinos observados el 12 de julio de 2026;los prefijos anunciados de RIPEstatdevuelve cero prefijos actuales. 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 de política de ruta actual en la vista de consistencia de RIPEstat no está activo. Laconsistencia de enrutamiento de AS de RIPEstatenumera 2001:678:11b0::/48 como presente en whois pero no en BGP, y enumera la política de importación/exportación de AS44854 y AS56393 como presente 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 tiene visibilidad de ruta pública actual de AS202019, ningún prefijo de cliente visible actual, ninguna observación activa de vecinos, ningún sitio de producto funcional en sus dominios de identidad probables, y ninguna evidencia pública de instalaciones, soporte, racks, respaldo o migración que respalde tratarlo como capacidad de alojamiento activa.
El nombre dice hosting, la tabla de rutas dice todavía no
La forma útil de leer HOSTING Eric Kelderman que opera como 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 que opera como Bodega ICT en los Países Bajos. El registro es reciente. Tiene estructura de patrocinador y mantenedor. Tiene una organización y dirección nombradas. Tiene política de importación y exportación. Tiene un prefijo IPv6 registrado en whois. Estos detalles son suficientes para que valga la pena rastrear la entidad 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 IPv6 /48 en whois pero no en BGP. Esa combinación no es una red de hosting activa en la tabla de rutas 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 listar un AS, pero una interrupción del cliente depende de sesiones de ruta, puertos upstream, acceso al router, energía, gabinetes, servidores, soporte y contratos. Si el AS no es visible, un cliente no puede confiar en él para la accesibilidad. Si los dominios visibles están alojados en otros lugares, la superficie web pública no demuestra 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 actualmente no respalda la afirmación de que AS202019 esté transportando capacidad de alojamiento de producción.
La conclusión correcta es, por lo tanto, estrecha: Bodega ICT tiene una identidad de recursos numéricos reciente de RIPE, pero Internet pública actualmente no muestra que esa identidad esté prestando 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 AS202019listan aut-num 202019, nombre ASBODEGA-HOSTING, organización ORG-BH128-RIPE, organización patrocinadora ORG-ABTA6-RIPE, importación desde AS44854, exportación a AS44854, importación desde AS56393, exportación a AS56393, contactos administrativo y técnicoeric800yERIC800, 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. NombraEric Kelderman que opera como Bodega ICT, da 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. Esto 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 numéricos de la entidad.
Los objetos de política sugieren upstreams previstos. AS44854 y AS56393 están listados en la política de importación y exportación. Lavista de consistencia de enrutamiento de AS de RIPEstat para AS202019lista 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 verificado. La política puede existir antes de activar circuitos, después de retirar circuitos, o mientras las sesiones son demasiado limitadas para aparecer en la vista del colector público.
La misma vista de consistencia lista 2001:678:11b0::/48 como presente en whois pero no en BGP. En otras palabras, hay al menos un objeto de ruta IPv6 o asignación en los datos del registro, pero no es visible como ruta anunciada de AS202019 en la vista de RIPEstat. Para un cliente, la pregunta práctica es si IPv6 está activo, planificado, no utilizado 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 matiz. 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 AS pueden ser reasignados, reutilizados, patrocinados de manera diferente o re-registrados 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 del dominio refuerza la calificación operativa 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. Las 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 predeterminada.
El DNS debodega.nlapunta a infraestructura de alojamiento de terceros. El registro A en 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 hosting compartido estilo ZXCS, no a una plataforma de cliente visible de AS202019.
El dominio de identidad probablebodegaict.nltambién se aleja de AS202019. Las comprobaciones locales de DNS 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 inclusiones SPF para correo de Hostinger y Google. Eso es un patrón común de dominio estacionado o alojado por terceros. Apoya la existencia de una superficie de identidad y correo electrónico. No apoya una 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 sólida en las comprobaciones locales de DNS. Eso importa porque el propio sitio web de un proveedor pequeño es a menudo la primera prueba pública de términos de servicio, contacto de soporte, menú de productos, política de uso aceptable, SLA, página de estado, portal de tickets y lenguaje de migración de clientes. Aquí, la evidencia pública del dominio da pistas de identidad y alojamiento de terceros, pero no una oferta de capacidad alojada.
Esto no significa que Bodega ICT no tenga clientes. Muchos operadores pequeños atienden 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 debe ser conservadora.
Qué tendría que ser cierto para la capacidad alojada
Para que Bodega ICT sea un proveedor activo de capacidad alojada 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 el cliente. Segundo, el proveedor necesitaría mostrar dónde se ejecutan realmente los servidores, almacenamiento o 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 intermediarios del servicio de otro host.
La evidencia pública actual no satisface esas pruebas. AS202019 no tiene prefijos visibles. Los dominios de Bodega utilizan 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, respaldos o derechos de exportación del cliente. Los registros de RIPE no nombran una instalación. La vista de consistencia no muestra sesiones upstream activas. PeeringDB y directorios de rutas públicas no proporcionan un perfil de instalación o interconexión que pueda llenar el vacío.
Eso deja una distinción estrecha pero importante. Un AS inactivo o en preparación aún puede ser evidencia útil para monitoreo futuro, porque 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 el respaldo. El objeto RIPE puede ayudar a identificar a la parte a 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 seguiría siendo evidencia temprana, no evidencia de madurez. El cliente necesitaría observaciones repetidas de ruta, una lista de prefijos estable, validación de origen de ruta cuando corresponda, consistencia de vecinos upstream, documentación del servicio y una prueba de restauración o exportación no productiva. Ese período de espera no es burocrático. Evita que el primer cliente de producción se convierta en la prueba de que el proveedor debería haber recopilado antes de vender capacidad crítica.
El mismo estándar debería aplicarse a los dominios. Una página pública funcional no es necesaria para cada servicio de infraestructura privada, 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 suposiciones. La evidencia de marcador de posición y dominio estacionado puede coexistir con un servicio privado serio; simplemente significa que el paquete de diligencia debida privado 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 sala. La sala necesita energía y refrigeración. El router necesita conectividad upstream. Alguien necesita acceso al rack. Alguien tiene que reemplazar hardware defectuoso. Alguien tiene que responder a 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, esas responsabilidades pueden no existir aún.
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 accesibilidad. Si un dominio de Bodega está alojado en infraestructura estilo ZXCS o Hostinger, los incidentes que involucren ese dominio pueden ser incidentes del host tercero, no de la red propia de Bodega. Si los servicios futuros del cliente se trasladan a AS202019, los clientes necesitarán una revisión fresca de upstreams, validación de origen de ruta, propiedad de prefijos, soporte y conmutación por error.
Por lo tanto, los compradores deberían hacer preguntas simples antes de comprometerse con cualquier servicio alojado bajo el nombre de Bodega ICT. ¿Qué AS lleva el servicio? ¿Qué prefijos están orientados al cliente? ¿Qué instalación alberga el equipo? ¿Quién posee el hardware? ¿Quién controla las sesiones 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 ahora.
La política de ruta sin sesiones activas no es resiliencia
El objeto aut-num de AS202019 lista 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 retener política después de retirar una ruta. Puede planear usar esos upstreams más tarde. Ninguno de esos casos da al cliente accesibilidad actual.
Es por eso que "dos ASN nombrados en el registro" no deberían describirse como multi-homing. Multi-homing significa capacidad activa o probada de continuar el servicio a través de más de un upstream. Requiere circuitos, configuración de router, filtros 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 rack tenga un segundo camino.
El mismo principio se aplica al IPv6 /48. 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 DNS, DNS inverso, firewalls, monitoreo y soporte al cliente estén listos para incidentes de IPv6. Si un proveedor vende IPv6, los clientes deberían 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 inválida. La pregunta práctica es si el proveedor tiene una ruta en absoluto. Si AS202019 comienza a anunciar el /48 o un nuevo prefijo IPv4, las verificaciones de RPKI y política de ruta deberían repetirse en ese momento. La respuesta actual es que los colectores públicos no ven una superficie de servicio activa de AS202019.
Este es el lugar correcto para ser estricto. Un negocio de hosting depende de la accesibilidad. Si la accesibilidad está ausente de la tabla de rutas pública, entonces el artículo no debería calificar la red como media o fuerte solo porque el objeto de registro está limpio. El objeto de registro es un documento de partida. La tabla de rutas es la evidencia operativa. Aquí, la evidencia operativa es negativa.
El riesgo del cliente es principalmente riesgo de incertidumbre
El riesgo principal en torno a Bodega ICT no es que la evidencia pública muestre una red mala. Es que la evidencia pública no muestra una red actual. Eso cambia cómo un cliente debería pensar sobre el nombre. Puede que no haya un servicio alojado 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 temprana 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 de prefijos, activación 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 la prueba específica del cliente: una ruta de prueba, traceroute, contrato, declaración de instalación, 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 qué parte preserva los datos si la relación termina.
Los dominios hacen que la incertidumbre sea más visible.bodega.nlsiendo una página placeholder significa que un posible cliente no puede inspeccionar los términos del producto allí.bodegaict.nlusando DNS-parking 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 esos, el cliente no puede saber si el proveedor es un operador práctico, una pequeña consultoría, un revendedor, una identidad inactiva o una red en preparación.
Esa incertidumbre no debería llenarse con suposiciones. El trabajo del artículo es identificar lo que la evidencia pública respalda. Respalda una identidad RIPE recientemente visible para Bodega ICT y un AS actualmente no anunciado. Respalda superficies de dominio alojadas por terceros. No respalda ninguna ruta de cliente pública actual de AS202019. Eso es suficiente para una nota de investigación vinculada a un directorio, pero no suficiente para una calificación positiva de infraestructura.
El alojamiento de dominios es evidencia de dependencia, no evidencia de capacidad
La evidencia del dominio merece su propio tratamiento porque es fácil de malinterpretar. Un proveedor puede ejecutar un negocio de infraestructura serio mientras usa proveedores externos para su propio sitio web público, correo electrónico y DNS. Eso no es automáticamente débil. Un operador de red pequeño podría alojar deliberadamente su sitio público fuera de su propio AS para que los clientes aún puedan alcanzar avisos de soporte durante una interrupción. Podría usar correo de Google u otro SaaS de correo porque la fiabilidad del correo es un problema operativo diferente al del alojamiento de servidores de clientes.
Podría estacionar un dominio durante un cambio de marca o antes de un lanzamiento completo del 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 placeholder debodega.nl, los servidores de nombres ZXCS vistos en las comprobaciones locales de DNS y las referencias SPF al filtrado de ZXCS muestran un dominio que está vivo pero no funciona como escaparate público de hosting. El patrón DNS debodegaict.nl, con servidores de nombres DNS-parking, registros MX de Google e inclusiones 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 un cliente haría.
Eso importa porque las superficies de dominio público son donde los proveedores pequeños suelen publicar los controles que hacen inteligible 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 esos están ausentes, el cliente debe recopilarlos de forma privada.
Un comprador debería preguntar si el dominio público placeholder no se usa intencionalmente, 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 tercero detrás de 185.104.29.66 o a 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. Por el contrario, si AS202019 más tarde se activa, un cliente podría ver problemas de ruta de AS202019 mientras el sitio web público permanece accesible a través de alojamiento externo. Un plan de incidentes adecuado tiene que separar esas superficies.
La solicitud de diligencia debida clara es, por lo tanto, un mapa de responsabilidades. ¿Qué dominios son marketing público? ¿Qué dominios son soporte? ¿Qué dominios son paneles de control del 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 propia ruta 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 se conecta
La calificación debería cambiar si la imagen de ruta pública cambia. La primera nueva prueba es simple: verifiquelos prefijos anunciados de RIPEstat para AS202019yel estado de enrutamiento de RIPEstat para AS202019. Si alguno comienza a mostrar prefijos actuales, registre la lista de prefijos, la hora de primera vista, el recuento de direcciones visible, el estado de IPv4 versus IPv6 y el número de peers 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 upstream. Verifiquelos vecinos ASN de RIPEstat para AS202019y compárelo conla consistencia de enrutamiento de 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 multi-homing. Si ambos aparecen en BGP, la siguiente pregunta es la diversidad física: si los dos caminos 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 ruta. Si 2001:678:11b0::/48 se vuelve visible, verifiquela validació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 racks o respaldos, 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 la base de datos 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 los clientes confiarían durante incidentes.
La quinta nueva prueba es la alineación del servicio público. Si el AS se conecta perobodega.nlsigue siendo un marcador de posición ybodegaict.nlsigue estacionado o alojado por terceros, la ruta probaría actividad de red pero aún no probaría una oferta de servicio alojado. 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 deberían cotejarse con los datos de ruta en lugar de aceptarse por sí mismas.
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 con el 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 se pretende que 2001:678:11b0::/48 esté activo, un BGP visible, DNS inverso, validación de origen de ruta y documentación del servicio ayudarían.
Una página de servicio pública también cambiaría la calificación. Debería decir si Bodega ICT vende hosting web, VPS, servidores gestionados, consultoría, servicios de dominio, servicios de red o infraestructura privada del cliente. Debería listar 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 placeholder 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 rack 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 externa proporciona la plataforma física, si Bodega ICT controla el router y si existe alguna ruta de respaldo. Para un proveedor pequeño, los límites claros del proveedor pueden ser más valiosos que las afirmaciones vagas de independencia.
La prueba operativa completaría el panorama. Un cliente debería poder ver una restauración de respaldo 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 manera segura. Estos son los detalles que convierten una pequeña identidad de hosting en un socio de infraestructura confiable.
Hasta que esos cambios aparezcan, la calificación responsable es Negativa para la operación de red actual. El registro es real. La operación no es públicamente visible. 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 estrecha. 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 de alojamiento enrutada activa. Esa es una declaración diferente y más útil para los lectores de infraestructura.
Esta distinción importa porque los proveedores pequeños 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 clientes de consultoría sin publicar un catálogo de hosting completo. Pueden mantener su propio sitio web en un host tercero porque es más simple o más resiliente. Ninguna de esas elecciones es automáticamente incorrecta.
Pero los clientes que compran infraestructura necesitan prueba operativa, no explicaciones comprensivas. Si el servicio que se vende depende de racks, tránsito y ventanas de reparación, el comprador necesita ver el límite del rack, el límite del tránsito y el límite de reparación. Un AS inactivo no puede responder un ticket de soporte. Un sitio placeholder no puede explicar la exportación de datos. Una línea de política whois no puede reemplazar un upstream fallido. Un dominio estacionado no puede probar que las copias de seguridad se prueban. 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 soporte y términos del cliente, y si los dominios se llevan a 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 está vendiendo 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 alojada, el comprador necesita ver el dominio de servicio, la ruta de soporte, el límite de instalación, el límite upstream y el límite de ruta. Si la respuesta es reventa, el comprador necesita conocer el proveedor subyacente y quién retiene los datos del cliente durante disputas o cancelaciones.
La siguiente pregunta es qué red transporta el servicio. Un cliente debería preguntar si AS202019 se utiliza en absoluto, si 2001:678:11b0::/48 está activo, si se asigna algún espacio IPv4 y si las rutas aparecen en lavisión general de prefijos de RIPEstato en los colectores de rutas públicos. Si el servicio se ejecuta en un host tercero, el proveedor debería decirlo directamente. No hay nada inherentemente malo en la reventa o el hosting gestionado sobre otra plataforma, pero el riesgo del cliente es diferente a 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 una mesa de ayuda al cliente. Un cliente debería preguntar por horas de soporte normales, soporte de emergencia, manejo de abuso, escalamiento de facturación, reglas de preservación de datos y 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 de instalación debería formularse sin asumir propiedad. ¿Bodega ICT posee servidores, alquila servidores, arrienda coubicación, ejecuta máquinas virtuales en un host tercero, 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 laboral? 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 debería cubrir la salida tanto como el tiempo de actividad. Un proveedor que es fácil de unir pero difícil de dejar crea un riesgo evitable. Los clientes deberían exigir exportación de datos, entrega de copias de seguridad, transferencia de DNS, transferencia de dominio, acceso a registros y términos de cierre de cuenta.NIST SP 800-146es útil aquí porque trata la contratación en la nube como un problema de portabilidad y contrato, no solo una elección tecnológica.NIST SP 800-145también es un recordatorio de que los servicios en la nube todavía dependen de redes, servidores, almacenamiento y aplicaciones. Esas capas tienen que ser nombradas antes de que se pueda confiar en ellas.
Finalmente, el comprador debería preguntar cómo se mantendrá actualizada la evidencia pública. Si AS202019 se conecta, ¿quién actualiza los objetos de ruta, quién publica ROAs y quién monitorea la visibilidad de ruta? Elmaterial RPKI de RIPE NCCexplica el mecanismo de autorización de origen de ruta, yRFC 6811explica el modelo de validación. Un proveedor pequeño 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 ruta activa futura seguiría siendo solo una señal de garantía parcial.
El punto práctico final es el momento. 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 debería esperar una ventana de observación estable, repetir las comprobaciones de ruta durante más de un día, confirmar que DNS, correo y canales de soporte están lo suficientemente separados para sobrevivir un incidente de infraestructura, y exigir una ruta de salida por escrito antes de almacenar datos de producción.
En un contexto de proveedor pequeño, la paciencia es un control. Permite al cliente ver si el proveedor está construyendo una superficie operativa duradera o solo una presencia de registro temporal. Un mínimo sensato sería varios días consecutivos de origen de ruta visible, disponibilidad de página de contacto, accesibilidad de soporte externo y una prueba exitosa de restauración o exportación no productiva antes de mover cualquier servicio crítico. Menos que eso 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 que opera como 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 organización nombra a Eric Kelderman que opera como 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 IPv6 /48 en whois pero no en BGP.
La evidencia de dominio visible es igualmente cautelosa.bodega.nles una página de hosting predeterminada en infraestructura de apariencia tercero.bodegaict.nlresuelve a través de hosting estacionado/tercero 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 críticas de infraestructura.
Por ahora, Bodega ICT pertenece a una lista de monitoreo más que 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 debería revisarse. Hasta entonces, los compradores no deberían inferir capacidad de alojamiento recuperable de la presencia de un objeto RIPE limpio. Los racks, el tránsito y las ventanas de reparación solo se convierten en protección del cliente cuando son visibles, contratados y probados.