Resumo

  • DNS Cookies oferecem proteção deliberadamente limitada contra amplificação, falsificação e envenenamento de cache por atacantes fora do caminho, ligando a requisição ao endereço de origem, ao Client Cookie e a uma resposta anterior.
  • Um Server Cookie válido não identifica uma pessoa nem um dispositivo duradouro: muitos clientes podem compartilhar um endereço NAT, mudanças de endereço exigem renovação e um observador no caminho pode reutilizar o valor durante sua validade.
  • A operação precisa guardar método, idade, contexto de endereço, domínio de validação anycast e resultado das tentativas; acesso, cobrança e limites por pessoa dependem de um principal autenticado separado.

O painel chama a consulta de “cliente autenticado” porque o Server Cookie passou na validação. Uma regra posterior usa esse rótulo para relaxar o limite de tráfego ou atribuir consumo a um assinante. A conclusão parece razoável: o servidor gerou um valor difícil de adivinhar e a requisição o devolveu a partir do endereço esperado. Só que esse endereço pode ser a saída de um NAT de operadora compartilhado por milhares de pessoas ou o endereço de um resolvedor recursivo que consulta por uma organização inteira.

O Cookie não falhou. Foi a interpretação que excedeu o contrato. A pergunta correta é mais estreita: a requisição demonstra que um cliente usando este Client Cookie, neste contexto de endereço de origem, recebeu antes uma resposta deste servidor ou do seu conjunto anycast interoperável? Essa é uma afirmação sobre caminho de volta e transação DNS. Não informa o nome da pessoa, sua conta ou seus direitos.

Um Server Cookie válido sustenta evidência de uma troca anterior

A RFC 9018 define DNS Cookies como um mecanismo leve de segurança de transação que oferece proteção limitada contra amplificação de negação de serviço, falsificação e envenenamento de cache por atacantes fora do caminho. “Limitada” descreve a arquitetura: o adversário considerado não observa o tráfego entre a suposta vítima e o serviço DNS e precisa adivinhar um valor que nunca recebeu.

Os dois campos da opção COOKIE têm papéis diferentes. O cliente cria um Client Cookie imprevisível e deve usar valores distintos para cada endereço IP de servidor. A RFC 9018 recomenda 64 bits de entropia. Ele não é uma credencial de conta emitida pelo servidor; é um valor escolhido pelo cliente e devolvido na resposta. A separação por endereço torna mais difícil que um servidor DNS falsifique respostas pertencentes a outro.

O Server Cookie é o token de retorno construído pelo serviço. A RFC 9018 o descreve, na prática, como um código de autenticação de mensagem calculado com Client Cookie, endereço IP do cliente, campos definidos de versão e tempo, e um segredo conhecido apenas pelo servidor ou pelo conjunto que atende no mesmo endereço anycast. Quando a requisição traz um valor válido, o servidor recebe uma garantia fraca de que um cliente naquele endereço, usando aquele Client Cookie, recebeu uma resposta anterior com o valor.

A RFC 7873 permite que o servidor considere que já conversou com esse contexto de cliente e deixe de aplicar algumas defesas voltadas a requisições UDP com origem forjada. Ela não transforma a opção DNS em autenticação geral. O Cookie não comprova uma conta, um equipamento gerenciado, o direito a uma visão protegida da zona nem a responsabilidade pela cobrança.

O texto operacional precisa manter o mesmo limite. “Server Cookie válido para este endereço, Client Cookie, conjunto de validação e horário” é uma descrição verificável. “Usuário autenticado” acrescenta um fato que o protocolo não transporta.

Endereço compartilhado não equivale a identidade

NAT mostra o limite mesmo sem atacante. Um gateway doméstico, uma borda empresarial ou um NAT em escala de operadora pode fazer diversos dispositivos e pessoas aparecerem ao servidor DNS sob um único endereço público. O Server Cookie pode incluir corretamente esse endereço no cálculo e continuar incapaz de dizer quem iniciou uma ação atrás dele.

A RFC 9018 reconhece que o cliente atrás de um equipamento NAT talvez não consiga perceber a mudança do próprio endereço público. O servidor, por outro lado, pode acompanhar o endereço público daquele equipamento; impedir esse rastreamento fica fora do escopo do documento. A evidência pode ser correta na fronteira de rede do servidor e ainda ser grosseira demais para atribuir uma consulta a um assinante.

Se um Server Cookie válido vira chave de limite por pessoa, usuários independentes são agregados. Se vira identidade de cobrança, uma propriedade temporária da conexão recebe responsabilidade duradoura. Não houve quebra criptográfica; a política exigiu que o Cookie distinguisse principais que nunca fizeram parte de seu desenho.

Mobilidade cria o erro inverso. Para evitar rastrear um dispositivo entre enlaces e contornar os IPv6 Privacy Extensions, a RFC 9018 proíbe reutilizar Client Cookie ou Server Cookie após a mudança do endereço IP do cliente. Um novo Cookie pode representar a mesma pessoa e o mesmo dispositivo cumprindo a regra de privacidade. Um valor estável só indica estabilidade de processo e endereço, não continuidade humana.

Um endereço pode representar muitos clientes, e um cliente pode usar legitimamente muitos endereços e Cookies. Identidade persistente precisa de uma credencial e um ciclo de vida capazes de expressar essas mudanças de forma deliberada.

BADCOOKIE abre um diagnóstico, não determina culpa

Um Server Cookie inválido tem várias causas previstas pela RFC 7873: pode estar velho demais; o endereço do cliente ou o Client Cookie pode ter mudado; o conjunto anycast pode estar configurado de modo inconsistente; ou pode ter ocorrido uma tentativa de falsificação. O servidor trata a requisição como se o Server Cookie inválido não estivesse presente. O resultado do protocolo não escolhe uma causa pelo operador.

BADCOOKIE organiza a recuperação. O cliente tenta novamente com o novo Server Cookie entregue na resposta. Se até esse valor recém-fornecido produz outro BADCOOKIE, divergência de segredos compartilhados ou métodos no conjunto anycast passa a ser uma hipótese concreta. A norma então orienta uma nova tentativa por TCP, cujas propriedades de transação podem ser aceitas pelo servidor.

A sequência vale mais que o contador: idade e método do Cookie anterior, endereço observado em cada ponta, membro ou domínio de validação anycast, novo valor, próxima resposta e efeito da troca para TCP. Registrar todo BADCOOKIE como “ataque” elimina a distinção entre expiração normal, mobilidade, deriva de implantação e tráfego hostil.

A rotação de segredos exige a mesma cadeia. A RFC 9018 determina uma mudança em etapas: todos os membros aprendem e validam o segredo novo antes de começar a emitir com ele e mantêm o anterior durante a transição. Um membro adiantado ou atrasado pode alternar resultados válidos e inválidos conforme o destino anycast. Culpar o cliente esconde a falha real de coordenação.

As outras defesas DNS continuam necessárias

DNS Cookies complementam, não substituem, o pareamento de respostas. A RFC 5452 exige que o resolvedor compare endereços de origem e destino, porta de destino, Query ID, nome consultado, classe e tipo antes de aplicar as regras de confiança DNS. Também exige portas de origem e IDs imprevisíveis. Cada atributo aumenta o esforço de uma falsificação fora do caminho, mas nenhum se torna identidade de aplicação.

Os controles respondem a perguntas próximas e distintas. O pareamento decide se a resposta corresponde à consulta pendente. A devolução do Client Cookie liga fracamente a resposta ao endereço de servidor escolhido. Um Server Cookie válido dá ao servidor evidência de um retorno anterior ao contexto de origem. Nenhum identifica uma pessoa ou oferece confidencialidade sozinho.

A RFC 6891 define a superfície de transporte. EDNS é uma extensão salto a salto, e o registro OPT carrega informação de controle para uma sequência de pergunta e resposta. Ele não contém dados DNS e não deve ser armazenado em cache, encaminhado ou gravado em arquivos mestres. A opção COOKIE pertence ao processamento da transação, não a um cadastro permanente de usuários.

O limite contra adversários no caminho também é explícito. Quem observa DNS em texto claro pode capturar um Server Cookie e reutilizá-lo contra aquele cliente enquanto for válido. O MAC do servidor dificulta que um atacante fora do caminho, sem o segredo, fabrique livremente valores válidos. Ele não cifra o Cookie durante o transporte nem autentica todos os atores capazes de observar e enviar no caminho.

Criar um recibo que preserve o contexto

Cada decisão sobre Cookie deve guardar o endereço de origem visto pelo servidor, o endereço visto pelo cliente quando disponível, uma referência não reversível ao Client Cookie, método e idade do Server Cookie, resultado de validação, conjunto anycast, sequência de tentativas e resultado da tentativa por TCP. O segredo não entra no registro; a geração do segredo e o estado de implantação de cada membro ficam separados para permitir auditoria da deriva.

Se o serviço também autentica uma conta ou dispositivo, esse principal precisa de método e horário próprios. A ligação com a transação DNS deve ser explícita: qual sessão autenticada produziu qual consulta, em qual intervalo e com qual incerteza quando houve resolvedor compartilhado ou NAT. Se a ligação não existe, o Cookie não pode inventá-la.

A linguagem do painel deve acompanhar a evidência. “Token de retorno válido” é preciso. “O serviço alcançou antes este contexto de origem” pode ser correto com endereço e tempo anexados. “Cliente conhecido”, “dispositivo confiável” e “usuário autorizado” exigem fatos independentes.

Fontes

  1. RFC 9018 — Interoperable Domain Name System (DNS) Server Cookies
  2. RFC 7873 — Domain Name System (DNS) Cookies
  3. RFC 5452 — Measures for Making DNS More Resilient against Forged Answers
  4. RFC 6891 — Extension Mechanisms for DNS (EDNS(0))