Resumen

  • DNS Cookies convierte un primer intercambio en evidencia limitada de alcanzabilidad: una petición posterior con el par correcto es más difícil de falsificar para un atacante fuera del trayecto.
  • RFC 7873 definió el protocolo y RFC 9018 fijó un Server Cookie versión 1 interoperable para que nodos anycast con software distinto pudieran validar el mismo estado.
  • No es una identidad ni un canal confidencial. Un observador en ruta puede copiar el token, NAT agrupa varios clientes bajo una dirección y siguen siendo necesarios los límites de respuesta y las demás defensas de DNS.

La primera consulta no trae una cuenta, un certificado ni una clave acordada. Solo llega como datagrama UDP, con una dirección de origen que puede ser real o inventada. El cliente coloca un Client Cookie de ocho bytes en la opción COOKIE de EDNS. Si el servidor entiende el mecanismo, devuelve ese valor junto con su propio Server Cookie. En la consulta siguiente, el cliente presenta ambos.

Ese segundo paquete lleva una historia mínima. El Server Cookie se calcula a partir del Client Cookie, la dirección aparente y un secreto que conserva el servidor. Un atacante fuera de ruta puede escribir la dirección de una víctima en la cabecera IP, pero no debería haber visto la respuesta enviada allí. Le falta el token. Para el servidor, el par correcto es un indicio de que ya intercambió tráfico con esa combinación de dirección y cookie. Para el cliente, la devolución de su Client Cookie permite descartar respuestas que no pertenecen a la transacción esperada.

El alcance es deliberadamente corto. La dirección pública puede representar una casa, una empresa o miles de abonados detrás de NAT. Una máquina comprometida situada en el lugar correcto continúa siendo peligrosa. Quien observa el tráfico en ruta ve el cookie en claro y puede reutilizarlo mientras sea válido. DNS Cookies no cifra el nombre consultado, no prueba la identidad de una persona y no sustituye DNSSEC. Prueba algo más pequeño: que un camino de retorno funcionó antes.

Ese dato era valioso porque DNS sobre UDP permitía convertir la falsificación de origen en amplificación. Una pregunta breve podía provocar una respuesta grande hacia una víctima. Una petición falsa también podía hacer que un resolvedor gastara trabajo en consultas recursivas o validación DNSSEC. En sentido contrario, respuestas inventadas podían competir con la respuesta legítima e intentar envenenar la caché.

DNSSEC autentica los datos; TSIG ofrece autenticación más fuerte con administración previa de claves; la entropía de puertos e identificadores dificulta adivinar respuestas; la limitación de tasa restringe la salida. Los cookies añadieron evidencia de retorno sin crear una tabla de clientes en el servidor.

RFC 7873, publicado en mayo de 2016, asignó el código 10 a la opción COOKIE. Cuando no conoce el Server Cookie, el cliente envía solo ocho bytes. Después del aprendizaje, la opción incluye también un valor del servidor, originalmente de entre ocho y treinta y dos bytes. La norma dejó la construcción exacta en manos de cada implementación. El servidor podía recalcular el valor con la fuente, el Client Cookie y su secreto, en vez de guardar una sesión por cliente.

La máquina de estados favorece el despliegue gradual. Un servidor sin soporte ignora la opción. Uno compatible que recibe solo el Client Cookie puede descartar, devolver BADCOOKIE o responder normalmente según su política; si responde, entrega un Server Cookie para el próximo intento. Una longitud ilegal produce FORMERR. Un valor servidor inválido o antiguo se trata como ausente. Un valor válido permite retirar defensas dirigidas exclusivamente contra el origen UDP falsificado, no declarar benigno todo el tráfico.

BADCOOKIE es una transición operativa. Si la respuesta devuelve el Client Cookie esperado, el cliente acepta el nuevo valor servidor y reintenta. Si ese valor recién emitido vuelve a fallar, puede recurrir a TCP. La repetición también delata un problema interno: servidores bajo una misma dirección anycast pueden no compartir secretos o métodos de cálculo.

NAT demuestra por qué el Server Cookie incorpora ambos elementos. Si dependiera solo de la dirección pública, un host podría obtener un token aprovechable por todos los demás detrás del mismo equipo. Al incluir el Client Cookie, el servidor separa los flujos sin almacenar un registro individual. Eso no identifica al usuario; conserva la distinción disponible en la red.

Anycast planteó un problema diferente. Dos consultas consecutivas a una dirección pueden llegar a máquinas y productos distintos. RFC 7873 recomendaba compartir el secreto, pero no estandarizaba la función. Dos implementaciones con el mismo secreto podían generar tokens incompatibles. Un cambio normal de ruta parecía entonces una falsificación.

RFC 9018, publicado en abril de 2021, cerró esa brecha con el Server Cookie versión 1 de dieciséis bytes: un byte de versión, tres reservados, cuatro de marca temporal y ocho de SipHash-2-4. Con el Client Cookie, la opción completa debe medir exactamente veinticuatro bytes. El cálculo cubre el Client Cookie, los campos visibles, la IP del cliente y el Server Secret. La dirección influye en la validación sin viajar dentro del token.

La marca temporal delimita la repetición. La recomendación acepta hasta una hora hacia el pasado y cinco minutos hacia el futuro para absorber diferencias de reloj; un servidor debería renovar un cookie de más de media hora. No son estadísticas de despliegue, sino límites de diseño. El observador en ruta conoce también el periodo durante el cual su copia puede funcionar.

La rotación del secreto exige coordinación. Primero se distribuye el nuevo valor a todos los nodos, que aún emiten con el anterior y validan ambos. Después emiten con el nuevo mientras conservan el antiguo para validación. Solo al final se retira el viejo. La consistencia de relojes, fases y secretos forma parte de la seguridad tanto como SipHash.

RFC 9018 modificó además el Client Cookie: recomienda sesenta y cuatro bits de entropía distintos para cada IP de servidor y prohíbe reutilizar los cookies cuando cambia la IP del cliente. Así se evita que un identificador estable siga al dispositivo entre redes. Tras un NAT, el host quizá no detecte un cambio de dirección pública; el documento deja esa observación residual fuera de alcance.

La historia de DNS Cookies no es la llegada de la identidad a DNS. Es el ajuste entre una prueba y la afirmación que puede sostener. El primer intercambio crea un token que encarece la mentira de estar en una dirección que nunca recibió la respuesta. RFC 7873 diseñó ese pacto. RFC 9018 lo convirtió en una práctica común para un servicio anycast diverso. La autoridad final reside en la política de respuesta, el tiempo, la reutilización del cliente y la custodia disciplinada del secreto.

Fuentes