Resumo

  • Cookies de DNS mantêm um estado transacional mínimo para dificultar ataques fora do caminho por amplificação, falsificação e envenenamento de cache.
  • Um valor Server Cookie válido oferece garantia limitada: a consulta veio do endereço observado e trouxe um valor Client Cookie visto em troca anterior.
  • O mecanismo não resiste a um observador no caminho nem identifica usuário, assinante, dono do dispositivo ou serviço autenticado atrás de resolvedor ou NAT.
  • A operação precisa de um registro de verificação da consulta DNS que separe validação do cookie, observação de rede, identidade do resolvedor e autorização.

Considere um sistema hipotético de controle de abuso. Uma residência, empresa ou rede de acesso envia DNS por um resolvedor recursivo compartilhado. Ele alcança um serviço anycast, recebe um valor Server Cookie e depois apresenta outro valor válido a partir do mesmo endereço público. Um controle posterior registra isso como prova de que o mesmo cliente fez as duas consultas. O protocolo demonstrou algo mais estreito: a segunda consulta carrega estado que o servidor consegue validar com o valor Client Cookie, o endereço observado, seu segredo e uma janela de tempo.

RFC 7873 define cookies de DNS como um mecanismo leve de segurança de transações. Seu objetivo é oferecer proteção limitada contra amplificação, falsificação de respostas e envenenamento de cache por atacantes que não conseguem observar a troca. Essa condição fora do caminho é a fronteira da garantia.

A primeira consulta leva um Client Cookie de oito bytes. Depois da resposta, consultas seguintes podem incluir o Client Cookie e o Server Cookie recebido. O servidor pode rejeitar ou limitar tráfego incapaz de reproduzir o estado emitido. O recurso admite implantação gradual, funciona com NAT e anycast e dispensa uma credencial previamente combinada com todo cliente da Internet.

Essas vantagens explicam por que o RFC fala em autenticação fraca, não em sistema de identidade. Roteador, ponte, participante de enlace compartilhado ou outro observador no caminho pode ler DNS em claro e ver o cookie. Durante sua validade, pode reutilizar o que observou. O cookie aumenta o custo para um falsificador fora do caminho; não transforma um valor portador visível em prova de pessoa ou organização.

RFC 9018 torna interoperável a construção do Server Cookie. A versão 1 combina Client Cookie, campos de versão e reserva, carimbo de tempo e endereço IP do cliente sob um Server Secret. O IP entra no cálculo mesmo sem aparecer no valor do cookie. O servidor verifica o resultado com o mesmo segredo.

A construção responde a uma pergunta precisa: a consulta é compatível com um cookie produzido antes para este Client Cookie e este endereço observado, sob segredo e janela válidos? Não responde quem usa o endereço. Pessoas podem compartilhar um resolvedor. Dispositivos podem sair por um NAT. O processo pode reiniciar, trocar o Client Cookie ou mudar de endereço. Por outro lado, um endereço estável pode representar pessoas e permissões diferentes.

O tempo integra a evidência. RFC 9018 exige verificar o carimbo dentro de período definido e recomenda aceitar aproximadamente uma hora no passado e cinco minutos no futuro. O servidor deve renovar um valor recebido com mais de meia hora. Essa janela limita repetição; não é época de autorização atual da conta.

Anycast cria outra distinção. Os membros precisam de construção compatível e dos segredos necessários para validar a saída dos demais. RFC 9018 descreve três etapas: distribuir o novo segredo ainda gerando com o antigo; passar a gerar com o novo validando ambos; retirar o anterior depois de dar tempo aos clientes. A aceitação por outro membro mostra coerência da frota, não a volta do mesmo servidor físico, processo resolvedor ou usuário.

As regras de privacidade reforçam o limite. O cliente deve criar novo Client Cookie quando seu endereço muda, e um cliente atrás de NAT talvez não perceba que seu IP público mudou. A continuidade fica deliberadamente ligada ao contexto de rede e ao estado da implementação. Usá-la como identidade durável contraria as premissas de privacidade e mobilidade.

O contraste mais útil é o TSIG, definido no RFC 8945. Ele autentica uma transação DNS por código de autenticação entre entidades que já compartilham um segredo configurado. Pode mostrar que uma atualização dinâmica ou resposta veio de uma parte aprovada que possui a chave. Isso exige distribuição, proteção da chave e uma relação de confiança identificada, requisitos que os cookies de DNS evitam intencionalmente.

Até TSIG tem fronteira: autentica transmissão entre partes com segredo comum, não a verdade nem a origem inicial de todo dado DNS. Cookies de DNS não herdam autenticação forte só porque ambos usam cálculo com chave. Um oferece proteção leve contra falsificação para ampla implantação; o outro autentica transações numa confiança preestabelecida.

O erro operacional comprime quatro observações em um indicador de identidade. O Server Cookie pode ser válido e o endereço pode corresponder, mas o caminho ainda pode ser observado e o resolvedor pode representar usuários com permissões distintas. Um limitador pode usar o cookie como sinal contra abuso sem afirmar que autenticou um cliente.

Um registro útil reuniria Client Cookie, versão e carimbo do Server Cookie, resultado, endereço observado, membro anycast, época do Server Secret, transporte e exposição no caminho, instância do resolvedor quando conhecida, usuário ou serviço autenticado separadamente, política de autorização e momento da ação. O segredo jamais seria armazenado.

Assim se preserva o valor real. Cookies válidos ajudam a controlar a frequência de consultas, reduzem a reflexão e filtram consultas claramente falsas antes de controles caros. Também revelam falhas de rotação e coerência anycast. O ganho vem de tornar a evidência legível, não de promovê-la além do modelo de ameaça.

Fontes

RFC 7873 — Domain Name System (DNS) Cookies; RFC 9018 — Interoperable DNS Server Cookies; RFC 8945 — Secret Key Transaction Authentication for DNS.