Resumo

  • A falha de DNSSEC da .de em 5 e 6 de maio de 2026 não foi uma história simples de indisponibilidade de servidores. O ponto central foi um estado criptográfico inconsistente produzido durante uma rolagem rotineira de ZSK, no qual múltiplos HSMs acabaram com pares de chaves distintos sob o mesmo key tag 33834, enquanto a zona publicava apenas uma DNSKEY compatível com uma dessas chaves privadas.
  • O caso desloca a pergunta de responsabilidade para controles mensuráveis: paridade entre ambiente de teste e topologia operacional, validação independente antes da distribuição, autoridade para bloquear uma liberação, dono de alerta, caminho de rollback, mitigação limitada por resolvedores recursivos e verificação externa das medidas anunciadas depois do incidente.

A zona .de é uma peça de infraestrutura pública com consequências práticas muito maiores do que a aparência técnica de um arquivo de zona. Ela conecta nomes, delegações, registros DS, ausência autenticada de registros e respostas assinadas que validadores recursivos usam para decidir se uma resposta pode ser aceita. Quando uma zona de topo opera com DNSSEC, ela não está apenas publicando dados; ela está publicando relações verificáveis entre DNSKEY, RRSIG, NSEC3, serial de zona, material de assinatura e cadeia de confiança.

O funcionamento normal depende de servidores autoritativos, redes separadas, anycast, equipamentos criptográficos e software de assinatura, mas também depende de uma relação mais simples e mais exigente: o que é assinado precisa corresponder ao que é publicado como chave pública.

Foi essa relação que quebrou durante a rolagem rotineira de DNSSEC da .de em 5 de maio de 2026. A linha do tempo formal divulgada pela DENIC deve ser mantida separada das observações feitas por operadores recursivos. Pela cronologia da própria DENIC, o impacto perceptível começou às 21:57 de 5 de maio; a distribuição de uma zona correta começou às 00:08 de 6 de maio; e a restauração do estado operacional anterior foi concluída às 01:15. Esse intervalo descreve a perspectiva operacional do registro. A Cloudflare, olhando de seu resolvedor 1.1.1.1, observou falhas de validação mais cedo em sua própria telemetria.

Essas duas camadas não devem ser fundidas em um único relógio mundial. Um resolvedor pode perceber sintomas antes de a organização registrar o impacto perceptível em sua própria cronologia, e diferentes redes podem experimentar efeitos conforme caches, caminhos recursivos, políticas de validação e dados stale variem.

Também é preciso separar alcance técnico de alcance medido. A DENIC afirmou que o incidente restringiu de forma significativa o acesso a domínios .de por aproximadamente três horas. Isso não autoriza dizer que todos os domínios .de ficaram inacessíveis para todos os usuários durante todo esse período. Nem autoriza transformar a observação de que, na prática, cerca de um terço das assinaturas geradas validava em uma porcentagem de domínios funcionando, usuários atingidos, tráfego perdido, consultas afetadas ou disponibilidade global.

O número de um terço descreve uma relação entre saída de assinatura e chave privada correspondente ao DNSKEY publicado. Ele não é uma métrica de alcance humano ou de disponibilidade por domínio.

A causa divulgada pela DENIC está no agente de rolagem de chave usado na terceira geração de seu sistema de assinatura, que havia entrado em operação em abril de 2026. Esse sistema combinava Knot DNS, componentes internos e múltiplos módulos de segurança de hardware distribuídos por dois centros de dados separados geográfica e logicamente por rede. Durante a rolagem de ZSK, o agente com defeito gerou um par de chaves diferente para cada HSM conectado, em vez de gerar um único par e carregá-lo em todos os HSMs. Essas chaves diferentes receberam os mesmos metadados e o mesmo key tag, 33834. A zona, porém, publicou apenas um DNSKEY.

Só o HSM que mantinha a chave privada correspondente a esse DNSKEY podia produzir assinaturas validáveis.

Essa distinção é a peça central do incidente. Não foi necessário que todos os servidores autoritativos caíssem. Não foi necessário que o anycast deixasse de encaminhar consultas. Não foi necessário que o HSM estivesse quebrado, que o Knot DNS tivesse falhado ou que uma chave tivesse sido comprometida. A DENIC afirmou explicitamente que descartou comprometimento, mau funcionamento do Knot DNS, mau funcionamento de HSM e uma colisão clássica de key tag.

O defeito descrito é mais específico e, do ponto de vista de responsabilidade, mais instrutivo: partes diferentes da topologia operacional foram levadas a manter material de chave diferente sob uma identidade operacional que parecia comum. A redundância não desapareceu; ela passou a carregar um estado compartilhado inválido.

Para entender o efeito, vale decompor o DNSSEC sem simplificá-lo demais. A ZSK, ou Zone Signing Key, assina conjuntos de registros da zona. A DNSKEY publicada permite que validadores verifiquem se as assinaturas RRSIG são compatíveis com a cadeia de confiança. Numa rolagem normal, a troca de chaves precisa preservar uma sobreposição segura entre chaves antigas e novas, tempos de cache, publicação, assinatura e validação. As práticas documentadas para operação de DNSSEC tratam rolagens como operações sensíveis justamente porque erros de coordenação podem tornar dados íntegros em dados não autenticáveis.

O validador recursivo não decide se um site é importante; ele verifica se a resposta está autenticada de acordo com as chaves publicadas e com a cadeia de confiança. Se a assinatura não valida, a resposta deve ser tratada como bogus.

O problema da .de foi agravado porque a falha não se limitou a domínios que tinham DNSSEC configurado no segundo nível. A zona de topo precisa responder sobre delegações e sobre a presença ou ausência de registros DS. Em DNSSEC, a negação autenticada é uma parte do sistema. NSEC3 permite provar, de forma assinada, que determinado registro não existe ou que uma delegação não tem DS correspondente. Quando assinaturas inválidas atingem esses registros, um resolvedor validador pode classificar a informação de delegação como bogus mesmo para um domínio filho que não usa DNSSEC.

Isso explica por que domínios não assinados embaixo da .de também podiam ser afetados. A rejeição não era um comportamento arbitrário de resolvedores rigorosos; era a consequência esperada de uma cadeia que não podia ser autenticada.

Resolvedores não validadores, por outro lado, continuaram retornando dados. Essa diferença pode criar a impressão de que a validação é a causa do problema. A interpretação correta é mais estreita. O DNSSEC revelou e aplicou a falha de autenticidade. Um resolvedor não validador pode continuar entregando dados quando a assinatura está incorreta, mas isso não prova que o dado esteja seguro; prova que a política local não está exigindo a validação que a zona anunciou como parte de sua cadeia de confiança. Em uma infraestrutura que escolheu publicar DNSSEC, a disponibilidade não pode ser definida apenas como “alguma resposta chegou”.

Ela precisa incluir a capacidade de entregar respostas que os validadores possam autenticar.

A Cloudflare acrescenta outra camada ao caso porque seus resolvedores tinham meios locais de mitigação. A empresa descreveu o uso de dados stale para amortecer parte do impacto e a aplicação temporária de uma Negative Trust Anchor para .de depois de confirmar o problema no lado autoritativo. Serve-stale permite que um resolvedor continue oferecendo dados expirados em certas condições, reduzindo o impacto imediato de falhas temporárias.

Uma NTA, conforme o mecanismo padronizado, é uma exceção temporária e local: o operador recursivo decide tratar uma zona quebrada como se estivesse não assinada por um período delimitado, para restaurar resolução enquanto a autoridade corrige o problema. Essa medida desloca uma decisão de segurança para o operador recursivo e precisa expirar. Ela não é uma estratégia geral para “resolver” DNSSEC desligando validação. É uma ferramenta de contenção quando a fonte autoritativa está sabidamente publicando material inválido.

A fronteira entre teste e ambiente operacional é uma das partes mais importantes do relatório da DENIC. Segundo a organização, o ambiente de teste tinha um HSM em um local. O defeito, porém, exigia múltiplos HSMs para se manifestar. Os cenários existentes não cobriram essa combinação; testes prévios, avaliação externa e operação paralela a frio não revelaram o comportamento específico que apareceu na topologia real. Isso não significa que não havia redundância. Significa que a redundância operacional introduziu uma condição de estado distribuído que o teste de menor escala não executou.

Se um agente de rolagem precisa coordenar N HSMs em dois locais, o teste de responsabilidade não é apenas “o código roda”. É “o código preserva identidade de chave, material privado, metadados, serial de zona, assinaturas e publicação quando todos os componentes reais participam”.

Essa é uma diferença prática entre testar funcionalidade e testar topologia. Um ambiente com um único HSM pode verificar se o caminho básico de assinatura funciona. Ele não verifica se um agente evita divergência de estado entre HSMs. Ele não verifica se todos os HSMs recebem o mesmo material, se uma chave pública publicada corresponde a todas as entidades que podem assinar, se a seleção de assinador distribui apenas assinaturas validáveis ou se a alternância entre locais preserva a mesma relação criptográfica. Em sistemas de registro, a escala não é detalhe operacional; ela faz parte da semântica do controle.

A pergunta correta depois desse incidente é se o sistema novo foi testado com paridade suficiente para reproduzir as condições que poderiam gerar falhas de estado compartilhado.

A detecção também precisa ser separada da intervenção. A DENIC disse que três ferramentas de teste e validação em execução contínua detectaram assinaturas ausentes ou não validáveis conforme esperado, mas que suas notificações não foram processadas corretamente. Isso é uma distinção dura para qualquer operador de infraestrutura crítica. Um monitor que registra o problema não é um controle suficiente se o alerta não tem dono, se a confirmação não tem prazo, se a escalada não é obrigatória, se a publicação não pode ser bloqueada ou se a reversão não tem autorização clara. A pergunta não é apenas “havia monitoramento?”.

A pergunta é: qual resultado de validação impede a distribuição de uma zona, quem recebe e reconhece o alerta, qual artefato independente autoriza a liberação e qual caminho restaura uma zona assinada conhecida como boa?

A rolagem de chaves é um ponto em que esses controles precisam estar amarrados. Antes de distribuir uma zona assinada, uma validação de cadeia completa deve verificar a zona candidata como um resolvedor validador a veria. Essa verificação precisa incluir DNSKEY, DS quando aplicável, RRSIG, NSEC3, serial de zona, tempos de validade e comportamento de delegação. Também precisa ser independente o bastante para não confiar apenas no componente que acabou de gerar o material. Se o mesmo sistema que assina é o único que declara que a assinatura está boa, a organização está aceitando um círculo de confiança operacional.

Em uma falha como a de maio de 2026, o controle que teria valor é aquele que compara a saída publicada com a verificação externa da própria cadeia.

O detalhe da validade variável ao longo do tempo também importa. A DENIC explicou que, conforme atualizações de zona prosseguiam, o registro SOA mudava e era reassinado, de modo que a validade podia variar. Isso torna inadequado falar de um estado estático de “um terço da zona funcionando”. A saída dependia de qual HSM produziu determinada assinatura, de quais registros foram reassinados, de tempos de cache e de quando os resolvedores observaram a zona. A falha era relacional: algumas assinaturas correspondiam ao DNSKEY publicado porque vinham do HSM que tinha a chave privada compatível; outras não.

A disponibilidade visível era mediada por caches, políticas de validação, serve-stale, consultas específicas e trajetórias de atualização. A precisão técnica exige preservar essa incerteza.

A restauração seguiu a lógica de voltar a um estado assinado válido, não a de simplesmente reiniciar servidores. A cronologia divulgada aponta a distribuição de uma zona correta a partir de 00:08 e a restauração do estado operacional anterior às 01:15. A diferença entre começar a distribuir material correto e restaurar completamente o estado anterior é relevante. Em DNS, caches, TTLs, propagação entre nós autoritativos, trajetórias de resolvedores e política local podem fazer com que a recuperação visível não seja simultânea para todos.

Um relatório responsável não transforma a primeira correção em recuperação universal instantânea, nem transforma a conclusão formal em prova de que todos os usuários tiveram a mesma experiência até aquele segundo. Ele descreve camadas: geração, validação, distribuição, observação por resolvedores, mitigação local e recuperação operacional.

As medidas anunciadas pela DENIC depois do incidente incluem fortalecimento de avaliação de código, alertas aprimorados, alternância acelerada para zona válida, validação parcial antes da implantação, suspensão de novas rolagens de ZSK enquanto trabalhos adicionais são realizados, ampliação do ambiente de teste e análise externa de segurança e processos. Essas medidas são relevantes, mas devem ser tratadas como compromissos que exigem evidência posterior. Elas não provam, por si só, que cada controle foi concluído ou que o novo desenho resiste ao mesmo tipo de falha.

A prova viria de registros de implementação, resultados de testes com múltiplos HSMs, exercícios de alerta, tempos medidos de rollback, validação independente de zonas candidatas e demonstração de que o ambiente de teste agora executa a mesma classe de estado distribuído que existe na topologia real.

A lição mais ampla é que anycast, múltiplos locais e múltiplos HSMs fornecem continuidade somente quando o estado assinado comum é válido. Anycast melhora alcance, latência e resistência a falhas de caminho ou de nó. Centros de dados separados reduzem riscos físicos e de rede. HSMs protegem material criptográfico e reduzem exposição de chaves privadas. Mas esses recursos não substituem a coerência do estado que eles servem. Se cada ponto da malha participa da distribuição de assinaturas que não correspondem ao DNSKEY publicado, a topologia robusta torna-se um mecanismo eficiente de replicação de erro.

Continuidade de infraestrutura de nomes é, em última instância, continuidade de registros corretos, assinaturas verificáveis e delegações autenticáveis.

A evidência pública ainda tem limites claros. O relatório não publica o código defeituoso, a ordem exata das condições internas do agente de rolagem, o grafo completo de implantação, a política de seleção de HSM durante a janela, as saídas brutas das três ferramentas de validação, a configuração completa de alerta, os tempos de primeiro alerta por ferramenta, métricas por resolvedor, por domínio, por rede ou por aplicação, nem perdas econômicas. Também não publica o escopo completo da avaliação externa anterior ou da operação paralela a frio.

Essas lacunas não são motivo para especular sobre ataque, negligência individual ou falha de componentes que foram descartados pela própria DENIC. Elas são a lista do que precisa ser medido para transformar um relatório causal em uma avaliação de controle.