Cloudflare manteve o .de no ar durante apagão DNSSEC: lições de resiliência para operadores de DNS

Em 5 de maio de 2026, um erro na rotação de chaves criptográficas da DENIC deixou milhões de domínios .de offline para usuários com validação DNSSEC. A Cloudflare reagiu com serve stale e Negative Trust Anchors — e revelou trade-offs que todo operador de DNS precisa conhecer.

O que aconteceu? Uma assinatura que quebrou o ecossistema

A DENIC realizava uma troca de Key Signing Key (KSK) — procedimento crítico no ciclo de vida do DNSSEC — quando publicou assinaturas incorretas para todo o TLD .de. As consequências foram imediatas:

• Resolvedores que validam DNSSEC (incluindo 1.1.1.1, Google Public DNS, OpenDNS) detectaram a inconsistência criptográfica e passaram a rejeitar todas as respostas da zona .de.
• Usuários finais receberam um SERVFAIL genérico — domínios .de inteiramente inacessíveis, de sites corporativos a serviços governamentais.
• Estima-se que mais de 30% dos usuários globais utilizam validação DNSSEC nos resolvedores. Sem mitigação, milhões de nomes ficariam inalcançáveis.

Dado crítico: o .de é o maior ccTLD da Europa, com mais de 17 milhões de domínios. Um apagão dessa escala expõe fragilidades estruturais na cadeia de confiança do DNS.

Por que isso importa? A fragilidade de uma âncora de confiança

O incidente expõe uma vulnerabilidade estrutural: uma falha em uma única zona (como um TLD) pode tornar toda a zona inacessível, independentemente da integridade dos domínios de segundo nível.

A cadeia de confiança é tão forte quanto seu elo mais fraco. Se o TLD erra, todos os subdomínios abaixo dele sofrem penalidades criptográficas, mesmo que estejam perfeitamente configurados.

Além disso, o caso demonstra que resolvedores públicos precisam de mecanismos operacionais para lidar com falhas upstream que não dependem de ação do registro. A Cloudflare ativou serve stale e Negative Trust Anchors (NTA) — revelando que resiliência de DNS não é apenas código, mas coordenação e trade-offs conscientes.

Implicações técnicas: serve stale, NTA e um bug inesperado

Serve stale (RFC 8767) — amortecendo o impacto imediato

Assim que a falha foi detectada, a Cloudflare ativou o serve stale: resolvedores continuam servindo respostas em cache mesmo após o TTL expirar, enquanto tentam obter dados novos. Durante o incidente, isso manteve consultas funcionando por horas.

• Benefício: redução drástica de SERVFAIL para usuários com consultas previamente cacheadas.
• Limitação: necessário que as respostas antigas tenham sido carregadas antes da falha. Domínios com baixo volume de consultas ou caches vazios sofreram mais.

Negative Trust Anchor (RFC 7646) — desabilitar a segurança momentaneamente

Às 22:17 UTC, a Cloudflare aplicou uma Negative Trust Anchor funcional (via override rule) para o TLD .de, desabilitando a validação DNSSEC exclusivamente para aquela zona. Isso fez com que resolvedores tratassem as respostas do .de como inseguras — mas disponíveis — eliminando o SERVFAIL.

Trade-off crítico: durante a janela de mitigação, a proteção contra spoofing de DNS foi removida para o TLD .de. Ataques de envenenamento de cache tornaram-se teoricamente possíveis.

Ação coordenada: a equipe de engenharia da Cloudflare comunicou-se via DNS-OARC com outros operadores para sincronizar a aplicação de NTA, evitando inconsistências entre resolvedores.

Bug de Extended DNS Errors (EDE) — diagnóstico prejudicado

Durante o incidente, a Cloudflare relatou que o 1.1.1.1 retornou o código EDE 22 (No Reachable Authority) em vez do correto 6 (DNSSEC Bogus). Um bug na propagação de códigos de erro internos mascarou a causa real.

Impacto prático: clientes e operadores receberam uma mensagem de erro enganosa, atrasando diagnósticos e aumentando a confusão.

Implicações de mercado: o que operadores e provedores devem aprender

1. Resolvedores públicos (1.1.1.1, Google, OpenDNS) precisam implementar mecanismos NTA e serve stale como requisito mínimo de resiliência. A ausência desses recursos pode tornar um serviço DNS vulnerável a falhas upstream.
2. Clientes CDN que usam domínios .de como origem devem ter resolvedores internos com as mesmas mitigações; caso contrário, mesmo com sites servidos via CDN, a origem pode ficar inalcançável.
3. Provedores de segurança DNS podem usar este caso como argumento para oferecer monitoramento automatizado e respostas a incidentes — por exemplo, sistemas que detectem falhas de validação e apliquem NTA temporário de forma controlada.
4. A coordenação entre operadores (papel do DNS-OARC) mostrou-se essencial para alinhar mitigação e evitar split-horizon (resolvedor A trata como bogus, B trata como válido). A comunicação em tempo real é um pilar de resiliência.

Riscos e limites: os trade-offs que ninguém gosta de discutir

A aplicação de NTA desabilita a proteção DNSSEC, expondo domínios a ataques de spoofing durante o período de mitigação. No contexto de uma falha conhecida (assinatura inválida), o risco é aceitável, mas em cenários de ataque ativo contra o TLD, a decisão seria muito mais complexa.

Além disso:

• A correção definitiva depende exclusivamente da DENIC; resolvedores só podem mitigar sintomas. A falha de um registro pode levar horas para ser corrigida — a DENIC suspendeu futuras rotações até identificar as causas exatas.
• Nem todos os resolvedores implementam serve stale ou NTA. Usuários de sistemas legados ou operadores menores podem ter sofrido impacto total, sem alternativas.
• O bug de EDE da Cloudflare obscurece a causa real, mas também revela que a arquitetura de propagação de erros em resolvedores precisa ser revista — códigos de erro devem refletir a falha fundamental, não intermediária.

Lições para a indústria

O apagão DNSSEC do .de não deve ser visto como um incidente isolado, mas como um sinal de alerta para toda a indústria de infraestrutura crítica. À medida que a adoção do DNSSEC se expande — pressionada por regulamentações e exigências de segurança —, a complexidade da rotação de chaves e a dependência de cadeias criptográficas monolíticas aumentam.

Resumo prático para operadores:

1. Mecanismos de degradação graciosa: resolvedores devem ser capazes de desabilitar seletivamente a validação por zona sem intervenção manual — um "modo seguro" que preserve disponibilidade quando a autoridade upstream falha.
2. Monitoramento automatizado de assinaturas: ferramentas que detectem assinaturas inválidas em zonas TLD em minutos e alertem operadores para aplicação de NTA ou, no limite, para ativação de fallback criptográfico.
3. Transparência nos códigos de erro: bugs como o EDE incorreto devem ser resolvidos, e os resolvedores devem expor a causa real (DNSSEC Bogus) com clareza, permitindo diagnóstico rápido.
4. Coordenação global: o DNS-OARC já provou seu valor; precisamos de canais mais rápidos e automatizados (webhooks, filas de incidentes) para que operadores de resolvedores e registries possam alinhar mitigação em minutos, não horas.

O incidente no .de nos lembrou de uma verdade fundamental: confiança criptográfica não é sinônimo de disponibilidade. A próxima vez que uma KSK falhar, a questão não será se o sistema vai se quebrar, mas quão rapidamente os operadores vão escolher entre segurança absoluta e continuidade do serviço. Aqueles que já tiverem testado suas Negative Trust Anchors e afinado seus serve stale estarão um passo à frente.

Quer se preparar para incidentes de DNS? Avalie hoje mesmo seus mecanismos de resiliência — comece testando serve stale e revisando suas políticas de NTA. A disponibilidade dos seus domínios depende disso.