Resumo

  • A Cloudflare relatou dois eventos separados em 27 de junho de 2024: o AS267613 começou a originar 1.1.1.1/32 às 18h51 UTC, e o AS262504 vazou 1.1.1.0/24 por meio do AS1031 às 18h52 UTC.
  • O anúncio /32 e o vazamento /24 não representam o mesmo mecanismo e não devem ser combinados em uma única narrativa de “sequestro”.
  • Segundo a Cloudflare, uma rede tier-1 não identificada aceitou o /32 como uma rota de blackhole acionada remotamente, fazendo com que tráfego associado àquele caminho fosse descartado.
  • O /24 vazado preservava o AS13335 da Cloudflare como origem. Por isso, a validação de origem RPKI podia considerar a origem válida sem certificar que o caminho intermediário ou a exportação estavam autorizados.
  • A Cloudflare registrou seu incidente às 20h03 UTC e informou a resolução completa do vazamento /24 às 2h28 UTC de 28 de junho.
  • Os efeitos relatados foram impossibilidade de alcançar 1.1.1.1 ou latência elevada para alguns usuários. As fontes não demonstram uma interrupção global do DNS.
  • A APNIC avaliou que o evento não teve visibilidade global e que seu efeito provavelmente foi marginal diante da base total de usuários da Internet. O Internet Society Pulse descreveu observações mais amplas, que devem permanecer atribuídas àquela fonte.
  • RouteViews e RIPE RIS preservam observações úteis para reconstrução, mas não autorizam rotas, aplicam filtros nem comprovam todos os resultados de encaminhamento.
  • A responsabilização acompanha o controle prático sobre origem, exportação de clientes, aceitação por provedores, propagação em trânsito ou route servers, autorização de blackhole, monitoramento, contenção e retirada confirmada.
  • Nenhuma fonte do conjunto estabelece intenção maliciosa, negligência, ilegalidade, ocultação, responsabilidade jurídica ou a totalidade das perdas e dos caminhos afetados.

Um incidente, dois eventos de roteamento

A distinção mais importante para compreender o episódio é também a mais fácil de perder. Não houve apenas uma rota problemática com duas descrições diferentes. A Cloudflare relatou dois eventos independentes, iniciados com um minuto de diferença e capazes de produzir efeitos por mecanismos distintos.

O primeiro começou, segundo a empresa, às 18h51 UTC de 27 de junho de 2024. O AS267613 passou a originar o prefixo 1.1.1.1/32. Esse anúncio descrevia um único endereço IPv4: justamente o endereço mais conhecido do resolvedor público da Cloudflare. Um /32 é mais específico que o 1.1.1.0/24 normalmente associado ao serviço. Onde fosse aceito, poderia prevalecer sobre uma rota menos específica para aquele destino.

A Cloudflare informou que uma rede tier-1 não identificada aceitou o anúncio /32 como uma rota de remotely triggered black hole, ou RTBH. Nesse contexto, o resultado não era encaminhar tráfego para o AS267613 como se ele oferecesse um caminho convencional até o resolvedor. A aceitação como blackhole fazia com que o tráfego correspondente fosse descartado. A identidade dessa rede não foi divulgada nas fontes públicas analisadas, e essas fontes não permitem reconstruir com segurança sua configuração privada, sua hierarquia de comunidades BGP ou o processo interno que autorizou a ação.

O segundo evento começou às 18h52 UTC. A Cloudflare atribuiu ao AS262504 o vazamento do prefixo 1.1.1.0/24 por meio do AS1031. Diferentemente do /32, essa rota carregava o AS13335, da própria Cloudflare, como origem. O problema estava na propagação do caminho: uma rota com origem reconhecível apareceu por uma cadeia que não deveria tê-la exportado daquela maneira.

Essa diferença produz duas perguntas de controle. Para o /32, é necessário perguntar por que uma origem não autorizada e um comprimento excepcional foram aceitos, inclusive no contexto destrutivo de RTBH. Para o /24, é necessário perguntar por que uma rota que podia parecer correta no teste de origem atravessou uma relação ou política de exportação não autorizada. Uma resposta operacional séria precisa tratar as duas perguntas separadamente.

Agrupar tudo sob o rótulo genérico de “BGP hijack” esconderia essa separação. O termo pode ser usado por uma fonte para descrever sua interpretação, mas não substitui a reconstrução técnica. Tampouco demonstra intenção. Uma origem indevida pode resultar de erro, automação mal limitada, configuração incorreta ou outra causa não visível publicamente. Um vazamento de rota também não prova, por si só, propósito malicioso. As fontes disponíveis não estabelecem a motivação dos AS envolvidos.

Cronologia delimitada pelo que foi relatado

Às 18h51 UTC, conforme a cronologia da Cloudflare, o AS267613 iniciou o anúncio de 1.1.1.1/32. Um minuto depois, às 18h52 UTC, o AS262504 começou a vazar 1.1.1.0/24 por meio do AS1031. A proximidade temporal ajuda a explicar por que os sintomas podem ter sido percebidos como parte de um único incidente de alcançabilidade, mas não elimina a independência técnica entre os eventos.

A empresa registrou formalmente seu incidente às 20h03 UTC. Esse horário não deve ser apresentado como o início comprovado de toda anomalia. Ele representa o momento declarado em que a Cloudflare abriu seu processo de incidente. A diferença entre o primeiro anúncio observado e a abertura formal é relevante para avaliar detecção, correlação e escalonamento, mas não basta para concluir que houve atraso negligente. Para isso seriam necessários registros internos sobre alertas, triagem e decisões, inexistentes nas fontes públicas analisadas.

A Cloudflare relatou que alguns usuários não conseguiam alcançar 1.1.1.1, enquanto outros enfrentavam latência elevada. Essas formulações delimitam o impacto demonstrado. O fato de um endereço de resolvedor público sofrer interferência de roteamento é material, mas não comprova que todo o serviço DNS da Cloudflare tenha parado, que todos os usuários do resolvedor tenham sido afetados ou que todas as regiões tenham observado o mesmo comportamento.

A APNIC apresentou uma avaliação independente segundo a qual o evento não foi globalmente visível e provavelmente teve efeito marginal em relação à base total de usuários da Internet. Essa conclusão ajuda a conter afirmações excessivas, mas não torna irrelevante a falha de controle. Uma propagação limitada ainda pode revelar um caminho de aceitação capaz de descartar tráfego destinado a um recurso amplamente reconhecido.

O Internet Society Pulse empregou uma descrição de observação mais ampla, envolvendo vários contextos de rede e países. Essa linguagem deve ser mantida como atribuição daquela fonte, sem ser combinada artificialmente com a avaliação da APNIC. As duas publicações podem ter usado coletores, janelas, critérios de visibilidade e conceitos de “afetação” diferentes. Observação de uma rota em uma rede ou país não equivale automaticamente a perda de serviço para todos os usuários daquele local.

A Cloudflare registrou a resolução completa do vazamento /24 às 2h28 UTC de 28 de junho. Esse marco se refere ao encerramento relatado da propagação indevida do /24. Não deve ser usado para presumir que todos os vestígios do /32, todos os caches, todos os caminhos de encaminhamento ou todos os efeitos percebidos desapareceram exatamente no mesmo instante. Uma cronologia responsável separa retirada do anúncio, convergência observada, recuperação do serviço e verificação posterior.

Por que o /32 podia mudar o encaminhamento

O encaminhamento IP normalmente escolhe a rota correspondente ao prefixo mais específico. Se um roteador conhece uma rota para 1.1.1.0/24 e outra para 1.1.1.1/32, a segunda oferece uma correspondência mais precisa para o endereço 1.1.1.1. Essa preferência ocorre antes de muitas comparações entre atributos BGP feitas para rotas do mesmo comprimento.

Na Internet IPv4, anúncios mais específicos que /24 costumam enfrentar filtros operacionais. Isso limita sua propagação convencional, mas “costuma” não significa “sempre”. Políticas podem variar conforme a sessão, a função do vizinho, as comunidades anexadas e o serviço oferecido. Uma rota que não seria aceita como anúncio global comum pode ser interpretada por uma configuração específica como instrução de blackhole.

O RTBH é uma defesa legítima. Operadores o utilizam, por exemplo, para descartar tráfego destinado a um endereço atacado e impedir que um volume nocivo prejudique uma infraestrutura maior. O problema não é a existência do mecanismo, mas a autoridade concedida a quem pode acioná-lo e a precisão com que o comando é delimitado.

Uma política segura de RTBH precisa vincular a solicitação ao cliente autorizado, aos prefixos que esse cliente pode controlar, aos comprimentos permitidos, às sessões pelas quais a comunidade pode ser recebida e ao domínio em que o descarte será aplicado. Também precisa registrar quem ou qual automação introduziu a rota, quando ela foi aceita, quais roteadores a instalaram e como sua retirada será confirmada.

Segundo o relato da Cloudflare, uma rede tier-1 aceitou o /32 como RTBH. O dado público sustenta a consequência geral — tráfego descartado no caminho que respeitava aquela decisão —, mas não revela o desenho exato da política. Não é possível afirmar se houve uma comunidade específica, um mapeamento bilateral, uma exceção de prefixo, uma validação incompleta de cliente ou outra condição privada.

Também não é possível generalizar o comportamento para todas as redes tier-1. O fato de uma rede não identificada ter aceitado o anúncio não demonstra que outras o fizeram, nem permite contar quantos usuários alcançaram o caminho de descarte. A evidência apoia uma análise do tipo de controle necessário, não uma acusação contra entidades não nomeadas.

Por que o /24 exigia uma defesa diferente

O vazamento de 1.1.1.0/24 apresentava um desafio complementar. A rota carregava o AS13335 como origem, isto é, o AS da Cloudflare. Um validador que verificasse apenas se o prefixo podia ser originado pelo AS13335 poderia obter um resultado aceitável. Ainda assim, a rota poderia ter sido exportada por uma relação inadequada ou propagada em sentido incompatível com a política econômica esperada.

Essa é a fronteira entre validação de origem e validação do caminho. Um ROA associa um prefixo, um AS autorizado e um comprimento máximo. A validação RPKI descrita para origem compara a rota recebida com essa autorização. Ela pode classificar como inválido um anúncio com AS de origem errado ou com comprimento mais específico que o permitido. Não certifica, porém, cada ligação entre ASes no AS_PATH.

No caso do /32, a origem e o comprimento contribuíam para a invalidade RPKI relatada. No caso do /24, o AS de origem correto podia preservar um estado de origem válido, embora o caminho tivesse sido exportado sem autorização. Dizer que “o RPKI aprovou a rota” seria impreciso. O que podia ser aprovado era a origem dentro do modelo de validação aplicado, não toda a cadeia de propagação.

O RFC 6811 fornece o contexto da validação de origem BGP. O RFC 8893 descreve uma forma de transportar o estado dessa validação dentro de um domínio administrativo. Nenhum dos dois prova que uma rede citada no incidente implementou o controle, que o aplicou a todas as sessões ou que rejeitou rotas com base no resultado.

Para vazamentos, os controles necessários incluem políticas explícitas de importação e exportação, conhecimento da relação com o vizinho e limites sobre quais rotas de clientes podem ser retransmitidas. O RFC 7908 organiza classes de vazamento de rota. O RFC 7454 apresenta práticas operacionais de segurança BGP, e o RFC 8212 estabelece a importância de políticas explícitas em sessões externas. Esses documentos descrevem contexto e práticas; não fornecem evidência sobre a configuração efetiva de AS267613, AS262504, AS1031 ou qualquer provedor não identificado.

O RFC 9234 acrescenta os papéis BGP e o atributo Only-to-Customer, ou OTC, como instrumentos para reduzir determinadas formas de vazamento. O mecanismo ajuda redes a expressar e avaliar relações de propagação. Ele não valida automaticamente toda política comercial, não corrige sessões que não o implantam e não demonstra que estava presente nos caminhos observados em junho de 2024.

Registros e ROAs são evidências, não comandos

Os materiais de alocação da APNIC ajudam a situar 1.1.1.0/24 no sistema de registros de recursos numéricos. Registros de alocação, objetos associados e autorizações criptograficamente verificáveis tornam mais clara a relação esperada entre um prefixo e sua origem. Eles apoiam filtragem, investigação e contato durante incidentes.

Mas um registro não entra sozinho na tabela de encaminhamento de um roteador. Um ROA não ativa filtros por conta própria. Cada operador decide como obter, validar, distribuir e aplicar os dados. A diferença entre uma autorização publicada e uma política executada é precisamente onde a responsabilização operacional se torna concreta.

Essa separação também impede que o registro seja tratado como autoridade absoluta sobre a realidade de encaminhamento. O registro oferece uma representação verificável da autorização de origem; a rede em funcionamento continua sendo determinada por sessões BGP, políticas, comunidades, filtros, preferências e decisões de operação.

Dados corretos continuam essenciais. Um prefixo sem registro preciso, contato atual ou ROA adequado torna a prevenção e a resposta mais difíceis. Ao mesmo tempo, a existência de dados corretos não absolve o operador que aceita uma rota incompatível com sua relação de cliente ou que permite uma comunidade destrutiva sem verificar autorização.

O explorador RPKI da Cloudflare fornece uma visão da cobertura e do estado de origem para prefixos. Ele é útil para demonstrar o tipo de evidência que um operador pode consultar. Não comprova a política aplicada por cada roteador que participou de uma propagação, nem mostra todas as decisões tomadas em sessões privadas.

Impacto: o que as observações permitem afirmar

A consequência confirmada pela Cloudflare foi que alguns usuários tiveram dificuldade para alcançar 1.1.1.1 ou observaram latência elevada. Há pelo menos dois caminhos plausíveis dentro dos fatos relatados: descarte associado à aceitação do /32 como blackhole e encaminhamento alterado pela propagação indevida do /24.

Essa plausibilidade não autoriza quantificar perdas. O conjunto de fontes não estabelece o número de clientes afetados, o volume exato de tráfego descartado, a distribuição geográfica completa ou a duração individual da degradação para cada usuário. Também não mostra todos os sistemas recursivos, dispositivos, provedores ou aplicações que conseguiram contornar o problema.

Uma rota visível em um coletor demonstra que uma sessão participante anunciou determinado estado ao sistema de observação. Isso não comprova que todos os roteadores daquela rede instalaram a rota, que ela se tornou o melhor caminho em todos os pontos ou que o plano de dados encaminhou cada pacote conforme a mesma decisão.

Da mesma forma, a ausência de uma rota em um coletor não prova que ela não existiu em outro lugar. RouteViews e RIPE RIS dependem de participantes e pontos de observação. Eles oferecem uma amostra extremamente útil da propagação BGP, mas não constituem um espelho completo de todas as sessões privadas da Internet.

A APNIC enfatizou a visibilidade não global e o provável impacto marginal em escala total. O Internet Society Pulse descreveu uma amplitude observacional maior. A leitura responsável preserva ambas as atribuições e evita converter uma diferença de medição em contradição simplista.

A conclusão proporcional é que o incidente teve alcance limitado, porém operacionalmente significativo. Ele afetou um endereço de infraestrutura reconhecido, atravessou controles em mais de um ponto e expôs como uma combinação de aceitação de rota, blackholing e vazamento pode escapar à proteção oferecida por registros de origem.

Observar não é autorizar

RouteViews e RIPE RIS cumprem uma função probatória. Seus coletores registram atualizações e visões de rotas recebidas de redes participantes. Esses dados permitem estabelecer sequências, comparar caminhos, localizar pontos de visibilidade e testar hipóteses sobre a propagação.

Eles não são autoridades que concedem permissão para originar um prefixo. Também não inserem filtros nas redes observadas, não interrompem uma sessão externa e não retiram uma rota indevida. Responsabilizá-los pela aceitação seria confundir o instrumento de medição com o sistema que toma a decisão.

A preservação de observações, contudo, muda os incentivos. Quando atualizações BGP podem ser comparadas com dados de registro, ROAs, horários de incidentes e comunicações de operadores, torna-se mais difícil tratar uma propagação problemática como um evento sem rastros. A evidência externa não substitui logs internos, mas pode revelar onde solicitá-los.

O valor dos coletores cresce quando os horários são normalizados, os caminhos são preservados sem perda de atributos e as limitações da amostra são declaradas. Uma análise que omite essas limitações pode confundir visibilidade com impacto. Outra que ignora coletores perde uma das poucas fontes independentes disponíveis para examinar rotas públicas.

Prevenção: controles diferentes para falhas diferentes

A prevenção do anúncio /32 começa no ponto capaz de originá-lo. O AS de origem deve limitar quais prefixos e comprimentos podem ser anunciados por pessoas, dispositivos e automações. Mudanças excepcionais precisam de autorização explícita e devem expirar quando seu propósito termina.

A rede que recebe uma rota de cliente deve aplicar filtros baseados no conjunto de prefixos que aquele cliente está autorizado a anunciar. Esses filtros precisam considerar não apenas o bloco agregado, mas também o comprimento máximo permitido. Aceitar 1.1.1.1/32 porque existe alguma relação distante com 1.1.1.0/24 não é equivalente a verificar autoridade sobre o endereço específico.

A validação de origem RPKI acrescenta uma defesa independente. Uma rota inválida pode ser rejeitada antes de influenciar o encaminhamento. Para que isso funcione, os dados precisam estar disponíveis, os validadores precisam ser mantidos e a política de roteamento precisa utilizar o resultado de modo previsível.

No RTBH, a autorização deve ser mais estrita, não mais permissiva, porque a ação solicitada é destrutiva por definição. O provedor precisa saber qual cliente pode solicitar o descarte, para quais prefixos, com quais comprimentos, em quais regiões e por quanto tempo. Uma comunidade de blackhole não deve transformar qualquer anúncio recebido em permissão automática para eliminar alcançabilidade.

O RFC 7999 define uma comunidade BLACKHOLE bem conhecida, enquanto o RFC 3882 explica o uso de blackholing acionado remotamente. Esses padrões dão contexto comum ao mecanismo. Eles não comprovam que a rede tier-1 citada usou exatamente aquela comunidade ou uma configuração específica desses documentos.

Para o vazamento /24, filtros de prefixo continuam úteis, mas podem não bastar quando a origem é legítima. A defesa precisa incorporar a função do vizinho. Uma rota aprendida de um provedor não deve, em condições econômicas típicas, ser exportada a outro provedor como se viesse de um cliente. Políticas explícitas de importação e exportação reduzem a possibilidade de uma sessão nova ou incompleta aceitar tudo por padrão.

Papéis BGP e OTC podem tornar certas violações mais detectáveis por máquinas. Porém, sua eficácia depende da implantação nas redes relevantes e da consistência com que as relações são classificadas. O padrão fornece uma ferramenta, não uma prova retroativa de que cada operador dispunha dela.

Route servers também precisam definir responsabilidade. Mesmo quando não aparecem como AS intermediário da forma convencional, podem facilitar a distribuição de rotas entre participantes. A política deve esclarecer se o servidor aplica filtros, usa dados RPKI, valida listas de prefixos e como notifica membros diante de uma anomalia.

Provedores de trânsito têm capacidade semelhante em outra escala. Eles podem limitar anúncios de clientes, aplicar validação de origem, estabelecer limites de prefixos, detectar mudanças incomuns e impedir que uma rota aprendida em uma relação seja exportada onde não deveria. A responsabilidade concreta depende do controle disponível em cada sessão, não do tamanho ou da reputação da empresa.

Detecção: combinar sinais que revelam falhas diferentes

Nenhum alerta isolado cobriria todo o incidente. Uma alteração de origem para 1.1.1.1/32 é um sinal diferente de uma mudança de caminho para 1.1.1.0/24 com origem AS13335 preservada.

A detecção do /32 pode combinar aparecimento de prefixo mais específico, estado RPKI inválido, origem inédita, comprimento fora do perfil e comunidades associadas a descarte. O simples fato de um /32 aparecer em uma sessão externa para um endereço de serviço conhecido deveria justificar análise imediata.

A detecção do /24 precisa observar mudanças no AS_PATH, vizinhos inesperados, relações econômicas incompatíveis, alcance geográfico novo e alterações de latência ou disponibilidade. Um monitor que verifica apenas a validade da origem pode deixar o vazamento passar sem alerta.

Sinais do plano de controle devem ser correlacionados com testes do plano de dados. Sondas de alcançabilidade, medições de latência, consultas reais ao resolvedor e observação a partir de vários provedores ajudam a distinguir uma rota visível de uma rota que efetivamente mudou a experiência de usuários.

A Cloudflare, como operadora do serviço, tinha uma posição privilegiada para correlacionar telemetria do 1.1.1.1 com mudanças BGP. Redes intermediárias tinham visibilidade superior sobre suas próprias sessões e decisões. Coletores públicos forneciam uma perspectiva externa. Nenhum desses pontos, isoladamente, continha toda a imagem.

Contenção: reduzir propagação sem ampliar o dano

A primeira tarefa de contenção é identificar qual evento está sendo tratado. Retirar ou rejeitar o /32 não elimina automaticamente o vazamento /24. Corrigir a exportação do /24 também não desfaz um blackhole já instalado para o endereço específico.

Para o /32, a contenção pode envolver retirada na origem, rejeição nas redes receptoras, remoção da autorização de blackhole e confirmação de que o descarte deixou de ser instalado. A simples retirada enviada por um vizinho não prova que todos os roteadores convergiram ou que uma configuração automática não voltará a anunciar a rota.

Para o /24, é necessário interromper a exportação indevida e impedir a propagação nos vizinhos que a receberam. Operadores podem filtrar temporariamente o caminho enquanto verificam a política definitiva. A medida deve ser precisa para não bloquear o anúncio legítimo da Cloudflare.

Comunicação entre equipes de peering, trânsito, operação e segurança reduz o tempo de contenção. Contatos de registro atualizados podem ajudar a localizar responsáveis, mas o registro não executa a retirada. A ação precisa ocorrer nas redes que controlam origem, sessão, aceitação e propagação.

É importante preservar evidências antes que as atualizações desapareçam das tabelas atuais. Logs de sessão, mudanças de configuração, mensagens de alerta, atributos recebidos e horários de retirada permitem verificar o que ocorreu sem manter a rota problemática ativa.

Recuperação: retirada não basta

Uma rota retirada pode continuar influenciando partes da rede até que a convergência seja concluída. Além disso, um serviço pode levar tempo para estabilizar conexões, caches, medições e caminhos alternativos. Por isso, a recuperação precisa ser demonstrada em mais de uma camada.

No plano de controle, deve-se confirmar que o /32 não aparece mais nos pontos relevantes, que o caminho vazado do /24 desapareceu e que os anúncios legítimos voltaram a prevalecer. No plano de dados, testes precisam verificar alcançabilidade, latência e respostas do resolvedor a partir de redes diversas.

A Cloudflare informou a resolução completa do vazamento /24 às 2h28 UTC em 28 de junho. Esse é o marco público disponível para aquele evento. Uma avaliação independente não deve ampliar o significado do horário além da atribuição feita pela empresa.

A recuperação também exige impedir recorrência. Uma correção manual pode encerrar o episódio sem eliminar a condição que o tornou possível. O fechamento técnico deve identificar se o reparo foi aplicado na origem, em filtros de cliente, em políticas de exportação, na aceitação de RTBH, no monitoramento ou em vários desses pontos.

A imagem editorial e seus limites

A imagem em destaque é um diagrama editorial determinístico de roteamento, em formato 16:9, com três caminhos curvos e diferenciados por cor convergindo para um sistema central de controle de rotas. Ela é genérica: não é uma fotografia, não mostra uma instalação da Cloudflare e não reconstrói visualmente as conexões reais do incidente.

Essa distinção protege a precisão editorial. O diagrama representa conceitos de propagação e resultados de roteamento, sem afirmar a topologia privada dos AS citados, a localização de equipamentos, a identidade da rede tier-1 ou a sequência exata de encaminhamento de pacotes.

Matriz de responsabilidade operacional

Superfície de controle Capacidade prática Evidência necessária Limite da atribuição
AS267613 e ponto de origem do /32 Impedir anúncio não autorizado, limitar prefixos e comprimentos, registrar mudanças e retirar a rota Configuração, logs de alteração, atualizações enviadas, autorização do prefixo O material público não prova intenção nem identifica o operador individual
AS262504 e exportação do /24 Impedir vazamento, aplicar função correta ao vizinho e retirar a exportação indevida Política de importação e exportação, histórico da sessão, registros de mudança A presença do AS no relato não prova negligência ou responsabilidade jurídica
AS1031, conforme o caminho citado pela Cloudflare Filtrar rotas recebidas e limitar propagação conforme a relação Rotas recebidas e anunciadas, política da sessão, estado de validação O caminho público não revela todas as decisões internas
Route server ou infraestrutura de interconexão envolvida Aplicar controles definidos para participantes e disseminar alertas Configuração do servidor, filtros, membros alcançados, horários Não se deve presumir a participação de um route server específico sem evidência
Provedor de trânsito Validar origem, prefixo, comprimento, função e exportação de clientes Filtros, políticas, logs e atualizações por vizinho Uma observação externa não mostra toda a configuração privada
Rede tier-1 não identificada Autorizar RTBH, limitar escopo e remover blackhole Solicitação recebida, comunidade, prefixo, cliente, duração e retirada A fonte não identifica a rede nem permite reconstruir sua implementação
Cloudflare como titular e operadora do serviço Manter registros e ROAs, monitorar rotas, detectar impacto, coordenar contenção e confirmar recuperação ROAs, alertas, telemetria, cronologia e comunicação com pares Operar o prefixo não concede controle direto sobre todos os roteadores externos
APNIC e sistema de registro Preservar dados de alocação e apoiar a verificabilidade do recurso Histórico de alocação e objetos aplicáveis O registro não configura filtros nem autoriza cada caminho BGP
RouteViews e RIPE RIS Preservar observações independentes de propagação Atualizações, horários, pontos de coleta e atributos Não autorizam rotas e não comprovam todo resultado de encaminhamento
Operadores que dependem de 1.1.1.1 Detectar degradação, usar redundância e fornecer evidência de impacto Sondas, logs de resolução, latência e caminhos A experiência de uma rede não representa toda a Internet

A matriz mostra por que a responsabilização não pode ser concentrada apenas no AS que aparece na origem de uma rota. O originador controla o que envia; o cliente controla parte de sua exportação; o provedor controla o que aceita; o trânsito ou route server controla parte da propagação; a rede que oferece RTBH controla uma ação destrutiva; o titular do serviço controla registros, monitoramento e resposta; coletores preservam observações.

Essas responsabilidades podem coexistir sem produzir, automaticamente, culpa legal. Controle prático identifica onde uma prevenção ou contenção poderia ocorrer. Culpa, negligência e responsabilidade jurídica exigiriam padrões legais, contratos, deveres, conhecimento e provas que não estão disponíveis neste conjunto de fontes.

O episódio demonstra uma característica fundamental do roteamento interdomínio: a disponibilidade não decorre apenas de quem possui um endereço no registro. Ela emerge de uma cadeia de decisões executadas por sistemas autônomos independentes. Quando uma dessas decisões aceita um estado inadequado, a pergunta relevante é quem tinha autoridade técnica para rejeitá-lo, quem podia detectá-lo e quem confirmou sua reversão.