Resumen

  • Una zona firmada maliciosa podía obligar al resolutor a probar muchas combinaciones de DNSKEY y RRSIG antes de declarar que ninguna era válida.
  • Las correcciones conservaron DNSSEC, pero devolvieron al resolutor el poder de terminar un cálculo patológico y mantener disponible el resto del servicio.

El coste viajaba en sentido contrario a los bytes

DNSSEC admite varias claves y firmas por motivos legítimos: rotaciones, cambios de algoritmo y esquemas con más de un firmante. La etiqueta de clave de 16 bits acelera la búsqueda, pero no es única. Distintas DNSKEY pueden compartirla.

KeyTrap aprovechó esa propiedad. El atacante controlaba una zona y preparaba muchas claves con la misma etiqueta junto a firmas candidatas que no verificaban. Un validador diligente recorría las posibilidades. La respuesta seguía siendo limitada en la red, mientras el coste de operaciones de clave pública crecía en el resolutor.

No era una falsificación. El resultado malicioso no adquiría estado Secure, la cadena raíz no se rompía y el atacante no obtenía autoridad sobre otro dominio. El objetivo era mantener ocupado al verificador. Por eso apagar DNSSEC era una salida peligrosa: eliminaba el trabajo y también la garantía.

ATHENE inició la divulgación coordinada en noviembre de 2023 y los proveedores publicaron sus avisos el 13 de febrero de 2024. Los ensayos encontraron bloqueos extremos, desde minutos hasta horas según la implementación. Son resultados de laboratorio sobre sistemas probados, no una estimación universal de impacto.

El límite se convirtió en una decisión operativa

ISC calificó CVE-2023-50387 como High y explotable de forma remota en las ramas de BIND 9 evaluadas. Recomendó versiones corregidas y declaró que no conocía explotación activa al publicar. Una capacidad demostrada no debe convertirse retrospectivamente en un incidente inventado.

Unbound 1.19.1 introdujo suspensiones tras un número acotado de intentos. La tarea cara cedía tiempo de CPU, otros trabajos avanzaban y la consulta acababa fallando después de reanudaciones limitadas. El resolutor protegía su cola, no solo su función criptográfica.

Cloudflare limitó validaciones por RRset y por tarea completa, añadió métricas y devolvió un error cuando el presupuesto se agotaba. Informó de que 1.1.1.1 estaba corregido el 8 de diciembre de 2023 y el resolutor interno del CDN el 13 de febrero de 2024 para KeyTrap y el problema NSEC3 relacionado.

No existe un número mágico común en estas respuestas. Existe una autoridad común: el publicador puede ofrecer material firmado; quien confía decide cuánto de su máquina dedicará a comprobarlo.

La corrección no cabía solo en la norma antigua

RFC 4034 define las piezas y RFC 4035 el proceso de validación. Esas reglas hicieron interoperable la autenticación. Sin embargo, no basta con que un algoritmo llegue al resultado correcto si una entrada hostil puede aplazar ese resultado hasta destruir el servicio.

Un Internet-Draft de 2026 sobre límites superiores registra que DNSKEY, DS y RRSIG carecían de techos explícitos relevantes para este coste. El borrador prueba que la cuestión sigue abierta; no prueba consenso ni futura adopción.

Por eso el proceso de estandarización del IETF es el foco institucional duradero de este caso. La cuestión ya no es solo qué proveedor corrigió primero, sino qué límites deben formar parte del contrato común del protocolo y cuáles deben seguir siendo locales a cada implementación. Un borrador individual no constituye consenso del IETF; los operadores no pueden sustituir límites desplegados por un trabajo todavía abierto.

La lectura de Heng Lu evita dos extremos. Una especificación inicial mínima mantiene el lenguaje común. Las decisiones futuras sobre recursos permanecen localizadas. La adopción voluntaria permite que BIND, Unbound y los grandes operadores prueben límites seguros sin convertir la política de un solo planificador en ley universal.

El inventario que falta

Un consejo de administración debería pedir implementación, versión exacta, origen del paquete, parche incluido y fecha de despliegue. Un sí en la columna «DNSSEC» no demuestra resistencia a KeyTrap.

La telemetría debe contar intentos de firma, tiempo de validación, retraso de cola, servicio desde caché y errores por límite. Las zonas de prueba maliciosas tienen que quedar aisladas, pero el ejercicio debe confirmar que consultas normales, incluso no cacheadas, siguen progresando.

Si una emergencia obliga a desactivar validación, la excepción necesita dueño, alcance, vencimiento y prueba de restauración. De otro modo, un ataque de disponibilidad consigue una degradación de autenticidad que sobrevive al ataque.

Lo que no muestran las fuentes

No hay prueba revisada de explotación mundial, interrupción global ni recuento completo de resolutores vulnerables. El día en que un proveedor publica no es el día en que toda distribución actualiza. Las cifras ATHENE no describen toda configuración y los superlativos no sustituyen una medición comparativa.

La conclusión defendible es concreta: la firma no otorga derecho a cálculo ilimitado. La parte que confía conserva autoridad sobre el precio de llegar a su veredicto.

Fuentes