Resumo

  • DNS Cookies transforma uma primeira ida e volta em evidência limitada de alcançabilidade: um pedido posterior com os dois tokens corretos é mais difícil de forjar fora do caminho.
  • A RFC 7873 definiu a troca; a RFC 9018 fixou um Server Cookie versão 1 interoperável para que nós anycast com implementações diferentes validassem o mesmo estado.
  • O mecanismo não comprova identidade nem cria sigilo. Um observador no caminho vê os tokens, o NAT reúne vários clientes em um endereço e os demais controles de abuso continuam necessários.

A primeira consulta não apresenta conta, certificado ou chave negociada. Chega como datagrama UDP, com uma origem que pode ser verdadeira ou falsificada. O cliente inclui um Client Cookie de oito bytes na opção COOKIE do EDNS. Se o servidor oferece suporte, devolve esse valor acompanhado de um Server Cookie. Na consulta seguinte, o cliente leva os dois.

O segundo pacote carrega uma história curta. O Server Cookie depende do Client Cookie, do endereço aparente e de um segredo guardado pelo servidor. Um atacante fora do caminho pode escrever o endereço de uma vítima no cabeçalho IP, mas não deveria ter visto a resposta enviada para lá. Portanto, não possui o token esperado. O servidor ganha um indício de que já falou com aquela combinação de endereço e cookie. O cliente, por sua vez, pode descartar uma resposta que não devolva o Client Cookie previsto.

Não se trata de identidade. Um roteador doméstico, um NAT de operadora ou a borda de uma empresa pode representar muitos dispositivos sob um único endereço público. Uma máquina comprometida no endereço correto continua capaz de atacar. Quem observa o DNS em trânsito pode copiar o cookie em texto claro e reutilizá-lo dentro do prazo. DNS Cookies não cifra a pergunta, não autentica a organização e não substitui o DNSSEC. Demonstra apenas que um caminho de retorno funcionou antes.

Essa conclusão era útil porque o DNS sobre UDP transformava falsificação de origem em amplificação. Uma pergunta curta podia provocar uma resposta maior para a vítima. Um pedido forjado também podia impor recursão e validação DNSSEC. No sentido inverso, respostas inventadas tentavam vencer a resposta legítima e contaminar o cache. DNSSEC autentica dados; TSIG oferece autenticação transacional mais forte com gestão prévia de chaves; aleatoriedade de portas e identificadores dificulta a adivinhação; limitação de taxa reduz a saída. Os cookies acrescentaram evidência leve do retorno sem manter uma sessão por cliente no servidor.

Publicada em maio de 2016, a RFC 7873 reservou o código 10 para a opção COOKIE. Sem conhecer o Server Cookie, o cliente envia somente os oito bytes do Client Cookie. Depois, inclui também um valor do servidor de oito a trinta e dois bytes. A especificação original deixava a construção exata para cada implementação. O servidor podia recalcular o valor usando origem, Client Cookie e segredo, sem uma tabela de clientes.

A máquina de estados permite adoção gradual. Um servidor sem suporte ignora a opção. Um servidor compatível que recebe apenas Client Cookie pode descartar, devolver BADCOOKIE ou responder normalmente, conforme a política; quando responde, fornece o Server Cookie para o próximo estado. Comprimento inválido gera FORMERR. Um cookie vencido ou incorreto é tratado como ausente. Um valor válido permite relaxar defesas dirigidas especificamente à origem UDP falsificada, não conceder confiança geral.

BADCOOKIE também é um mecanismo de sincronização. Se a resposta traz o Client Cookie esperado, o cliente aceita o novo Server Cookie e tenta de novo. Se o valor recém-entregue falha imediatamente, pode recorrer ao TCP. Falhas repetidas podem revelar um defeito interno: membros do mesmo anycast não compartilham o segredo, o algoritmo ou a fase de rotação.

O NAT explica a presença das duas partes. Se o Server Cookie dependesse só do endereço público, um dispositivo poderia obter um token utilizável por todos atrás do mesmo gateway. Incluir o Client Cookie separa os fluxos sem criar estado individual no servidor. A distinção permanece no nível da rede; não identifica a pessoa.

O anycast revelou a lacuna histórica mais difícil. Consultas seguidas ao mesmo endereço podem chegar a máquinas e produtos distintos. A RFC 7873 recomendava compartilhar o Server Secret, mas não padronizava a transformação. Duas implementações com o mesmo segredo podiam gerar valores incompatíveis. Uma mudança normal de rota fazia o cliente parecer suspeito.

A RFC 9018, publicada em abril de 2021, definiu o Server Cookie versão 1 com dezesseis bytes: um de versão, três reservados, quatro de timestamp e oito de resultado SipHash-2-4. Com o Client Cookie, a opção completa tem exatamente vinte e quatro bytes. O cálculo cobre Client Cookie, campos estruturais, IP do cliente e Server Secret. O endereço participa da validação sem ser gravado dentro do token.

O timestamp limita a repetição. A RFC recomenda aceitar valores de até uma hora no passado, tolerar cinco minutos no futuro por diferença de relógio e renovar um cookie com mais de meia hora. São recomendações, não uma medição universal de configurações. Mostram que o token deve expirar e que um observador no caminho também conhece sua janela de uso.

A rotação do segredo virou uma operação coletiva. Primeiro, o novo segredo chega a todos os nós, que continuam emitindo com o antigo e validam ambos. Em seguida, passam a emitir com o novo sem abandonar a validação anterior. Só depois do período de sobreposição o segredo antigo é removido. Relógios, distribuição e fase de implantação são tão importantes quanto a função criptográfica.

A RFC 9018 também mudou a orientação do Client Cookie: sessenta e quatro bits de entropia distintos para cada IP de servidor, sem reutilização depois que o IP do cliente muda. A regra evita que um identificador estável acompanhe o dispositivo entre redes. Um host atrás de NAT pode não perceber a mudança do endereço público; esse rastreamento residual fica fora do alcance.

A história de DNS Cookies não é a chegada de identidade ao DNS. É o alinhamento da evidência com a afirmação que ela consegue sustentar. A primeira ida e volta cria um token que torna mais cara a mentira de estar em um endereço que não recebeu a resposta. A RFC 7873 desenhou a troca; a RFC 9018 a tornou viável em um serviço anycast heterogêneo. O controle real continua nas políticas do cliente e do servidor, nos relógios e na custódia coordenada dos segredos.

Fontes