Resumo

  • O DNS compara letras ASCII sem considerar maiúsculas e minúsculas, mas muitos servidores devolvem a pergunta com a forma recebida. O DNS-0x20 propôs usar esse eco exato como identidade temporária da transação.
  • Cada letra elegível acrescentaria no máximo um bit, sujeito à preservação ao longo do caminho, à restauração antes da descompressão e a um recuo que não pudesse ser forçado. O mecanismo não autenticava a resposta e o documento expirou sem se tornar RFC.

A autoridade ignorava o desenho que o resolvedor guardava

Ao montar uma consulta, o resolvedor pode alternar aleatoriamente as letras do nome entre maiúsculas e minúsculas. A autoridade deve localizar o mesmo conjunto de registros qualquer que seja a combinação. Quando a resposta volta, porém, o resolvedor confronta a seção de pergunta com a cópia que manteve em memória.

A primeira regra determina a identidade do nome. A segunda relaciona um pacote a uma consulta ainda pendente. Um falsificador fora do caminho talvez saiba qual nome está sendo pesquisado, mas precisa adivinhar também uma forma que só existiu depois que aquela pergunta foi criada.

Esse era o alcance do DNS-0x20. Ele não transformava capitalização em parte do namespace. Usava uma representação semanticamente neutra como estado descartável de uma única troca.

O DNS separou identidade de apresentação

A RFC 1035, de 1987, manda fazer as comparações oficiais do protocolo sem distinção de caixa. Nomes cuja única diferença esteja entre A-Z e a-z são idênticos. Ao mesmo tempo, o texto recomenda preservar a caixa original quando possível e minimizar sua perda.

Essa divisão favorecia a interoperabilidade. O usuário não deveria precisar decorar uma capitalização para chegar ao mesmo objeto, mas sistemas capazes de conservar a grafia não tinham motivo para apagá-la. A equivalência era obrigatória; a apresentação podia sobreviver.

A RFC 4343 esclareceu que a regra diz respeito ao ASCII, não a transformações linguísticas gerais nem ao processamento IDNA. Também explicou por que a preservação não é promessa. Formas diferentes podem ocupar o mesmo ponto de armazenamento, e a compressão pode fazer uma etiqueta reutilizar bytes de outro local da mensagem.

Foi nesse espaço entre equivalência garantida e reprodução frequente que a proposta encontrou seus bits.

O 0x20 acrescentava escolhas à consulta pendente

O Internet-Draft Use of Bit 0x20 in DNS Labels, de março de 2008, sugeriu sortear o bit 0x20 de cada letra ASCII do QNAME. Esse é o bit que separa as duas caixas. Todas as versões continuariam iguais para a autoridade; o solicitante as trataria como desafios diferentes enquanto esperava a resposta.

O método dependia de a seção Question ser copiada exatamente. Os autores relataram que as principais implementações autoritativas testadas naquela época faziam isso, embora a especificação não exigisse a cópia da caixa bit a bit. Havia exceções que uniformizavam o nome em minúsculas.

A RFC 5452 mostra o contexto da defesa contra respostas forjadas. Não basta o ID de transação: pergunta, endereços, portas, classe e tipo também integram a correspondência. Um ID aleatório de 16 bits ainda oferece um alvo finito, e portas de origem imprevisíveis aumentam o espaço. A caixa aleatória pretendia adicionar escolhas já transportadas dentro do QNAME.

O acréscimo era probabilístico. Não havia assinatura, segredo compartilhado ou prova de autoridade. O pacote que acertasse todos os elementos ainda poderia vencer a resposta legítima.

Cada nome trazia um orçamento diferente

Somente letras ASCII elegíveis oferecem duas formas. Dígitos e hífens não contribuem. Nomes longos e cheios de letras podem carregar mais bits; nomes curtos ou numéricos, menos. O rascunho apresentava essa desigualdade abertamente.

Por isso, “DNS-0x20 ativado” não é medida suficiente. É preciso contar as letras da pergunta específica, avaliar se o sorteio é imprevisível e verificar quantas escolhas atravessaram autoridade, encaminhadores e dispositivos intermediários.

Rótulos internacionalizados não autorizam uma soma por analogia. A RFC 4343 separa a equivalência ASCII das transformações IDNA. Aplicar regras de caixa próprias de um idioma ao valor na rede pode mudar o nome processado, e não ampliar com segurança o desafio.

Um intermediário correto podia apagar a proteção

Um encaminhador que converte perguntas para minúsculas pode entregar o RRset correto. Para a semântica básica do DNS, o nome não mudou. Para o resolvedor que guardou o padrão, a informação de transação desapareceu.

Essa diferença expõe a dependência distribuída. O resolvedor escolhe os bits, mas autoridades, encaminhadores e caixas de inspeção determinam se eles voltam. Os testes relatados em 2008 descreviam uma amostra histórica, não uma obrigação eterna de todo caminho.

Uma divergência de caixa também é ambígua. Pode vir de falsificação, normalização estável, peculiaridade de rota ou defeito. O rascunho recomendava registrar, descartar a resposta e tentar outros endereços autoritativos. Não elevava a divergência isolada à condição de prova de ataque.

O estado temporário precisava morrer antes do cache

Nomes em uma mensagem DNS podem ser comprimidos com ponteiros. Um nome nas seções Answer, Authority ou Additional pode apontar de volta para a pergunta. Se o resolvedor descomprimir tudo com a combinação aleatória ainda presente, essa forma pode infiltrar-se no cache e aparecer em respostas futuras.

A proposta exigia guardar a pergunta original, conferir o eco e então restaurar a pergunta antes de descomprimir as demais seções. O padrão pertencia à tabela de transações pendentes, não ao RRset durável.

Essa ordem oferece uma lição mais ampla do que a aleatoriedade. Quando uma tolerância de representação vira nonce, o sistema precisa definir sua retirada. Sem limpeza, a proteção de uma troca altera o estado compartilhado de outras.

O recuo podia ser induzido

Rejeitar rigorosamente toda mudança de caixa preserva o desafio, mas pode tornar uma autoridade normalizadora inacessível. Desligar a verificação depois da primeira falha preserva disponibilidade, porém oferece ao atacante a chance de provocar um modo mais fraco.

O documento propôs tentar outras autoridades e repetir a sequência inteira com novos IDs, novos elementos aleatórios e, se possível, outra ordem de servidores. Se os demais campos retornassem corretamente em várias rodadas e só a caixa fosse modificada de maneira constante, haveria melhor fundamento para declarar incompatibilidade.

O custo aparecia em latência e tráfego. Autoridades que uniformizassem a caixa poderiam receber várias vezes mais consultas, e o gerador aleatório exporia mais saídas. A eficácia dependia da política de tentativas e da memória de exceções, não apenas da geração dos bits.

O DNSSEC elimina a mesma diferença por outra razão

A RFC 4034 define a forma canônica usada no DNSSEC: expande nomes comprimidos e converte para minúsculas as letras ASCII relevantes. Assinante e validador precisam construir exatamente os mesmos octetos.

O 0x20 queria conservar uma variação aleatória durante uma ida e volta. O DNSSEC remove variações para autenticar dados canônicos. Um eco correto apenas torna a adivinhação menos provável; uma assinatura válida pode ligar o RRset à cadeia de autoridade. São controles de categorias diferentes.

Uma proposta expirada, não uma norma escondida

O Internet-Draft expirou em setembro de 2008. Não virou RFC e não comprova a participação atual de produtos ou caminhos. As observações de implementação devem permanecer datadas.

Seu valor histórico é mostrar que uma distinção abandonada para identificar objetos pode continuar disponível como estado transitório. Para extraí-la, o sistema precisa medir a capacidade real, mapear as dependências, evitar que o recuo vire degradação e apagar o estado antes da persistência.

As maiúsculas nunca receberam autoridade sobre o nome. Por uma consulta, elas só fizeram a resposta demonstrar que trazia de volta uma escolha recém-criada.

Fontes e limites

Esta análise usa a RFC 1035, a RFC 4343, a RFC 5452, a RFC 4034 e o Internet-Draft DNS-0x20 de março de 2008. As fontes não estabelecem configurações atuais, participação de mercado nem compatibilidade universal.