Solo un paquete malo puede derribar un servidor DNS vulnerable gracias a DNSSEC

Artículo original ↗ Discusión en Hacker News ↗

Un fallo recién revelado “KeyTrap” en el estándar DNSSEC permite que un solo paquete manipulado agote la CPU de los resolvedores que validan, pudiendo dejar fuera de servicio al software DNS principal hasta que se aplique un parche. Los comentaristas sostienen que esto expone problemas de diseño más profundos en DNSSEC: alta complejidad operativa, riesgos de self-DoS, beneficios limitados en el mundo real dadas las bajas tasas de firma y la dependencia de intermediarios para la gestión de claves, especialmente cuando HTTPS, DoH/DoT y CT ya cubren la mayor parte de la seguridad visible para el usuario. Otros responden que DNSSEC sigue siendo importante para detectar manipulación entre los resolvedores y los servidores autoritativos y que sustenta mecanismos como DANE, pero admiten que el despliegue sigue siendo desigual y a menudo frágil.

Alcance de la vulnerabilidad

  • El ataque solo afecta a los resolvedores recursivos que validan DNSSEC, no a los servidores autoritativos normales.
  • La explotación (“KeyTrap”) abusa de una decisión de diseño de DNSSEC de hace más de 20 años: los validadores pueden pasar un tiempo ilimitado persiguiendo y comprobando múltiples claves/firma inválidas.
  • Todos los validadores principales (BIND, Unbound, dnsmasq, PowerDNS, etc.) se vieron afectados porque seguían la especificación.
  • Los parches añaden sobre todo límites al trabajo/tiempo de validación; técnicamente eso hace que las implementaciones no cumplan la especificación, lo que pone de relieve un fallo de la especificación más que un bug clásico de memoria.

El diseño de DNSSEC y sus problemas operativos

  • DNSSEC se diseñó en los años 90 en torno a la firma offline debido al coste asumido de la criptografía; varios sostienen que esta elección arquitectónica fue un “pecado original”.
  • La rotación y expiración de claves se describen como un gran obstáculo para su adopción: es fácil provocar un self-DoS, difícil de automatizar; CDS/CDNSKEY ayudan, pero tienen poco soporte.
  • Las configuraciones erróneas y las zonas rotas provocan fallos opacos (“Internet is broken”), lo que hace que los operadores desactiven la validación en la práctica.
  • Algunos llaman a DNSSEC una “footgun”, un “impuesto de infraestructura” y sugieren tratar DNSSEC en sí mismo como una responsabilidad de alta gravedad.

Valor de seguridad frente a WebPKI / DoH

  • Lado pro-DNSSEC:
    • Proporciona detección de manipulación entre el resolvedor y los servidores autoritativos; es la única forma de “confiar en el contenido de una zona”.
    • Habilita protocolos como DANE y la verificación basada en DNS de SSHFP/PGPKEY.
  • Lado escéptico:
    • DNSSEC no ofrece privacidad ni cifrado; DoH/DoT/ODoH protegen el último tramo de forma más eficaz y son más fáciles de desplegar.
    • Para la Web, TLS + CA + Certificate Transparency ya se encargan de la integridad; las respuestas DNS incorrectas, en su mayoría, se convierten en DoS, no en compromiso silencioso.
    • Existen ataques de downgrade/stripping de DNSSEC; la validación ocurre sobre todo en resolvedores recursivos, no en los clientes finales.

Adopción y uso en el mundo real

  • Se dice que la firma DNSSEC global de grandes TLDs (.com, .net) es muy baja (alrededor de unos pocos por ciento), mientras que algunos ccTLDs (.nl, .se, .ch) están mucho más altos.
  • Se informa que las tasas de validación medidas en resolvedores rondan el 30–40% a nivel global, pero los críticos señalan que eso no equivale a seguridad de extremo a extremo para el cliente.
  • Debate sobre si el DNSSEC gestionado por registradores para muchos dominios cuenta como una adopción “significativa”.

Alternativas y direcciones futuras

  • Algunos promueven DNSCurve o DNSCrypt como diseños mejores con seguridad de transporte adecuada, pero reconocen que DoH ha “ganado” efectivamente ese nicho.
  • Varios argumentan que DNSSEC es poco probable que reemplace a WebPKI; los experimentos con DANE en navegadores se probaron y se eliminaron.
  • Hay interés en nuevas implementaciones de DNS seguras frente a memoria (por ejemplo, resolvedores basados en Rust), pero varios comentaristas subrayan que este problema específico tiene que ver con el diseño del protocolo, no con la seguridad de la memoria.