Resumo

  • DNS Cookies acrescenta ao DNS por UDP um sinal leve e sem estado individual no servidor. Um Server Cookie válido vincula fracamente uma troca anterior a Client Cookie e IP de origem; não identifica uma pessoa, autentica dados DNS, cifra consultas nem bloqueia observador on-path.
  • A RFC 9018 define uma versão 1 interoperável com Server Cookie de 16 bytes, SipHash-2-4, timestamp e segredo configurável. Em anycast, distribuição e rotação desse segredo se tornam uma superfície de autoridade.
  • A prova precisa conectar bytes, razão de validação, nó, época, BADCOOKIE, defesa flexibilizada, tamanho da resposta e resultado do retry. “Válido” é só a conclusão.

Quando o painel chama um endereço de cliente

Um serviço DNS autoritativo anycast recebe uma avalanche de consultas UDP por uma resposta assinada grande. Restringe fontes de primeiro contato para não amplificar pacotes com origem forjada. Um resolver retorna com seu Client Cookie e o Server Cookie emitido antes. A validação passa e a policy permite uma resposta mais completa.

O painel escreve “cliente conhecido”. A frase é mais forte que a evidência. Um endereço CGNAT pode representar outro assinante minutos depois. Um observador no caminho pode copiar a opção. Um nó anycast pode continuar aceitando uma época que os demais já retiraram. O mesmo conjunto de bytes não garante o mesmo ator.

A pergunta correta é: alguém que recebia nesse endereço aparente obteve recentemente um valor do servidor ligado a este Client Cookie? Ela não pergunta nome, intenção, integridade do resolver ou direito contratual. O validator entrega um fato; rate limiter e response policy decidem o poder dado a ele.

Duas partes com funções diferentes

A IANA reserva o código EDNS 10 para COOKIE. No primeiro contato, a RFC 7873 usa apenas um Client Cookie de oito bytes. O servidor o devolve junto de um Server Cookie. A consulta posterior carrega os dois, permitindo verificar sem manter tabela por cliente.

Client Cookie não é certificado. A RFC 9018 recomenda 64 bits de entropia, valor distinto para cada IP de servidor, troca quando o IP do cliente muda e nenhuma persistência após reinício. O servidor não extrai identidade desse campo.

O Server Cookie versão 1 tem 16 bytes; a opção completa, exatamente 24. SipHash-2-4 recebe Client Cookie, versão, reservado, timestamp e IP cliente sob um Server Secret. O atacante off-path não recebe a primeira resposta e dificilmente fabrica um MAC atual.

A arquitetura stateless economiza memória durante ataques, mas aumenta a importância de segredo, relógio e parsing. Tolerância a comprimento ambíguo, clock drift ou distribuição excessiva do segredo muda a garantia sem remover o indicador “enabled”.

A evidência fraca só deve liberar pouco

O valor válido distingue muitas fontes reais de floods que apenas falsificam IP. Pode justificar alguns bytes a mais ou uma cota temporária maior. Não justifica tudo.

Um ator on-path enxerga e reutiliza o cookie. DNS Cookies não autentica RRsets nem oferece sigilo. DNSSEC, entropia de transação e transportes protegidos respondem a perguntas diferentes. Resolver comprometido também apresenta cookies perfeitos.

Portanto, a opção só deve alterar defesas diretamente relacionadas à falsificação off-path. Não abre recursão, ignora ACL, pula DNSSEC, elimina teto global nem substitui bloqueio de incidente. A validade criptográfica não atesta benignidade.

IP também não é pessoa. NAT agrega, mobilidade desloca, lease muda. O vínculo de endereço serve ao modelo de ameaça; não sustenta identidade social ou organizacional.

Anycast transforma segredo em responsabilidade coletiva

Consultas ao mesmo IP anycast podem alcançar máquinas diferentes. O segundo nó precisa validar o valor criado pelo primeiro. A RFC 9018 torna a construção interoperável e exige Server Secret configurável.

A rotação tem três fases. Primeiro, todos aprendem a chave nova, geram com a anterior e verificam ambas. Depois, geram com a nova e ainda verificam a antiga. Por fim, retiram a antiga após a janela de renovação. Gerar cedo cria BADCOOKIE por região; retirar cedo transforma clientes reais em desconhecidos; aceitar para sempre amplia exposição.

“Configuração entregue” não prova convergência. Cada nó deve mostrar identificador de época não secreto, estados learned/generating/accepting e saúde do relógio. O segredo deve cobrir apenas o menor conjunto que precisa interoperar, sem unir ambientes ou clientes independentes.

BADCOOKIE não determina a causa

Invalidade pode significar expiração, troca de IP ou Client Cookie, época desconhecida, formato incorreto ou spoofing. BADCOOKIE entrega um valor novo e permite retry limitado quando o Client Cookie coincide. Loop infinito cria carga adicional.

Falha em um site aponta para drift de época; aumento em rede móvel pode refletir NAT; comprimentos ilegais em todos os sites sugerem abuso do parser. Preservar a categoria antes de atribuir intenção.

Medir primeiro contato, válido, expirado, malformed, unknown epoch, BADCOOKIE, retry bem-sucedido, abandono e TCP fallback. Bloquear forge e impedir resolução legítima não é sucesso.

A coordenação é comum; a decisão permanece local

Pela Minimum Initial Specification de Heng Lu, codepoint, comprimento, algoritmo, tempo e recuperação formam o núcleo comum. Budget de resposta, policy DDoS, custódia e cronograma continuam locais.

Localized Future Decision permite negar privilégio mesmo com cookie válido sob sobrecarga e operar com servidor que não adotou a opção. Voluntary Adoption exige pacotes reais: registro IANA é símbolo; opção é estado; policy que amplia resposta é poder executável; bytes enviados são consequência.

Running-code primacy exige mostrar que todos os sites validam as épocas certas, off-path perde vantagem, on-path permanece risco conhecido e fallback não vira indisponibilidade. Não torna legítima toda decisão automática.

Fontes