Incidente de indisponibilidade do Cloudflare 1.1.1.1 em 14 de julho de 2025

(blog.cloudflare.com)

1 pontos por GN⁺ 2025-07-17 | 1 comentários | Compartilhar no WhatsApp

A Cloudflare causou uma indisponibilidade total de 62 minutos no resolver DNS público 1.1.1.1 em 14 de julho de 2025, durante uma mudança na topologia do serviço
A maioria dos usuários globais foi diretamente afetada e ficou sem conseguir usar a internet
A causa da indisponibilidade foi uma configuração incorreta em um sistema legado interno, sem relação com ataque externo ou sequestro de BGP
O incidente foi desencadeado pela acumulação de mudanças de configuração incorretas junto com uma redefinição em toda a rede
Como medidas para evitar recorrência, a empresa prepara a adoção de um sistema de implantação gradual e a desativação do sistema legado de configuração

Visão geral

Em 14 de julho de 2025, a Cloudflare provocou uma falha global de rede no resolver DNS público 1.1.1.1 durante uma mudança na topologia do serviço. Por causa desse incidente, usuários que utilizavam os serviços 1.1.1.1 e Gateway DNS enfrentaram indisponibilidade de acesso à internet ou degradação severa do serviço por 62 minutos. A causa foi um erro de configuração em um sistema legado interno, e não um ataque externo nem sequestro de BGP.

Escopo e impacto da indisponibilidade

Entre 21:52 UTC e 22:54 UTC, o resolver 1.1.1.1 ficou praticamente indisponível em todo o mundo
A maior parte dos clientes globais não conseguiu resolver nomes de domínio, o que tornou o uso da internet praticamente impossível
A situação do incidente pôde ser confirmada no Cloudflare Radar
O motivo da falha foi uma configuração incorreta em um sistema legado que gerencia a infraestrutura responsável por anunciar na internet os endereços IP pertencentes à Cloudflare
Houve impacto crítico em todo o tráfego que chegava à Cloudflare pelo canal 1.1.1.1

Causa e contexto do incidente

A Cloudflare usa roteamento Anycast para serviços globais como o DNS Resolver
Embora ofereça serviços em várias regiões, alguns serviços que exigem localização de dados são limitados a regiões específicas
Em 6 de junho, durante uma mudança de configuração para preparar futuros serviços DLS (data localization), a faixa de IPs do resolver 1.1.1.1 foi incluída sem intenção no novo DLS
- Esse erro não foi aplicado imediatamente e, na prática, não causou impacto naquele momento, por isso nenhum alerta foi disparado
Em 14 de julho, foi aplicada uma mudança para adicionar uma localização offline de teste à topologia DLS
- Essa mudança forçou uma atualização global da configuração da rede, expondo o erro existente
- Os prefixes do 1.1.1.1 foram retirados dos datacenters no mundo todo, interrompendo o serviço

Linha do tempo do incidente (resumo)

2025-06-06 17:38: mudança de configuração para o serviço DLS passa a incluir os prefixes do 1.1.1.1 (sem impacto, erro latente)
2025-07-14 21:48: uma mudança de configuração atualiza a configuração de toda a rede, iniciando a retirada global dos prefixes do 1.1.1.1
2025-07-14 21:52: queda abrupta do tráfego global de DNS
2025-07-14 22:01: alerta interno e declaração de incidente
2025-07-14 22:20: rollback para a configuração anterior e início do procedimento de recuperação do serviço
2025-07-14 22:54: normalização do tráfego, encerramento dos alertas e fim do incidente

IPs e protocolos afetados

Escopo do impacto: prefixes amplos de IPv4 e IPv6, como 1.1.1.0/24, 1.0.0.0/24 e 2606:4700:4700::/48
Foi observada uma queda brusca no tráfego de consultas usando UDP, TCP e DoT (DNS over TLS)
O DoH (DNS over HTTPS) quase não foi afetado, já que em muitos casos é baseado no domínio cloudflare-dns.com

Explicação técnica da falha

Falha no serviço Resolver 1.1.1.1

Em 6 de junho, um erro nos prefixes foi introduzido durante uma mudança prévia de configuração para DLS
Em 14 de julho, uma localização offline foi adicionada para fins de teste, e a configuração global da rede foi atualizada
Nesse processo, os prefixes do resolver 1.1.1.1 ficaram globalmente restritos a uma única localização offline, levando à retirada do serviço

Análise da causa técnica

Atualmente, a Cloudflare opera em paralelo com um sistema legado e um novo sistema estratégico, sincronizando os anúncios de roteamento por espaço de endereçamento
O sistema legado depende de atualizações manuais e não possui implantação gradual, o que aumenta a probabilidade de erro
- Houve peer review e revisão por outros engenheiros, mas não havia uma estrutura que garantisse aplicação gradual, como implantação canário
A nova abordagem é orientada por topologia em vez de hardcoding e introduz um mecanismo de aplicação gradual de mudanças e monitoramento
Às 22:01, foi disparado o alerta do DNS Resolver
Foi confirmado que todas as rotas do Resolver haviam desaparecido da tabela interna de roteamento BGP
Após a retirada dos prefixes, a subnet 1.1.1.0/24 passou a ter uma tentativa de anúncio BGP pela Tata Communications India (AS4755)
- Isso se assemelha a um sequestro temporário de prefixo, mas não teve relação direta com o incidente

Procedimento de recuperação e ações posteriores

Às 22:20 UTC, foi feito rollback para a configuração anterior e os prefixes voltaram a ser anunciados
- Cerca de 77% do tráfego foi recuperado imediatamente
- Alguns servidores de borda foram redefinidos automaticamente, exigindo reaplicação por um sistema manual de gerenciamento de mudanças
- Embora a rede normalmente use rollout gradual por segurança, neste incidente a aplicação foi acelerada após validação
Às 22:54, todas as localizações voltaram ao normal

Planos de melhoria futura

Adoção de um sistema de implantação gradual (Stage Deployment): descontinuação do modelo legado de deploy e introdução de rollback automático com base em health checks
Aceleração da desativação do sistema legado: eliminação de configurações manuais e métodos de deploy arriscados, com reforço de documentação e cobertura de testes

Conclusão

A indisponibilidade do DNS Resolver 1.1.1.1 da Cloudflare foi causada por um erro de configuração interno, e a Cloudflare está concentrando esforços em melhorar a estabilidade e prevenir recorrências no futuro. A empresa pediu desculpas pelo transtorno causado aos clientes e pretende continuar reforçando medidas para minimizar incidentes semelhantes.

1 comentários

GN⁺ 2025-07-17

Comentários do Hacker News

Para muitos usuários, quando o resolvedor 1.1.1.1 (DNS) não funciona, isso significa ficar sem acesso a praticamente todos os serviços da internet. Mas normalmente não se configuram dois servidores DNS em todos os dispositivos? Fico curioso se o segundo também caiu, ou, se não, por que não houve failover para ele
- A Cloudflare recomenda configurar os dois, 1.1.1.1 e 1.0.0.1, como servidores DNS. Porém, por causa do erro de configuração que causou esta falha, os anúncios BGP da Cloudflare para os prefixos 1.1.1.0/24 e 1.0.0.0/24 foram interrompidos
- No Android, em Configurações > Rede e internet > DNS privado, só dá para inserir um único "hostname do provedor de DNS privado" (até onde eu sei). E não entendo por que ele não aceita um IP (1.1.1.1) e exige um endereço (one.one.one.one). Ao especificar um servidor DNS, faz muito mais sentido configurar por IP
- Listar dois é melhor do que não listar nenhum, mas não é perfeito. Se um lado cair, como não há rastreamento de qual está funcionando corretamente, em geral isso resulta em longas esperas e problemas intermitentes. Isso continua valendo a menos que você use uma configuração mais avançada, como um proxy DNS local com cache e múltiplos upstreams
- Se você acha que consegue falar com propriedade sobre DNS, eu diria que deveria operar o seu próprio serviço. O domínio raiz . funciona bem há décadas; a principal razão de dar problema no 1.1.1.1 não é o DNS em si, e sim o anycast. A Cloudflare (e o Google etc.) insiste em IPs "vanity" — para viabilizar esse tipo de IP é preciso usar anycast, e o problema real não é o DNS, e sim o anycast. Recomendo escolher e configurar mais de um provedor
- A configuração recomendada pela Cloudflare é manter o servidor de backup 1.0.0.1 como DNS secundário, mas neste incidente ele também foi afetado
É interessante que, em uma indisponibilidade de cerca de 20 minutos, o tráfego do 1.1.1.1 tenha caído só uns 20%. Impressiona que a Cloudflare continue tropeçando em problemas tão simples e antigos (não foi a primeira vez, e provavelmente não será a última). Já o 8.8.8.8 e o 8.8.4.4 do Google praticamente não tiveram nem 1 segundo de downtime no mundo todo em quase 10 anos. (1: houve alguns problemas regionais, mas isso foi culpa da internet; mesmo quando vários serviços do Google sofreram falhas graves, o DNS em si continuou funcionando normalmente.)
- Não é só disponibilidade; para DNS, velocidade e privacidade também importam. Se você está na Europa, pode usar a lista de alternativas europeias de DNS em vez de uma empresa americana (sujeita ao CLOUD Act)
- Para quem pergunta por que não se resolve facilmente problemas de engenharia em um ambiente de rede gigantesco e extremamente complexo como o da Cloudflare, a realidade é que são problemas que só 0,001% da indústria chega a vivenciar
- A cultura de resposta a incidentes da Cloudflare é razoável, mas falta incentivo para promover ativamente medidas preventivas
- Esse número de 20% citado significa que alguns clientes/resolvedores, depois de várias falhas de resposta, colocam temporariamente o servidor DNS em quarentena, evitando que o usuário tenha de esperar 500 timeouts a cada requisição. No longo prazo, o volume no gráfico de tráfego volta ao normal
- Concordo que muita gente não quer usar o Google DNS
Surpreende que tenham levado mais de 5 minutos para detectar o impacto (mesmo com o tráfego do protocolo principal caindo para 10% e permanecendo lá). Nunca operei um sistema nessa escala, mas eu esperaria um alerta imediato. Fico curioso para saber se os especialistas consideram isso razoável
- Há uma tensão constante entre velocidade de detecção e taxa de falso positivo. Sistemas de monitoramento como Nagios e Icinga normalmente só geram evento após 3 falhas consecutivas, porque erros transitórios são comuns. Se o alerta dispara demais, os responsáveis ficam dessensibilizados e passam a reagir com um "vamos esperar um pouco". Nunca operei diretamente um serviço global como o da Cloudflare, mas uma detecção confiável em 8 minutos não me parece surpreendente
- Como nos antigos NOCs (centros de operações de rede), se esse tipo de gráfico estivesse na parede, alguém bateria o olho, diria "tem algo errado" e já sairia correndo para agir
- Acho que, quando o impacto começou, o serviço ainda não estava completamente fora do ar (principalmente se era o começo de um rollout global), então deve ter levado algum tempo até o efeito se tornar mensurável
- Se você fizer o alerta disparar em menos de 1 minuto, no fim estará só testando a performance da infraestrutura de alertas. A questão é se realmente dá para coletar e calcular os dados com estabilidade a cada minuto
- Quando o serviço de agregação de métricas cai, os indicadores podem ficar atrasados até o sistema ser redistribuído e parecer uma queda de 100%. Se você mandar alerta em 1 minuto, vai acordar um monte de gente às 2 da manhã sem necessidade; se isso se repete, os alertas acabam ficando cada vez mais frouxos — por isso essa calibragem tende a ficar em torno de 5 minutos
É um bom texto de resumo. Foi interessante a parte que diz que o DoH (DNS sobre HTTPS) era acessado principalmente pelo domínio cloudflare-dns.com (manual ou via navegador) e, por não depender de um IP fixo, sofreu relativamente menos com a falha. Eu fui afetado ontem e, mesmo com DoH ativado no roteador, nada resolvia; troquei para 8.8.8.8 e o problema sumiu
- Fico curioso sobre como o DoH funciona. É preciso saber o IP de cloudflare-dns.com, e o roteador pode ter usado 1.1.1.1 para isso
- Hoje eu estava configurando um domínio novo e, por uns 20 minutos, ele só abria no Firefox de um notebook. A ferramenta de DNS do Google mostrava o domínio como ativo, eu conseguia até usar SSH no servidor da AWS, mas na minha rede local as consultas DNS não funcionavam. Limpei cache, tentei de tudo, e no fim aquele Firefox estava configurado separadamente para usar o DoH da Cloudflare
- Eu discordo. A causa raiz de fato fica escondida por trás de um jargão pedante e vago, o que confunde até administradores experientes. O termo "legacy" não é claro; ele parece abstrato e opaco. Quando leio algo como "Os componentes legacy não usam implantação gradual, e a Cloudflare vai introduzir uma abordagem moderna com rollout gradual e rollback", eu entendo o sentido, mas não havia necessidade de escrever de forma tão difícil de entender
- Meu roteador Unifi parece usar DoH automático com Cloudflare e Google ao mesmo tempo. Não senti impacto, então ou o DoH da Cloudflare continuou funcionando ou ele passou imediatamente para o Google
- No geral é um bom resumo, mas a linha do tempo no começo do texto está incorreta
Com dnsmasq, dá para configurar vários servidores DNS ao mesmo tempo e usar o que responder mais rápido. Mesmo que um serviço caia, quase não se percebe o problema
- Ao usar all-servers sem a configuração strict-order, o dnsmasq automaticamente reenvia tentativas para todos os servidores. Mas, se você usa systemd-resolved, ele só tenta novamente em ordem, então é importante alternar servidores de provedores diferentes. Se combinar IPv4 e IPv6 como no exemplo, o failover fica mais rápido. O IP da Quad9 citado tem filtragem padrão ativada, enquanto os outros dois não, então os resultados de resolução podem diferir. Pessoalmente, se você valoriza validação de DNSSEC (extensões de segurança de domínio), não deveria misturar resolvedores que validam com os que não validam (os DNS do exemplo todos suportam DNSSEC)
- Pergunta-se se existe uma configuração mais privada para quem não quer que todo o histórico de DNS fique exposto a big techs (Cloudflare, Google etc.) e também não quer DoH. Parece interessante usar no dnsmasq uma lista confiável de DNS menores, mas fico na dúvida se enviar requisições a vários provedores ao mesmo tempo não seria falta de etiqueta. Também não sei onde encontrar uma lista estável de DNS focados em privacidade
- Vários provedores DNS têm políticas e prioridades diferentes, então eu não trataria dois deles como substitutos. Em vez disso, escolheria um só e deixaria o DNS do ISP como backup
- Se você usa systemd-resolved, por padrão já há suporte a DoT e DNSSEC, então dá para obter algo parecido. Para evitar totalmente um DNS centralizado, é possível rodar um daemon do Tor e expor um resolvedor DNS na rede. Também dá para ter vários resolvedores
- Mesmo sem a configuração all-servers, o dnsmasq periodicamente faz uma corrida de consultas entre os servidores (por padrão, retenta a cada 20 segundos). Mesmo em uma falha súbita, o impacto não deve durar mais que alguns segundos
Mesmo uma falha de cerca de 1 hora representa 0,13% no mês e 0,0114% no ano. Fico curioso sobre qual é o SLO (objetivo de nível de serviço) que a Cloudflare aplica a esse serviço. Encontrei este link, mas ele vale só para serviços pagos. Com esta falha, a disponibilidade de julho entraria na faixa "< 99.9% but >= 99.0%", o que daria direito a reembolso de 10% da cobrança
- Para preservar a reputação da marca, imagino que seja 99,9% ao ano ou mais
É interessante que, mesmo após o incidente, o tráfego não tenha voltado totalmente ao normal. Recentemente passei a usar o luci-app-https-dns-proxy do OpenWrt para fazer consultas simultâneas à Cloudflare e ao Google DNS, e como o DoH quase não foi afetado, nem percebi a falha (se até o DoH tivesse quebrado, teria havido troca automática para o Google)
- O texto aborda mais adiante por que o tráfego não se recuperou imediatamente logo após o incidente. Parece que alguns servidores exigiram intervenção direta
- Quando a internet para de funcionar, muitas vezes a pessoa simplesmente vai fazer outra coisa por um tempo. Imagino que quase ninguém troque de provedor DNS naquele momento
- Como os clientes armazenam temporariamente os resultados de DNS em cache, por algum tempo após a falha ainda podem usar valores antigos
Surpreende que tanto o 1.1.1.1 quanto o 1.0.0.1 tenham sido afetados pela mesma mudança. Agora parece que o backup de DNS deveria ser de um provedor totalmente diferente (por exemplo, 8.8.8.8, 9.9.9.9)
- Os dois endereços na verdade são oferecidos pelo mesmo serviço. Nunca foram anunciados como backups independentes entre si
- O propósito original do DNS era usar o resolvedor mais próximo. O ideal é distribuir adequadamente entre vários provedores, backbones e regiões diferentes (e, se possível, evitando endereços anycast). Mas, neste caso, por causa das características de funcionamento do DNS, também podem surgir problemas inesperados
- Sempre foi assim de qualquer forma
- Eu já misturo OpenDNS, Quad9 e Cloudflare configurados em dois Pi-hole. A maior parte dos meus dispositivos usa esses dois Pi-hole como DNS
- Na verdade, o próprio conceito de "backup de DNS" não faz muito sentido. A maioria dos clientes simplesmente escolhe um dos endereços de forma arbitrária, e se um lado cai não necessariamente faz failover automático para o outro. O comportamento real não corresponde ao que se imagina
A topologia interna da Cloudflare vem evoluindo de uma forma em que sistemas "legacy" e "strategic" ficam sincronizados. É um texto que explica bem a situação de forma clara, para técnicos e não técnicos. Achei que conseguiu até tornar o processo de migração interessante. O pedido de desculpas pelo transtorno causado pelo incidente, junto com a mensagem de que vão melhorar e evitar recorrência, causa boa impressão. Valorizo esse tipo de postura corporativa
- "legacy" é um termo mais usado por técnicos, e "strategic" é mais usado por marketing ou liderança não técnica; misturar os dois pode acabar confundindo e irritando ambos os lados
Surpreende que, mesmo com vários engenheiros revisando o rebranding, ninguém tenha percebido o erro de adicionar 1.1.1.0/24 à lista de rerroteamento. Fico curioso sobre que tipo de erro humano, ou até má-fé, poderia ter causado isso. Parece que o DLS (Domain List Service) precisaria de uma exceção hardcoded para impedir que 1.1.1.1/32 e 1.0.0.1/32 fossem apontados para um único local
- Talvez a causa tenha sido a confiança do tipo "se o Jerry fez, então deve estar certo"
- Em geral, tendo a culpar mais as ferramentas do que as pessoas. Dependendo da estrutura do sistema ou da forma como os arquivos de configuração são gerados, esse tipo de erro pode passar com facilidade (principalmente se o diff for autogerado). No fim, code review também é feito por pessoas, então esse tipo de falha é um problema de processo. Na prática, para evitar que um serviço realmente grande saia do ar, é preciso uma estratégia de defesa com múltiplas salvaguardas em várias camadas