ZEROSPACE Christian Wittenberg trading as Zerospace Cloud vende capacidade hospedada que ainda depende de racks, trânsito e janelas de reparo

Resumo

• O RDAP da RIPE identificaAS201801como ZEROSPACE e o vincula a Christian Wittenberg trading as Zerospace Cloud em Veldhoven, Países Baixos; avisão geral do ASdo RIPEstat informou que o AS foi anunciado em 15 de julho de 2026.
• O espaço roteado é pequeno, mas visível: ostatus de roteamentomostrou um prefixo IPv4, 256 endereços IPv4, oito /48s IPv6 e dois vizinhos observados, enquanto osprefixos anunciadoslistaram 185.140.53.0/24 mais oito /48s IPv6 visíveis.
• A higiene de origem de rota é um ponto forte: o RIPEstat retornou RPKI válido para185.140.53.0/24e para2a07:1a84::/48, com a validação IPv6 dependendo de um ROA sobre 2a07:1a84::/44 e comprimento máximo /48.
• A prova operacional é fraca: oPeeringDBlista Zerospace Cloud, mas mostra contagem zero de IX público e zero de instalações; ogeofeedmapeia fatias de endereços em dez rótulos de metrópoles, mas não prova racks locais, energia, hardware, suporte ou capacidade de migração de clientes nessas metrópoles.

A empresa tem uma identidade de rede real, mas a identidade é nova

O primeiro fato que vale a pena separar do ruído é que a Zerospace Cloud não é apenas uma frase de marketing. O RDAP da RIPE emhttps://rdap.db.ripe.net/autnum/201801registra AS201801 como ZEROSPACE, status ativo, com um evento de registro em 30 de janeiro de 2026 e um evento de última alteração em 13 de março de 2026. A entidade organizacional na mesma resposta RDAP é Christian Wittenberg trading as Zerospace Cloud, com Veldhoven, Países Baixos, como endereço público. A resposta RDAP também nomeia Zerospace Cloud Network Operations como contato administrativo e técnico e Zerospace Cloud Abuse Department como contato de abuso. Para um pequeno provedor de nuvem ou hospedagem, essa é uma linha de base útil: há uma organização nomeada, uma rede nomeada e funções de contato operacional nomeadas.

Os registros de endereço correspondem à identidade do AS. O RDAP da RIPE emhttps://rdap.db.ripe.net/ip/185.140.53.0/24identifica 185.140.53.0 a 185.140.53.255 como ZEROSPACE-CLOUD, atribuído PA, país NL, status ativo, com observações apontando para um geofeed emhttp://download.zerospace.cloud/ipam/geofeed.csv. O RDAP da RIPE emhttps://rdap.db.ripe.net/ip/2a07:1a84::/44identifica 2a07:1a84::/44 como ZEROCLOUD, agregado pelo LIR, país NL, status ativo, com a mesma organização e a mesma referência de geofeed. A visão geral do prefixo do RIPEstat parahttps://stat.ripe.net/data/prefix-overview/data.json?resource=185.140.53.0/24identifica AS201801 como o titular de origem para o IPv4 /24.

Esses registros não provam um patrimônio de hospedagem maduro. Eles provam um titular de rota atual com recursos registrados ativos. A idade importa. O sistema autônomo e o agregado IPv6 foram registrados no final de janeiro de 2026, e o IPv4 /24 foi registrado em fevereiro de 2026. Isso é recente o suficiente para que os clientes tratem as evidências operacionais públicas como ainda em formação. Provedores de infraestrutura novos podem ser capazes; eles também podem estar no estágio em que roteamento, marca, processos de suporte e contratos de fornecedores físicos ainda estão sendo consolidados. A pergunta certa não é se o AS201801 existe.

Ele existe. A pergunta certa é quais serviços de cliente podem ser colocados com segurança sobre ele.

O sinal de rota pública está ativo. A visão geral do AS do RIPEstat emhttps://stat.ripe.net/data/as-overview/data.json?resource=AS201801informou o titular como ZEROSPACE Christian Wittenberg trading as Zerospace Cloud e o AS como anunciado na consulta de 15 de julho de 2026. O status de roteamento do RIPEstat emhttps://stat.ripe.net/data/routing-status/data.json?resource=AS201801relatou ampla visibilidade pública: 324 de 326 peers IPv4 RIS e 322 de 322 peers IPv6 RIS estavam vendo o espaço roteado. Essa não é a assinatura de um registro não utilizado. É a assinatura de uma pequena rede que é visível para o sistema de roteamento global.

Para compradores de infraestrutura, a visibilidade de rota ao vivo é necessária, mas não suficiente. Um provedor pode rotear um /24 e vários /48s IPv6 enquanto ainda depende de servidores virtuais alugados, colocation revendido, um único fornecedor de mão de obra remota ou um pequeno conjunto de upstreams. Uma rota mostra que os pacotes podem encontrar os prefixos anunciados. Não mostra que um cliente pode obter hardware de reposição após uma falha de disco, exportar um grande conjunto de dados sob pressão de tempo, recuperar-se de uma falha de armazenamento ou alcançar um humano com autoridade para corrigir um incidente de energia.

A capacidade hospedada transforma a visibilidade de rota em um serviço apenas quando há racks, energia, refrigeração, estoque de hardware, procedimentos de acesso, cobertura de suporte e caminhos de saída por trás dos prefixos.

O patrimônio roteado é pequeno, visível e anunciado de forma desigual

O quadro IPv4 é compacto. Os dados de prefixos anunciados do RIPEstat emhttps://stat.ripe.net/data/announced-prefixes/data.json?resource=AS201801mostraram 185.140.53.0/24 anunciado continuamente durante a janela de 1º a 15 de julho de 2026. O status de roteamento contou isso como um prefixo IPv4 e 256 endereços IPv4. Para um serviço de hospedagem ou nuvem, um /24 pode ser operacionalmente útil, mas é pequeno. Pode suportar um serviço anycast focado, gateways NAT, endpoints de gerenciamento de cliente, um conjunto de nós VPS ou um número limitado de endereços de cliente atribuídos diretamente. Não é, por si só, evidência de um grande patrimônio de computação.

O quadro IPv6 é mais expansivo em matemática de endereços e mais matizado em visibilidade atual. O registro RDAP cobre 2a07:1a84::/44, que contém dezesseis /48s possíveis. O objeto de rede do PeeringDB emhttps://www.peeringdb.com/api/net?asn=201801lista um prefixo IPv4 e dezesseis prefixos IPv6 no perfil. O endpoint de prefixos anunciados do RIPEstat, no entanto, mostrou oito /48s IPv6 visíveis durante a janela de revisão: 2a07:1a84::/48,:1::/48,:2::/48,:3::/48,:4::/48,:5::/48,:6::/48 e:9::/48. A visão de consistência de roteamento do AS do RIPEstat emhttps://stat.ripe.net/data/as-routing-consistency/data.json?resource=AS201801adicionou o detalhe útil de que 2a07:1a84::/44 estava no whois mas não no BGP, enquanto vários /48s estavam tanto no whois quanto no BGP e vários outros /48s estavam no whois mas não no BGP.

Essa diferença importa para capacidade instalada versus capacidade utilizável. Capacidade de endereço instalada é o IPv6 /44 registrado e a declaração do PeeringDB de dezesseis prefixos IPv6. Capacidade roteada utilizável é o subconjunto realmente visível no BGP durante o período relevante. A capacidade utilizável pelo cliente é ainda mais restrita: os prefixos que um cliente pode contratar, rotear através de um site conhecido, proteger com RPKI, monitorar, suportar e mover se um provedor, instalação ou upstream falhar.

Um /44 pode parecer enorme no papel, enquanto apenas /48s selecionados estão ativos no roteamento público e apenas um subconjunto menor está vinculado a serviços de produção.

O tempo do IPv6 também aponta para uma rede em mudança ativa. O RIPEstat mostrou 2a07:1a84::/48 e 2a07:1a84:5::/48 visíveis desde o início de julho, com:5::/48 mostrando uma breve lacuna entre 3 e 5 de julho. Mostrou vários outros /48s começando a visibilidade em 12 de julho de 2026. Isso não prova instabilidade em um sentido que impacta o cliente; novos locais IPv6 ou nós de serviço geralmente entram online em ondas. Isso significa que o cliente deve perguntar quais /48s são considerados produção, quais são alocações de teste ou homologação, quais estão vinculados a um rótulo de cidade e quais têm failover testado.

A validação de origem de rota é uma das melhores partes do registro da Zerospace. O RIPEstat retornou um estado válido para 185.140.53.0/24 emhttps://stat.ripe.net/data/rpki-validation/data.json?resource=201801&prefix=185.140.53.0/24, com AS de origem 201801 e comprimento máximo /24. Retornou um estado válido para 2a07:1a84::/48 emhttps://stat.ripe.net/data/rpki-validation/data.json?resource=201801&prefix=2a07:1a84::/48, validando contra um ROA sobre 2a07:1a84::/44 com comprimento máximo /48. O RPKI não mantém servidores funcionando, mas dá aos filtros de rota uma maneira de distinguir anúncios de origem autorizados dos não autorizados. Para uma rede nova e pequena, essa higiene é importante.

O quadro upstream é visível, mas o quadro de instalações não é

O registro upstream é mais claro que o registro de instalações. Os vizinhos ASN do RIPEstat emhttps://stat.ripe.net/data/asn-neighbours/data.json?resource=AS201801mostraram dois vizinhos observados: AS57758 e AS63473. A visão geral do AS do RIPEstat identifica AS57758 como CBWS Holding B.V. e AS63473 como HostHatch, LLC. A visão whois emhttps://stat.ripe.net/data/whois/data.json?resource=AS201801também lista entradas de política de importação e exportação para AS20473, AS63473 e AS57758, enquanto a observação pública de vizinhos mostrou AS57758 e AS63473 no momento verificado. AS20473 é The Constant Company, LLC na visão geral do AS do RIPEstat, comumente associado à Vultr no nome do AS.

Isso é suficiente para descrever uma superfície de dependência, não suficiente para certificar diversidade. Dois vizinhos observados são melhores que um se eles são realmente independentes no caminho de serviço do cliente, presentes em instalações separadas ou domínios de falha, e ambos configurados para os prefixos do cliente. Mas dois ASNs podem compartilhar o mesmo prédio, mesma sala de meet-me, mesma fibra metropolitana, mesmo evento de energia ou mesma janela de manutenção remota. Os dados públicos de BGP não podem nos dizer se os roteadores Zerospace estão em um rack ou em múltiplos sites.

Não pode nos dizer se ambos os vizinhos carregam todos os prefixos de produção, se o failover é automático, se um vizinho é apenas backup, ou se o plano de controle do cliente depende do mesmo handoff físico.

O PeeringDB aprofunda essa cautela. O registro de rede da Zerospace Cloud no PeeringDB emhttps://www.peeringdb.com/api/net?asn=201801lista AS201801, sitehttps://zerospace.cloud, IRR as-set AS201801:AS-ZEROSPACE-CLOUD, um prefixo IPv4, dezesseis prefixos IPv6, policy_general Open, status ok, um timestamp de criação em outubro de 2022 e um timestamp de atualização em 8 de fevereiro de 2026. Mas o endpoint de LAN de exchange do PeeringDB emhttps://www.peeringdb.com/api/netixlan?asn=201801não retornou linhas de IX público, e seu endpoint de instalação emhttps://www.peeringdb.com/api/netfac?net_id=31374não retornou linhas de instalação pública. O PeeringDB é mantido pelo operador e pode estar incompleto, então uma lista de instalações vazia não é prova de ausência de presença de instalação. É prova de que a prova pública de instalação está ausente.

Para um comprador de nuvem, a ausência de prova de instalação não é um pequeno detalhe. As instalações são onde as promessas de rota se tornam promessas operacionais. Um cliente precisa saber qual data center abriga os servidores, qual entidade contrata o rack, qual equipe de mão de obra remota pode tocar no hardware, se há fontes de energia redundantes, se os gabinetes estão dentro dos limites de energia contratados, como a refrigeração é fornecida e quais cross-connects alcançam quais upstreams.

Sem uma lista pública de instalações ou declaração de instalação de primeira parte, os clientes têm que perguntar diretamente e verificar contratualmente.

Isso é especialmente verdadeiro para a Zerospace porque o geofeed é global enquanto a evidência pública de instalação visível está vazia. Um geofeed pode ser útil para localização de conteúdo, controles de fraude, roteamento de latência e expectativas do cliente. Não pode substituir uma declaração de instalação. Um provedor pode geolocalizar pequenos blocos de endereços para uma cidade porque uma VM, endpoint de túnel, nó revendedor, instância de nuvem ou implantação de parceiro está lá.

Isso não prova racks próprios, servidores sobressalentes, óptica sobressalente, gerenciamento fora de banda, tempo de bateria, cobertura de gerador ou suporte local.

O geofeed descreve rótulos de cidade, não infraestrutura local garantida

O geofeed emhttps://download.zerospace.cloud/ipam/geofeed.csvé um dos artefatos públicos mais informativos no registro da Zerospace. Ele mapeia 185.140.53.0/29 para Amsterdã, 185.140.53.8/29 para Londres, 185.140.53.16/29 para Estocolmo, 185.140.53.24/29 para Seul, 185.140.53.32/29 para Singapura, 185.140.53.40/29 para Hong Kong, /32s selecionados em 185.140.53.48 a 185.140.53.55 para Tóquio, 185.140.53.56/29 para Sydney, 185.140.53.64/29 para Nova York e 185.140.53.72/29 para Los Angeles. Mapeia /48s IPv6 para o mesmo padrão de cidade: 2a07:1a84::/48 para Amsterdã,:1::/48 para Londres,:2::/48 para Estocolmo,:3::/48 para Seul,:4::/48 para Singapura,:5::/48 para Hong Kong,:6::/48 para Tóquio,:7::/48 para Sydney,:8::/48 para Nova York e:9::/48 para Los Angeles.

Isso é um sinal de área de serviço global, não uma prova de capacidade global. No IPv4, a maioria das entradas de cidade são /29s, significando oito endereços cada. As entradas IPv4 de Tóquio são /32s individuais ou agrupamentos muito pequenos, e o geofeed não cobre cada endereço no /24 com uma cidade nomeada explícita. A geolocalização do RIPEstat emhttps://stat.ripe.net/data/geoloc/data.json?resource=185.140.53.0/24e a visualização MaxMind GeoLite emhttps://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=185.140.53.0/24refletiram uma distribuição semelhante, mas também mostraram uma grande parte do IPv4 /24 como Suécia sem cidade na visualização consultada. Isso significa que a imagem de geolocalização pública é mista: algumas fatias de endereço têm rótulos de cidade precisos; grande parte do espaço de endereço IPv4 não se apresenta como um mapa de computação cidade por cidade detalhado.

A visualização de localização IPv6 também precisa de leitura cuidadosa. A geolocalização do RIPEstat parahttps://stat.ripe.net/data/geoloc/data.json?resource=2a07:1a84::/44e a visualização MaxMind GeoLite emhttps://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=2a07:1a84::/44mostraram o /44 dividido em vários /48s rotulados por cidade, com uma parte substancial do agregado aparecendo como Suécia sem cidade. O geofeed lista:7::/48 para Sydney e:8::/48 para Nova York, enquanto o endpoint de prefixos anunciados não mostrou esses /48s entre os oito prefixos visíveis durante esta janela de revisão. Isso não é necessariamente uma contradição; as entradas do geofeed podem descrever localidade pretendida ou registrada enquanto a visibilidade de roteamento muda ao longo do tempo. É um lembrete de que as alegações de localidade devem estar vinculadas ao estado atual da rota.

Os clientes afetados por essa distinção não são apenas usuários finais nessas cidades. Um pequeno provedor de nuvem pode estar servindo gateways VPN, nós de borda, hospedagem gerenciada, cargas de trabalho de desenvolvedor, alvos de backup, infraestrutura de jogos, ambientes de teste, serviços de pequenas empresas ou pontos de acesso regionais. Se uma fatia rotulada como Amsterdã falhar, um cliente europeu pode se importar com a latência e localização legal. Se uma fatia de Hong Kong ou Singapura falhar, os usuários da Ásia-Pacífico podem ver maior latência ou failover para outra região.

Se a fatia de Nova York ou Los Angeles não estiver atualmente roteada, um cliente planejando uma implantação na América do Norte precisa saber se esse local está ativo, reservado, pausado ou pendente.

A pergunta de diligência certa, portanto, não é "o geofeed menciona minha cidade?" É "qual site físico ou virtual atende meu endereço rotulado por cidade, quem opera esse site, quais upstreams o carregam, que energia e hardware estão por trás dele, e como ele será restaurado ou migrado?" Um rótulo de cidade pode ajudar um cliente a decidir o que perguntar. Não deve ser usado como evidência de que a Zerospace possui infraestrutura própria em todas as dez cidades.

O site e o registro DNS revelam uma dependência de disponibilidade separada

O site principal também precisa ser mantido separado da infraestrutura do cliente. O endpoint de cadeia DNS do RIPEstat emhttps://stat.ripe.net/data/dns-chain/data.json?resource=zerospace.cloudmostrou zerospace.cloud usando nameservers autoritativos da Cloudflare, ali.ns.cloudflare.com e rudy.ns.cloudflare.com, com registros A 172.67.142.47 e 104.21.87.70 e registros AAAA 2606:4700:3035::ac43:8e2f e 2606:4700:3036::6815:5746 no momento da consulta em 15 de julho de 2026. O endpoint de cadeia DNS parahttps://stat.ripe.net/data/dns-chain/data.json?resource=download.zerospace.cloudmostrou os mesmos endereços frontados pela Cloudflare para o host de download. O endpoint parahttps://stat.ripe.net/data/dns-chain/data.json?resource=www.zerospace.cloudretornou os nameservers autoritativos da Cloudflare, mas nenhum registro de encaminhamento parawww.zerospace.cloud.

Durante uma verificação HTTPS direta em 15 de julho de 2026,https://zerospace.cloudnão retornou uma página utilizável dentro de um timeout curl de 15 segundos deste ambiente. Verificações anteriores frontadas pela Cloudflare podem revelar falhas de acessibilidade de origem do tipo 522 quando a origem não responde à Cloudflare. Mesmo sem confiar em nenhum resultado HTTP transitório isolado, a evidência DNS mostra que o caminho do site público é mediado pela Cloudflare. Isso é comum e muitas vezes sensato. Também significa que a disponibilidade do site não é a mesma coisa que a disponibilidade de rota do AS201801.

Há duas dependências separadas aqui. Primeiro, a presença web de marketing ou controle da Zerospace depende do DNS e proxy da Cloudflare, mais o serviço de origem que está por trás da Cloudflare. Segundo, os prefixos roteados do cliente da Zerospace dependem do AS201801, seus vizinhos upstream e os locais físicos ou virtuais que carregam esses prefixos. Um comprador não deve inferir que, porque o site está por trás da Cloudflare, o tráfego do cliente está por trás da Cloudflare.

Nem deve inferir que, porque o AS201801 é visível no BGP, o portal do cliente, documentação, avisos de status ou caminho de suporte permanecerão acessíveis durante uma falha na origem do site.

O host de download é interessante porque serviu o geofeed mesmo que o site principal não fosse uma página de serviço público legível durante a verificação. Isso sugere que alguns caminhos frontados pela Cloudflare podem estar acessíveis enquanto outros não. Para as operações do cliente, a questão é se portais críticos, formulários de suporte, painéis de controle, páginas de status, geofeeds e endpoints de API são hospedados independentemente ou compartilham a mesma dependência de origem.

Se a única rota de suporte do cliente for um formulário web por trás de uma origem frágil, então uma falha de rede ou origem pode atrasar a recuperação mesmo quando a rota BGP permanece ativa.

A evidência do site também reduz a quantidade de detalhes de serviço de primeira parte disponíveis para pessoas de fora. Muitos provedores publicam páginas de instalações, termos de produto, objetivos de nível de serviço, procedimentos de suporte, termos de exportação de dados, políticas de backup e documentos legais em seu site. Se o site principal não for legível de forma confiável, a diligência pública tem que confiar mais fortemente em evidências de registro e roteamento. Isso é suficiente para um artigo de identidade de rede. Não é suficiente para uma compra confiante de capacidade hospedada.

As dependências físicas estão principalmente ocultas atrás da camada de rede

O registro público da Zerospace nos dá recursos de rota, mas não nos dá um mapa físico completo. Não há linha pública de instalação no PeeringDB para AS201801. Não há página de instalação pública disponível no site principal nesta revisão. Não há lista publicada de gabinetes, declaração de densidade de energia, design de refrigeração, provedor de mão de obra remota, política de inventário de hardware, arquitetura de backup, página de status ou guia de migração nas evidências disponíveis aqui. Isso não significa que essas coisas não existam. Significa que elas não são comprovadas publicamente.

A pilha de dependência física para um cliente ainda é concreta. Se a Zerospace vende capacidade hospedada, algum servidor ou instância virtual deve estar em algum lugar. Esse algum lugar tem um rack ou máquina host, alimentação de energia, caminho de refrigeração, rede de gerenciamento, porta upstream, dependência de armazenamento e processo de acesso. Se um disco falhar, alguém ou alguma automação deve substituir ou mover a carga de trabalho. Se um roteador falhar, um segundo caminho deve carregar o prefixo. Se um disjuntor de gabinete desarmar, deve haver um plano para esse gabinete.

Se uma instalação tiver uma janela de manutenção, o provedor deve saber quais serviços do cliente estão expostos. Se um endereço rotulado por cidade é na verdade um endpoint virtual em uma região de nuvem maior, o cliente também deve saber disso.

Energia e refrigeração são as partes menos visíveis do registro da Zerospace. Um /24 e um /44 podem ser anunciados a partir de muito pouca infraestrutura física, de máquinas virtuais alugadas, de hosts parceiros ou de um pequeno número de servidores colocalizados. O número de endereços IP, portanto, não diz quase nada sobre a margem de energia. Os clientes precisam saber a alocação de energia instalada, a energia utilizável após redundância, a densidade de refrigeração por rack, as suposições de UPS e gerador da instalação, e se uma única implantação de alta densidade poderia esgotar a margem local do provedor.

Sem essas informações, um comprador não pode distinguir um nó de borda de cidade de uma região de hospedagem resiliente.

O inventário de hardware é igualmente opaco. Um provedor pode rotear endereços globalmente, mas ainda depender de um pool limitado de hosts. Se a Zerospace oferece VPS ou serviços gerenciados, o comprador deve perguntar quantos hosts de produção estão por trás de cada local, se o armazenamento é local ou compartilhado, como as falhas são evacuadas, se existem nós sobressalentes no mesmo local, e se a capacidade de substituição requer pedido de um host terceirizado. A pequena alocação IPv4 torna provável o uso eficiente de endereços; também significa que a escassez de IP público pode afetar os planos de migração e expansão.

O suporte é visível apenas no nível de contato de rede. O RDAP nomeia operações de rede e funções de abuso, o que importa para operações de rota e tratamento de abuso. Não mostra horários de suporte ao cliente, níveis de escalação, objetivos de resposta a incidentes, níveis de suporte pagos, idiomas, ferramentas de chamado ou autoridade de emergência. Um cliente que compra capacidade de infraestrutura deve tratar a existência de contato de rede como o piso, não a promessa de suporte.

A verdadeira questão de recuperação é quem pode agir quando uma sessão de roteador cai, um host falha, um endpoint de cidade desaparece ou um cliente precisa evacuar dados em curto prazo.

Caminhos de falha: rota, upstream, instalação, suporte e migração

O primeiro caminho de falha é a acessibilidade upstream. O AS201801 tinha dois vizinhos observados no RIPEstat, AS57758 e AS63473, e uma lista de políticas whois que também nomeava AS20473. Se o AS57758 ou AS63473 perder uma sessão, o resultado depende se ambos os vizinhos carregam os prefixos afetados, se a engenharia de tráfego é simétrica o suficiente para os caminhos de retorno, e se a falha está isolada a um upstream. Se ambas as sessões terminarem no mesmo site ou dependerem do mesmo handoff local, a redundância pode ser menos útil do que a contagem de AS sugere.

Os clientes devem pedir um diagrama de rota mostrando quais upstreams carregam cada prefixo de produção e onde essas sessões estão localizadas.

O segundo caminho de falha é a autorização ou filtragem de rota. O RPKI é válido para o IPv4 /24 e o padrão IPv6 /44 para /48, o que é bom. Mas os clientes ainda devem perguntar se a Zerospace monitora vazamentos de rota, anúncios inválidos, erros de comprimento máximo e deriva de geolocalização. Um ROA válido pode se tornar operacionalmente doloroso se um provedor posteriormente anunciar uma rota mais específica além do comprimento máximo, se um upstream filtrar inesperadamente, ou se um /48 específico de cidade for adicionado sem autorização de rota correspondente.

O estado atual do RPKI é um controle positivo; não é um substituto para o controle de mudanças.

O terceiro caminho de falha é a perda de instalação ou concentração oculta de instalação. Como o PeeringDB lista zero linhas de instalação pública, os clientes não podem determinar independentemente se múltiplas cidades representam múltiplas instalações, uma sobreposição upstream, ou um patrimônio de revenda. Se um endereço rotulado como Amsterdã e um endereço rotulado como Londres dependem ambos de uma conta de provedor, um relacionamento de faturamento, uma equipe de suporte remoto ou um concentrador de túnel, uma falha nesse relacionamento de provedor pode afetar mais de uma região aparente.

As entradas de geofeed de várias cidades devem ser verificadas contra evidências independentes de instalação, fornecedor e roteamento.

O quarto caminho de falha é o plano de controle e suporte. O DNS frontado pela Cloudflare do domínio principal, o registro www vazio e o site principal indisponível durante a verificação apontam para a importância de saber como os clientes alcançam o suporte durante uma falha. Se o portal do cliente, avisos de status, documentação e formulários de suporte compartilham uma origem frágil, o provedor pode perder a comunicação enquanto o problema de rede ainda está se desenrolando. A recuperação da infraestrutura depende tanto dos caminhos de contato quanto dos pacotes.

Os compradores devem exigir um contato de incidente fora de banda, não apenas um formulário web.

O quinto caminho de falha é a migração. Redes novas mudam. As datas de registro de 2026 da Zerospace, as mudanças de visibilidade IPv6 em julho de 2026 e o layout do geofeed de cidades sugerem uma plataforma ainda sendo expandida ou ajustada. Isso pode ser promissor, mas torna os direitos de saída e os caminhos de migração essenciais.

Os clientes precisam saber se podem exportar imagens de disco, snapshots, dumps de banco de dados, logs e registros DNS; se podem manter endereços IPv4 durante uma mudança; se as atribuições de /48 IPv6 são portáteis dentro dos locais da Zerospace; quanto tempo leva a exportação de dados; e o que acontece se um local for desativado ou rerroteado.

Capacidade instalada, capacidade utilizável e capacidade comprada são coisas diferentes

A evidência da Zerospace é um exemplo útil de por que a capacidade de nuvem tem três camadas. Capacidade instalada é o que o provedor pode plausivelmente afirmar possuir ou controlar: AS201801, 185.140.53.0/24, 2a07:1a84::/44, política de rota registrada e um perfil no PeeringDB. Capacidade de rede utilizável é o que aparece no roteamento público e pode ser alcançado com autorização de origem válida: um IPv4 /24, oito /48s IPv6 visíveis na janela de revisão, dois vizinhos observados e ampla visibilidade RIPE RIS.

Capacidade comprada é o que um cliente pode realmente consumir sob contrato, com termos de computação, armazenamento, largura de banda, suporte e migração anexados.

A distância entre essas camadas é onde o risco se esconde. Um cliente pode ver dez cidades de geofeed e assumir dez regiões de produção. A evidência não suporta essa suposição. Um cliente pode ver dezesseis prefixos IPv6 no PeeringDB e assumir que todos os dezesseis estão ativos. O RIPEstat mostrou oito /48s visíveis durante esta janela, com alguns /48s listados no whois não presentes no BGP. Um cliente pode ver dois vizinhos upstream observados e assumir redundância de rota. Isso só é verdade se os dois vizinhos são independentes para os prefixos e domínio de falha do cliente.

Um cliente pode ver RPKI válido e assumir resiliência operacional. O RPKI ajuda na autenticidade da rota, não no reparo do servidor.

Isso não torna a Zerospace inutilizável. Torna-a um provedor que deve ser comprado com um modelo de evidência estreito. Um desenvolvedor que precisa de um pequeno serviço roteado, um laboratório IPv6, um experimento de borda ou um endpoint hospedado não crítico pode achar a pegada pública adequada, desde que os termos comerciais correspondam ao risco. Uma empresa movendo cargas de trabalho de produção, dados de clientes, sistemas adjacentes a pagamentos, dados de saúde ou registros regulamentados deve exigir mais do que evidências públicas de roteamento.

Deve exigir detalhes de instalação, compromissos de suporte, separação de backup, termos de saída do cliente e prova de que a cidade ou região que está sendo comprada está realmente ativa.

A falta de linhas públicas de instalação também muda a forma de pensar sobre a prova de redundância. Redundância não é uma contagem de nomes de cidades. É uma prova de que duas falhas não compartilham a mesma causa. Para a Zerospace, essa prova precisaria mostrar pelo menos: independência upstream, independência de instalação, independência de energia, independência de armazenamento ou backup, independência do plano de gerenciamento e independência de escalação de suporte. Se algum deles estiver faltando, então uma segunda região rotulada pode ainda falhar junto com a primeira.

Capacidade instalada versus capacidade utilizável também afeta o preço. Provedores pequenos podem ser atraentes porque são flexíveis, acessíveis e tecnicamente diretos. Mas uma oferta de baixo custo pode excluir as peças sobressalentes, horas de equipe, margem de trânsito ou retenção de backup que os grandes compradores de nuvem assumem. Os clientes devem precificar as peças ausentes explicitamente. Se uma carga de trabalho precisa de recuperação rápida, o cliente deve pagar e testar essa recuperação.

Se uma carga de trabalho só precisa de um endpoint público e pode ser reconstruída em outro lugar, o cliente pode aceitar um serviço mais leve e manter sua própria portabilidade.

A localidade dos dados é declarada através do geofeed, mas a localidade legal e operacional permanece em aberto

O geofeed fornece um sinal de localidade de dados, mas não é um contrato de soberania de dados. Ele diz aos consumidores de geolocalização como a Zerospace quer que as fatias de endereço sejam interpretadas. Não diz onde os discos estão, onde os backups estão, qual empresa opera o host, onde a equipe de suporte está localizada, qual lei rege o serviço, ou quais subcontratados podem acessar os dados do cliente. Essa distinção é essencial para clientes na Europa, Ásia-Pacífico e América do Norte que podem ler Amsterdã, Londres, Hong Kong, Tóquio ou Nova York como uma declaração de conformidade ou latência.

Para clientes europeus, o registro de organização holandesa e o código de país Países Baixos nos registros de endereço são úteis, mas não provam que todos os dados do cliente permanecem nos Países Baixos ou no Espaço Econômico Europeu. O próprio geofeed aponta para fora da Europa para várias fatias. Para clientes da Ásia-Pacífico, os rótulos Seul, Singapura, Hong Kong, Tóquio e Sydney podem ser úteis para latência, mas o cliente ainda precisa saber se os dados são processados localmente, proxy através de outro país, backup em outro lugar ou operados por um fornecedor de hospedagem terceirizado.

Para clientes dos EUA, os rótulos Nova York e Los Angeles exigem as mesmas perguntas.

A leitura mais segura é que a Zerospace declarou localidade de rede para blocos de endereço, não garantias de residência de dados. Os clientes devem pedir termos específicos da região que nomeiem o fornecedor de hospedagem ou classe de instalação, definam onde os dados do cliente e backups residem, identifiquem locais de acesso de suporte e descrevam como logs, snapshots e exportações são tratados. Se o serviço é apenas uma sobreposição de rede ou pequena presença de borda, o contrato deve dizer isso claramente. Se a Zerospace tem infraestrutura física local, o contrato deve declarar os limites operacionais.

A localidade também se intersecta com a resposta a falhas. Se um endereço rotulado como Hong Kong é servido por um parceiro em Hong Kong, o caminho de reparo pode depender da fila de suporte desse parceiro. Se é servido por um nó virtual de um provedor de nuvem global, o reparo pode depender da conta desse provedor e do status da região. Se é servido através de um túnel de outro local, o rótulo de geofeed pode ser útil para aplicações, mas não para independência física. Nenhum desses modelos está automaticamente errado. O que importa é a divulgação.

Um cliente não pode projetar resiliência em torno de um nome de cidade a menos que saiba o que o nome da cidade realmente significa.

Quem é afetado se o serviço falhar

Os usuários afetados dependem do que a Zerospace está realmente vendendo. A evidência pública suporta uma identidade de rede de nuvem ou hospedagem, mas não publica um catálogo de produtos que possa ser lido independentemente aqui. Ainda assim, as classes de dependência são claras. Os clientes que usam a Zerospace para endpoints hospedados, instâncias VPS, nós de borda, gateways VPN, serviços adjacentes a DNS, sites de pequenas empresas ou backends de aplicação seriam afetados por retirada de rota, falha upstream, falha de servidor, perda de armazenamento, atraso de suporte ou falha de controle do site.

Usuários finais regionais notariam a camada de geofeed primeiro. Se o tráfego destinado a Amsterdã, Londres ou Estocolmo mudar para um local mais distante, aplicações sensíveis à latência podem degradar. Se as fatias de Seul, Singapura, Hong Kong ou Tóquio estiverem indisponíveis, os usuários da Ásia-Pacífico podem ver caminhos mais longos ou falha de serviço. Se as fatias de Nova York ou Los Angeles não forem roteadas quando esperado, os usuários norte-americanos podem não obter a localidade prometida em um design comercial. O mapa de geofeed, portanto, cria expectativas mesmo quando não prova capacidade.

Os clientes também seriam afetados pela escassez de endereços. Com apenas um IPv4 /24 visível, as atribuições IPv4 são um recurso finito. Se um cliente precisar de mais endereços IPv4 públicos, expansão rápida ou migração limpa para outro provedor, o pool limitado de IPv4 se torna uma restrição prática. O IPv6 é mais abundante, mas a adoção de IPv6 ainda depende dos usuários, redes e aplicações do cliente. Um serviço que funciona bem sobre IPv6 ainda pode precisar de IPv4 para clientes, correio, sistemas legados ou integrações de terceiros.

O cliente mais exposto é aquele que trata a Zerospace como uma plataforma de nuvem completa sem testar a recuperação. Se o serviço é usado para experimentos de borda não críticos, o cliente pode reconstruir em outro lugar. Se contém bancos de dados primários, serviços de produção voltados para o cliente ou backups insubstituíveis, o cliente precisa de provas mais fortes. O registro público ainda não mostra o suficiente para justificar tratar o AS201801 como uma plataforma madura de múltiplas regiões por padrão.

O que aumentaria o grau de evidência

A Zerospace poderia aumentar rapidamente o grau de evidência publicando uma declaração de infraestrutura datada. A declaração pública mais útil distinguiria infraestrutura própria, colocation alugado, nós virtualizados e locais de parceiros. Mapearia cada cidade no geofeed para o tipo de implantação lá, nomearia se a computação do cliente está disponível nesse local, declararia se IPv4 e IPv6 são ambos de produção, e explicaria quais upstreams carregam cada prefixo. Não precisaria revelar detalhes sensíveis; precisaria separar a geografia de marketing da dependência operacional.

A próxima melhoria seria a prova de instalação e suporte. Linhas de instalação no PeeringDB, uma página de status pública, uma página de suporte ao cliente, contatos de emergência fora de banda, uma política de backup e restauração, e um guia de migração ou exportação de dados melhorariam materialmente a confiança do comprador. Um pequeno provedor pode ser credível sem publicar cada nome de fornecedor, mas deve mostrar como os clientes se recuperam quando um host, rota, instalação ou conta falha. O registro público atual é pesadamente inclinado para evidências de registro e BGP.

O RPKI deve continuar sendo um ponto forte. A Zerospace já tem autorização de origem de rota válida para as rotas IPv4 e IPv6 revisadas. Evidências públicas futuras devem manter essa disciplina à medida que novos /48s aparecem. Se:7::/48 e:8::/48 devem se tornar locais de cidade ativos, a visibilidade e validação de rota devem estar alinhadas com o geofeed. Se algumas entradas de geofeed são reservadas ou planejadas, o provedor deve dizer isso em vez de deixar os clientes inferirem localidade de produção a partir de um arquivo de localização de endereço.

O grau de evidência cairia se o AS201801 perdesse ampla visibilidade de rota, se o RPKI se tornasse inválido, se o geofeed continuasse a anunciar locais que permanecem não roteados sem explicação, se o site permanecesse intermitentemente ilegível sem um caminho de suporte separado, ou se os clientes não pudessem obter detalhes de instalação e recuperação. Também cairia se o provedor vendesse resiliência multi-região enquanto depende de uma única conta, única instalação, única fila de suporte ou único domínio de falha upstream.

Conclusão para operadores dependentes

A Zerospace Cloud tem evidência pública suficiente para ser tratada como uma rede roteada real, não o suficiente para ser tratada como uma plataforma de hospedagem global comprovada. Os registros RIPE vinculam AS201801, 185.140.53.0/24 e 2a07:1a84::/44 a Christian Wittenberg trading as Zerospace Cloud. O RIPEstat mostra o AS anunciado com ampla visibilidade IPv4 e IPv6. O RPKI é válido para as origens IPv4 e IPv6 revisadas. O PeeringDB lista um objeto de rede Zerospace Cloud. O geofeed é detalhado e atual o suficiente para apoiar perguntas sérias sobre o design geográfico do serviço.

A cautela é igualmente clara. O patrimônio IPv4 é um /24. A visibilidade IPv6 cobre oito /48s na janela de revisão, não todos os /48s implícitos pelo /44 e perfil. O PeeringDB não mostra linhas públicas de instalação ou IX. O site principal não foi uma fonte confiável de detalhes de serviço durante a verificação. O geofeed mapeia cidades, mas não prova racks, energia, refrigeração, hardware, suporte ou capacidade de migração nessas cidades. O quadro upstream atual mostra dois vizinhos observados, mas os dados públicos de roteamento não provam domínios de falha independentes.

Um comprador prático deve, portanto, usar a Zerospace apenas com evidência explícita para o serviço exato que está sendo comprado. Pergunte onde a carga de trabalho executa, quem opera a instalação ou host, quais upstreams carregam os prefixos, se IPv4 e IPv6 estão ambos ativos no local solicitado, como falhas de energia e hardware são tratadas, como o suporte é alcançado durante uma falha no site, como os backups são separados, e como os dados podem ser exportados. Trate o geofeed como um mapa de localidade de endereço reivindicada, não como um mapa de regiões de nuvem garantidas.

Para cargas de trabalho não críticas, o registro público pode ser suficiente para justificar testes. Para serviços de produção, a evidência ausente é importante demais para ser ignorada. A capacidade hospedada sempre se resolve em dependências físicas. No caso da Zerospace, a Internet pública pode ver as rotas; os clientes ainda precisam de prova dos racks, independência upstream, autoridade de suporte e caminhos de migração por trás deles.