Un dominio de servidor WHOIS caducado. Un registro CAA olvidado. Una ruta BGP que se cuela por el control de validación de una CA. No son vectores de ataque hipotéticos: son los mecanismos que hay detrás de incidentes que ya han afectado a redes gubernamentales, resolvers de gran escala y autoridades de certificación de amplia confianza. Si tu equipo de infraestructura sigue tratando la seguridad del DNS como una casilla que se marca una vez y se olvida, el modelo de amenaza ha avanzado sin ti.
Este artículo repasa los controles concretos disponibles hoy: despliegue de DNSSEC, configuración de registros CAA, monitorización de transparencia de certificados, hardening de resolvers, y qué cambia realmente con las nuevas reglas de corroboración de emisión multiperspectiva del CA/Browser Forum. El objetivo es una lista de verificación accionable, no un catálogo de cosas que podrían salir mal.
Qué demuestran realmente los incidentes recientes
El incidente del TLD .mobi, documentado por WatchTowr, es la ilustración más clara de lo frágil que se vuelve la cadena de confianza cuando un dominio caducado ocupa un punto de estrangulamiento crítico. El dominio del antiguo servidor WHOIS de .mobi (whois.dotmobiregistry.net) expiró tras la migración del TLD a un nuevo dominio. WatchTowr lo adquirió, levantó un servidor WHOIS y en cinco días recibió más de 2,5 millones de consultas procedentes de 135.000 sistemas únicos, entre ellos organismos gubernamentales y militares. La superficie de ataque no era una vulnerabilidad en ningún software; era una brecha administrativa que persistió porque nadie la vigilaba.
El incidente de la CA Fina es un modo de fallo diferente. Entre febrero de 2024 y agosto de 2025, la CA croata Fina emitió doce certificados TLS no autorizados para el servicio de resolver 1.1.1.1 de Cloudflare. No se encontraron evidencias de explotación activa, pero el episodio ilustra que la emisión incorrecta de certificados puede pasar desapercibida durante meses cuando no existe monitorización. Las CAs cometen errores; los controles que se describen a continuación existen precisamente porque el modelo de confianza asume que eso ocurrirá.
Un tercer patrón, documentado por Unit 42 de Palo Alto Networks, es más peligroso desde el punto de vista operativo: un adversario compromete el plano de control DNS de un dominio y luego ejecuta un flujo de trabajo ACME legítimo sobre ese control secuestrado para obtener un certificado válido. El certificado es real, emitido por una CA de confianza, y será aceptado por cualquier navegador. El ataque funciona porque la validación del control de dominio, en esencia, solo pregunta si puedes responder una consulta DNS o servir un archivo, no si eres el titular legítimo del dominio.
DNSSEC: necesario pero no suficiente
DNSSEC proporciona autenticación criptográfica de los datos DNS, denegación de existencia autenticada e integridad de los datos. No proporciona disponibilidad ni confidencialidad, y no impide que una CA sea engañada por un plano de control secuestrado si el resolver que realiza la validación no aplica DNSSEC. Esa distinción importa para definir el alcance del control.
El despliegue sigue siendo escaso. Los datos de Verisign sitúan la adopción de DNSSEC en torno al 5% de los dominios de segundo nivel en .net y alrededor del 4% en .com. Las tasas de validación extremo a extremo en países de la UE (la proporción de consultas que se verifican criptográficamente de extremo a extremo, no solo las firmadas) son aún menores: Alemania se sitúa en aproximadamente el 0,63%, Francia en el 0,59%, los Países Bajos en el 0,51% y España en el 0,35%. Las tasas de firma son considerablemente más altas que las de validación, lo que significa que muchos operadores han firmado sus zonas pero no están aplicando la validación en los resolvers que usan sus cargas de trabajo. Firmar sin aplicar la validación es insuficiente.
La lista de verificación de despliegue de DNSSEC es sencilla en principio:
- Firma todas las zonas autoritativas que controles, incluidos los subdominios que delegan en proveedores externos. Verifica que el registro DS esté correctamente publicado en la zona padre.
- Configura tus resolvers recursivos para aplicar la validación DNSSEC, no solo para solicitarla. Un resolver que solicita firmas DNSSEC pero no las verifica no ofrece ninguna protección.
- Monitoriza los calendarios de rotación de claves. Una rotación de claves mal configurada o perdida hará que tu zona sea irresoluble para los resolvers que validan; automatiza las alertas antes del plazo de rotación.
- Audita las delegaciones DNS de terceros. Una zona padre firmada con una delegación de subdominio sin firmar o firmada incorrectamente rompe la cadena de confianza en ese punto.
Registros CAA: restringe quién puede emitir y cómo
Los registros CAA (definidos formalmente en el RFC 8659, que sustituyó al RFC 6844 en 2019) te permiten publicar una política a nivel DNS que restringe qué autoridades de certificación pueden emitir certificados para tu dominio. Desde que la Votación 187 del CA/Browser Forum fue aprobada en 2017, las CAs están obligadas a comprobar los registros CAA antes de emitir cualquier certificado. Un registro CAA ausente significa que cualquier CA pública puede emitir; uno presente pero mal configurado puede ser peor que ninguno.
Un registro CAA que nombra a la CA correcta pero omite las restricciones de comodín, o que carece de una dirección de notificación iodef, es una política sin aplicación y sin visibilidad. No sabrás cuándo alguien intenta vulnerarla.
Las tres etiquetas CAA principales son issue (permite la emisión de certificados regulares), issuewild (permite la emisión de certificados comodín y debe configurarse por separado) e iodef (especifica una dirección de notificación para intentos de emisión no autorizados). El RFC 8657 añade dos parámetros que vale la pena desplegar: accounturi, que vincula la emisión a una cuenta ACME específica, y validationmethods, que restringe los métodos de validación del control de dominio aceptables. Juntos, estos parámetros abordan el patrón de ataque documentado por Unit 42, en el que un adversario usa un plano de control secuestrado para superar un desafío ACME legítimo.
Una configuración mínima práctica para un dominio que usa una única CA tiene este aspecto:
- Establece issue solo para tu CA elegida. Configura issuewild de forma explícita, aunque no uses comodines en este momento, para evitar emisiones futuras no deseadas.
- Establece iodef en una dirección monitorizada. La mayoría de los equipos no se molesta; los informes son genuinamente útiles.
- Si usas ACME, añade accounturi para vincular la emisión a tu identificador de cuenta. Esto impide que otra cuenta en la misma CA emita certificados para tu dominio.
- Revisa los registros CAA de cada subdominio que tenga su propia delegación. Un subdominio sin registro CAA hereda la política del padre, pero uno con su propia zona no.
Monitorización de transparencia de certificados
La Transparencia de Certificados (estandarizada en el RFC 6962, con el RFC 9162 describiendo una arquitectura de versión 2.0, actualmente clasificada como Experimental) crea un registro público auditable y de solo adición de cada certificado TLS emitido por las CAs participantes. Los navegadores exigen que los certificados aparezcan en los registros CT antes de confiar en ellos. Esto significa que cualquier certificado emitido para tu dominio, incluidos los emitidos de forma fraudulenta, aparecerá en un registro que puedes consultar.
La monitorización es la parte que la mayoría de los equipos omite. Entre las herramientas útiles se encuentran crt.sh (búsqueda pública de CT de Sectigo), MerkleTown de Cloudflare y Cert Spotter de SSLMate, que proporciona alertas en tiempo real cuando aparece un nuevo certificado para un dominio monitorizado. Como mínimo, configura alertas para cualquier certificado emitido para tu dominio apex y sus subdominios inmediatos. La latencia de las alertas importa: la ventana entre la emisión incorrecta y la detección es la ventana en la que un atacante puede operar.
Corroboración de emisión multiperspectiva: qué cambia con SC-067
La Votación SC-067 del CA/Browser Forum, aprobada en agosto de 2024, introdujo la Corroboración de Emisión Multiperspectiva (MPIC, por sus siglas en inglés). El requisito, en plena aplicación desde septiembre de 2025, exige que la validación del control de dominio y las comprobaciones CAA se realicen desde al menos dos perspectivas de red independientes separadas por un mínimo de 500 km. El número de perspectivas escala progresivamente: tres perspectivas en marzo de 2026, cuatro en junio de 2026 y cinco en diciembre de 2026.
El propósito explícito de MPIC es que un secuestro BGP localizado sea insuficiente para engañar a la validación de dominio de una CA. Un secuestro de ruta BGP que redirige el tráfico desde un punto de observación de red no redirigirá simultáneamente el tráfico desde perspectivas en redes geográficamente separadas. Esto aborda directamente el vector de secuestro de rutas BGP que se ha utilizado para interceptar desafíos de validación de dominio. MPIC no elimina el riesgo, pero eleva considerablemente el coste y la coordinación necesarios para un ataque exitoso.
Hardening de resolvers y la capa DNS soberana
El resolver que usan tus cargas de trabajo para las consultas DNS salientes forma parte de tu superficie de ataque. Un resolver que no aplica la validación DNSSEC, que no filtra dominios maliciosos conocidos o que enruta las consultas a través de infraestructura fuera de tu jurisdicción debilita todos los demás controles de esta lista.
DNS4EU, lanzado en junio de 2025 y gestionado por un consorcio de diez estados miembros de la UE liderado por la empresa checa de ciberseguridad Whalebone, ofrece un servicio de resolver europeo conforme con la normativa de privacidad como alternativa a los proveedores no europeos. Fue desarrollado como respuesta directa a las preocupaciones de la Comisión Europea sobre la dependencia de la UE de un número reducido de resolvers DNS no europeos.
Para los equipos que ejecutan cargas de trabajo en AMS1, el denso peering de nuestro sitio de Ámsterdam en AMS-IX nos proporciona rutas directas de baja latencia hacia la infraestructura de resolvers de la UE y hacia los principales proveedores de tránsito cuyas tablas de enrutamiento importan cuando se realizan comprobaciones MPIC. Operamos nuestros propios resolvers recursivos con validación DNSSEC aplicada, lo que significa que la capa DNS sobre la que se asientan tus cargas de trabajo no es un servicio opaco gestionado por la infraestructura compartida de un hiperescalador. Eso importa cuando el vector de ataque es el propio resolver.
La lista de verificación
- Firma tus zonas y aplica la validación. Firmar sin aplicar la validación en tus resolvers es insuficiente. Audita ambos aspectos.
- Configura registros CAA para cada dominio que poseas, incluidos los subdominios con delegaciones independientes. Incluye issuewild, iodef y accounturi si usas ACME.
- Monitoriza los registros de transparencia de certificados en tiempo real. Usa Cert Spotter o una herramienta equivalente para recibir alertas inmediatas. No te bases en comprobaciones manuales periódicas.
- Audita las delegaciones DNS de terceros. Los dominios caducados en tu cadena DNS, ya sean servidores WHOIS, nombres de host de servidores de nombres o subdominios delegados, son el punto de entrada más sencillo para un atacante.
- Verifica que tu CA aplica MPIC. Desde septiembre de 2025 es obligatorio, pero confirmar la implementación de tu CA es una diligencia debida razonable.
- Refuerza la configuración de tu resolver. Aplica la validación DNSSEC, restringe el DNS saliente a resolvers controlados y valora si la infraestructura de resolvers soberana de la UE encaja en tu modelo de amenaza.
- Configura iodef y lee los informes. Los intentos de emisión no autorizada contra tu política CAA son inteligencia. Trátala como tal.
Ninguno de estos controles es exótico. La mayoría son cambios de configuración que tu equipo puede completar en un día. La brecha entre conocerlos y ejecutarlos en producción es donde ocurren los incidentes.
