Internet Systems Consortium (ISC) ha publicado actualizaciones de mantenimiento para el servidor DNS BIND 9 que corrigen tres fallos relevantes en el resolver recursivo. Dos vulnerabilidades abren la puerta al envenenamiento de caché DNS y una tercera permite ataques de denegación de servicio (DoS). Las correcciones están disponibles en 9.18.41, 9.20.15 y 9.21.14; para BIND Supported Preview Edition (SPE), en 9.18.41‑S1 y 9.20.15‑S1. ISC recomienda actualizar sin dilación.
Detalles técnicos y CVE: qué cambia en el resolver DNS
CVE-2025-40780 (CVSS 8.6): puertos y TXID predecibles
Un defecto en el generador de números pseudoaleatorios puede hacer predecibles el puerto de origen y el identificador de transacción (TXID) en consultas salientes. Esta situación debilita la defensa adoptada tras el ataque de Kaminsky (2008), basada en la aleatorización de puertos, y facilita sincronizar respuestas falsificadas para insertar datos fraudulentos en la caché.
CVE-2025-40778 (CVSS 8.6): validación laxa de respuestas
El resolver no validaba con suficiente rigor ciertas entradas incluidas en respuestas DNS, lo que permitía inyectar registros directamente en la caché. Un atacante podría redirigir el tráfico de los clientes atendidos por el resolver hacia dominios controlados por él.
CVE-2025-8677 (CVSS 7.5): DoS mediante DNSKEY malformadas
Consultas contra zonas con DNSKEY especialmente manipuladas podían disparar el consumo de CPU, provocando degradación del servicio o indisponibilidad. Se trata de una vulnerabilidad de denegación de servicio sin impacto en la confidencialidad, pero con efecto operativo significativo.
Impacto, alcance y probabilidad de explotación
Según ISC, los fallos afectan a servidores recursivos; los servidores autoritativos que solo sirven sus zonas no se ven afectados. De acuerdo con valoraciones de Red Hat, CVE‑2025‑40780 presenta una explotación compleja porque requiere spoofing de red y precisión de temporización. Aun así, el efecto potencial en la integridad de la caché lo convierte en un riesgo operativo para proveedores, ISPs y organizaciones con resolvers expuestos.
Las defensas de la industria siguen siendo efectivas cuando están bien configuradas: DNSSEC con validación estricta bloquea la mayoría de intentos de cache poisoning; Response Rate Limiting (RRL) reduce el impacto de abusos; y los controles perimetrales (ACL, firewalls y anti-spoofing BCP 38/84) disminuyen la superficie de ataque.
Recomendaciones prioritarias para administradores
1) Actualización inmediata: instale 9.18.41, 9.20.15 o 9.21.14 (SPE: 9.18.41‑S1/9.20.15‑S1). Tras actualizar, ejecute rndc flush para limpiar la caché y eliminar posibles entradas manipuladas.
2) Refuerzo con DNSSEC: active la validación de firmas, mantenga actualizado el trust anchor (KSK de la raíz) y monitorice la cadena de confianza. DNSSEC reduce drásticamente la probabilidad de respuestas falsificadas aceptadas por el resolver.
3) Endurecimiento del resolver: limite la recursión con ACL a redes de confianza, habilite RRL, aplique qname-minimization y verifique que la aleatorización de puertos y TXID esté activa.
4) Controles de red anti-spoofing: implemente BCP 38/84 en routers de borde y egress/ingress filtering para reducir la viabilidad del spoofing a nivel IP.
5) Monitorización y respuesta: habilite registros detallados, alerte sobre picos de NXDOMAIN/ServFail y anomalías de CPU para detectar tempranamente DoS, y ejecute pruebas periódicas de integridad de caché.
Contexto del ecosistema: hallazgos similares en Unbound
Los investigadores que reportaron los fallos en BIND identificaron vulnerabilidades análogas en Unbound, con riesgo evaluado en 5.6 CVSS. Operadores con entornos mixtos deberían sincronizar parches y endurecimiento en todos los componentes DNS para mantener una postura coherente.
La ventana de ataque contra la infraestructura DNS se reduce con actualizaciones rápidas, validación estricta y controles perimetrales eficaces. Verifique la versión de sus resolvers, aplique las correcciones indicadas, refuerce DNSSEC y el anti-spoofing, y mantenga una supervisión proactiva. Estas medidas combinadas minimizan la exposición a cache poisoning y DoS, y contribuyen a la continuidad de servicios críticos.
