Resumen

  • DNS Cookies incorpora una señal ligera y sin estado por cliente al DNS sobre UDP. Vincula débilmente un intercambio anterior con un Client Cookie y una IP; no identifica personas, no autentica datos DNS, no cifra consultas y no resiste a un observador on-path.
  • RFC 9018 fija para la versión 1 un Server Cookie de 16 bytes, SipHash-2-4, timestamp y secreto configurable. En anycast, compartir y rotar ese secreto es una superficie operativa crítica.
  • La evidencia debe unir bytes recibidos, motivo de validación, nodo, época, BADCOOKIE, defensa relajada, tamaño de respuesta y reintento. Un campo “valid=true” no basta.

La equivocación de llamar conocido al cliente

Un servicio autoritativo anycast recibe una oleada de consultas UDP por una respuesta firmada grande. Limita a las fuentes nuevas para no amplificar tráfico falsificado. Un resolver vuelve con su Client Cookie y con el Server Cookie entregado antes. La comprobación pasa y una política permite responder con más bytes.

La consola lo llama “cliente conocido”. Sin embargo, una IP de CGNAT puede representar a otro abonado minutos después; una sonda en el camino puede copiar la opción; un nodo anycast puede seguir aceptando una época retirada en otros sitios. Los bytes son válidos en un punto, pero no narran una identidad estable.

La pregunta correcta es más estrecha: ¿alguien con capacidad de recibir en esta dirección aparente obtuvo recientemente una salida del servidor ligada a este Client Cookie? No sabemos quién, con qué intención, ni si el resolver está comprometido. El validador produce un dato; la política que aumenta cuota o tamaño ejerce autoridad.

Dos piezas, dos responsabilidades

IANA asigna el código EDNS 10 a COOKIE. En el primer contacto, RFC 7873 usa un Client Cookie de ocho bytes. El servidor devuelve ese valor junto a un Server Cookie. La siguiente consulta carga ambos y permite verificar sin mantener una tabla por cliente.

El Client Cookie no es credencial. RFC 9018 recomienda 64 bits de entropía, valores distintos por IP de servidor, cambio cuando cambia la IP del cliente y no conservarlo tras reiniciar el programa. Solo el cliente reconoce su elección.

La versión 1 del Server Cookie mide 16 bytes; la opción completa, 24. SipHash-2-4 recibe Client Cookie, versión, reserva, timestamp e IP cliente, bajo un Server Secret. El mecanismo dificulta que un atacante fuera del camino fabrique un valor fresco, pero no oculta nada a quien observa el intercambio.

La ausencia de estado ahorra memoria bajo ataque. A cambio, secreto, reloj y parsing exacto se vuelven decisivos. Aceptar longitudes ambiguas, tolerar relojes sin control o distribuir la clave fuera del conjunto necesario altera la garantía aunque la opción siga apareciendo en los paquetes.

Un indicio débil merece un privilegio limitado

El atacante que solo falsifica una IP no recibe la primera respuesta y normalmente no puede devolver un MAC válido. El servidor puede usar esa diferencia para permitir una respuesta más grande o una cuota algo mayor al origen que demostró recepción previa.

No debe inferir más. DNS Cookies no autentica RRsets: esa es otra función de DNSSEC. Tampoco reemplaza entropía de transacción, comparación de pregunta o transporte cifrado. Un observador on-path puede reutilizar el token; un resolver comprometido puede enviar abuso con cookies impecables.

Por ello, la señal solo debería modificar defensas dirigidas a falsificación off-path. No abre recursión, no anula ACL, no omite DNSSEC, no elimina límites globales ni vence bloqueos de incidente. “Válido” describe la construcción, no la legitimidad de la consulta.

La IP tampoco es persona. NAT agrega usuarios, movilidad cambia salida y los arrendamientos se reasignan. Vincular la prueba a la dirección es útil para el modelo de amenaza; convertir la ubicación de red en identidad social es un salto injustificado.

Anycast convierte la interoperabilidad en custodia

Consultas consecutivas a una IP anycast pueden llegar a máquinas distintas. El segundo nodo debe validar lo emitido por el primero. RFC 9018 normaliza la construcción y exige un Server Secret configurable, incluso en conjuntos heterogéneos.

La rotación sigue tres etapas: todos aprenden la clave nueva mientras generan con la antigua y verifican ambas; después generan con la nueva y aún aceptan la antigua; por último retiran la anterior tras la ventana de actualización. Generar antes de que todos aprendan produce BADCOOKIE geográfico. Retirar demasiado pronto devuelve clientes reales al estado inicial. Conservar indefinidamente amplía exposición.

Una herramienta de despliegue que dice “entregado” no prueba el estado de ejecución. Cada nodo debe exponer un identificador no secreto de época, estado de generación y verificación, y salud de reloj. La misma clave no debería cruzar direcciones, entornos o clientes que no necesitan interoperar.

BADCOOKIE es una bifurcación, no un veredicto

Un valor inválido puede estar caducado, asociado a otra IP o Client Cookie, creado por una época desconocida, mal codificado o falsificado. BADCOOKIE entrega material nuevo para un reintento cuyo Client Cookie coincide. La repetición debe tener límite.

La distribución explica más que el total. Fallos concentrados en un sitio señalan deriva de secreto; una población móvil puede mostrar cambio de dirección; longitudes anómalas en toda la red sugieren abuso de parser. No atribuir malicia antes de conservar la razón exacta.

Medir primeras consultas, válidos, expirados, malformados, épocas desconocidas, BADCOOKIE, reintentos exitosos, abandonos y fallback TCP. Una protección que impide resolver a clientes legítimos no es éxito, aunque filtre falsificaciones.

El estándar coordina, la ejecución demuestra

La Minimum Initial Specification de Heng Lu encaja en el diseño: código, formato, algoritmo, tiempo y recuperación forman el mínimo común. Presupuesto de respuesta, política DDoS, custodia y ritmo de adopción siguen siendo locales.

Localized Future Decision permite negar privilegio incluso con cookie válido durante sobrecarga, o interoperar con un servidor que no ofrece la opción. Voluntary Adoption exige implementación y uso: el registro IANA es símbolo; la opción es estado; la rama que responde con más bytes es poder ejecutable; el paquete es consecuencia.

Running-code primacy obliga a probar que todos los sitios comparten las épocas correctas, que off-path pierde ventaja, que on-path sigue documentado como riesgo y que fallback no crea caída. No convierte cualquier salida del código en decisión legítima.

Fuentes