5 de maio às 21h43. há uma crise na parte alemã da Internet: qualquer pessoa que tente acessar um endereço com terminação .de só recebe uma mensagem de erro – pelo menos se o servidor DNS usar uma assinatura DNSSEC validada. Por volta da 1h, o problema estava completamente resolvido. A DENIC eG, que gere este domínio, é responsável pela configuração DNSSEC da zona .de. Isso agora explica o problema.
Leia mais depois do anúncio
A postagem no blog do DENIC indica que o servidor DNS usa o software Knot, um serviço de servidor de código aberto mantido pela organização tcheca de gerenciamento de domínio CZ.NIC, o administrador do domínio .cz. Na DENIC, Knot funciona junto com o “desenvolvimento interno junto com módulos de segurança de hardware (HSMs)”. Em abril de 2026, esta infraestrutura foi transformada na terceira geração.
colisão de chave
A troca regular de chaves de marcação de zona começa em 2 de maio. Uma nova chave pública com ID 33834 foi emitida – 3 dias antes de ser usada para fazer login pela primeira vez. O que ninguém desconfia é que houve um erro na parte do código que foi desenvolvido por ele mesmo que fez com que três pares de chaves com a tag 33834 fossem gerados no servidor, mas apenas uma chave pública foi emitida com esse número. Quando esta chave foi usada pela primeira vez para inserir a entrada SOA, apareceu um estranho padrão de erro, que pode ser rastreado com uma ferramenta como dnsviz.com: Apenas alguns dos seis servidores de nomes DENIC usam a chave privada correta que corresponde à chave pública, os outros sempre enviam assinaturas inválidas. O registro SOA muda frequentemente porque sempre que há uma mudança na zona, o número de série nesse registro muda. Isto é consistente com a reciprocidade que tem sido observada na análise detalhada dos dados disponíveis.
O responsável pela DENIC observou que a parte do código do software de fabricação própria “não foi totalmente coberta pelo cenário de teste e, portanto, não foi reconhecida como um defeito durante o teste ou na operação paralela ‘fria’ antes do comissionamento” e enfatizou ainda que foram utilizadas três ferramentas de teste na zona, todas eficazes – “mas a mensagem não foi processada corretamente”.
Jogos de azar: A cada mudança de zona, é necessária uma mudança de número de série e uma nova assinatura. O erro fez com que seis servidores usassem uma das três chaves com o mesmo ID. Apenas um corresponde à chave pública.
A explicação não fornece clareza total. O código de desenvolvimento interno não é de código aberto, os módulos de segurança de hardware utilizados não são nomeados e as circunstâncias em que as principais colisões ocorrem exclusivamente em sistemas produtivos e não em ambientes de teste não são descritas. Afinal, ele prometeu fornecer mais informações quando a investigação for concluída.
Todos os domínios são afetados
Leia mais depois do anúncio
Em uma postagem no blog, o DENIC também corrigiu a afirmação da noite passada de que apenas os domínios onde o DNSSEC está ativo são afetados. Esta afirmação é inconsistente com as observações durante o apagão. Na verdade, além das entradas SOA, as entradas NSEC3 também são afetadas. O NSEC3 evita que invasores com engarrafamentos derrotem o DNSSEC simplesmente enviando a resposta “DNSSEC está desabilitado para este domínio”. NSEC3 é uma prova criptográfica do nada. Sem entradas NSEC3 válidas, as verificações de DNSSEC falham em todos os domínios .de.
Conclusão
O caso ainda não está encerrado, como escreveu o próprio DENIC. Além de uma explicação precisa do problema (incluindo o melhor código), o DENIC não publicou uma lista de medidas previstas sobre como o problema pode ser identificado no futuro. Não apenas os operadores de infraestrutura DNSSEC para domínios, mas também os operadores de outros TLDs beneficiarão destas conclusões. O problema com colisões de chaves no nível do domínio de nível superior não é novidade: em 2024, o operador russo do TLD .ru sofreu uma interrupção e a culpa foi de uma colisão de chaves.
(hora)
