Resumo

  • Em 20 de fevereiro de 2026, uma alteração no gerenciamento de endereços da Cloudflare retirou da Internet cerca de 1.100 prefixos BYOIP pertencentes a clientes antes que a mudança inicial fosse interrompida.
  • A narrativa de abertura da Cloudflare situa a experiência da indisponibilidade às 17h48 UTC e informa duração de seis horas e sete minutos; a cronologia detalhada, porém, marca impacto entre 17h56 e 23h03 UTC. Essa divergência interna da fonte deve permanecer explícita.
  • O incidente não foi um ataque, sequestro de rota, vazamento de rota nem falha demonstrada de validação de origem. Tratou-se da retirada de prefixos legítimos pelo próprio sistema de controle do provedor.
  • Registros em RIR, objetos IRR, ROAs e Cartas de Autorização documentam autoridade e permissão, mas não provam que uma rota esteja sendo anunciada naquele momento ou que o serviço associado esteja alcançável.
  • Interromper novas mutações conteve a propagação do problema, mas não recriou automaticamente registros, vínculos de serviço e configurações de borda que já haviam sido alterados ou removidos.
  • Segundo a Cloudflare, aproximadamente 800 prefixos foram recuperados por volta das 20h20 UTC; cerca de 300 dependeram de caminhos adicionais de restauração até 23h03 UTC.
  • O site público do 1.1.1.1 apresentou erros, enquanto o resolvedor DNS continuou respondendo consultas, distinção importante entre a página associada ao serviço e a função de resolução propriamente dita.
  • A responsabilização adequada exige simulações exatas, proteção contra exclusões dependentes, grupos de mudança limitados, canários representativos, reversão independente e reconciliação entre intenção, implantação e observação externa.

A cronologia pública e sua divergência interna

A Cloudflare descreveu uma indisponibilidade de BYOIP ocorrida em 20 de fevereiro de 2026. O evento começou após uma alteração na forma como sua rede administrava espaço de endereços IP pertencente a clientes. Um subprocesso de limpeza interpretou determinados registros de modo incompatível com o estado operacional esperado. Prefixos ainda ativos foram retirados, e parte dos usuários também perdeu configurações de endereçamento presentes nos servidores de borda.

Há uma divergência temporal dentro do próprio relato público. Na narrativa inicial, a empresa afirma que a indisponibilidade foi sentida às 17h48 UTC e durou seis horas e sete minutos. Na cronologia detalhada, o período de impacto aparece entre 17h56 e 23h03 UTC. Os dois enunciados não devem ser fundidos em um intervalo artificial. São referências publicadas pela mesma fonte, mas não produzem uma única conta coerente. Uma análise responsável precisa registrar a discrepância em vez de escolher silenciosamente uma versão ou inventar uma reconciliação que o material público não oferece.

Antes que a alteração inicial fosse revertida, cerca de 1.100 prefixos BYOIP haviam sido retirados. A reversão impediu que novas mutações do mesmo tipo continuassem acontecendo, mas o seu alcance foi de contenção, não de restauração integral. Dados e configurações já modificados não retornaram automaticamente ao estado anterior.

De acordo com a Cloudflare, aproximadamente 800 prefixos foram recuperados por volta das 20h20 UTC. Os cerca de 300 restantes exigiram outras rotas de recuperação. Entre elas estavam a possibilidade de clientes voltarem a anunciar prefixos por mecanismos de autoatendimento, a recuperação de registros, a restauração de vínculos com serviços e uma distribuição global de configuração para máquinas. Esses trabalhos prosseguiram até 23h03 UTC na cronologia detalhada.

A diferença entre conter uma alteração e reparar seus efeitos é central. Um controle pode impedir a próxima exclusão sem saber quais objetos já foram eliminados. Pode restabelecer um registro administrativo sem garantir que a configuração correspondente voltou aos roteadores. Pode também recolocar uma rota em circulação sem restaurar corretamente o serviço que deveria receber o tráfego atraído por ela. Por isso, “reverter” não pode ser usado como sinônimo automático de “recuperar”.

Como autoridade sobre endereços se transforma em alcance roteado

BYOIP, sigla para “Bring Your Own IP”, permite que uma organização use espaço de endereçamento próprio dentro da infraestrutura de um provedor. Esse arranjo preserva vantagens como continuidade de endereços, identidade de rede e portabilidade operacional. Ao mesmo tempo, cria uma cadeia de dependências que precisa permanecer coerente.

O primeiro nível é a autoridade sobre o recurso numérico. Um registro regional da Internet, ou RIR, mantém registros relacionados à alocação ou atribuição do espaço. Objetos em um Internet Routing Registry, ou IRR, expressam informações de roteamento, incluindo a relação esperada entre prefixos e sistemas autônomos. A infraestrutura RPKI permite que detentores de recursos publiquem ROAs, as autorizações de origem de rota, indicando quais sistemas autônomos estão autorizados a originar determinados prefixos. Uma Carta de Autorização registra a permissão concedida pelo cliente para que o provedor anuncie o espaço.

Essas evidências respondem a perguntas de autoridade e autorização. Elas não respondem, isoladamente, à pergunta operacional “a rota está sendo anunciada agora?”. Um ROA válido não envia uma atualização BGP e não obriga uma rede autorizada a manter o anúncio. Uma Carta de Autorização não configura um roteador. Um objeto IRR correto não demonstra que a política correspondente foi carregada nos equipamentos. Um cadastro de conta não prova que o serviço esteja recebendo o tráfego.

O segundo nível é a representação do prefixo dentro da plataforma. A documentação atual da Cloudflare descreve o registro do prefixo na conta, a validação da titularidade e dos estados de IRR e RPKI, a associação a um serviço e a existência de um objeto de prefixo BGP. Esse objeto começa no estado retirado. Uma operação autorizada muda o estado para anunciado, permitindo que a Cloudflare propague o prefixo por sua rede global.

A documentação também descreve delegações de prefixos. Uma conta pode permitir que outra utilize parte do espaço, enquanto a conta principal mantém responsabilidades sobre vínculos de serviço. Isso separa ainda mais os conceitos de propriedade, permissão de uso e operação efetiva. A conta que administra um recurso, a conta que o utiliza, o serviço conectado a ele e o estado de anúncio podem ser representados por registros diferentes.

O terceiro nível é o vínculo de serviço. Depois que o provedor atrai tráfego para um prefixo, a plataforma precisa saber o que fazer com os pacotes. Serviços de CDN e segurança, Spectrum, Dedicated Egress e Magic Transit dependem de configurações específicas. Mapas de endereços podem relacionar IPs a respostas DNS intermediadas. Outros objetos associam o prefixo a capacidades de encaminhamento, proteção ou saída. A existência da rota, portanto, não prova que o destino funcional esteja corretamente definido.

O quarto nível é a implantação. O estado pretendido em uma API ou base de controle precisa chegar às máquinas que executam a rede. Roteadores e servidores de borda precisam receber a configuração adequada. É possível que uma interface administrativa diga “anunciado” enquanto parte da rede ainda não exporta a rota. Também é possível observar o prefixo no BGP sem encontrar o vínculo de serviço correto na borda.

O quinto nível é a realidade externa. Coletores de rotas, pontos de observação distribuídos, sessões de teste e verificações de alcance mostram o que outras redes efetivamente veem. Essa camada não substitui os registros internos, pois uma observação externa pode ser incompleta ou atrasada. Ainda assim, ela é indispensável: a continuidade de um serviço público não pode ser provada apenas por uma intenção registrada dentro do provedor.

O mecanismo da falha e o limite da reversão

O relato público conecta o incidente à Addressing API, descrita pela Cloudflare como fonte de verdade para os endereços IP de clientes. Essa expressão tem peso operacional. Uma fonte de verdade não é apenas um catálogo; ela orienta decisões posteriores, alimenta automações e representa relações que outros componentes presumem corretas.

No caso em análise, o mesmo domínio operacional relacionava um prefixo pertencente ao cliente, seus vínculos de serviço e o estado de anúncio BGP usado na borda. Um subprocesso de limpeza tratou registros ativos de maneira que levou à retirada de prefixos. Para alguns usuários, configurações de endereçamento também foram removidas dos servidores de borda.

Esse comportamento revela um risco comum em sistemas de ciclo de vida: confundir ausência, inatividade, obsolescência e elegibilidade para exclusão. Um objeto pode parecer não utilizado quando uma dependência não foi consultada. Pode parecer duplicado quando representa uma delegação válida. Pode aparentar estado retirado em um registro enquanto continua necessário para um serviço. Pode ainda estar correto na fonte central e divergente em uma camada derivada.

Uma automação de limpeza é especialmente perigosa porque costuma combinar classificação e mutação. Primeiro ela decide que um registro não deveria existir; em seguida, remove o registro ou seus efeitos. Se a classificação estiver errada, a mesma velocidade que torna a automação eficiente amplia a falha. Uma operação aplicada globalmente pode transformar uma interpretação equivocada em centenas de retiradas antes que alarmes humanos confirmem o padrão.

A reversão da mudança inicial interrompeu novas mutações, mas não recompôs tudo o que já havia sido alterado. Isso é compatível com sistemas em que o código da nova operação pode ser revertido sem que os dados afetados sejam restaurados. Se um registro foi excluído, parar a rotina que o excluía não o recria. Se um vínculo de serviço foi removido, restaurar o processo anterior não necessariamente recupera a relação. Se uma configuração de borda já foi distribuída, trocar a versão do controlador não garante que todos os nós receberão a configuração corretiva.

A recuperação, por isso, precisou usar vários caminhos. O autoatendimento permitiu que alguns clientes voltassem a anunciar seus prefixos. Outros casos dependeram da recuperação de registros e de vínculos. Também houve necessidade de distribuir configuração globalmente. Essa diversidade é evidência de que o dano não estava contido em um único botão de anúncio BGP.

O autoatendimento é útil, mas tem limites como mecanismo de recuperação. Ele pode reduzir o tempo de indisponibilidade quando o cliente está disponível, reconhece o problema e possui acesso adequado. Não elimina, porém, a obrigação do provedor de identificar todo o conjunto afetado. Clientes podem não perceber imediatamente a retirada, podem não ter pessoal de rede em atividade naquele horário ou podem recear agravar o estado usando controles durante uma falha do próprio sistema.

A recuperação controlada pelo cliente também não prova que todos os registros internos voltaram a coincidir. Um prefixo pode reaparecer externamente enquanto permanece uma inconsistência no vínculo de serviço. Por essa razão, o autoatendimento deve ser tratado como canal complementar, e não como substituto para a reconciliação conduzida pelo operador.

Impacto: o que uma retirada provoca e o que ela não demonstra

Quando a Cloudflare deixou de atrair tráfego para os prefixos afetados, usuários encontraram falhas de conexão ou esgotamento de tempo. O pedido podia não alcançar a camada de aplicação. Isso distingue o incidente de uma falha comum em que o servidor de origem recebe a requisição e responde com um erro. Sem uma rota utilizável até o prefixo, a aplicação pode nem ter a oportunidade de registrar ou reparar a tentativa.

O impacto alcançou configurações dependentes dos anúncios, incluindo serviços de CDN e segurança, Spectrum, Dedicated Egress e Magic Transit. Essa enumeração define superfícies técnicas, não uma lista de clientes. O registro público não sustenta a identificação de organizações afetadas além do que a própria Cloudflare divulgou, nem autoriza estimativas de perdas financeiras ou conclusões jurídicas.

A distinção relativa ao 1.1.1.1 é igualmente importante. O site público associado ao endereço apresentou erros, mas o resolvedor continuou respondendo consultas DNS. Dizer apenas que “o 1.1.1.1 ficou fora do ar” apagaria a diferença entre a página e a função principal do resolvedor. Em infraestrutura, serviços que compartilham uma marca ou um endereço reconhecível podem depender de caminhos operacionais diferentes.

O incidente não deve ser chamado de ataque. Não há base no material congelado para classificá-lo como sequestro de BGP, falha de validação de origem, vazamento de rota ou ação externa. Um sequestro normalmente envolve um anúncio indevido por uma origem não autorizada ou inesperada. Um vazamento de rota envolve propagação contrária à relação ou à política esperada entre redes. Aqui, o problema descrito foi a retirada de prefixos legítimos pelo sistema de controle da própria Cloudflare.

Também não há fundamento para atribuir a falha a um fornecedor específico de roteadores, a determinada tecnologia de banco de dados, a uma equipe interna nomeada ou a uma sequência particular de comandos. O material público permite analisar as classes de estado envolvidas e os efeitos observados. Não permite reconstruir detalhes privados que não foram divulgados.

Cinco camadas de evidência que não podem ser reduzidas a uma só

Uma análise de responsabilização pode organizar o caso em cinco camadas independentes, porém relacionadas.

A primeira é a autoridade sobre o prefixo. Ela inclui registros de recursos numéricos, evidência de titularidade e a autorização concedida ao provedor. Sua pergunta principal é: quem tem legitimidade documentada para determinar o uso e o anúncio desse espaço?

A segunda é a autorização de origem. Objetos IRR, ROAs e dados de ASN ajudam a expressar quais origens são esperadas ou autorizadas. Sua pergunta é: se uma rota for anunciada, a origem declarada é compatível com os registros de autorização?

A terceira é a intenção interna. Contas, delegações, objetos de prefixo BGP, mapas de endereços e vínculos de serviço representam o estado que a plataforma pretende manter. Sua pergunta é: qual serviço deve usar o prefixo, e ele deveria estar anunciado ou retirado?

A quarta é o estado implantado. Configurações executadas em roteadores e servidores de borda representam o comportamento real dentro da rede. Sua pergunta é: os equipamentos receberam e aplicaram a intenção correta?

A quinta é a observação externa. Coletores BGP, testes de alcance e medições distribuídas mostram como a Internet enxerga o prefixo. Sua pergunta é: a rota está visível em caminhos relevantes e o serviço responde conforme esperado?

Cada camada pode estar correta enquanto outra está errada. Um prefixo pode ter autoridade registral impecável e estar ausente das tabelas de roteamento. Pode ser anunciado por uma origem autorizada, mas apontar para um serviço sem vínculo válido. Pode constar como anunciado na interface de controle e não aparecer externamente. Pode aparecer em alguns coletores e continuar inalcançável em regiões específicas devido à implantação incompleta.

Essa separação também explica por que RPKI não teria impedido o incidente descrito. A arquitetura RPKI e a validação de origem tratam da autorização da origem de uma rota recebida. Elas não exigem que uma rede anuncie permanentemente um prefixo. Se o provedor autorizado retira a rota, não há anúncio que a validação possa transformar em alcance.

As definições técnicas dos RFCs ajudam a estabelecer esses limites. O RFC 4271 descreve o funcionamento do BGP, incluindo anúncio e retirada de informações de alcançabilidade. Os RFCs 6480, 6811 e 8210 delimitam a arquitetura RPKI, a validação de origem e a comunicação de dados RPKI aos roteadores. Os RFCs 7908 e 9234 tratam de vazamentos de rota e de mecanismos destinados a reduzir sua ocorrência. Eles não documentam a implementação privada da Cloudflare em fevereiro, tampouco provam a eficácia de qualquer correção posterior.

A documentação atual do produto também tem um limite probatório. Ela oferece vocabulário para compreender prefixos, delegações, vínculos, mapas de endereços, LOAs e estados de anúncio. Não deve ser tratada como fotografia retroativa do código ou da arquitetura interna que executou a alteração do incidente. Uma documentação atualizada pode refletir controles presentes hoje sem demonstrar como cada componente funcionava naquele momento.

Da prevenção abstrata aos controles verificáveis

A lição mais forte do caso não é “testar melhor” de forma genérica. Sistemas que alteram o estado de prefixos precisam de controles específicos e auditáveis.

O primeiro é uma simulação exata. Antes de qualquer mutação, a automação deve produzir a lista completa de prefixos que pretende alterar, o motivo individual da elegibilidade e todas as dependências relevantes. Uma contagem agregada não basta. Um resultado como “1.100 registros serão limpos” não informa quais clientes, serviços, delegações ou anúncios serão atingidos.

A simulação deve usar as mesmas regras de seleção da execução real. Se o modo de teste consulta uma réplica diferente, ignora vínculos ou simplifica condições, ele pode aprovar uma operação que o caminho efetivo executará de outro modo. O artefato de simulação deve ser comparável à mutação realizada, permitindo demonstrar que nenhum objeto fora do conjunto aprovado foi alterado.

O segundo controle é a proteção contra exclusão dependente. Um prefixo não deveria ser removido enquanto existir um vínculo de serviço, uma delegação ativa, uma intenção de anúncio, uma configuração implantada ou outra referência que exija continuidade. Essas relações precisam funcionar como bloqueios objetivos, não apenas como advertências visuais. Caso a exclusão seja realmente necessária, o sistema deve exigir uma sequência explícita de desvinculação e drenagem.

O terceiro é a limitação de coorte. Uma alteração de alto impacto não deve alcançar toda a população de uma só vez. O conjunto inicial precisa ser pequeno, mensurável e reversível. A ampliação deve depender de sinais positivos, não apenas da ausência de alarmes. Se a primeira coorte revelar uma retirada inesperada, a automação deve parar antes de atingir centenas de prefixos.

O quarto é a escolha de canários representativos. Um prefixo de laboratório sem clientes, delegações ou serviços complexos não representa o risco de uma população BYOIP. O conjunto de canários precisa cobrir diferentes tipos de vínculo, produtos dependentes, estados de anúncio, delegações e caminhos de configuração. O objetivo não é experimentar com tráfego crítico, mas testar as combinações de estado que a lógica realmente encontrará.

O quinto é uma reversão independente. Se a mesma automação que causou a mutação for a única capaz de desfazê-la, uma falha de classificação pode contaminar também o caminho de retorno. Uma reversão robusta precisa de inventário anterior, cópia recuperável dos registros e capacidade de reconstruir vínculos e configurações sem depender da lógica defeituosa.

O sexto é a reconciliação posterior. Depois da restauração, o operador deve comparar, prefixo por prefixo, autoridade, autorização, conta, delegação, vínculo de serviço, intenção BGP, estado implantado e observação externa. O encerramento não deveria depender apenas da queda de alertas agregados. Um pequeno grupo residual pode permanecer inacessível mesmo quando a maioria já se recuperou.

O sétimo é a telemetria independente. Métricas produzidas pelo mesmo controlador que registra a intenção podem repetir o erro do controlador. É necessário comparar o estado administrativo com dados oriundos dos equipamentos e com observações externas. A independência não exige confiar cegamente em um único coletor público; exige diversidade suficiente para detectar divergências entre o que a plataforma acredita e o que a rede está fazendo.

Retirada segura e continuidade operacional

A documentação atual da Cloudflare sobre retirada segura de prefixos alerta para rotas presas e buracos negros. Ela recomenda uma sequência que inclui o estabelecimento de um anúncio nativo com o mesmo comprimento de prefixo, a observação da convergência e, somente depois, a retirada do anúncio da Cloudflare.

Esse procedimento é apresentado ao cliente, mas ilustra um princípio mais amplo: retirar uma rota é uma transição operacional, não uma simples alteração de campo. A etapa anterior, a propagação e o estado posterior precisam ser observados. Em uma rede global, a ausência de erro na API não prova que a convergência ocorreu como esperado.

Para automações internas, a exigência deve ser pelo menos tão rigorosa quanto a orientação oferecida ao cliente. Uma rotina que pretende retirar um prefixo precisa saber se existe outra rota, se ela tem o mesmo comprimento, se está sendo propagada e se o serviço continuará alcançável. Quando a retirada não é intencional, a plataforma deve detectar rapidamente a divergência entre o estado esperado e a queda da visibilidade externa.

A continuidade também depende de segurança dos metadados. Alterações em autoridade, delegação e vínculo precisam ser registradas com precisão. Um sistema de ciclo de vida deve explicar não apenas o estado atual, mas a transição: quem autorizou, qual objeto mudou, que dependências foram avaliadas, quais configurações foram distribuídas e qual evidência confirmou o resultado.

Responsabilização sem extrapolação

O registro público permite uma conclusão delimitada: os controles da Cloudflare falharam nesse incidente porque uma alteração de gerenciamento retirou prefixos ativos e, em alguns casos, removeu estado de endereçamento necessário na borda. A necessidade de múltiplos caminhos de recuperação demonstra que a simples reversão não recompôs toda a cadeia.

Essa conclusão não equivale a uma afirmação de negligência, ilegalidade, ocultação ou responsabilidade jurídica. O material disponível não apresenta decisão regulatória, apuração independente completa nem dados suficientes para estimar danos. Responsabilização técnica significa exigir evidência sobre decisões, estados e recuperação, sem transformar lacunas documentais em acusações.

A Cloudflare anunciou melhorias após o incidente. Esses anúncios são relevantes como compromissos declarados, mas não constituem verificação independente de eficácia. Para demonstrar que um controle funciona, seria necessário observar sua aplicação em mudanças posteriores, examinar resultados de simulações, confirmar a limitação de coortes e verificar se exercícios de reversão restauram todas as camadas.

Um bom pós-incidente deveria tornar possível responder a perguntas concretas. Quantos prefixos foram classificados para alteração? Quais dependências existiam? Em que momento cada prefixo deixou de ser visível? Quais registros foram excluídos? Quais recuperações dependeram de clientes? Quais foram conduzidas pelo provedor? Quando o estado administrativo voltou a coincidir com os roteadores e com observações externas?

Nem todas essas respostas precisam expor informações confidenciais. O provedor pode publicar dados agregados, propriedades dos controles e evidências de teste sem revelar identidades de clientes ou detalhes exploráveis. A confidencialidade não elimina a necessidade de demonstrar que o sistema distingue intenção, implantação e realidade externa.

Um placar prático para controles de ciclo de vida de prefixos

A qualidade do controle pode ser avaliada por um conjunto de perguntas.

Inventário: existe uma identidade estável para cada prefixo, conta, delegação, vínculo, objeto BGP e configuração implantada? O histórico permite reconstruir relações anteriores?

Autoridade: o sistema distingue titularidade do recurso, permissão concedida por LOA, objetos IRR, autorização RPKI e uso delegado? Uma alteração em uma camada aciona a revisão das demais sem presumir equivalência?

Intenção: há um estado explícito para “anunciado”, “retirado”, “em transição” e “bloqueado”? A justificativa da mudança é preservada?

Dependências: exclusões são impedidas quando serviços, delegações ou configurações ainda dependem do objeto? Referências indiretas também são verificadas?

Simulação: a prévia enumera exatamente os objetos e efeitos? O mecanismo de seleção é idêntico ao da execução?

Limitação: há teto absoluto e proporcional para cada rodada? Uma alteração que excede o limite exige nova autorização?

Canários: os primeiros casos representam a variedade real da população? A expansão depende de confirmação de rotas e serviços?

Implantação: a plataforma diferencia a configuração desejada daquela confirmada nos equipamentos? Nós atrasados ou divergentes são identificados?

Observação externa: o provedor compara sua visão com múltiplos pontos de observação? A ausência inesperada de anúncios interrompe automaticamente a mudança?

Reversão: o caminho de retorno restaura dados, vínculos e configuração, além de parar novas mutações? Ele é testado separadamente?

Recuperação do cliente: o autoatendimento é claramente comunicado e seguro, mas permanece complementar à obrigação de recuperação do provedor?

Encerramento: o incidente só é considerado resolvido quando todas as camadas foram reconciliadas? Exceções residuais são registradas e acompanhadas?

Esse placar desloca a discussão de promessas gerais para propriedades observáveis. O objetivo não é exigir perfeição, mas impedir que um único registro administrativo seja usado como prova de continuidade de uma cadeia inteira.