Skip to main content
TECH_SCIENCE05 / 05 · história do dia3 min · 873 palavras · 14 fontes

Cloudflare valida assinaturas DNS pós-quânticas

✦
Escrito por IAto brief AI · 11 de setembro de 2026, 02:50
Como foi escrita

A stronger seal arrives before the internet can carry its weight.

Composição da imagem · tobrief
o texto · 3 min de leitura

Quando um navegador procura o endereço de um site, uma cadeia de consultas converte-o num endereço numérico que os computadores conseguem encaminhar. As respostas podem ser assinadas digitalmente, permitindo ao dispositivo confirmar que ninguém as alterou durante o percurso. A 10 de setembro, a Cloudflare passou a permitir que o seu resolvedor público, o 1.1.1.1, verificasse um novo tipo de assinatura concebido para resistir a futuros computadores quânticos. Já existe um domínio de teste que passa essa verificação, mas entre uma consulta validada e uma Internet resistente à computação quântica há um caminho que nenhuma empresa consegue percorrer sozinha.

O selo de autenticidade aumentou

Nos domínios que utilizam DNSSEC, os registos DNS relevantes incluem assinaturas criptográficas. O resolvedor consegue seguir cada assinatura ao longo de uma cadeia de chaves de confiança, confirmando que o registo veio da autoridade DNS esperada e não foi alterado pelo caminho. Funciona como um selo de cera num postal: autentica a origem, embora qualquer pessoa continue a poder ler a mensagem. O DNSSEC não cifra a consulta nem protege a sessão de navegação.

Os sistemas atuais recorrem a criptografia clássica que, em teoria, poderia ser falsificada por um computador quântico suficientemente poderoso. O ML-DSA-44, normalizado pelo NIST em agosto de 2024 como FIPS 204, é um mecanismo de assinatura assente em estruturas matemáticas que, tanto quanto se sabe, as máquinas quânticas não conseguirão quebrar. A IANA atribuiu-lhe o número de algoritmo 18 no registo DNSSEC. A Cloudflare passou agora a conseguir reconhecer e verificar esse algoritmo quando um domínio publica os registos necessários (Cloudflare).

Os utilizadores do 1.1.1.1 não tiveram de alterar qualquer configuração, e os domínios que usam algoritmos convencionais continuam a ser validados como antes. O resolvedor limitou-se a aprender uma nova linguagem criptográfica.

Demasiado grande para um só pacote

O principal desafio de engenharia está no tamanho. Uma assinatura ML-DSA-44 ocupa 2 420 bytes, aos quais se soma uma chave pública de 1 312 bytes (NIST FIPS 204, rascunho do IETF). O DNS clássico foi concebido para respostas pequenas, capazes de caber num único pacote de rede. Uma só assinatura resistente à computação quântica ultrapassa esse limite confortável.

As respostas demasiado grandes obrigam a repetir a consulta através de TCP, o mesmo protocolo que os navegadores utilizam para carregar páginas. O TCP transmite volumes maiores de dados de forma fiável, mas acrescenta uma viagem de ida e volta entre os dois pontos. No teste publicado pela Cloudflare, uma consulta a valid.mldsa44.dnstest.dev concluiu esta sequência em 20,7 milissegundos (Cloudflare). O resultado demonstra que a infraestrutura funciona, embora represente apenas um exemplo, obtido a partir de um único local, e não uma medição do desempenho em toda a rede mundial da empresa. A Cloudflare não divulgou distribuições de latência, taxas de falha ou dados sobre o consumo de largura de banda.

A cadeia clássica que permanece acima

A cadeia de confiança do DNSSEC começa numa chave-raiz, passa pelos domínios de topo, como .com, .de ou .fr, e só depois chega a cada site. Tanto a raiz do DNS como as camadas situadas acima dos domínios individuais continuam, por enquanto, a assinar os registos com algoritmos clássicos. A própria Cloudflare inclui entre os próximos passos, e não entre as capacidades já disponíveis, a assinatura das suas zonas DNS autoritativas e a possibilidade de o seu serviço de registo submeter registos ML-DSA (Cloudflare).

Esta limitação é relevante porque a segurança do DNSSEC depende do elo mais fraco da cadeia. Um atacante quântico capaz de falsificar uma assinatura clássica numa camada superior poderia desviar o tráfego antes de começar qualquer verificação pós-quântica mais abaixo.

Para responder a uma parte do problema, a Cloudflare introduziu uma regra contra a redução silenciosa do nível de segurança. Quando uma zona-mãe declara que o ML-DSA é obrigatório, o 1.1.1.1 rejeita respostas validadas apenas com criptografia mais antiga, impedindo que a nova proteção seja retirada sem aviso abaixo desse ponto (Cloudflare). A salvaguarda aplica-se, naturalmente, apenas a partir do nível da cadeia em que começa efetivamente a assinatura pós-quântica.

A especificação que adapta o ML-DSA aos formatos dos registos DNSSEC continua a ser um rascunho em discussão num grupo de trabalho do IETF, pelo que o formato operacional ainda não está fechado.

Ao contrário do tráfego cifrado, os registos DNS assinados são públicos. Não existe, por isso, a urgência associada à estratégia de «recolher agora para decifrar mais tarde»: ninguém pode armazenar as respostas DNS atuais para vir a falsificá-las com um computador quântico no futuro. O risco surge quando essa capacidade permitir produzir uma falsificação em tempo real. Ainda assim, a migração do DNS exige coordenação entre operadores da raiz, registos, agentes de registo, servidores autoritativos, programas de resolução e equipamentos de rede que poderão não conseguir processar pacotes demasiado grandes ou ligações TCP bloqueadas. Começar cedo permite identificar essas falhas antes de terem consequências práticas.

Esta implementação poderá servir precisamente como plataforma de testes em condições reais, mostrando onde falha o recurso ao TCP ou que equipamentos descartam respostas de grandes dimensões. A Cloudflare demonstrou que um resolvedor público em produção consegue validar uma resposta DNS assinada com ML-DSA depois de recorrer ao TCP. Falta demonstrar com que rapidez e fiabilidade esse percurso funciona sob uma carga representativa.

Details about this article
Model:
claude-opus-4-6
Generated:
9/11/2026, 1:46:37 AM
Pipeline run:
eu_pipeline_20260911_005007
Watermark:
SynthID (Google's invisible watermark)
Human review:
None before publication
Learn more about our methodology →