Resumo

  • Uma rotina de limpeza enviou pending_delete sem valor. A API Addressing interpretou a chamada como uma consulta a todos os prefixos BYOIP; a rotina apagou prefixos e vínculos de serviço dependentes.
  • Cerca de 1.100 prefixos foram retirados. Aproximadamente 800 voltaram com novo anúncio; perto de 300 também perderam configurações de serviço na borda e exigiram uma restauração global posterior. Recolocar a rota era apenas uma parte da recuperação.

A segunda espera

O relato da Cloudflare sobre 20 de fevereiro de 2026 pode ser resumido como uma falha de BGP. O ponto mais relevante veio depois que os anúncios começaram a voltar: para alguns prefixos, os sistemas de borda já não tinham o vínculo que dizia qual produto deveria processar o tráfego. A rota reapareceu antes do serviço.

Um endereço IP público não é uma aplicação. O prefixo pode estar registrado em nome do cliente, autorizado para anúncio pelo provedor, presente na base de endereçamento do provedor, anunciado via BGP, associado a um produto e configurado nas máquinas de borda. São estados ligados, mas diferentes. Ver a rota de fora não prova que o pacote alcançará o serviço correto.

Segundo o post-mortem, uma tarefa periódica deveria automatizar a remoção de prefixos que clientes solicitavam retirar do BYOIP. Ela chamou a API usando pending_delete sem valor. Na implementação descrita, a consulta só filtrava os itens pendentes quando o valor textual do parâmetro não estava vazio. Sem valor, a API devolveu todos os prefixos BYOIP. A tarefa tratou cada resultado como elegível para exclusão e removeu objetos dependentes, inclusive vínculos de serviço.

A Cloudflare diz que não houve ataque. A versão da Addressing API foi implantada às 17h46 UTC; dez minutos depois a tarefa começou a rodar. Engenheiros identificaram e interromperam o processo às 18h46. Nesse intervalo, cerca de 1.100 prefixos foram retirados. A empresa informa que isso correspondeu a 25% dos seus 4.306 prefixos BYOIP anunciados globalmente. O relatório também cita uma visão de 6.500 prefixos para um par de rede; é outro denominador e não deve ser confundido com o total mundial de BYOIP.

A mudança foi aplicada de forma iterativa. Isso conteve o alcance: ela foi revertida antes de atingir todos os clientes. É um controle relevante de exposição, mas não uma estratégia de recuperação por si só.

Anunciar não é atender

A documentação da Cloudflare separa anúncio BGP de vínculo de serviço. O anúncio atrai o tráfego do prefixo para a rede da empresa; o vínculo direciona esse tráfego para CDN, Spectrum ou Magic Transit. No CDN, mapas de endereços podem acrescentar outra camada. Se a automação apaga tanto o prefixo quanto seus vínculos, anunciar a rota novamente pode devolver o tráfego à rede do provedor sem reconstituir o caminho do produto na borda.

Por isso, a solução pelo painel atendia apenas parte dos casos. Às 19h19 UTC, a Cloudflare orientou clientes a anunciar novamente os prefixos. Por volta das 20h20, cerca de 800 tinham sido recuperados. Quase 300 não podiam ser corrigidos com uma simples mudança de status: suas configurações de serviço também haviam sumido dos sistemas de borda. O cliente não podia recriar um vínculo que já não existia na configuração acessível à sua conta. Os engenheiros precisaram restaurar esse estado e propagar uma configuração global, concluída às 23h03 UTC. A empresa informou duração total de seis horas e sete minutos.

O post-mortem público não informa quantos clientes, regiões, perdas de receita ou créditos de SLA foram afetados. Ele mostra, no entanto, três trajetórias: apenas a rota retirada, alguns vínculos removidos ou todos os vínculos de serviço ausentes. Sob o rótulo de uma única “falha BYOIP” havia diferentes responsáveis e prazos de retorno.

O site one.one.one.one também apresentou erros HTTP 403. A Cloudflare ressalta que as consultas DNS do resolvedor público 1.1.1.1, inclusive por DNS sobre HTTPS, não foram afetadas. O erro na página web indicava um impacto em uma superfície atendida por BYOIP, não uma interrupção do resolvedor. Essa distinção evita que as equipes investiguem o componente errado.

Configuração também é infraestrutura

A Cloudflare descreve a Addressing API como um conjunto autoritativo de endereços cujas mudanças eram refletidas na rede global. Solicitações de clientes acionavam bancos de dados e fluxos operacionais que alteravam anúncios e vínculos de produto. O relato reconhece que a configuração desejada pelo cliente e as ações operacionais usavam o mesmo estado persistido. Isso dificultou a reversão: foi necessário recorrer a snapshots do banco, em vez de comparar o estado pretendido com o estado em execução.

A lacuna de testes também foi específica. Dados de staging e simulações não cobriram o cenário. O fluxo de autoatendimento do cliente foi testado; a tarefa independente que alterou dados sem solicitação explícita não. O caminho iniciado por uma pessoa pode funcionar corretamente enquanto uma rotina agendada que reutiliza a mesma API causa danos. Testar apenas a interface deixa fora do modelo a identidade e a autoridade da automação.

As medidas anunciadas vão além de validar o parâmetro: padronizar o esquema da API, separar estado configurado do operacional, aplicar snapshots em etapas sob métricas de saúde, interromper ou reverter automaticamente uma propagação ruim e acionar um disjuntor diante de retiradas rápidas ou abrangentes. A Cloudflare também citou sinais de saúde dos serviços dos clientes. O post-mortem registrou planos e trabalhos em andamento; não confirma sua conclusão posterior.

O valor do BYOIP é manter a identidade de endereço do cliente ao usar a rede e os produtos do provedor. O arranjo operacional é mais complexo: o cliente pode possuir o bloco e autorizar seu anúncio, enquanto o provedor opera o plano de controle que retira a rota, associa um produto e distribui a configuração para a borda. Um ativo portátil ainda pode depender de um estado que seu proprietário não consegue reconstruir sozinho.

Isso não é uma crítica ao roteamento gerenciado. É um motivo para definir continuidade no limite do serviço. A documentação de anúncio dinâmico da Cloudflare diz que uma resposta API bem-sucedida confirma o registro do pedido; a propagação da rota leva tempo adicional. O guia de BYOIP também pede que os vínculos de serviço estejam prontos antes do anúncio de produção. Confirmação recebida e serviço funcionando são provas diferentes.

O que uma promessa de continuidade precisa provar

O cliente precisa saber qual estado falhou e quem pode repará-lo, não apenas se o provedor anuncia um prefixo. O cronograma de recuperação deve distinguir quatro marcos: interrupção da tarefa defeituosa; visibilidade da rota em observadores externos; restauração dos vínculos e da configuração de borda; e sucesso do tráfego da aplicação. Cada marco tem um responsável e um relógio próprios.

A aceitação pode incluir um exercício em que a rota voltou, mas o vínculo de serviço está ausente. O provedor detecta essa diferença? Consegue restaurar a configuração de um cliente sem reverter de forma arriscada o banco inteiro? A saúde do produto, e não apenas o número de rotas, pode interromper o rollout? O que o cliente ainda consegue alterar durante uma pausa de escrita e por quanto tempo?

Uma rota alternativa pode fazer parte do plano, mas não substitui sempre a recuperação do provedor. A orientação operacional da Cloudflare alerta que anúncios sobrepostos e preferência de rotas exigem cuidado. A alternativa só serve se autorização de origem, tratamento de tráfego e comportamento do serviço forem testados em conjunto. Atrair pacotes para uma rede sem a configuração da aplicação apenas desloca a falha.

A conclusão é verificável: o endereço identifica um recurso; a rota declara alcançabilidade; o vínculo define onde o tráfego será processado; serviço ativo é o resultado. Relatórios de continuidade não devem comprimir essas camadas em uma única luz verde. A volta do prefixo foi progresso. Não encerrou a recuperação.

Fontes