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

Em 5 de maio de 2026, a DENIC publicou assinaturas DNSSEC inválidas para o TLD .de, tornando milhões de domínios alemães inacessíveis para resolvers com validação DNSSEC habilitada. O incidente expôs fragilidades estruturais na gestão de chaves, na ausência de validação canary antes da publicação de zonas assinadas e no trade-off fundamental entre segurança criptográfica e disponibilidade operacional.

- URL: https://fernando.moretes.com/studies/denic-de-dnssec-2026

- Markdown: https://fernando.moretes.com/studies/denic-de-dnssec-2026/study.md?lang=pt

- Type: Post-mortem

- Company: DENIC

- Domain: Rede

- Date: 2026-05-05

- Tags: dnssec, dns, tld, incident, postmortem, key-management, availability, trust-chain

- Reading time: 11 min

---

## Ficha do Incidente

- **Operador afetado:** DENIC eG — operadora do TLD .de (maior ccTLD da Europa)
- **Data do incidente:** 5 de maio de 2026
- **Duração estimada:** Várias horas (estimativa: 4–8 h até mitigação ampla; TTL de caches prolongou impacto residual)
- **Escala do TLD .de:** ~17 milhões de domínios registrados — maior ccTLD da Europa
- **Impacto primário:** Falha de resolução DNSSEC para todos os domínios .de em resolvers com validação habilitada (SERVFAIL)
- **Resolvers afetados:** Resolvers públicos e corporativos com DNSSEC validation ativo (ex.: 8.8.8.8, 1.1.1.1, resolvers ISP)
- **Resolvers não afetados:** Resolvers com validação DNSSEC desabilitada (continuaram resolvendo normalmente)
- **Tipo de falha:** Assinaturas RRSIG inválidas / expiradas publicadas na zona raiz .de
- **Stack relevante:** DNSSEC (RFC 4033–4035, RFC 9364), BIND/NSD (servidores autoritativos), HSM para chaves ZSK/KSK, pipeline de assinatura de zona
- **Classificação:** Disponibilidade — P1 / Severidade crítica

Uma assinatura criptográfica inválida publicada no topo do TLD .de foi suficiente para tornar inacessíveis milhões de domínios alemães para qualquer resolver que cumpre o protocolo DNSSEC corretamente. O incidente não foi um ataque — foi uma falha operacional silenciosa que o próprio mecanismo de segurança transformou em indisponibilidade em escala continental. É o paradoxo central do DNSSEC: quando funciona, é invisível; quando quebra, quebra tudo de uma vez.

## O que aconteceu: a mecânica da falha

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.

## Linha do Tempo do Incidente

1. **T-? (Pré-incidente): Rollover ou re-assinatura agendada** — A DENIC executa periodicamente o rollover de chaves ZSK e KSK, bem como a re-assinatura da zona .de. Um processo automatizado ou manual de geração e publicação de assinaturas RRSIG é disparado como parte da manutenção regular da zona.

2. **T+0 (5 mai 2026, início): Zona assinada com chave inválida publicada** — A zona .de é republicada nos servidores autoritativos com assinaturas RRSIG que não passam na validação — possivelmente porque a chave ZSK ativa foi substituída mas o DS record correspondente não foi atualizado na zona raiz, ou porque as assinaturas foram geradas com uma chave que não corresponde ao DNSKEY publicado. Os servidores autoritativos respondem normalmente a queries; o problema está nos dados que eles servem.

3. **T+~5 min: Primeiras falhas detectadas por monitoramento externo** — Ferramentas de monitoramento DNS externas (como DNSViz, Zonemaster, ou alertas de clientes) começam a reportar SERVFAIL para domínios .de em resolvers validadores. O problema se propaga imediatamente — não há período de degradação gradual, pois a falha é na raiz da cadeia de confiança do TLD.

4. **T+~15–30 min: DENIC confirma o incidente internamente** — A equipe de operações da DENIC identifica a causa raiz: inconsistência entre as assinaturas RRSIG publicadas e a(s) chave(s) DNSKEY ativa(s). O diagnóstico é relativamente rápido porque a natureza da falha DNSSEC é auditável — ferramentas como `dig +dnssec` e DNSViz tornam a inconsistência imediatamente visível.

5. **T+~30–90 min: Decisão de mitigação — rollback ou re-assinatura emergencial** — A DENIC avalia duas opções: (1) reverter para a zona anterior com assinaturas válidas (rollback), ou (2) re-assinar a zona com a chave correta e republicar. A re-assinatura de uma zona do tamanho de .de (~17M domínios) não é instantânea — envolve operações criptográficas em HSM e propagação para múltiplos servidores autoritativos distribuídos globalmente.

6. **T+~2–4 h: Zona corrigida propagada para servidores autoritativos** — A zona .de com assinaturas RRSIG válidas é publicada nos servidores autoritativos. Resolvers que consultam diretamente os autoritativos começam a obter respostas válidas. Porém, caches de resolvers recursivos que já armazenaram respostas de falha ou respostas com dados inválidos precisam expirar seus TTLs antes de recuperar.

7. **T+~4–8 h: Recuperação ampla; impacto residual por TTL de cache** — A maioria dos resolvers validadores recupera a resolução normal à medida que os caches expiram e novas consultas aos autoritativos retornam dados válidos. Alguns ambientes com TTLs longos ou políticas de cache agressivas podem ter experimentado impacto residual por mais tempo.

8. **Pós-incidente: Comunicado público e revisão de processos** — A DENIC publica comunicado reconhecendo o incidente, descreve a causa raiz e anuncia revisão dos procedimentos de assinatura de zona e validação pré-publicação.

## Fluxo de Falha: Cadeia de Confiança DNSSEC Quebrada no .de

O diagrama reconstrói o fluxo de resolução DNSSEC e onde a falha se manifestou. A zona .de foi assinada com chave inconsistente; todo resolver validador que percorreu a cadeia de confiança encontrou o elo quebrado e retornou SERVFAIL ao cliente.

### 👤 Client Layer

- Browser / App End User (user)

### 🔄 Recursive Resolver (Validating)

- Recursive Resolver DNSSEC Validation ON (e.g. 8.8.8.8, 1.1.1.1) (network)
- Resolver Cache Negative / SERVFAIL cached by TTL (data)

### 🌐 DNS Root & Trust Anchor

- DNS Root (.) Trust Anchor Signs .de DS record (security)

### 🇩🇪 DENIC — TLD .de (Failure Zone)

- DENIC Authoritative Nameservers (a–f.nic.de) (network)
- Zone Signing Pipeline HSM + ZSK/KSK ⚠️ Inconsistent RRSIG (security)
- DNSKEY Record (Published Key) ✓ Valid in zone (security)
- RRSIG Records (Signatures) ❌ Signed w/ wrong key or expired (security)

### 📦 Downstream Domains (.de)

- example.de Authoritative NS (unreachable via DNSSEC) (network)

### Fluxos

- browser -> resolver: Query: example.de
- resolver -> root: Valida âncora de confiança
- root -> denic_auth: Delega .de (DS record OK)
- denic_auth -> dnskey: Retorna DNSKEY
- denic_auth -> rrsig: Retorna RRSIG
- zone_sign -> rrsig: ⚠️ Assina com chave errada
- dnskey -> resolver: Chave pública
- rrsig -> resolver: ❌ Assinatura inválida
- resolver -> cache: Armazena SERVFAIL
- resolver -> browser: SERVFAIL ← cadeia quebrada
- domain_auth -> resolver: Nunca alcançado (SERVFAIL antes)

> **Causa Raiz: Inconsistência entre Chave de Assinatura e DNSKEY Publicado:** A falha central foi uma divergência entre a chave criptográfica usada para gerar os registros RRSIG e a chave pública anunciada no registro DNSKEY da zona .de — ou, alternativamente, assinaturas RRSIG com janela de validade expirada publicadas em produção. Em ambos os cenários, o resultado é idêntico do ponto de vista do resolver: a verificação criptográfica falha, a cadeia de confiança é considerada comprometida, e o resolver retorna SERVFAIL por design — exatamente como o protocolo especifica que deve se comportar (RFC 4035, Seção 5). O DNSSEC não tem modo de 'degradação graciosa': ou a cadeia valida completamente, ou o domínio é inacessível. Não existe meio-termo.

## Remediação: o que a DENIC precisou fazer e por que levou horas

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 Trade-off Fundamental: Segurança vs. Disponibilidade no DNSSEC

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.

2. **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.

3. **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.

## Lições Técnicas do Incidente

- **DNSSEC é fail-closed por design:** Uma assinatura inválida em qualquer elo da cadeia resulta em SERVFAIL total para toda a hierarquia abaixo. Não existe degradação graciosa — o blast radius é imediatamente máximo.
- **Validação canary antes de publicar zonas assinadas é obrigatória:** Antes de promover uma zona assinada para produção, um resolver validador isolado deve verificar a cadeia de confiança completa. Se falhar no canary, falha para todos — melhor falhar silenciosamente antes da publicação.
- **Rollover de chaves ZSK/KSK tem uma sequência precisa e não tolerante a erros:** A nova chave deve ser publicada no DNSKEY *antes* de ser usada para assinar; o DS record no pai deve ser atualizado *antes* de remover a chave antiga; a chave antiga deve sobreviver pelo menos um TTL máximo de cache após a transição.
- **Automação de rollover reduz risco humano mas exige testes rigorosos:** Processos manuais de rollover são propensos a erros de sequência. Automação (ex.: OpenDNSSEC, BIND's built-in KASP) reduz esse risco, mas a automação com bug é pior que o processo manual — ela executa o erro em escala e velocidade.
- **TTL de cache é uma segunda camada de latência na recuperação:** Mesmo após corrigir os autoritativos, resolvers com caches negativos levam minutos a horas para recuperar. O campo `minimum` do SOA controla o negative TTL — valores baixos (300s) aceleram a recuperação mas aumentam a carga nos autoritativos em condições normais.
- **Monitoramento DNSSEC deve ser externo e contínuo:** A DENIC (e qualquer operador de zona assinada) deve monitorar continuamente a validade das assinaturas RRSIG a partir de múltiplos pontos externos com validação habilitada. Ferramentas como Zonemaster, DNSViz e Nagios/Icinga com plugins DNSSEC devem disparar alertas horas antes da expiração de assinaturas.

> **Minha Leitura Sênior: O Problema não é DNSSEC — é Maturidade Operacional:** Depois de 16 anos trabalhando com sistemas que precisam ser simultaneamente seguros e disponíveis — infraestrutura financeira, plataformas de pagamento, sistemas críticos — o que me chama atenção neste incidente não é a falha técnica em si. É a ausência de controles que deveriam existir *antes* da publicação da zona.

Um sistema de assinatura de zona para um TLD com 17 milhões de domínios deveria ter, no mínimo: (1) um resolver validador canary que verifica a zona *antes* de ela ser promovida para os autoritativos de produção — se o canary falhar, a publicação é bloqueada automaticamente; (2) alertas de expiração de assinatura com antecedência de pelo menos 48 horas, não 0 horas; (3) snapshots versionados da zona para rollback em menos de 5 minutos; e (4) um runbook testado trimestralmente para o cenário de 'zona DNSSEC inválida em produção'.

O que me preocupa mais é o padrão sistêmico que este incidente representa. DNSSEC foi projetado nos anos 1990 e padronizado nos anos 2000 com a premissa de que operadores de zona teriam processos operacionais maduros. A realidade é que a complexidade do protocolo — especialmente o gerenciamento de chaves e o processo de rollover — é genuinamente difícil, e a maioria das implementações depende de automação que raramente é testada em cenários de falha.

Se eu fosse arquitetar a solução de assinatura de zona da DENIC hoje, eu usaria um pipeline de CI/CD para a zona DNS: cada mudança na zona passa por um stage de validação onde um resolver DNSSEC completo verifica a cadeia antes de qualquer promoção para produção. Falha na validação = pipeline bloqueado = zero impacto em produção. É o mesmo princípio que aplicamos a qualquer software crítico — você não faz deploy sem testes. Por que seria diferente com DNS?

O trade-off segurança vs. disponibilidade é real, mas é gerenciável. O que não é gerenciável é descobrir esse trade-off pela primeira vez durante um incidente P1 às 3 da manhã.

## Estratégias de Mitigação: Comparação de Abordagens
| Critério | Abordagem | Tempo de Recuperação | Risco de Segurança | Complexidade Operacional | Recomendação |
| --- | --- | --- | --- | --- | --- |
| Rollback de zona assinada (snapshot) | 5–15 min | Baixo (dados válidos anteriores) | Baixa (se snapshots existirem) | ✅ Preferida — requer snapshots versionados | — |
| Re-assinatura emergencial da zona | 30–90 min | Baixo (se feita corretamente) | Alta (pressão, HSM, propagação) | ⚠️ Aceitável se não há snapshot disponível | — |
| Desabilitar DNSSEC validation nos resolvers | Imediato (por resolver) | Alto (remove proteção contra cache poisoning) | Média (coordenação com operadores) | 🚨 Último recurso — decisão com implicações sérias | — |
| Aguardar expiração de TTL de cache | Automático após fix nos autoritativos | Nenhum | Nenhuma (passiva) | ℹ️ Inevitável — complementar a qualquer abordagem | — |

## Veredicto: DNSSEC Exige Engenharia de Confiabilidade, não apenas Criptografia

O incidente DENIC de maio de 2026 não é uma falha de criptografia — é uma falha de engenharia de confiabilidade aplicada a um sistema de segurança crítico. O DNSSEC funciona exatamente como foi projetado: ele detectou uma inconsistência na cadeia de confiança e bloqueou a resolução. O problema é que a inconsistência foi introduzida pelo próprio operador, não por um atacante.

Isso revela uma verdade desconfortável sobre segurança em infraestrutura crítica: **mecanismos de segurança que não têm salvaguardas operacionais equivalentes à sua criticidade tornam-se vetores de indisponibilidade**. O DNSSEC, implementado sem validação pré-publicação, sem automação de rollover testada e sem runbooks de recuperação, é uma aposta de alto risco: quando funciona, protege contra ataques sérios; quando quebra por erro operacional, derruba tudo.

As três lições que eu levaria deste incidente para qualquer projeto de infraestrutura crítica são:

**1. Fail-closed sem escape hatch é uma decisão de design que deve ser explícita.** O DNSSEC escolheu segurança sobre disponibilidade. Essa é uma escolha legítima — mas precisa ser acompanhada de controles operacionais que tornem a falha operacional improvável, não apenas a falha de segurança.

**2. Validação canary antes de qualquer publicação de zona assinada não é opcional.** É o equivalente DNS de um teste de integração antes do deploy. Custa minutos; economiza horas de incidente.

**3. O blast radius de uma falha em TLD é categoricamente diferente do blast radius de uma falha em um domínio.** Arquiteturas de segurança para infraestrutura hierárquica precisam ser projetadas com essa assimetria em mente — os controles no topo da hierarquia precisam ser proporcionalmente mais rigorosos.

Para engenheiros que trabalham com DNS e DNSSEC: leiam o RFC 9364 não como documentação de protocolo, mas como especificação de um sistema que falha de forma total e imediata quando qualquer invariante é violado. Projete seus controles operacionais a partir dessa premissa.

## Referências

- [DENIC eG — Official Website (TLD .de operator)](https://www.denic.de/en/)
- [RFC 9364 — DNS Security Extensions (DNSSEC) Overview](https://www.rfc-editor.org/rfc/rfc9364)
- [RFC 4033 — DNS Security Introduction and Requirements](https://www.rfc-editor.org/rfc/rfc4033)
- [RFC 4034 — Resource Records for the DNS Security Extensions](https://www.rfc-editor.org/rfc/rfc4034)
- [RFC 4035 — Protocol Modifications for the DNS Security Extensions](https://www.rfc-editor.org/rfc/rfc4035)
- [RFC 6781 — DNSSEC Operational Practices, Version 2](https://www.rfc-editor.org/rfc/rfc6781)
- [DNSViz — DNSSEC Visualization Tool](https://dnsviz.net/)
- [Zonemaster — DNS Zone Testing Tool](https://www.zonemaster.net/)

## Fontes do caso

- [DENIC](https://www.denic.de/en/)
- [RFC 9364 — DNSSEC overview](https://www.rfc-editor.org/rfc/rfc9364)