HOSTING Eric Kelderman trading as Bodega ICT vende capacidade hospedada que ainda depende de racks, trânsito e janelas de reparo

Resumo

• A identidade do registro público é real. Avisão geral da AS para AS202019do RIPEstat identificaBODEGA-HOSTING Eric Kelderman trading as Bodega ICT, e oobjeto aut-num AS202019do Banco de Dados da RIPE listaBODEGA-HOSTING, organização ORG-BH128-RIPE, organização patrocinadora ORG-ABTA6-RIPE, política de importação/exportação com AS44854 e AS56393, e criação em 23 de janeiro de 2026.
• O registro da organização também é específico. Uma pesquisa no Banco de Dados da RIPE porBodega ICTretorna ORG-BH128-RIPE, com o nome da organizaçãoEric Kelderman trading as Bodega ICT, endereçoSakuralaan 13, Almere, país NL, e-mail[email protected], contato de abuso ACRO63211-RIPE e última modificação em 13 de maio de 2026.
• O roteamento público atual está ausente. Ostatus de roteamento do RIPEstat para AS202019não mostra anúncios IPv4 ou IPv6 visíveis e nenhum vizinho observado em 12 de julho de 2026;prefixos anunciados do RIPEstatretorna zero prefixos atuais. Mostra visibilidade histórica de IPv4, com primeira aparição de 185.39.216.0/22 em 2015 e última aparição de 95.181.220.0/22 em 2022, antes do estado atual do objeto de registro de 2026.
• O único objeto de política de rota atual na visão de consistência do RIPEstat não está ativo. Aconsistência de roteamento AS do RIPEstatlista 2001:678:11b0::/48 como presente no whois mas não no BGP, e lista a política de importação/exportação com AS44854 e AS56393 como presente no whois mas não no BGP.
• A classificação de evidência é Negativa para a operação de rede atual. A Bodega ICT tem uma identidade de registro real, mas não há visibilidade de rota pública atual para AS202019, nenhum prefixo de cliente visível, nenhuma observação de vizinho ativo, nenhum site de produto resolvível em seus domínios de identidade prováveis, e nenhuma evidência pública de instalação, suporte, rack, backup ou migração que sustentaria tratá-la como capacidade de hospedagem ativa.

O nome diz hospedagem, a tabela de roteamento diz ainda não

A maneira útil de ler HOSTING Eric Kelderman trading as Bodega ICT é separar identidade de operação. A camada de identidade é clara. Os registros da RIPE associam AS202019 a BODEGA-HOSTING e a Eric Kelderman trading as Bodega ICT na Holanda. O registro é recente. Possui estrutura de patrocinador e mantenedor. Possui uma organização nomeada e endereço. Possui política de importação e exportação. Possui um prefixo IPv6 registrado no whois. Esses detalhes são suficientes para tornar a entidade digna de rastreamento em um diretório de infraestrutura.

A camada operacional é muito mais fraca. O RIPEstat não vê AS202019 anunciando nada em 12 de julho de 2026. Não vê um prefixo IPv4. Não vê um prefixo IPv6. Não vê um vizinho. A visão de prefixos anunciados está vazia. A visão de consistência vê um /48 IPv6 no whois, mas não no BGP. Essa combinação não é uma rede de hospedagem ativa na tabela de roteamento pública. É uma pegada de registro e política que pode estar se preparando para serviço, preservando uma identidade ou aguardando ativação.

Essa distinção é importante porque as falhas de infraestrutura são reparadas na camada operacional, não na camada de nomenclatura. Um objeto de registro pode listar um AS, mas uma interrupção do cliente depende de sessões de rota, portas upstream, acesso ao roteador, energia, gabinetes, servidores, suporte e contratos. Se o AS não estiver visível, um cliente não pode confiar nele para acessibilidade. Se os domínios visíveis estiverem hospedados em outro lugar, a superfície web pública não prova que a Bodega ICT opera infraestrutura de cliente por trás do AS202019.

A tentação em um programa de cobertura de empresas é tratar cada titular de AS como um provedor ativo. Isso superestimaria este caso. A Bodega ICT pode se tornar uma rede ativa. Pode ter clientes privados ou infraestrutura não pública. Pode usar hospedagem de terceiros enquanto prepara seu próprio AS. Mas a evidência pública disponível agora não suporta a afirmação de que AS202019 está transportando capacidade de hospedagem em produção.

A conclusão correta é, portanto, restrita: a Bodega ICT tem uma identidade recente de recurso numérico da RIPE, mas a internet pública não mostra atualmente essa identidade entregando serviço roteado. Os compradores devem solicitar evidência de rota atual, termos de serviço e prova de instalação antes de tratar o nome como um provedor de hospedagem operacional.

RIPE identifica a entidade, mas não uma plataforma em funcionamento

Os dados whois do RIPEstat para AS202019 listam aut-num 202019, nome ASBODEGA-HOSTING, organização ORG-BH128-RIPE, organização patrocinadora ORG-ABTA6-RIPE, importação de AS44854, exportação para AS44854, importação de AS56393, exportação para AS56393, contatos administrativo e técnicoeric800eERIC800, status ASSIGNED e criação em 23 de janeiro de 2026. O objeto aut-num do Banco de Dados da RIPE mostra a mesma estrutura.

O resultado da pesquisa RIPE para Bodega ICT fornece o registro da organização. Ele nomeiaEric Kelderman trading as Bodega ICT, fornece endereço Sakuralaan 13, Almere, país NL, e-mail[email protected], contato de abuso ACRO63211-RIPE, mantenedornl-eritap-1-MNT, criação em 20 de janeiro de 2026 e última modificação em 13 de maio de 2026. Esta não é uma entrada de diretório secundária vaga. É o objeto oficial do Banco de Dados da RIPE que ancora a identidade do recurso numérico da entidade.

Os objetos de política sugerem upstreams pretendidos. AS44854 e AS56393 estão listados na política de importação e exportação. A visão de consistência de roteamento AS do RIPEstat para AS202019 lista esses pares como presentes na política whois, mas não no BGP. Esse é um sinal útil de estado planejado. Não é evidência de conectividade ativa no momento verificado. A política pode existir antes que os circuitos sejam ativados, depois que os circuitos sejam desativados ou enquanto as sessões são muito limitadas para aparecer na visão do coletor público.

A mesma visão de consistência lista 2001:678:11b0::/48 como presente no whois, mas não no BGP. Em outras palavras, há pelo menos um objeto de rota ou alocação IPv6 nos dados de registro, mas não é visível como uma rota AS202019 anunciada na visão do RIPEstat. Para um cliente, a questão prática é se o IPv6 está ativo, planejado, não utilizado ou atribuído apenas para serviço futuro. A resposta pública em 12 de julho de 2026 é: não roteado visivelmente.

Os dados históricos do RIPEstat adicionam nuances. A visão de status de roteamento diz que AS202019 foi visto pela primeira vez com 185.39.216.0/22 em 2015 e visto pela última vez com 95.181.220.0/22 em 2022. O objeto aut-num atual da RIPE, no entanto, foi criado em janeiro de 2026. Os números AS podem ser reatribuídos, reaproveitados, patrocinados de forma diferente ou registrados novamente ao longo do tempo. Isso significa que a visibilidade histórica de prefixos não deve ser tratada como prova de que a entidade Bodega ICT de hoje está transportando essas rotas antigas.

A verificação operacional atual deve focar na visibilidade presente, e essa visibilidade está vazia.

Os domínios apontam para hospedagem de terceiros, não para AS202019

As evidências de domínio reforçam a classificação operacional fraca. O domíniobodega.nlresolve, mas a página web é um placeholder de hospedagem padrão: "Welcome to the home of bodega.nl" e "To change this page, upload your website into the public_html directory," com uma data de criação mostrada na página. Caminhos como/hosting,/contact,/dienstene/ictretornaram respostas 404 nas verificações locais. Isso não é um site de produto ativo para um provedor de hospedagem. É uma página hospedada padrão.

O DNS parabodega.nlaponta para infraestrutura de hospedagem de terceiros. O registro A nas verificações locais era 185.104.29.66, o registro AAAA era 2a06:2ec0:1::111, os servidores de nome eramns.zxcs.eu,ns.zxcs.beens.zxcs.nl, e o destino MX eramail.bodega.nl. O registro SPF incluía o intervalo 185.104.29.0/24, o endereço 185.104.29.66, o endereço web IPv6 e a filtragem de correio ZXCS. Essa evidência aponta para infraestrutura de hospedagem compartilhada estilo ZXCS, não para uma plataforma de cliente AS202019 visível.

O domínio de identidade provávelbodegaict.nltambém aponta para longe de AS202019. As verificações DNS locais mostraram registro A 2.57.91.91, registro AAAA 2a02:4780:84::32, servidores de nomens1.dns-parking.comens2.dns-parking.com, registros MX do Google e includes SPF para correio Hostinger e Google. Esse é um padrão comum de domínio estacionado ou hospedado por terceiros. Ele suporta a existência de uma superfície de e-mail e identidade. Não suporta a afirmação de que a Bodega ICT hospeda seu próprio site público ou serviços de cliente em seu AS atribuído.

As variantes inativas debodega-ict.nlnão forneceram uma superfície de site mais forte nas verificações DNS locais. Isso é importante porque o próprio site de um pequeno provedor é frequentemente a primeira prova pública de termos de serviço, contato de suporte, menu de produtos, política de uso aceitável, SLA, página de status, portal de tickets e linguagem de migração de cliente. Aqui, a evidência pública de domínio fornece pistas de identidade e hospedagem de terceiros, mas não uma oferta de capacidade hospedada.

Isso não significa que a Bodega ICT não tenha clientes. Muitos operadores pequenos atendem clientes por indicação, contrato direto, portal privado ou acordo de revenda. Alguns mantêm seu site público mínimo enquanto operam infraestrutura real. Mas a cobertura pública não pode assumir isso. Se o site visível é um placeholder e o AS atribuído não está anunciando, a conclusão editorial tem que ser conservadora.

O que seria necessário para capacidade hospedada

Para que a Bodega ICT seja um provedor de capacidade hospedada ativa no sentido relevante para esta série de cobertura, várias coisas teriam que ser comprovadas. Primeiro, AS202019 ou outro AS claramente identificado precisaria originar prefixos relevantes para o cliente. Segundo, o provedor precisaria mostrar onde servidores, armazenamento ou infraestrutura virtual realmente funcionam. Terceiro, os clientes precisariam de suporte, backup, faturamento e termos de migração. Quarto, um comprador precisaria saber se a Bodega ICT controla a camada física ou apenas intermedia o serviço de outro host.

As evidências públicas atuais não satisfazem esses testes. AS202019 não tem prefixos visíveis. Os domínios Bodega usam superfícies de hospedagem de terceiros. As páginas web públicas revisadas não descrevem níveis de produto, locais de data center, canais de suporte, termos, histórico de status, backups ou direitos de exportação do cliente. Os registros do banco de dados RIPE não nomeiam uma instalação. A visão de consistência não mostra sessões upstream ativas. PeeringDB e diretórios de rota pública não fornecem uma instalação ou perfil de peering que possa preencher a lacuna.

Isso deixa uma distinção estreita, mas importante. Um AS dormente ou em preparação ainda pode ser uma evidência útil para monitoramento futuro, porque diz aos observadores qual recurso verificar se um lançamento de serviço aparecer. Não é evidência útil para dependência atual do cliente. Um cliente comprando hospedagem hoje precisa de um endereço que roteie, um canal de suporte que funcione, um limite de instalação ou fornecedor e uma resposta por escrito sobre o que acontece quando equipamentos, trânsito, DNS, faturamento ou backup falham. O objeto RIPE pode ajudar a identificar a parte a quem perguntar.

Não pode responder às perguntas operacionais por si só.

O momento também é importante. Se AS202019 se tornar visível amanhã, uma única captura de rota ainda seria evidência inicial, não evidência de maturidade. O cliente precisaria de observações repetidas de rota, uma lista de prefixos estável, validação de origem de rota quando aplicável, consistência de vizinho upstream, documentação de serviço e um teste de restauração ou exportação não produtiva. Esse período de espera não é burocrático. Impede que o primeiro cliente de produção se torne a prova de que o provedor deveria ter reunido antes de vender capacidade crítica.

O mesmo padrão deve se aplicar aos domínios. Uma página pública funcional não é necessária para todo serviço de infraestrutura privada, mas um cliente crítico ainda precisa de um endereço de suporte, um caminho de abuso, um caminho de faturamento, um canal de status e um caminho de retorno de dados que não dependam de suposições. Evidências de placeholder e domínio estacionado podem coexistir com um serviço privado sério; significa simplesmente que o pacote de due diligence privado tem que ter mais peso.

As dependências físicas permanecem as mesmas que para qualquer serviço de hospedagem. Um servidor tem que estar em uma sala. A sala precisa de energia e resfriamento. O roteador precisa de conectividade upstream. Alguém precisa ter acesso ao rack. Alguém tem que substituir hardware com falha. Alguém tem que responder a relatórios de abuso. Alguém tem que preservar os dados do cliente durante disputas de faturamento ou eventos de suspensão. Se a Bodega ICT vende hospedagem privadamente, essas responsabilidades existem mesmo que não sejam visíveis.

Se está apenas preparando uma identidade de rede, essas responsabilidades podem ainda não existir.

A ausência de visibilidade de rota pública é especialmente importante para análise de falhas. Se não há rota pública AS202019, um cliente não pode monitorar AS202019 para acessibilidade. Se um domínio Bodega está hospedado em infraestrutura ZXCS ou estilo Hostinger, incidentes envolvendo esse domínio podem ser incidentes do host terceirizado, não da própria rede da Bodega. Se futuros serviços de cliente migrarem para AS202019, os clientes precisarão de uma nova revisão de upstreams, validação de origem de rota, propriedade de prefixo, suporte e failover.

Os compradores devem, portanto, fazer perguntas simples antes de se comprometer com qualquer serviço hospedado sob o nome Bodega ICT. Qual AS transporta o serviço? Quais prefixos são voltados para o cliente? Qual instalação abriga o equipamento? Quem possui o hardware? Quem controla as sessões upstream? Existem ROAs atuais? Os backups são testados? Como os dados são exportados? O que acontece se o provedor suspender o serviço? O registro público não responde a essas perguntas agora.

Política de rota sem sessões ativas não é resiliência

O objeto aut-num AS202019 lista AS44854 e AS56393 como pares de política. Isso é útil apenas como um caminho pretendido ou documentado. Não é uma prova de resiliência. O RIPEstat viu ambos na política whois e nenhum no BGP para AS202019 no momento da consulta. Um provedor pode manter linhas de política prontas antes de ativar um circuito. Pode reter política após uma rota ser retirada. Pode planejar usar esses upstreams mais tarde. Nenhum desses casos dá ao cliente acessibilidade atual.

É por isso que "dois ASNs nomeados no registro" não devem ser descritos como multi-homing. Multi-homing significa capacidade ativa ou testada de continuar o serviço através de mais de um upstream. Requer circuitos, configuração de roteador, filtros upstream, autorização de origem de rota, capacidade e procedimentos operacionais. Uma linha de política estática não pode transportar tráfego. Não pode absorver uma interrupção. Não pode provar que um rack tem um segundo caminho.

O mesmo princípio se aplica ao IPv6 /48. A presença de 2001:678:11b0::/48 no whois indica preparação ou alocação. Não mostra que os serviços do cliente podem usar IPv6. Não mostra que DNS, DNS reverso, firewalls, monitoramento e suporte ao cliente estão prontos para incidentes IPv6. Se um provedor vende IPv6, os clientes devem testá-lo de múltiplas redes e exigi-lo nos termos de serviço.

A validação de origem de rota não poderia resgatar a classificação de evidência. Sem rota visível no BGP, a questão prática não é se uma rota atual é válida ou inválida. A questão prática é se o provedor tem uma rota. Se AS202019 começar a anunciar o /48 ou um novo prefixo IPv4, as verificações de RPKI e política de rota devem ser repetidas nesse momento. A resposta atual é que os coletores públicos não veem uma superfície de serviço AS202019 ativa.

Este é o lugar certo para ser rigoroso. Um negócio de hospedagem depende de acessibilidade. Se a acessibilidade está ausente da tabela de roteamento pública, então o artigo não deve classificar a rede como média ou forte meramente porque o objeto de registro está limpo. O objeto de registro é um documento inicial. A tabela de roteamento é a evidência operacional. Aqui, a evidência operacional é negativa.

O risco do cliente é principalmente risco de incerteza

O principal risco em torno da Bodega ICT não é que a evidência pública mostre uma rede ruim. É que a evidência pública não mostra uma rede atual. Isso muda como um cliente deve pensar sobre o nome. Pode não haver serviço hospedado voltado para o cliente para comprar sob AS202019 hoje. Pode haver serviço privado não visível para coletores públicos. Pode haver uma rede em estágio inicial que se tornará ativa mais tarde. Cada possibilidade tem implicações diferentes.

Se o serviço ainda não estiver ativo, então a due diligence correta é prontidão de lançamento: propriedade de prefixo, ativação upstream, autorização de origem de rota, contatos de suporte, comunicações de incidentes, termos de faturamento e design de backup. Se o serviço for privado, então a due diligence correta é prova específica do cliente: uma rota de teste, traceroute, contrato, declaração de instalação, exercício de restauração e procedimento de saída.

Se o serviço for revenda de terceiros, então a due diligence correta é limite de fornecedor: qual host, qual data center, qual conta, qual direito de suporte e qual parte preserva os dados se o relacionamento terminar.

Os domínios tornam a incerteza mais visível.bodega.nlsendo uma página placeholder significa que um cliente em potencial não pode inspecionar os termos do produto lá.bodegaict.nlusando DNS-parking e correio Google/Hostinger sinaliza uma superfície de identidade, mas não uma plataforma de infraestrutura. Não há portal público de tickets, página de status, SLA de suporte, catálogo de produtos ou guia de migração nas páginas verificadas para este artigo. Sem esses, o cliente não pode dizer se o provedor é um operador prático, uma pequena consultoria, um revendedor, uma identidade dormente ou uma rede em preparação.

Essa incerteza não deve ser preenchida com suposições. O trabalho do artigo é identificar o que a evidência pública suporta. Ela suporta uma identidade RIPE recentemente visível para Bodega ICT e um AS atualmente não anunciado. Suporta superfícies de domínio hospedadas por terceiros. Não suporta nenhuma rota de cliente AS202019 pública atual. Isso é suficiente para uma nota de pesquisa vinculada a diretório, mas não suficiente para uma classificação positiva de infraestrutura.

Hospedagem de domínio é evidência de dependência, não de capacidade

As evidências de domínio merecem seu próprio tratamento porque são fáceis de interpretar mal. Um provedor pode administrar um negócio de infraestrutura sério enquanto usa provedores externos para seu próprio site público, e-mail e DNS. Isso não é automaticamente fraco. Um operador de rede pequeno pode deliberadamente hospedar seu site público fora de seu próprio AS para que os clientes ainda possam alcançar avisos de suporte durante uma interrupção. Pode usar o Google Mail ou outra pilha de SaaS de e-mail porque a confiabilidade do e-mail é um problema operacional diferente da hospedagem de servidor do cliente.

Pode estacionar um domínio durante um rebranding ou antes de um lançamento completo de serviço.

O problema neste caso não é que a hospedagem externa exista. O problema é que a hospedagem externa é a única superfície pública visível. A página placeholder debodega.nl, os servidores de nome ZXCS vistos nas verificações DNS locais e as referências SPF à filtragem ZXCS mostram um domínio que está vivo, mas não operando como uma vitrine pública de hospedagem. O padrão DNS debodegaict.nl, com servidores de nome DNS-parking, registros MX do Google e includes SPF Hostinger/Google, mostra um domínio de identidade e configuração de e-mail, em vez de uma plataforma auto-operada. Essas são pistas úteis, mas não respondem às perguntas de serviço que um cliente faria.

Isso é importante porque as superfícies de domínio público são onde pequenos provedores geralmente publicam os controles que tornam sua infraestrutura inteligível: descrições de produtos, termos, janelas de suporte, regras de abuso, políticas de backup, páginas de status e linguagem de migração. Se esses estão ausentes, o cliente deve coletá-los privadamente. Um comprador deve perguntar se o domínio placeholder público é intencionalmente não utilizado, se outro domínio de serviço existe, se algum portal de cliente é privado e se a comunicação de suporte depende dos mesmos provedores externos usados para os domínios públicos.

Os links DNS públicos também criam um limite de monitoramento. Sebodega.nlestiver fora do ar, a interrupção pode envolver o host terceirizado por trás de 185.104.29.66 ou a configuração DNS do domínio, não AS202019. Se o e-mail debodegaict.nlestiver atrasado, o problema pode envolver o roteamento de e-mail do Google, autorização de e-mail da Hostinger ou estacionamento DNS, em vez de uma rede operada pela Bodega. Por outro lado, se AS202019 se tornar ativo mais tarde, um cliente poderia ver problemas de rota AS202019 enquanto o site público permanece acessível através de hospedagem externa. Um plano de incidente adequado tem que separar essas superfícies.

O pedido de due diligence limpo é, portanto, um mapa de responsabilidades. Quais domínios são marketing público? Quais domínios são suporte? Quais domínios são painéis de controle do cliente? Quais partes são hospedadas por terceiros? Quais partes, se houver, rodam em AS202019? Qual fornecedor é responsável pela entrega de e-mail? Qual canal de contato sobrevive se a própria rota do provedor estiver fora do ar? Sem essas respostas, o uptime do domínio não prova a capacidade da infraestrutura do cliente.

Como testar novamente o AS202019 se ele ficar online

A pontuação deve mudar se o quadro de rota pública mudar. O primeiro reteste é simples: verifique osprefixos anunciados do RIPEstat para AS202019e ostatus de roteamento do RIPEstat para AS202019. Se algum começar a mostrar prefixos atuais, registre a lista de prefixos, o horário da primeira aparição, a contagem de endereços visíveis, o status IPv4 versus IPv6 e o número de pares RIS vendo a rota. Isso estabelece se o AS passou do estado de registro para o estado operacional.

O segundo reteste é a diversidade upstream. Verifique osvizinhos ASN do RIPEstat para AS202019e compare com aconsistência de roteamento AS do RIPEstat. Se AS44854 e AS56393 permanecerem no whois, mas apenas um ou nenhum aparecer no BGP, a evidência pública ainda não prova multi-homing. Se ambos aparecerem no BGP, a próxima questão é a diversidade física: se os dois caminhos entram na mesma instalação, dependem do mesmo patrocinador, usam o mesmo tecido de troca ou compartilham o mesmo relacionamento comercial.

O terceiro reteste é a segurança de rota. Se 2001:678:11b0::/48 se tornar visível, verifique avalidação de origem de rota do RIPEstat para AS202019 e 2001:678:11b0::/48. Se um novo prefixo IPv4 aparecer, verifique esse prefixo separadamente. Um estado RPKI válido não provaria racks ou backups, mas melhoraria a garantia de roteamento. Desconhecido seria uma lacuna de higiene. Inválido seria uma preocupação operacional material.

O quarto reteste é o alinhamento do registro. Compare os prefixos ativos com oobjeto AS202019 do Banco de Dados da RIPE, oregistro da organização Bodega ICT no Banco de Dados da RIPEe oregistro do Banco de Dados da RIPE para 2001:678:11b0::/48. O objetivo não é punir pequenas inconsistências. É entender se a rota anunciada está vinculada à mesma organização, patrocinador e contatos em que os clientes confiariam durante incidentes.

O quinto reteste é o alinhamento do serviço público. Se o AS ficar online, masbodega.nlpermanecer um placeholder ebodegaict.nlpermanecer estacionado ou hospedado por terceiros, a rota provaria atividade de rede, mas ainda não provaria uma oferta de serviço hospedado. Os clientes ainda precisariam de uma página de produto, contrato, caminho de suporte e plano de migração. Se um novo site de produto aparecer, suas alegações devem ser confrontadas com os dados de rota, em vez de aceitas por si só.

O que mudaria a pontuação

A maneira mais rápida de a Bodega ICT melhorar a classificação de evidência pública seria anunciar um prefixo relevante para o cliente a partir de AS202019 e mantê-lo visível ao longo do tempo. Um único prefixo visível não provaria resiliência, mas moveria o caso de uma pegada apenas de registro para uma pegada de rede operacional. Se o 2001:678:11b0::/48 pretende estar ativo, BGP visível, DNS reverso, validação de origem de rota e documentação de serviço ajudariam.

Uma página de serviço pública também mudaria a pontuação. Ela deveria dizer se a Bodega ICT vende hospedagem web, VPS, servidores gerenciados, consultoria, serviços de domínio, serviços de rede ou infraestrutura de cliente privada. Deveria listar canais de suporte, regras de uso aceitável, termos de backup, direitos de cancelamento e exportação de dados e a entidade contratante legal. Uma página placeholder padrão não pode fazer esse trabalho.

A divulgação de instalação e fornecedor seria mais importante. A Bodega ICT não precisa publicar identificadores de rack sensíveis, mas os clientes devem poder saber se os serviços rodam na Holanda, qual parte possui o hardware, se uma empresa de hospedagem terceirizada fornece a plataforma física, se a Bodega ICT controla o roteador e se existe algum caminho de backup. Para um pequeno provedor, limites claros de fornecedor podem ser mais valiosos do que alegações vagas de independência.

Prova operacional completaria o quadro. Um cliente deve poder ver uma restauração de backup recente, um aviso de incidente de amostra, um caminho de escalonamento de suporte, um processo de mudança de rota, um processo de exportação de dados e um processo de cancelamento que preserve os dados do cliente tempo suficiente para sair com segurança. Esses são os detalhes que transformam uma pequena identidade de hospedagem em um parceiro de infraestrutura confiável.

Até que essas mudanças apareçam, a pontuação responsável é Negativa para a operação de rede atual. O registro é real. A operação não é publicamente visível. Na cobertura de infraestrutura, essa diferença é o ponto.

Por que Negativo não é um julgamento de caráter

A classificação Negativa aqui é deliberadamente estreita. Não diz que Eric Kelderman ou Bodega ICT é ilegítimo. Não diz que a entidade não pode operar uma rede mais tarde. Não diz que não há serviços privados. Diz que a evidência pública atual não mostra capacidade de hospedagem roteada ativa. Essa é uma afirmação diferente e mais útil para os leitores de infraestrutura.

Essa distinção é importante porque pequenos provedores frequentemente vivem em estados transitórios. Eles podem registrar um AS antes que o primeiro circuito esteja pronto. Podem solicitar espaço IPv6 antes que os serviços do cliente sejam ativados. Podem testar política de rota com um patrocinador antes de mover o tráfego de produção. Podem atender clientes de consultoria sem publicar um catálogo completo de hospedagem. Podem manter seu próprio site em um host terceirizado porque é mais simples ou mais resiliente. Nenhuma dessas escolhas está automaticamente errada.

Mas clientes comprando infraestrutura precisam de prova operacional, não de explicações simpáticas. Se o serviço sendo vendido depende de racks, trânsito e janelas de reparo, o comprador precisa ver o limite do rack, o limite do trânsito e o limite de reparo. Um AS dormente não pode responder a um ticket de suporte. Um site placeholder não pode explicar exportação de dados. Uma linha de política whois não pode substituir um upstream falho. Um domínio estacionado não pode provar que os backups são testados. Esses não são julgamentos morais; são fatos operacionais.

O melhor resultado seria uma reavaliação futura com melhores evidências. Se AS202019 começar a anunciar 2001:678:11b0::/48, se a autorização de origem de rota for publicada, se AS44854 ou AS56393 se tornarem vizinhos visíveis, se uma página de serviço documentar suporte e termos do cliente, e se os domínios forem trazidos para um modelo operacional claro, a classificação deve subir. Até lá, o registro público é melhor tratado como uma identidade de infraestrutura inicial ou dormente.

As perguntas do comprador são excepcionalmente concretas

Se um comprador encontrar a Bodega ICT como um possível fornecedor de hospedagem ou serviço gerenciado, a primeira pergunta não deve ser preço. Deve ser: o que exatamente está sendo vendido sob este nome hoje? Se a resposta for consultoria, o comprador precisa de referências, escopo e documentação de entrega. Se a resposta for capacidade hospedada, o comprador precisa ver o domínio de serviço, caminho de suporte, limite de instalação, limite upstream e limite de rota. Se a resposta for revenda, o comprador precisa saber o provedor subjacente e quem detém os dados do cliente durante disputas ou cancelamento.

A próxima pergunta é qual rede transporta o serviço. Um cliente deve perguntar se AS202019 é usado, se 2001:678:11b0::/48 está ativo, se algum espaço IPv4 é atribuído e se as rotas aparecem navisão geral de prefixo do RIPEstatou em coletores de rota públicos. Se o serviço roda em um host terceirizado, o provedor deve dizer isso diretamente. Não há nada inerentemente errado com revenda ou hospedagem gerenciada acima de outra plataforma, mas o risco do cliente é diferente de comprar serviço em um AS controlado pelo provedor.

A pergunta de suporte deve ser igualmente explícita. O papel de abuso RIPEACRO63211-RIPEe o objeto de pessoaERIC800são contatos de registro, não uma central de atendimento ao cliente. Um cliente deve perguntar sobre horários normais de suporte, suporte de emergência, tratamento de abuso, escalonamento de faturamento, regras de preservação de dados e metas de resposta. Se o único contato público é um endereço de e-mail, isso não é suficiente para infraestrutura crítica.

A pergunta de instalação deve ser formulada sem assumir propriedade. A Bodega ICT possui servidores, aluga servidores, aluga colocation, executa máquinas virtuais em um host terceirizado ou fornece consultoria em torno da infraestrutura de outra pessoa? Se servidores físicos existem, onde estão, quem pode acessá-los, quem substitui hardware e o que acontece fora do horário comercial? Se infraestrutura virtual existe, quem controla snapshots, backups, política de firewall e credenciais do cliente? Essas perguntas decidem se o provedor pode reparar o serviço ou apenas encaminhar uma solicitação para outro fornecedor.

A pergunta de contrato deve cobrir a saída bem como o uptime. Um provedor fácil de contratar, mas difícil de sair, cria risco evitável. Os clientes devem exigir exportação de dados, entrega de backup, transferência de DNS, transferência de domínio, acesso a logs e termos de encerramento de conta. ANIST SP 800-146é útil aqui porque trata a aquisição de nuvem como um problema de portabilidade e contrato, não apenas uma escolha de tecnologia. ANIST SP 800-145também é um lembrete de que os serviços de nuvem ainda dependem de redes, servidores, armazenamento e aplicativos. Essas camadas têm que ser nomeadas antes que possam ser confiáveis.

Finalmente, o comprador deve perguntar como a evidência pública será mantida atualizada. Se AS202019 ficar online, quem atualiza objetos de rota, quem publica ROAs e quem monitora a visibilidade de rota? Omaterial RPKI do RIPE NCCexplica o mecanismo de autorização de origem de rota, e aRFC 6811explica o modelo de validação. Um pequeno provedor não precisa publicar todos os detalhes do roteador, mas deve ser capaz de explicar quem possui as mudanças de rota e como os erros são corrigidos. Sem isso, mesmo uma rota ativa futura permaneceria apenas um sinal de garantia parcial.

O ponto prático final é o momento. Um AS novo ou reativado pode passar de dormente a visível rapidamente, e uma página de produto público pode aparecer antes que a evidência de rota alcance. Isso não significa que o primeiro cliente deve se tornar o caso de teste. Um comprador deve esperar por uma janela de observação estável, repetir verificações de rota por mais de um dia, confirmar que DNS, correio e canais de suporte são separados o suficiente para sobreviver a um incidente de infraestrutura, e exigir um caminho de saída por escrito antes de armazenar dados de produção. Em um contexto de pequeno provedor, paciência é um controle.

Permite que o cliente veja se o provedor está construindo uma superfície operacional durável ou apenas uma presença de registro temporária. Um mínimo sensato seria vários dias consecutivos de origem de rota visível, disponibilidade de página de contato, acessibilidade de suporte externo e um teste de restauração ou exportação não produtiva bem-sucedido antes que qualquer serviço crítico seja movido. Qualquer coisa menos deixa o cliente financiando o primeiro ponto de prova público do provedor, com dados de produção em risco antes que a responsabilidade operacional esteja clara. Esse risco é evitável.

A leitura operacional

HOSTING Eric Kelderman trading as Bodega ICT é melhor lido como uma identidade de infraestrutura registrada na RIPE cuja superfície de rede pública ativa ainda não se materializou. O registro AS202019 é específico e recente, o registro da organização nomeia Eric Kelderman trading as Bodega ICT, e as linhas de política nomeiam pares pretendidos. Mas o RIPEstat não vê o AS anunciado, não vê prefixos atuais, não vê vizinhos e mostra o IPv6 /48 no whois mas não no BGP.

A evidência de domínio visível é igualmente cautelosa.bodega.nlé uma página de hospedagem padrão em infraestrutura de aparência terceirizada.bodegaict.nlresolve através de hospedagem estacionada/terceirizada e correio do Google. Essas são superfícies de identidade legítimas, mas não provam uma plataforma de hospedagem operada pela Bodega. Também não dão aos clientes o contrato público, suporte ou detalhe de migração necessários para decisões críticas de infraestrutura.

O valor de monitoramento ainda é real. Uma identidade RIPE recente, uma organização holandesa nomeada e um objeto de rota IPv6 preparado dão aos observadores alças concretas para observar se o serviço começar. O erro seria converter essas alças em uma alegação de hospedagem no tempo presente antes que uma rota, superfície de produto, caminho de suporte e modelo de recuperação estejam visíveis juntos.

Por enquanto, a Bodega ICT pertence a uma lista de monitoramento, não a uma lista de fornecedores. Se AS202019 começar a anunciar prefixos, se um site de produto aparecer ou se evidência de instalação e suporte se tornar pública, a avaliação deve ser revisitada. Até lá, os compradores não devem inferir capacidade de hospedagem recuperável da presença de um objeto RIPE limpo. Racks, trânsito e janelas de reparo só se tornam proteção ao cliente quando são visíveis, contratados e testados.