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 do AS para AS202019do RIPEstat identificaBODEGA-HOSTING Eric Kelderman trading as Bodega ICT, e oobjeto aut-num AS202019do Banco de Dados 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 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. Ele 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 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 atual de rota pública AS202019, nenhum prefixo de cliente atual visível, nenhuma observação ativa de vizinho, nenhum site de produto resolvendo em seus prováveis domínios de identidade e nenhuma evidência pública de instalação, suporte, rack, backup ou migração que apoiaria tratá-la como capacidade hospedada ativa.

O nome diz hospedagem, a tabela de rotas 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 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 algo 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 IPv6 /48 no whois, mas não no BGP. Essa combinação não é uma rede de hospedagem ativa na tabela de rotas 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 estão 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 uma alegação de que AS202019 está transportando capacidade de hospedagem em produção.

A conclusão correta é, portanto, estreita: a Bodega ICT tem uma identidade recente de recurso numérico RIPE, mas a internet pública não mostra atualmente essa identidade entregando serviço roteado. Os compradores devem pedir evidências de rota atuais, 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 funcional

Os dados whois do RIPEstat paraAS202019listam 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 administrativos e técnicoseric800eERIC800, status ASSIGNED e criação em 23 de janeiro de 2026. Oobjeto aut-numdo Banco de Dados RIPE mostra a mesma estrutura.

Oresultado da pesquisa RIPE para Bodega ICTfornece 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 RIPE que ancora a identidade de 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. Avisão de consistência de roteamento AS do RIPEstat para AS202019lista esses peers 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 da ativação de circuitos, depois que os circuitos são retirados, 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 IPv6 ou alocação 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 visivelmente roteado.

Dados históricos do RIPEstat adicionam nuance. 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 RIPE atual, no entanto, foi criado em janeiro de 2026. Números AS podem ser reatribuídos, reaproveitados, patrocinados de forma diferente ou re-registrados ao longo do tempo. Isso significa que a visibilidade histórica do prefixo 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 se concentrar 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 baixa nota operacional. O domíniobodega.nlresolve, mas a página web é um placeholder de hospedagem padrão: "Bem-vindo ao lar do bodega.nl" e "Para alterar esta página, faça upload do seu site no diretório public_html," 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 nomes 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 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. Verificações DNS locais mostraram registro A 2.57.91.91, registro AAAA 2a02:4780:84::32, servidores de nomesns1.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. Suporta a existência de uma superfície de e-mail e identidade. Não suporta uma alegaçã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 importa porque o próprio site de um pequeno provedor costuma ser 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 identidade e pistas de 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 teria que ser verdade para capacidade hospedada

Para que a Bodega ICT seja um provedor de capacidade hospedada ativo no sentido relevante para esta série de cobertura, várias coisas teriam que ser provadas. 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 rodam. Terceiro, os clientes precisariam de termos de suporte, backup, faturamento e 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.

A evidência pública atual não satisfaz 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 tiers de produtos, localizações 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 rotas públicas 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 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 escrita sobre o que acontece quando equipamento, trânsito, DNS, faturamento ou backup falham. O objeto RIPE pode ajudar a identificar a parte a ser perguntada.

Não pode responder às questões operacionais por si só.

O tempo também importa. Se AS202019 se tornar visível amanhã, um instantâneo 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 fora da produção. 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 carregar mais peso.

As dependências físicas permanecem as mesmas para qualquer serviço de hospedagem. Um servidor tem que estar em uma sala. A sala precisa de energia e refrigeração. 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 de forma privada, 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 terceiro, não da própria rede da Bodega. Se futuros serviços de cliente migrarem para AS202019, os clientes precisarão de uma revisão nova 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 peers 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. Exige 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 alguma 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 naquele 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 rotas pública, então o artigo não deve pontuar a rede como média ou forte apenas porque o objeto de registro está limpo. O objeto de registro é um documento inicial. A tabela de rotas é 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 depois. Cada possibilidade tem implicações diferentes.

Se o serviço ainda não estiver ativo, então a due diligence correta é a prontidão de lançamento: propriedade do prefixo, ativação de 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 é a 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 é o limite do 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.nlser uma página placeholder significa que um cliente em potencial não pode inspecionar os termos do produto lá.bodegaict.nlusar DNS-parking e correio Google/Hostinger sinaliza uma superfície de identidade, mas não uma plataforma de infraestrutura. Não há portal de tickets público, 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. 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. Suporta nenhuma rota de cliente pública AS202019 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 evidência de capacidade

A evidência de domínio merece seu próprio tratamento porque é fácil 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 acessar comunicados de suporte durante uma interrupção. Pode usar o Google Mail ou outra pilha de SaaS para correio porque a confiabilidade do correio é um problema operacional diferente da hospedagem de servidores de cliente.

Pode estacionar um domínio durante uma reformulação de marca ou antes de um lançamento completo de serviço.

A questão neste caso não é que a hospedagem externa existe. A questão é que a hospedagem externa é a única superfície pública visível. A página placeholderbodega.nl, os servidores de nomes ZXCS vistos nas verificações DNS locais e as referências SPF para filtragem ZXCS mostram um domínio que está vivo, mas não operando como uma vitrine pública de hospedagem. O padrão DNSbodegaict.nl, com servidores de nomes DNS-parking, registros MX do Google e includes SPF Hostinger/Google, mostra um domínio de identidade e configuração de correio, 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 importa 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 existe outro domínio de serviço, 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 terceiro por trás de 185.104.29.66 ou a configuração DNS do domínio, não AS202019. Se o correio debodegaict.nlestiver atrasado, o problema pode envolver roteamento de correio Google, autorização de correio Hostinger ou estacionamento DNS, em vez de uma rede operada pela Bodega. Por outro lado, se AS202019 se tornar ativo mais tarde, um cliente pode 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 correio? Qual canal de contato sobrevive se a rota do próprio provedor cair? Sem essas respostas, o uptime do domínio não prova capacidade de infraestrutura do cliente.

Como testar novamente AS202019 se ele ficar online

A classificação deve mudar se o quadro de rota pública mudar. O primeiro reteste é simples: verifiqueprefixos anunciados do RIPEstat para AS202019estatus de roteamento do RIPEstat para AS202019. Se algum começar a mostrar prefixos atuais, registre a lista de prefixos, o momento da primeira visualização, a contagem de endereços visível, o status IPv4 versus IPv6 e o número de peers RIS vendo a rota. Isso estabelece se o AS passou do estado de registro para o estado operacional.

O segundo reteste é a diversidade upstream. Verifiquevizinhos ASN do RIPEstat para AS202019e compare comconsistê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, verifiquevalidaçã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 de registro. Compare prefixos ativos com oobjeto AS202019 do Banco de Dados RIPE, oregistro de organização do Banco de Dados RIPE para Bodega ICTe oregistro do Banco de Dados 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 nos quais os clientes confiariam durante incidentes.

O quinto reteste é o alinhamento de 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 classificação

A maneira mais rápida para a Bodega ICT melhorar a classificação de evidência pública seria anunciar um prefixo relevante para o cliente 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 classificaçã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 privada de cliente. 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 importaria mais. A Bodega ICT não precisa publicar identificadores de rack sensíveis, mas os clientes devem ser capazes de aprender se os serviços rodam na Holanda, qual parte possui o hardware, se uma empresa de hospedagem terceira 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 ser capaz de ver uma restauração de backup recente, um aviso de incidente de amostra, um caminho de escalada 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 classificaçã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 nota 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 hospedada roteada ativa. Essa é uma afirmação diferente e mais útil para leitores de infraestrutura.

Essa distinção importa porque pequenos provedores frequentemente vivem em estados transitórios. Eles podem registrar um AS antes que o primeiro circuito esteja pronto. Eles podem solicitar espaço IPv6 antes que os serviços do cliente estejam habilitados. Eles podem testar política de rota com um patrocinador antes de mover tráfego de produção. Eles podem atender clientes de consultoria sem publicar um catálogo completo de hospedagem. Eles podem manter seu próprio site em um host terceiro 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 do 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 com falha. Um domínio estacionado não pode provar que os backups são testados. Essas não são opiniões 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 de 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 o preço. Deveria ser: o que exatamente está sendo vendido sob este nome hoje? Se a resposta é consultoria, o comprador precisa de referências, escopo e documentação de entrega. Se a resposta é capacidade hospedada, o comprador precisa ver o domínio de serviço, caminho de suporte, limite de instalação, limite de upstream e limite de rota. Se a resposta é revenda, o comprador precisa saber o provedor subjacente e quem detém os dados do cliente durante disputas ou cancelamento.

A próxima questão é 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 terceiro, 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, escalação 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, roda máquinas virtuais em um host terceiro 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 a outro fornecedor.

A pergunta de contrato deve cobrir a saída tanto quanto o uptime. Um provedor que é fácil de entrar, 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.NIST SP 800-146é útil aqui porque trata a contratação de nuvem como um problema de portabilidade e contrato, não apenas uma escolha de tecnologia.NIST SP 800-145também é um lembrete de que 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 da rota?O material de RPKI do RIPE NCCexplica o mecanismo de autorização de origem de rota, eRFC 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 é responsável por mudanças de rota e como erros são corrigidos. Sem isso, mesmo uma futura rota ativa permaneceria apenas um sinal de garantia parcial.

O ponto prático final é o tempo. Um AS novo ou reativado pode passar de dormente a visível rapidamente, e uma página de produto pública 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 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 bem-sucedido de restauração ou exportação fora da produção antes que qualquer serviço crítico seja movido. Qualquer coisa menos deixa o cliente financiando o primeiro ponto de prova pública 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 no 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 peers 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/de terceiros e correio 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.

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.