Resumo

  • Na reprodução de um dia de consultas .nl, assinaturas Falcon-512 sem preenchimento tiveram mediana de 655 bytes, 11 a menos que o tamanho fixo de 666. A diferença não aumentou de forma relevante as respostas NOERROR abaixo dos limites de 1.232 e 1.500 bytes.
  • Todas as respostas NXDOMAIN testadas passaram dos dois limites. Várias provas NSEC3 assinadas, e não o preenchimento de uma assinatura isolada, fizeram essas respostas negativas crescerem.

Onze bytes parecem um desconto. No NXDOMAIN, o pacote continuou caro. Esse é o atrito que Ginevra Fabrizio levou à RIPE 93: a assinatura ficou menor na tabela, enquanto a resposta DNS completa quase não perdeu tamanho.

Fabrizio, pesquisadora da Universidade de Twente, apresentou um estudo feito com colegas da SIDN. O artigo saiu no Applied Networking Research Workshop em 2025; em 29 de outubro de 2026, ela retomou a comparação dos formatos na sessão de DNS da RIPE 93. A pergunta era operacional: encurtar um pouco a assinatura DNSSEC permite que mais respostas reais caibam em um único pacote?

O DNSSEC acrescenta assinaturas aos registros para que os resolvedores verifiquem a origem e a integridade das respostas. Essas assinaturas ocupam espaço justamente onde uma prova de não existência pode precisar de várias delas.

A equipe partiu de consultas recebidas pelos servidores autoritativos de .nl durante 24 horas, em 3 de abril de 2025. Removeu os dados DNSSEC já existentes na zona, assinou duas cópias de teste com Falcon-512 e reproduziu as consultas em servidores NSD: uma cópia usava assinaturas preenchidas; a outra, sem preenchimento. O estudo mediu o tamanho das duas respostas mais comuns, NOERROR e NXDOMAIN. Falcon não foi executado na zona .nl de produção.

No gráfico de assinaturas, a compressão vence. Falcon-512 preenchido tem tamanho fixo de 666 bytes. Na zona testada, a mediana sem preenchimento foi de 655. Onze bytes fazem diferença, mas são uma parte do pacote, que também carrega o nome consultado, registros DNS, provas DNSSEC e assinaturas.

A maioria das respostas NOERROR ficou abaixo do orçamento de 1.232 bytes para a mensagem DNS e do MTU Ethernet de 1.500 bytes usado na comparação. Uma parcela menor, mas relevante, passou desses valores. As curvas de preenchido e sem preenchimento quase se sobrepuseram; trocar o formato não levou um número expressivo de respostas para dentro do limite. A maioria já cabia, e onze bytes raramente mudavam o resultado.

NXDOMAIN mostrou o caso difícil. Uma resposta negativa assinada precisa provar que o nome não existe. Nessa zona, a prova podia incluir dois ou três registros NSEC3, cada um com a própria assinatura. A reprodução gerou 113.348.878 respostas NXDOMAIN, todas acima dos dois limites. Com duas provas NSEC3 assinadas, as respostas mediram de 2.269 a 2.420 bytes; com três, de 3.075 a 3.767. A assinatura entrava em uma resposta que já vinha carregada de provas.

O conjunto NOERROR teve 59.312.128 respostas NOERROR depois da reprodução. A parcela acima dos limites importa, mas não deve ser confundida com o resultado de NXDOMAIN: no primeiro grupo, houve respostas dos dois lados da linha; no segundo, todas passaram dos dois limites neste teste. A tabela do artigo mostra o mecanismo. Acrescentar uma prova assinada soma centenas de bytes; mudar o formato de uma assinatura altera bem menos.

O trabalho de Fabrizio também comparou a variação no comprimento dos nomes consultados com a variação no tamanho de uma assinatura Falcon-512 sem preenchimento. As duas ficaram na mesma ordem de grandeza. Essa comparação recoloca a economia da compressão na aritmética real do DNS: nomes variam, o número de provas varia e o formato de uma assinatura não define o tamanho da resposta inteira.

Os autores concluíram que o formato preenchido de tamanho fixo pode ser preferível por sua previsibilidade e por reduzir erros de implementação. Na sessão de perguntas da RIPE 93, Fabrizio descreveu a aritmética de ponto flutuante como um desafio de implementação e a colocou ao lado do volume de fallback para TCP. O preenchimento não encolhe uma resposta grande demais; mantém previsível o tamanho da assinatura enquanto o ecossistema avalia se vale carregar mais complexidade por uma pequena economia média.

Ela contou ainda que começava, com a SIDN, um ambiente de testes para cargas de resolvedores e servidores autoritativos com Falcon e ML-DSA. Os resultados estavam novos demais para aparecer em gráficos na palestra. A próxima medida útil ligaria as distribuições de tamanho a novas tentativas TCP e à latência observada nos resolvedores. O estudo não mediu essas tentativas recursivas em produção nem o atraso de ponta a ponta; esses dados poderiam mudar o custo operacional atribuído aos 11 bytes.

A divisão observada já é clara: a maioria das respostas NOERROR testadas ficou abaixo dos limites; todas as NXDOMAIN passaram deles. Uma futura escolha de formato Falcon para DNSSEC precisa avaliar o tipo de resposta e a quantidade de provas, não apenas a mediana de uma assinatura.

Fontes

Página e resumo da palestra na RIPE 93 · transcrição oficial da sessão · registro do artigo na University of Twente · PDF completo no repositório da University of Twente