Resumen

  • Las cookies DNS son estado transaccional ligero concebido para dificultar ciertos ataques fuera de ruta por amplificación, falsificación y envenenamiento de caché.
  • Un valor Server Cookie válido da al servidor una garantía limitada: la consulta llega desde la dirección observada y lleva un valor Client Cookie visto en un intercambio anterior.
  • El mecanismo no resiste a un observador en ruta ni identifica al usuario, abonado, dueño del dispositivo o servicio autenticado detrás de un resolvedor o NAT.
  • La operación necesita un registro de evidencias de la consulta DNS que mantenga separadas la validación de la cookie, la observación de red, la identidad del resolvedor y la autorización.

Imaginemos un sistema hipotético de control de abuso. Un hogar, una oficina o una red de acceso envía tráfico DNS mediante un resolvedor recursivo compartido. El resolvedor alcanza un servicio anycast, recibe un valor Server Cookie y más tarde presenta otro válido desde la misma dirección pública. Un control posterior lo registra como prueba de que el mismo cliente hizo ambas consultas. El protocolo demuestra algo más estrecho: la segunda consulta incluye estado que el servidor puede validar con el valor Client Cookie, la dirección observada, su secreto y una ventana temporal.

RFC 7873 define las cookies DNS como un mecanismo ligero de seguridad de transacciones. Su finalidad es ofrecer protección limitada frente a la amplificación, la falsificación de respuestas y el envenenamiento de caché por atacantes que no pueden observar el intercambio. Esa condición de estar fuera de ruta es el límite de la garantía.

La primera consulta incluye un valor Client Cookie de ocho bytes. Tras la respuesta, las consultas posteriores pueden transportar tanto ese valor como el Server Cookie recibido. Así, el servidor puede rechazar o limitar tráfico incapaz de reproducir el estado que emitió. El mecanismo admite despliegue gradual, funciona con NAT y anycast, y no exige una credencial previamente pactada con cada cliente de Internet.

Esas ventajas explican que el RFC hable de autenticación débil y no de identidad de cliente. Un router, puente, participante en un enlace compartido u otro observador en ruta puede ver el tráfico DNS en claro y la cookie. Mientras esta sea utilizable, ese observador puede reutilizar lo aprendido. La cookie eleva el coste para el falsificador fuera de ruta; no transforma un valor portador visible en prueba de una persona u organización.

RFC 9018 normaliza una construcción interoperable de Server Cookies. La versión 1 combina el valor Client Cookie, los campos de versión y reserva, una marca temporal y la dirección IP del cliente bajo un Server Secret. La IP participa en el cálculo aunque no aparezca dentro del valor. El servidor verifica el resultado con el mismo secreto.

La construcción responde a una pregunta precisa: ¿coincide la consulta con una cookie producida antes para este valor Client Cookie y esta dirección observada, bajo un secreto y una ventana válidos? No responde quién usa la dirección. Varias personas pueden compartir resolvedor. Varios dispositivos pueden salir por un NAT. El proceso puede reiniciarse, renovar su Client Cookie o cambiar de dirección. A la inversa, una dirección estable puede representar personas y permisos distintos con el tiempo.

El tiempo forma parte de la prueba. RFC 9018 exige comprobar la marca dentro de un periodo definido y recomienda admitir aproximadamente una hora hacia el pasado y cinco minutos hacia el futuro. El servidor debería renovar una cookie recibida cuando tenga más de media hora. Esa ventana limita la repetición, pero no constituye una época de autorización vigente para una cuenta.

Anycast añade otra separación. Los miembros del conjunto necesitan una construcción compatible y los secretos necesarios para validar la salida de los demás. RFC 9018 prescribe tres etapas para rotarlos: distribuir el nuevo secreto mientras se sigue generando con el anterior; empezar a generar con el nuevo y validar ambos; retirar el antiguo tras dar tiempo a renovar. Que otro miembro acepte la cookie demuestra coherencia de validación, no que hayan vuelto el mismo servidor físico, la misma instancia de resolvedor o el mismo usuario.

Las reglas de privacidad refuerzan el límite. El cliente debe generar una nueva Client Cookie cuando cambia su dirección, y la especificación advierte que un cliente tras NAT quizá no detecte el cambio de su IP pública. La continuidad queda ligada deliberadamente al contexto de red y al estado de la implementación. Convertirla en identidad duradera contradice las premisas de privacidad y movilidad.

El comparador más fuerte es RFC 8945, que define TSIG. TSIG autentica una transacción DNS mediante un código de autenticación entre entidades que ya comparten un secreto configurado. Puede demostrar que una actualización dinámica o respuesta procede de una parte aprobada que posee esa clave. Eso exige distribución, custodia y una relación de confianza nombrada que las cookies DNS evitan a propósito.

Incluso TSIG tiene límites: autentica la transmisión entre partes con secreto compartido, no la veracidad ni el origen primero de todos los datos DNS. Las cookies no heredan esa autenticación de parte solo porque ambos mecanismos usan cálculos con clave. Uno ofrece estado ligero contra falsificación para despliegue general; el otro autentica transacciones dentro de una confianza preestablecida.

El error operativo es condensar cuatro observaciones en una bandera de identidad. El Server Cookie puede ser válido. La dirección fuente puede coincidir. El trayecto puede seguir siendo observable. El resolvedor puede representar a usuarios con permisos de aplicación distintos. Un sistema de limitación de consultas puede usar la cookie como señal de abuso sin declarar que autenticó a un cliente.

Un registro útil anotaría el valor Client Cookie, la versión y marca temporal del Server Cookie, el resultado de validación, la dirección observada, el miembro anycast, la generación del Server Secret, el transporte y la exposición en ruta, la instancia del resolvedor cuando se conozca, cualquier usuario o servicio autenticado por separado, la política de autorización y el momento de la acción. Nunca guardaría el secreto.

Así se conserva el valor real. Las cookies válidas permiten limitar la frecuencia de las consultas, reducen la reflexión y filtran consultas evidentemente falsificadas antes de controles costosos. También revelan fallos de rotación o coherencia anycast. La ganancia procede de hacer legible la prueba, no de ampliar su modelo de amenaza.

Fuentes

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