Resumo

  • Em um teste com consultas reais ao .nl, pesquisadores da University of Twente e do SIDN Labs mediram 655 bytes na assinatura Falcon-512 comprimida mediana, diante de 666 bytes fixos no formato preenchido. A economia de onze bytes quase não mudou quantas respostas DNSSEC ficaram abaixo dos limites de tamanho estudados.
  • As respostas para nomes inexistentes carregavam várias provas assinadas e ultrapassaram, sem exceção no conjunto analisado, os limites de 1.232 e 1.500 bytes. O formato vencedor no folheto da assinatura isolada pode perder na entrega do pacote inteiro.

O desconto que não pagou o frete

A loja oferece onze gramas de desconto na embalagem de um armário. O caminhão continua tendo de levar o armário. Essa é a diferença entre medir uma assinatura criptográfica e medir uma resposta DNSSEC completa. A assinatura ocupa espaço; a resposta também leva nomes, registros e, às vezes, várias provas assinadas de que algo não existe.

Um artigo científico de 2025 da University of Twente e do SIDN Labs levou essa diferença para uma simulação com o domínio .nl. Os autores compararam duas formas de assinatura Falcon-512. A comprimida varia de tamanho e marcou 655 bytes na mediana; a preenchida ocupa sempre 666 bytes. A economia é verdadeira. A pergunta decisiva é quanto dela chega ao transporte, onde respostas acima de 1.232 ou 1.500 bytes criam outro problema.

O estudo aproveitou a zona .nl de 3 de abril de 2025 e um dia de consultas observadas nos servidores autoritativos. Os pesquisadores retiraram os dados DNSSEC existentes, assinaram duas versões da zona com Falcon-512 e repetiram as consultas em duas instâncias de teste do NSD. A análise comparou 59.312.128 respostas que continuaram NOERROR e 113.348.878 que continuaram NXDOMAIN. O padrão de consultas vinha da operação; as respostas Falcon foram produzidas no laboratório. Medir a experiência dessa maneira é útil. Chamar o procedimento de implantação real seria trocar o método pela manchete.

Entre as respostas NOERROR, a maior parte cabia nos dois limites com qualquer um dos formatos. Uma parcela menor, porém relevante, ultrapassava o tamanho. Em certos casos, era preciso carregar mais um registro NSEC3 assinado para demonstrar a falta de um registro DS de um domínio filho sem assinatura. Encurtar uma assinatura não remove essa prova. As curvas de tamanho das duas versões ficaram próximas, e a compressão não levou um número significativo de respostas para o lado desejado do limite.

As respostas NXDOMAIN, usadas quando o nome pedido não existe, foram uma derrota ainda mais seca para a propaganda dos onze bytes. Todas as respostas consideradas passaram dos dois limites. Com duas provas NSEC3 assinadas, mediam de 2.269 a 2.420 bytes. Com três, de 3.075 a 3.767. Quanto mais assinaturas, maior a economia total obtida pela compressão; ainda assim, nenhuma dessas respostas caiu para 1.500 bytes, muito menos para 1.232. O frete continua sendo calculado pelo móvel completo.

Até a palavra “comprimida” pede cuidado. Entre 9.912.711 assinaturas na zona experimental, houve uma assinatura sem preenchimento de 667 bytes, um byte acima do tamanho fixo preenchido. A implementação preenchida gera outra assinatura quando o resultado ultrapassa 666. A ocorrência foi excepcional. Ela mostra o trabalho que acompanha um tamanho variável: a distribuição inteira precisa caber nas regras do software, não apenas o número mediano que fica bonito no resumo executivo.

Os autores consideram que um formato fixo pode ser preferível no DNSSEC pela previsibilidade e pelo menor espaço para erros de implementação, já que a vantagem de tamanho não alterou materialmente os limites de transporte nesse teste. Eles avaliaram dimensões de mensagens, não a conta integral de CPU, memória, hardware, assinatura e validação. O estudo também não decretou um padrão. Ele fez algo mais valioso para a discussão: obrigou a economia de um componente a aparecer na fatura da resposta inteira.

A situação institucional segue aberta. A página do NIST sobre padronização pós-quântica, atualizada em 27 de outubro de 2026, diz que Falcon foi selecionado e que o FIPS 206 continua em desenvolvimento. Um Internet-Draft individual de Paul Hoffman, da ICANN, enumera o que a escolha para DNSSEC ainda deve pesar: tamanho dos registros, rapidez de adoção, CPU, mudanças no protocolo, módulos de segurança de hardware, criptoanálise e licenças de patente. O documento não tem posição formal no processo de padrões do IETF. A lista, porém, impede que a discussão seja sequestrada por uma única coluna da planilha.

O programa da RIPE 93 prevê que Ginevra Fabrizio apresente esse trabalho em 29 de outubro. No dia 28, a apresentação ainda não ocorreu. O artigo publicado já permite chegar à sala com perguntas concretas: quantas provas cabem em cada resposta, quantas respostas cruzam o limite, quantas precisam de TCP e qual o custo de implementar a escolha. Uma reunião de padrões pode gostar do desconto; quem opera a rede recebe a nota do frete.

Uma média não responde pelo pacote

Formatos ficam arrumados em tabelas quando se mede uma assinatura por vez. O DNS real acrescenta o comprimento do nome consultado, o estado da delegação e provas de inexistência. O próprio artigo mostra que a variação no comprimento dos nomes tem ordem parecida com a variação do tamanho das assinaturas comprimidas. O mundo operacional altera a conta antes mesmo que a discussão chegue ao limite de transmissão.

Dar primazia ao código que funciona exige testes com padrões de consulta observados e distribuições de respostas completas. A promessa de um padrão deve ter uma medida de serviço entregue. Se o pacote continua grande demais, uma vitória elegante em bytes por assinatura permanece uma vitória pequena. O armário não entrou no caminhão porque a etiqueta emagreceu.