DENIC .de (2026): Assinaturas DNSSEC Quebradas e o Colapso da Cadeia de Confiança

O DNSSEC funciona como uma cadeia de confiança hierárquica. A raiz DNS (.) assina os registros de delegação para cada TLD; cada TLD assina os registros de delegação para os domínios sob ele; e assim por diante até o domínio folha. Cada elo dessa cadeia é um par de registros: o DNSKEY (a chave pública) e o RRSIG (a assinatura digital sobre um conjunto de registros). Um resolver validador percorre essa cadeia de cima para baixo, verificando cada assinatura. Se qualquer elo falhar, assinatura expirada, chave incorreta, registro ausente, o resolver retorna SERVFAIL e o domínio torna-se efetivamente inacessível.

No caso DENIC, o elo que quebrou foi o próprio TLD .de. As assinaturas RRSIG publicadas nos servidores autoritativos da DENIC tornaram-se inválidas, seja por expiração de validade criptográfica, por um rollover de chave ZSK (Zone Signing Key) mal executado, ou por uma inconsistência entre a chave usada para assinar e a chave publicada no registro DNSKEY. O resultado foi imediato e total: qualquer resolver com validação DNSSEC ativa que tentasse resolver qualquer domínio .de recebia SERVFAIL. Não havia fallback parcial, a falha era binária.

O que torna este incidente particularmente instrutivo é a assimetria de impacto: resolvers com DNSSEC desabilitado continuaram funcionando normalmente. Isso significa que parte dos usuários finais, aqueles atrás de ISPs ou resolvers corporativos sem validação, não percebeu nada. Mas os usuários protegidos pelo mecanismo de segurança foram exatamente os mais afetados. É uma inversão cruel: a feature de segurança tornou-se o vetor de indisponibilidade.

A mitigação de um incidente DNSSEC em nível de TLD não é trivial. Ao contrário de um rollback de aplicação, onde você reverte um deploy e em minutos o sistema se recupera, a correção de uma zona DNSSEC quebrada envolve múltiplas camadas com latências próprias.

Opção 1: Rollback de zona: Se a DENIC mantém snapshots versionados da zona assinada, é possível republicar a versão anterior com assinaturas válidas. Isso é rápido em termos de geração, mas ainda requer propagação para todos os servidores autoritativos (a DENIC opera múltiplos servidores anycast distribuídos globalmente) e aguardar a expiração de caches negativos nos resolvers.

Opção 2: Re-assinatura emergencial: Assinar a zona .de do zero com a chave correta é uma operação computacionalmente intensiva. Com ~17 milhões de registros de delegação, cada um precisando de um ou mais RRSIGs, o processo pode levar dezenas de minutos mesmo com HSMs de alta performance. Após a geração, a zona precisa ser transferida (via AXFR/IXFR) para todos os servidores autoritativos secundários.

O problema do cache: Mesmo após a correção nos autoritativos, resolvers recursivos que já cachearam respostas SERVFAIL ou dados inválidos precisam aguardar a expiração do TTL negativo (controlado pelo campo minimum do registro SOA da zona, tipicamente 300–900 segundos para zonas de TLD). Alguns resolvers implementam negative caching mais agressivo. Isso significa que a recuperação percebida pelos usuários finais é sempre mais lenta do que a correção nos servidores autoritativos, há uma janela de impacto residual inevitável.

Comunicação durante o incidente: Um aspecto frequentemente subestimado é a comunicação com operadores de resolvers grandes (Google, Cloudflare, ISPs nacionais). Em incidentes DNSSEC de TLD, é possível pedir a esses operadores que temporariamente desabilitem a validação DNSSEC para o TLD afetado como medida de emergência, uma decisão com implicações de segurança sérias, mas que pode ser justificada para reduzir o impacto enquanto a correção é preparada. Não há evidência pública de que isso foi feito neste caso.

O incidente DENIC materializa um debate que existe desde a concepção do DNSSEC: o protocolo foi projetado para ser fail-closed por razões de segurança. Se um resolver encontra uma assinatura inválida, a resposta correta do protocolo é rejeitar a resposta, não servir dados potencialmente adulterados. Isso é correto do ponto de vista da segurança: um atacante que consegue interceptar e modificar respostas DNS não deve ser capaz de servir dados falsos simplesmente porque a assinatura 'não pôde ser verificada'.

Mas essa decisão de design tem um custo operacional enorme: uma falha de configuração, não um ataque, apenas um erro humano ou de automação, produz exatamente o mesmo resultado que um ataque bem-sucedido do ponto de vista do usuário final. O domínio fica inacessível. Não há distinção visível entre 'zona comprometida por atacante' e 'zona com chave rotacionada incorretamente'.

Esse trade-off é especialmente agudo em TLDs por três razões:

1. Blast radius total: Uma falha na assinatura do TLD invalida toda a hierarquia abaixo dele. Não é um domínio, são milhões. O impacto não escala linearmente com o tamanho do erro; ele é imediatamente máximo.

1. Sem circuit breaker nativo: O protocolo DNS não tem um mecanismo de circuit breaker. Não existe um 'modo de degradação' onde o resolver serve dados não-validados com um aviso. A escolha é binária: validar ou não validar. Operadores que desabilitam DNSSEC como resposta a incidentes estão essencialmente desligando um sistema de segurança em produção.

1. Complexidade operacional da gestão de chaves: Rollovers de ZSK e KSK são operações complexas com janelas de tempo precisas (o DS record na zona pai precisa ser atualizado antes que a nova chave comece a ser usada para assinar, e a chave antiga precisa permanecer válida por tempo suficiente para que os caches expirem). Qualquer desvio nessa sequência pode resultar em exatamente o que ocorreu com a DENIC.

A lição não é que o DNSSEC é ruim, é que DNSSEC é uma tecnologia de segurança que exige maturidade operacional equivalente à sua complexidade criptográfica. Implementar DNSSEC sem automação robusta de rollover, sem validação pré-publicação e sem runbooks testados é aceitar um risco operacional significativo em troca de proteção contra ataques de envenenamento de cache.