Um domínio nacional deixou de resolver durante mais de uma hora
O domínio .al da Albânia partiu-se este mês. Durante mais de uma hora, os endereços de todo o país deixaram de resolver: portais do Estado, órgãos de comunicação social e plataformas privadas por igual. Os cidadãos não chegavam aos serviços públicos, e as empresas que operam sob domínios albaneses desapareceram simplesmente da internet. A AKEP, a autoridade nacional das comunicações eletrónicas e postais, indicou que o problema estava em sistemas no estrangeiro que gerem parte da infraestrutura do .al. A causa foi uma troca de chaves DNSSEC falhada, aquela manutenção criptográfica de rotina que deve permanecer invisível.
Porque importa. O DNSSEC existe para provar que uma resposta de DNS é autêntica. Quando as assinaturas não validam, um resolvedor bem configurado tem de recusar a resposta por completo e devolver um erro. É a norma a funcionar exatamente como foi desenhada. O modo de falha de um controlo de segurança que faz bem o seu trabalho é um país a ficar sem internet.
A solução foi desligar a segurança
Ninguém no registo conseguia reparar as assinaturas a tempo, por isso a rede contornou o problema da única maneira que sabe. A Cloudflare desativou temporariamente a validação DNSSEC para o .AL no seu resolvedor 1.1.1.1, e outros operadores fizeram o mesmo. O mecanismo chama-se âncora de confiança negativa e diz ao resolvedor para tratar uma zona assinada como se não estivesse assinada. Existe precisamente para estes incidentes. A resolução voltou. A validação não.
A Cloudflare tinha exposto a lógica sem rodeios durante um episódio idêntico em maio: nenhum utilizador que esteja neste momento a resolver um desses nomes preferiria um erro a uma resposta não validada. É quase de certeza verdade, e aí reside o problema todo. O controlo não falha em modo seguro nem falha em voz alta. Falha aberto, por convenção do setor, exatamente no momento em que um atacante mais o quereria desligado.
Dez semanas antes, o mesmo aconteceu ao .de
A 5 de maio de 2026, por volta das 19:30 UTC, a DENIC publicou assinaturas DNSSEC defeituosas para a zona .de. Os resolvedores que validam eram obrigados a rejeitá-las e a devolver erros, e um dos maiores domínios de topo da internet começou a cair. As falhas subiram durante três horas enquanto expiravam os registos em cache. A própria DENIC apontou a causa: uma troca de chaves de rotina e programada, durante a qual foram geradas e distribuídas assinaturas que não podiam ser validadas. Os operadores de resolvedores colocaram âncoras de confiança negativa em menos de uma hora, e o 1.1.1.1 tinha a sua mitigação de pé às 22:17 UTC.
Dois registos nacionais, com dez semanas de intervalo, ambos derrubados por manutenção programada e não por um atacante. Esta não é uma história sobre a Albânia, e não foi uma história sobre a Alemanha. É a mesma falha a chegar duas vezes, o que faz dela um padrão e não um acidente. Vai chegar uma terceira vez.
Agora o resolvedor diz-lhe quando deixou de verificar
O que é genuinamente novo saiu deste incidente. A par do contorno, a Cloudflare introduziu o Extended DNS Error 33, um código devolvido na própria resposta que sinaliza que a validação DNSSEC foi contornada. Até agora, um resolvedor que tinha deixado cair em silêncio a validação de uma zona parecia igual a outro que continuava a verificar. Recebia uma resposta, a resposta funcionava, e em lado nenhum se dizia que a garantia criptográfica por trás dela estava suspensa, talvez durante horas e talvez para um domínio de topo inteiro.
O que muda. Esse silêncio era a exposição a sério. Quem coloca o DNSSEC num registo de riscos, num questionário de segurança ou num conjunto de controlos da NIS2 andava a afirmar algo que não conseguia observar. O EDE 33 transforma um estado invisível num estado registado. É um pequeno acrescento a um pacote de resposta e é o primeiro sinal honesto neste modo de falha.
O que fazer com uma chave que não é sua
A parte incómoda é o pouco que lhe cabe corrigir. A sua zona pode estar assinada de forma impecável e o seu domínio desaparece na mesma, porque a rutura aconteceu um nível acima, no registo que opera o sufixo do seu país. A NIS2 já trata os prestadores de serviços de DNS e os registos de domínios de topo como entidades de elevada criticidade, o que reconhece que esta camada é sistémica. Não lhe dá uma alavanca. O que pode fazer é deixar de considerar essa camada inerte: vigie se o seu próprio domínio resolve a partir de vários resolvedores públicos e não apenas da rede do escritório, e anote o que esses resolvedores respondem.
A conclusão. Registe o EDE 33 e emita alerta sobre ele. Se o seu resolvedor começar a comunicar que contornou a validação para o seu domínio de topo, está numa janela em que as respostas de DNS do seu domínio não estão verificadas, e convém sabê-lo enquanto acontece em vez de o ler mais tarde. Dois países já atravessaram essa janela sem a conseguirem ver. O terceiro terá pelo menos uma luz acesa.
Leia a seguir: A sua dependência da cloud é agora um risco regulado. A maioria das empresas nem sequer consegue ver a sua. | Uma falha da Cisco com 18 anos tem agora um prazo de 3 dias
