Resumen
- DNS Cookies ofrecen protección deliberadamente limitada contra amplificación, falsificación y envenenamiento de caché por atacantes fuera de ruta, vinculando la petición con una dirección de origen, una Client Cookie y una respuesta previa.
- Una Server Cookie válida no identifica a una persona ni a un dispositivo duradero: varios clientes pueden compartir una dirección NAT, un cambio de dirección exige renovar las cookies y un observador en ruta puede reutilizar un valor visto mientras siga vigente.
- La operación debe conservar método, antigüedad, contexto de dirección, dominio de validación anycast y resultado de los reintentos; acceso, facturación y límites por persona necesitan un principal autenticado independiente.
El panel llama «cliente autenticado» a toda petición cuya Server Cookie resulta válida. A partir de esa etiqueta, un sistema de acceso relaja un límite o asigna consumo a un abonado. El razonamiento parece sólido: el servidor generó un valor difícil de adivinar y la petición lo devuelve desde la dirección esperada. Sin embargo, esa dirección puede ser la salida de un NAT de operador compartido por miles de usuarios o la de un resolvedor recursivo que consulta en nombre de una organización entera.
La cookie no ha fallado. La interpretación excede su cometido. La pregunta correcta es más estrecha: ¿presenta esta petición evidencia de que un cliente que usaba esta Client Cookie, desde esta dirección de origen, recibió antes una respuesta de este servidor o de su conjunto anycast interoperable? Eso describe una ruta de retorno y un intercambio DNS. No dice quién era la persona ni qué permisos tenía.
Una Server Cookie válida respalda la evidencia de un intercambio anterior
RFC 9018 define DNS Cookies como un mecanismo ligero de seguridad de transacción que aporta protección limitada frente a amplificación, falsificación y envenenamiento de caché por atacantes fuera de ruta. La palabra «limitada» es parte del modelo de seguridad: el atacante considerado no observa el tráfico entre la supuesta víctima y el servicio DNS y debe adivinar una información que no recibió.
Los dos campos de la opción COOKIE tienen funciones distintas. El cliente genera una Client Cookie impredecible y debe usar una diferente para cada dirección IP de servidor. RFC 9018 recomienda 64 bits de entropía. No es una credencial de cuenta emitida por el servidor; es un valor elegido por el cliente y reflejado posteriormente en la respuesta. Separarlo por dirección de servidor complica que un servidor suplante respuestas correspondientes a otro.
La Server Cookie es el token de retorno que construye el servicio. RFC 9018 la describe como, en efecto, un código de autenticación de mensaje calculado a partir de la Client Cookie, la dirección IP del cliente, campos definidos de versión y tiempo, y un secreto que solo conoce el servidor o el conjunto que atiende la misma dirección anycast. Cuando vuelve en una petición y valida, ofrece al servidor una garantía débil de que un cliente en esa dirección, usando esa Client Cookie, recibió una respuesta anterior con el valor.
RFC 7873 permite que el servidor considere que ya habló con ese contexto de cliente y que no necesita aplicar ciertas defensas dirigidas a peticiones UDP con origen falsificado. La norma no convierte la opción DNS en un protocolo general de autenticación. La Server Cookie no acredita una cuenta, un contrato, un dispositivo administrado ni el derecho a acceder a una vista protegida.
La etiqueta operativa debe conservar ese alcance. «Server Cookie válida para dirección, Client Cookie, conjunto de validación y momento» es una descripción verificable. «Usuario autenticado» añade una afirmación que los campos no contienen.
La dirección compartida rompe la equivalencia con una identidad
NAT muestra el límite sin necesidad de un atacante. Un router doméstico, una salida empresarial o un NAT a escala de operador puede presentar al servidor DNS una sola dirección pública para numerosos equipos y personas. La Server Cookie puede incorporar correctamente esa dirección y, aun así, no distinguir quién inició una acción concreta detrás de ella.
RFC 9018 reconoce que un cliente detrás de un dispositivo NAT quizá no pueda detectar un cambio de su dirección pública. El servidor sí puede observar y seguir la dirección pública del dispositivo; evitar ese seguimiento queda fuera del alcance del documento. La evidencia puede ser precisa en la frontera de red del servidor y demasiado gruesa para atribuir actividad a un abonado.
Si la Server Cookie se usa como clave para un límite individual, usuarios independientes quedan agregados. Si se usa como identidad de facturación, una propiedad temporal de la conexión recibe una responsabilidad duradera. No es un fallo criptográfico: la política pidió al mecanismo distinguir principales que nunca formaron parte de su contrato.
La movilidad produce el error inverso. Para evitar que un dispositivo sea seguido entre enlaces y para no anular las direcciones de privacidad IPv6, RFC 9018 exige no reutilizar Client Cookie ni Server Cookie después de cambiar la dirección del cliente. Una cookie nueva puede corresponder a la misma persona y al mismo dispositivo actuando correctamente. Una cookie estable solo puede reflejar estabilidad de dirección y proceso; tampoco prueba continuidad humana.
Una dirección puede representar muchos clientes, y un cliente puede usar legítimamente muchas direcciones y cookies. La identidad necesita una credencial y un ciclo de vida capaces de expresar esos cambios de forma intencional.
BADCOOKIE abre un diagnóstico, no señala a un culpable
Una Server Cookie inválida admite varias explicaciones previstas por RFC 7873: puede ser demasiado antigua; quizá cambió la dirección del cliente o la Client Cookie; el clúster anycast puede estar configurado de forma incoherente; o puede existir un intento de suplantación. El servidor procesa la petición como si la Server Cookie inválida no estuviera presente. El resultado del protocolo no elige una causa por el operador.
BADCOOKIE organiza la recuperación. El cliente reintenta con la nueva Server Cookie incluida en la respuesta. Si incluso ese valor recién emitido produce otro BADCOOKIE, una divergencia de secretos o métodos dentro del conjunto anycast se vuelve una hipótesis concreta. La norma indica entonces reintentar mediante TCP, cuyas propiedades de transacción pueden permitir que el servidor continúe.
El orden de eventos es la evidencia: edad y método del valor anterior, dirección vista en cada extremo, miembro o dominio de validación anycast, nueva cookie, respuesta del reintento y efecto del paso a TCP. Un contador que traduzca cada BADCOOKIE en «ataque» borra la diferencia entre caducidad normal, cambio de red, deriva de despliegue y tráfico hostil.
La rotación de secretos exige el mismo cuidado. RFC 9018 especifica una transición por etapas: todos los miembros deben aprender y validar el secreto nuevo antes de empezar a emitir con él, y conservar el anterior durante la ventana de cambio. Un miembro adelantado o atrasado puede crear alternancia entre valores válidos e inválidos según el destino anycast. Culpar al cliente oculta el fallo de coordinación.
Las demás defensas DNS siguen vigentes
DNS Cookies complementan, no sustituyen, el emparejamiento de respuestas. RFC 5452 exige que el resolvedor compare direcciones de origen y destino, puerto de destino, Query ID, nombre consultado, clase y tipo antes de aplicar las reglas de confianza. También exige puertos de origen e identificadores impredecibles. Cada atributo reduce el espacio disponible para una respuesta falsificada sin convertirse en identidad de aplicación.
Los controles responden a preguntas cercanas pero diferentes. El emparejamiento decide si una respuesta corresponde a la pregunta pendiente. La Client Cookie devuelta vincula débilmente la respuesta con la dirección de servidor elegida. Una Server Cookie válida da al servidor evidencia de una ruta previa de retorno al contexto de origen. Ninguno identifica a una persona ni proporciona confidencialidad por sí solo.
RFC 6891 define el soporte de transporte: EDNS es una extensión salto a salto y el registro OPT lleva información de control de una secuencia pregunta-respuesta. No contiene datos DNS y no debe almacenarse en caché, reenviarse ni guardarse en archivos maestros. La opción COOKIE pertenece al procesamiento de la transacción, no a un directorio permanente de usuarios.
La frontera frente a un adversario en ruta es explícita. Quien observe DNS en texto claro puede capturar una Server Cookie y reutilizarla contra ese cliente mientras siga vigente. El MAC dificulta fabricar valores válidos a un atacante fuera de ruta que desconoce el secreto. No cifra el campo en tránsito ni autentica a todo actor capaz de observar y transmitir desde el camino.
Construir un recibo que conserve el contexto
Cada decisión debería conservar la dirección de origen visible para el servidor, la dirección visible para el cliente cuando exista, una referencia no reversible de la Client Cookie, método y antigüedad de la Server Cookie, resultado de validación, dominio anycast, secuencia de reintentos y resultado del fallback a TCP. Las épocas de secretos y el estado de despliegue de cada miembro se registran aparte, sin exponer el secreto.
Si el servicio autentica además una cuenta o dispositivo, ese principal debe tener su propio método y sello temporal. La unión con el recibo DNS debe ser explícita: qué sesión autenticada produjo qué consulta, durante qué intervalo y con qué incertidumbre cuando intervinieron un resolvedor compartido o un NAT. Si no existe esa unión, la cookie no puede inventarla.
El lenguaje de alertas debe seguir la prueba. «Token de retorno válido» es preciso. «El servicio alcanzó antes este contexto de origen» puede serlo si adjunta dirección y tiempo. «Cliente conocido», «dispositivo fiable» y «usuario autorizado» requieren evidencias independientes.
Fuentes
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance