Falha no DNSSEC do .AL expõe vulnerabilidade e Cloudflare inova com bypass de validação

O incidente do .AL em 3 de julho de 2026 não foi só uma falha operacional, foi um teste de estresse para a arquitetura de confiança do DNS. O domínio google.al, por exemplo, ficou inacessível para qualquer cliente usando resolvedores que validam DNSSEC, como o 1.1.1.1 antes da intervenção. Isso aconteceu porque a cadeia de confiança se quebrou duas vezes: primeiro com um DS na raiz apontando para uma chave DNSKEY que já não existia no .AL; depois com a remoção total das chaves DNSKEY sem restaurar a antiga, deixando a zona sem nenhuma assinatura válida. A Cloudflare reagiu com uma Negative Trust Anchor (NTA), mas dessa vez fez algo novo: usou o código EDE 33 para sinalizar explicitamente, dentro da própria resposta DNS, que a validação havia sido ignorada. Não é só um bypass técnico, é uma mudança de contrato entre resolvedor e cliente.

Essa abordagem contrasta com o que ocorreu no incidente do .DE em maio de 2026, coberto pela CEVIU em 7 de junho de 2026. Naquela ocasião, a Cloudflare aplicou uma NTA, mas sem transparência técnica na resposta: o cliente recebia um NOERROR idêntico ao de um domínio plenamente validado. Agora, com o EDE 33, ferramentas de observabilidade, scripts de monitoramento e até clientes DNS avançados conseguem distinguir, em tempo real, quando uma resposta está livre de spoofing por DNSSEC, ou quando ela está sendo entregue sob uma exceção operacional explícita. É um passo concreto rumo à operação de infraestrutura como código: onde cada decisão de contorno tem seu log estruturado embutido no protocolo.

A diferença entre o incidente do .DE (maio de 2026) e o do .AL (julho de 2026) não está no uso da NTA, esse mecanismo já era padrão desde então. Está na forma como a Cloudflare comunicou sua aplicação. Em maio, a NTA foi invisível para quem consumia a resposta DNS. Em 3 de julho de 2026, pela primeira vez, o 1.1.1.1 devolveu o EDE 33 junto com cada resposta para google.al e demais domínios .AL, transformando uma medida de emergência em um evento auditável. Também corrigiu o erro de diagnóstico anterior: agora, além do EDE 33, inclui o EDE 9 (DNSKEY Missing), identificando com precisão a causa raiz, algo que não aconteceu no caso do .DE, conforme relatado pela CEVIU em 7 de junho de 2026.

Para equipes de SRE e DevOps, isso muda como se faz observabilidade de DNS. Um alerta baseado apenas em SERVFAIL perdeu relevância: agora é possível diferenciar entre falha de rede, timeout de autoritativo e falha intencional de validação. Para equipes de segurança, o EDE 33 permite integrar verificações de integridade DNSSEC diretamente em pipelines CI/CD, por exemplo, bloquear deploy se um domínio crítico estiver respondendo com EDE 33 sem justificativa documentada. E para provedores de nuvem, é um aviso claro: resiliência não é só manter o serviço funcionando, mas garantir que cada atalho operacional seja rastreável, audível e reversível, sem depender de status pages ou comunicação fora de banda.