Resumo

  • A opção 12 do EDNS(0) permite acrescentar padding de comprimento variável a uma mensagem DNS cifrada. Ela padroniza o recipiente, não o efeito de privacidade; os blocos de 128 octetos para consultas e 468 para respostas são uma política experimental do RFC 8467.
  • A proteção é compartilhada. O cliente define a consulta, o servidor escolhe a resposta, o transporte cria outra moldura e o caminho limita custo e fragmentação. Tempo, endereços e quantidade de trocas continuam observáveis.

Dois resolvedores DoT podem anunciar “padding ativo” e entregar efeitos opostos. Um arredonda consultas para múltiplos de 128 e respostas para 468. O outro sempre soma 16 bytes. Ambos usam corretamente a opção 12, mas o segundo conserva todas as diferenças originais; um observador apenas desconta a constante.

A criptografia protege o conteúdo entre cliente e servidor. Ela não elimina o comprimento do texto cifrado. Certos nomes, tipos de registro e conjuntos de resposta produzem pares de tamanhos característicos. Com amostras conhecidas, um observador pode tentar correlacionar o fluxo sem ler o nome.

O RFC 7830 oferece uma peça propositalmente estreita. No pseudorregistro OPT do EDNS, o código 12 identifica Padding. A opção aparece no máximo uma vez por mensagem. O campo de comprimento conta os octetos extras; zero é válido, embora o cabeçalho ocupe quatro octetos. O emissor normalmente usa zeros, mas o receptor deve aceitar outros valores. Esses bytes não carregam semântica DNS.

O padrão não escolhe a quantidade. Assim, sintaxe comum não vira política mundial. O RFC 8467 compara estratégias e recomenda, de modo experimental, blocos de 128 octetos na consulta e 468 na resposta. Vários tamanhos originais caem na mesma classe visível.

Uma classe ainda informa. Se o bloco é conhecido, uma consulta de 256 octetos revela um intervalo para o tamanho anterior. Momento, intervalo, direção e número de mensagens permanecem. Mesmo cifrado e preenchido, o tráfego pode parecer DNS. Tráfego de cobertura ou jitter atacaria outros canais com outros custos.

A solicitação não é uma ordem ilimitada. Ao receber Padding, o servidor deve preencher a resposta, salvo se ultrapassar o tamanho UDP permitido. Pode adicionar Padding a uma consulta EDNS sem a opção, mas não a quem não anunciou EDNS. A consulta concede permissão limitada pela capacidade; não escolhe uma resposta eficaz.

O caminho transforma privacidade em entrega. Padding deve ser aplicado depois das demais opções EDNS, pois ocupa o espaço restante. O cálculo exclui os dois octetos de comprimento do DNS sobre TCP, evitando que a troca de transporte produza outra classe por mero enquadramento. Perto do MTU, blocos grandes fragmentam; acima dele, a fragmentação UDP é certa. O RFC 7830 proíbe padding em DNS aberto e alerta para maior amplificação.

DoH e DoQ redistribuem o controle. DoH leva Padding dentro de HTTPS autenticado, mas cabeçalhos, cookies, conexões e tempo oferecem outras correlações. DoQ pode preencher a mensagem DNS ou, se a API QUIC permitir, alinhar o pacote inteiro e considerar confirmações e controle de fluxo.

Nenhum ator possui o resultado completo. O cliente escolhe consulta e resolvedor. O servidor escolhe resposta. A biblioteca TLS, HTTP ou QUIC pode controlar a moldura final. A rede decide o tamanho que chega com confiabilidade. O registro da IANA comprova um vocabulário comum, não implementação, ativação ou efeito.

O teste do código em execução é uma distribuição. Compare tamanhos antes e depois, ocupação dos blocos, respostas sem padding, bytes adicionais, truncamento, fragmentação, perda, repetição e fallback. Só esses dados mostram se o conjunto de anonimato cresceu.