Quando o DNSSEC quebra: a resposta da Cloudflare ao apagão do .de com serve stale, NTAs e um bug revelador

Em 5 de maio de 2026, a cadeia de confiança do DNSSEC sofreu um colapso operacional raro e violento. O TLD .de publicou assinaturas inválidas durante um key rollover. Resolvedores validadores como o 1.1.1.1 da Cloudflare começaram a devolver SERVFAIL para milhões de sites alemães. A resposta da equipe de engenharia — combinando serve stale, Negative Trust Anchors improvisadas e a descoberta de um bug nos códigos de erro estendidos — virou um case study urgente para toda a indústria de infraestrutura crítica.

A cronologia do incidente

A falha na raiz: assinaturas corrompidas

A DENIC executou um key rollover — procedimento padrão de renovação de chaves criptográficas do DNSSEC. Mas as novas assinaturas (RRSIG) geradas não correspondiam às chaves públicas anunciadas na zona. Resultado: qualquer resolvedor que implementasse rigorosamente os RFCs 4033/4034/4035 quebrava a validação.

O efeito dominó nos resolvedores

Resolvedores validadores detectaram a discrepância. Em vez de entregar registros potencialmente corrompidos, aplicaram o comportamento padrão do DNSSEC: SERVFAIL. Para o usuário final, o site .de simplesmente deixou de existir.

A Cloudflare, operadora do 1.1.1.1, estava entre os primeiros a sentir o impacto. Seu resolvedor Big Pineapple (núcleo de validação) começou a rejeitar respostas para consultas .de.

“O DNSSEC não pode ser um sistema binário — tudo funciona ou tudo quebrado.”

A mitigação em duas fases

Fase 1: Serve Stale (RFC 8767)

A primeira linha de defesa foi o mecanismo de serve stale. Em vez de retornar SERVFAIL imediatamente, o resolvedor continuou servindo registros expirados do cache, desde que ainda houvesse dados armazenados da tentativa anterior de resolução válida.

Como funciona: O servidor mantém respostas antigas (TTL expirado) e as entrega ao cliente, enquanto tenta revalidar em background. Se a revalidação falha, os dados stale continuam sendo servidos por um período limitado.

Isso manteve a disponibilidade parcial para usuários cujo cache ainda continha registros .de válidos. Para consultas que nunca haviam sido resolvidas ou cujo cache já havia expirado, o SERVFAIL ainda ocorria.

Resultado: A mitigação reduziu o impacto imediato, mas não estancou a hemorragia. Após cerca de 3 horas, a Cloudflare percebeu que o serve stale não era suficiente — o volume de SERVFAIL continuava crescente.

Fase 2: Negative Trust Anchor (NTA) por override

A Cloudflare tomou uma decisão drástica: desabilitar a validação DNSSEC exclusivamente para o TLD .de. Tecnicamente, isso é equivalente a uma Negative Trust Anchor conforme o RFC 7646.

O problema: o resolvedor Big Pineapple não possuía suporte nativo a NTA. A equipe contornou criando uma regra de override que forçava o resolvedor a ignorar as âncoras de confiança da zona .de.

Efeito imediato: Todas as consultas .de passaram a ser resolvidas sem validação DNSSEC. Os SERVFAILs cessaram. A resolução foi restaurada em minutos.

Risco assumido: Ao desativar a validação, a Cloudflare expôs seus usuários a potenciais ataques de envenenamento de cache para o TLD .de. Em um incidente coordenado entre a falha da DENIC e um ataque ativo, a janela de vulnerabilidade seria crítica.

O bug revelador: Extended DNS Errors (EDE)

Durante a análise pós-incidente, a Cloudflare identificou um bug em seu código de Extended DNS Errors (RFC 8914). Em vez de reportar o código correto 6 (DNSSEC Bogus), o resolvedor retornou o código 22 (No Reachable Authority).

Por que isso importa? O EDE foi projetado para fornecer informações diagnósticas adicionais no cabeçalho da resposta DNS. Operadores que recebem código 22 tenderão a investigar problemas de conectividade com servidores autoritativos — roteamento, firewalls, DDoS — quando a causa real era uma falha de criptografia.

Impacto: Atraso na identificação da causa raiz por operadores terceiros que não tinham acesso direto ao console da Cloudflare. O bug mascarou a falha da DENIC, prolongando a confusão.

Implicações técnicas e operacionais

Serve stale como padrão de resiliência

O RFC 8767 já é uma recomendação consolidada, mas poucos operadores o implementam com o devido rigor. A Cloudflare demonstrou que, em incidentes de validação, serve stale pode ser a diferença entre apagão total e degradação controlada.

• Configure tempos de stale longos o suficiente para cobrir janelas de mitigação humana (horas, não minutos).
• Monitore a taxa de stale servido versus resoluções frescas para detectar anomalias.

Negative Trust Anchors: ferramenta de último recurso

NTAs são uma faca de dois gumes. Desabilitar a validação para uma zona inteira restaura disponibilidade, mas abre brecha para ataques.

• Mantenha suporte nativo a NTA via override, mesmo que o software base não tenha.
• Documente e audite toda ativação de NTA — deve ser um procedimento de emergência com rollback programado.
• Comunique imediatamente aos peers (via DNS-OARC ou canais fechados) quando ativar uma NTA.

A necessidade de códigos EDE precisos

O bug da Cloudflare expõe que a implementação de EDE ainda é imatura. Códigos errados podem direcionar equipes de resposta para pistas falsas.

Ação para a indústria: Adote testes automatizados que verifiquem, para cada resposta DNSSEC Bogus, se o código EDE retornado é realmente o 6 (ou equivalente). Ferramentas como dnscheck da ICANN deveriam incluir validação de EDE.

Nota: O incidente do .de expôs a fragilidade da cadeia de confiança: um erro em um único TLD derrubou milhões de domínios. A rotação de chaves da DENIC falhou, e o sistema de validação é tão forte quanto seu elo mais fraco.

Riscos e limites da mitigação

A desativação temporária do DNSSEC

A NTA aplicada pela Cloudflare, embora eficaz, criou uma janela de vulnerabilidade. Se um atacante tivesse observado a falha da DENIC e lançado um ataque de envenenamento de cache direcionado ao .de, os usuários da Cloudflare ficariam expostos.

Mitigação futura: idealmente, a NTA deveria ser combinada com source address validation ou filtros de reputação de servidores autoritativos. Infelizmente, essas camadas adicionais ainda não são padrão.

Bug no EDE dificultou diagnósticos

Operadores terceiros que consultavam o 1.1.1.1 recebiam código 22. Isso pode ter levado times de segurança a perder horas investigando conectividade com servidores da DENIC, quando o problema era de assinatura.

Dependência de comunicação manual

A Cloudflare e a DENIC se coordenaram via DNS-OARC? O briefing não detalha, mas ressalta que canais como esse podem não ser suficientes em incidentes de grande escala, especialmente se a falha for global e assíncrona.

Recomendação: Criação de um feed automatizado de NTAs entre grandes operadores — algo como um BGP de bloqueio de validação. O incidente do .de pode acelerar sua adoção.

Visão Metatron: o futuro da resiliência DNSSEC

O incidente do TLD .de em maio de 2026 não foi uma exceção — foi um prenúncio. À medida que o DNSSEC se torna obrigatório em mais TLDs (como previsto para .com e .org nos próximos anos), o número de pontos de falha na cadeia de confiança cresce exponencialmente.

O que precisa mudar

1. Key rollover de duas fases: Antes de publicar novas assinaturas, submeta a nova zona a um pool de resolvedores de validação (um sandbox DNSSEC) que emita um atestado de conformidade. Algo similar ao que a Let’s Encrypt faz com Certificate Transparency.
2. NTAs como feature nativa em todo resolvedor: Implementar RFC 7646 não é opcional. Operadores precisam de um botão de kill para validação de zonas específicas, com logs de ativação, notificação automática a peers e rollback programado.
3. EDE obrigatório e auditado: Códigos de erro estendidos devem ser testados em todos os cenários de validação quebrada. Sugiro a criação de uma matriz de testes coordenada pela ICANN ou DNS-OARC, onde operadores validam periodicamente se seus resolvedores retornam o código EDE correto.
4. Serve stale inteligente: Em vez de apenas servir dados expirados, o resolvedor poderia tentar múltiplas fontes (servidores autoritativos alternativos) antes de declarar SERVFAIL.

“A grande lição: O DNSSEC não pode ser um sistema binário. Precisamos de estratégias de degradação graciosa que preservem segurança e disponibilidade simultaneamente.”

Resumo prático para operadores

• Implemente serve stale com tempos de stale longos (horas).
• Tenha suporte nativo a Negative Trust Anchors — mesmo que via override.
• Audite seus códigos EDE para respostas DNSSEC Bogus.
• Crie um plano de comunicação automatizada com peers para ativação de NTAs.
• Participe de testes coordenados de validação de EDE (ICANN/DNS-OARC).

A Cloudflare agiu rápido, foi transparente sobre o bug e compartilhou os detalhes. Mas a indústria precisa evoluir de reação heróica para prevenção sistêmica. O apagão do .de foi um alerta. O tempo para agir é agora.