O problema do bypass silencioso no DNSSEC
Quando um TLD de país quebra a cadeia de confiança do DNSSEC, resolvedores validantes como o 1.1.1.1 da Cloudflare são obrigados a rejeitar todas as consultas daquele TLD. A solução operacional é conhecida: instalar um Negative Trust Anchor (NTA), conforme a RFC 7646, que diz ao resolvedor pra tratar a zona como não assinada e pular a validação.
O problema? Até pouco tempo, uma resposta servida sob NTA era idêntica a uma resposta totalmente validada. Clientes, ferramentas de monitoramento e aplicações não tinham como diferenciar uma resposta criptograficamente verificada de uma que foi servida com a validação suspensa.
É exatamente essa lacuna que o trabalho recente da Cloudflare com o EDE 33 (근거자료) resolve. Quando o TLD .al (Albânia) sofreu um rollover de chave DNSSEC quebrado em julho de 2026, o 1.1.1.1 se tornou o primeiro resolvedor grande a sinalizar a presença de NTA dentro da própria resposta DNS.
Por que isso importa pra quem opera infra
Antes do EDE 33, a única forma de divulgação era out-of-band: uma status page, um post em lista de e-mail ou um blog. Isso exige que o usuário vá procurar. Um sistema de monitoramento automatizado consultando o 1.1.1.1 não tinha como detectar programaticamente que a validação DNSSEC foi ignorada pra um TLD inteiro.
Como o EDE 33 funciona na prática
Os códigos Extended DNS Error (EDE), definidos na RFC 8914, permitem que resolvedores anexem contexto extra a qualquer resposta — sucesso ou falha. O novo código EDE 33, proposto por Babak Farrokhi do Quad9 com a Cloudflare como coautora, sinaliza que um Negative Trust Anchor está ativo pra zona consultada.
Olha só uma resposta real capturada durante o incidente do .al:
$ kdig @1.1.1.1 google.al
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 32848
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1
;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR
;; EDE: 9 (DNSKEY Missing): 'no SEP matching the DS found for al.'
;; EDE: 33 (Negative Trust Anchor): 'a Negative Trust Anchor has been applied for this query (see RFC 7646)'
;; ANSWER SECTION:
google.al. 300 IN A 142.251.142.196
Lendo a resposta
status: NOERROR+ registro A válido — o domínio resolve normalmente.- EDE 9 (DNSKEY Missing) — a cadeia DNSSEC subjacente estava quebrada; a validação falhou.
- EDE 33 (Negative Trust Anchor) — o 1.1.1.1 aplicou um NTA e serviu a resposta mesmo assim.
Juntos, esses dois códigos dão visibilidade total: a resposta é real, mas não foi validada por DNSSEC.
Detalhe de comportamento que vale a pena notar
O 1.1.1.1 retorna EDE 33 em qualquer resposta gerada enquanto um NTA está ativo — mesmo pra domínios que não usam DNSSEC. Isso é intencional: o NTA cobre a zona inteira, e a transparência se aplica uniformemente. Também corrige um bug do incidente do .de (Alemanha), onde o 1.1.1.1 retornava EDE 22 (No Reachable Authority) em vez de expor o erro DNSSEC real.
Trade-offs e limitações que você precisa saber
O EDE 33 é um mecanismo de sinalização, não uma correção. Entender seus limites é essencial antes de construir monitoramento em cima dele.
| Aspecto | O que o EDE 33 faz | O que ele NÃO faz |
|---|---|---|
| Visibilidade | Informa que a validação foi ignorada | Não restaura a proteção DNSSEC |
| Escopo | Cobre a zona inteira sob NTA | Não aponta quais registros são afetados |
| Compatibilidade | Código atribuído pela IANA, reconhecido pelo kdig | PR do Unbound ainda em revisão |
| Adoção | Cloudflare 1.1.1.1 saiu na frente | Outros resolvedores precisam implementar |
| Fallback | EDE é opcional; precisa ser solicitado via EDNS | Clientes que ignoram EDNS não veem nada |
Avisos críticos
- A zona fica sem assinatura durante o NTA. Todo domínio
.alperdeu proteção DNSSEC durante o incidente — o EDE 33 torna isso visível, não seguro. - Suporte no cliente é obrigatório. Se sua lib DNS ou stub resolver não parseia EDE, você recebe a resposta sem o aviso. Audite sua stack:
dig,kdigegetdnsmoderno suportam EDE; muitos resolvedores minimalistas não. - Até a publicação, o
.alcontinua sem assinatura. O registro DS não foi restaurado na zona raiz pelo operador do.al. Todo domínio.alsegue sem proteção DNSSEC. - NTA é uma resposta operacional agressiva. A Cloudflare só aplica quando a falha é pública, confirmada e afeta todos os resolvedores validantes igualmente.
A lição mais profunda
Falhas DNSSEC em nível de TLD são raras, mas quando acontecem afetam todos os domínios abaixo simultaneamente. Os incidentes .de e .al, em sequência num intervalo de dois meses, mostram que o ferramental operacional pra esses eventos ainda está amadurecendo. O EDE 33 é um passo pra tornar o comportamento do resolvedor auditável, não só documentado.
Próximos passos
Se você opera infraestrutura DNS ou constrói ferramentas de monitoramento, aqui está sua lista de ações:
- Audite sua stack de resolvedor pra suporte a EDE. Rode
kdig @1.1.1.1 <domínio> +ednsopt=15contra uma zona sob NTA conhecida e inspecione a saída. - Adicione parsing de EDE no seu monitoramento. Trate EDE 33 como sinal de alerta distinto — significa "resolvendo, mas não verificado".
- Acompanhe o Internet-Draft. A proposta foi submetida ao IETF DNSOP Working Group e será discutida na reunião de Viena (18–24 de julho). Feedback vai pra lista DNSOP.
- Entenda o trade-off do NTA antes de pedir pro seu resolvedor aplicar um. Suspender validação DNSSEC é uma decisão real de segurança, não um toggle de conveniência.
Leitura relacionada
- How Blockchain is Revolutionizing Agricultural Traceability: A Deep Dive into Tokenized Cotton — uma olhada em como modelos de confiança distribuída são aplicados fora do DNS.
- Dynamic Path MTU Discovery: How Cloudflare Eliminates Network Black Holes for Good — outro mergulho da Cloudflare em modos silenciosos de falha de rede e como expô-los.
A transparência no DNS está evoluindo rápido. O EDE 33 é um código pequeno com uma implicação enorme: resolvedores não podem mais tomar decisões silenciosas sobre o seu tráfego.