Na manhã do dia 14 de julho de 2025, milhões de usuários em todo o mundo se depararam com um problema incomum: estavam sem acesso à internet. Rapidamente, o popular serviço de DNS 1.1.1.1 da Cloudflare foi identificado como o epicentro da falha, desencadeando uma onda de especulações sobre possíveis ataques cibernéticos ou sequestros de BGP.
Nas redes sociais e fóruns técnicos, os boatos sobre um ataque em larga escala ganharam força. No entanto, horas depois, a própria Cloudflare veio a público esclarecer o ocorrido. Segundo a empresa, a falha não teve qualquer relação com ataques externos ou sequestros de tráfego. Em vez disso, a falha Cloudflare 1.1.1.1 foi causada por um erro de configuração interna.
Neste artigo, vamos entender o que realmente causou a interrupção no 1.1.1.1, por que muitos imaginaram um sequestro de BGP e quais lições a Cloudflare e a comunidade técnica podem extrair desse incidente.
A importância do DNS e do 1.1.1.1
O DNS (Domain Name System) funciona como uma lista telefônica da internet. É ele quem traduz nomes de domínio, como google.com, em endereços IP compreendidos pelos servidores. Sem ele, a navegação simplesmente para.
O 1.1.1.1 da Cloudflare, lançado em 2018, é um dos serviços DNS mais utilizados no mundo. Promete velocidade, segurança e privacidade, sendo especialmente popular entre usuários que buscam alternativas ao DNS padrão das operadoras.
O que realmente aconteceu com o 1.1.1.1?
Segundo o relatório oficial da empresa, o problema começou por volta das 07h00 UTC do dia 14 de julho. A Cloudflare identificou uma grande quantidade de falhas de resolução em seus servidores DNS públicos, com usuários relatando lentidão, falha de navegação e perda de conectividade geral.
Os principais IPs afetados foram:
- IPv4: 1.1.1.1 e 1.0.0.1
- IPv6: 2606:4700:4700::1111 e 2606:4700:4700::1001
A detecção do problema foi rápida, mas a restauração total do serviço só foi concluída após mais de duas horas de instabilidade. Durante todo esse período, consultas DNS realizadas por métodos tradicionais (como UDP, TCP e DoT) falharam, embora algumas consultas via DoH (DNS over HTTPS) tenham continuado funcionando parcialmente.
A Cloudflare foi enfática: “A causa raiz foi um erro de configuração interna e não o resultado de um ataque ou sequestro de BGP.”
A causa técnica: um erro de configuração em cascata
A origem do problema remonta a uma alteração de configuração feita em junho, parte da preparação para o lançamento futuro de uma nova funcionalidade chamada Data Localization Suite (DLS). O DLS visa permitir que dados sejam processados e armazenados dentro de regiões específicas, em conformidade com legislações de privacidade e soberania digital.
Essa alteração, no entanto, permaneceu “adormecida” até ser ativada acidentalmente por uma atualização de rotina no dia 14 de julho. Como consequência, os prefixos IP relacionados ao 1.1.1.1 foram removidos da rede de produção da Cloudflare, tornando os servidores inacessíveis em diversas regiões.
A falha foi amplificada por outro fator: a configuração afetava de maneira diferente os protocolos DNS, o que explica por que o DoH continuou respondendo enquanto UDP, TCP e DoT falharam.
Diferença entre DoH e DoT
- DoT (DNS over TLS) e os protocolos tradicionais (UDP/TCP) dependem do roteamento convencional via BGP.
- DoH (DNS over HTTPS), por sua vez, é tratado como tráfego HTTPS comum, que pode ser roteado via outras infraestruturas da Cloudflare, como servidores de borda (edge).
Isso fez com que parte das requisições via DoH continuasse funcionando, mesmo com o 1.1.1.1 “fora do ar” nos protocolos tradicionais.
Por que a comunidade suspeitou de um sequestro de BGP?
O BGP (Border Gateway Protocol) é o protocolo que permite o roteamento global da internet. Em termos simples, ele determina o “caminho” que os dados devem seguir para chegar ao destino correto.
Um sequestro de BGP ocorre quando um ator malicioso anuncia prefixos IP falsos, desviando o tráfego de forma intencional. Isso pode resultar em espionagem, interceptação ou queda de serviços inteiros.
No caso da falha Cloudflare 1.1.1.1, a rápida propagação da interrupção, aliada à natureza do serviço DNS, levantou suspeitas. O fato de prefixos IP sumirem da tabela global de roteamento é compatível com os sintomas de um sequestro de BGP. Por isso, mesmo profissionais experientes inicialmente suspeitaram de uma ação externa.
No entanto, os logs e análises da Cloudflare descartaram essa hipótese, confirmando a falha de configuração como causa única.
Lições aprendidas: o caminho da Cloudflare para evitar futuras falhas
Um ponto importante revelado pela Cloudflare foi que a plataforma ainda depende de sistemas legados, que não suportam implementações progressivas (progressive rollout).
Uma implementação progressiva permite que mudanças sejam aplicadas a uma parte da infraestrutura de forma controlada e escalonada. Se houvesse esse mecanismo, o erro teria sido identificado em um ambiente limitado, evitando impacto global.
A empresa já anunciou medidas para:
- Acelerar a migração para sistemas modernos com suporte a rollout gradual.
- Melhorar a documentação interna, evitando ativação não intencional de configurações antigas.
- Revisar as práticas de gestão de configuração para minimizar riscos semelhantes no futuro.
Além disso, a transparência da Cloudflare em publicar rapidamente um relatório técnico detalhado foi elogiada por muitos na comunidade de redes e segurança.
Conclusão
A falha Cloudflare 1.1.1.1 serve como um lembrete poderoso de que, mesmo as empresas mais experientes e preparadas estão sujeitas a falhas internas. A complexidade crescente da infraestrutura digital torna essencial ter processos robustos de controle, validação e rollback de configurações.
Incidentes como esse mostram que transparência, aprendizado e melhoria contínua são os caminhos mais eficazes para fortalecer a confiança dos usuários e da comunidade técnica.
