Ballot SC-085v2: las autoridades de certificación verifican DNSSEC antes de emitir un certificado TLS

⚡TL;DR

• Desde el 15 de marzo de 2026 las CA deben verificar DNSSEC durante la validación de dominio (DCV) antes de emitir un certificado TLS (Ballot SC-085v2)
• Si tu dominio publica DNSSEC y la cadena de confianza está rota (BOGUS), no se emitirá ningún certificado mientras el problema persista
• SC-085v2 complementa MPIC (SC-067): juntos protegen la DCV contra el BGP hijacking y el DNS spoofing
• SC-081v3 también reduce la duración de los certificados TLS a 47 días para 2029: consulta nuestra guía completa SC-081v3

Desde el 15 de marzo de 2026, renovar un certificado TLS puede fallar si tu dominio publica DNSSEC con una cadena de confianza inválida. No es un bug de tu proveedor de certificados: es la aplicación del Ballot SC-085v2 del CA/Browser Forum, que obliga a las autoridades de certificación (CA) a validar las respuestas DNSSEC durante la verificación de control de dominio.

Este cambio afecta a todos los dominios que publican DNSSEC. Si tu zona DNS está correctamente firmada, te beneficias de una protección reforzada contra ataques de tipo BGP hijacking y DNS spoofing durante la emisión de certificados. Pero si tu configuración DNSSEC está rota (DS record caducado, firmas expiradas, algoritmo obsoleto), la CA rechazará emitir el certificado.

Este artículo detalla el problema que SC-085v2 resuelve, su funcionamiento técnico, su interacción con MPIC (SC-067), el impacto operativo según tu situación y una guía práctica para verificar y corregir tu configuración antes de la próxima renovación.

El problema: la DCV depende de un DNS no autenticado

La validación de control de dominio (DCV) es el proceso mediante el cual una CA verifica que el solicitante de un certificado controla efectivamente el dominio en cuestión. Este proceso se basa en el DNS, un protocolo diseñado sin autenticación de las respuestas.

Cómo funciona la validación de dominio (DCV)

Antes de emitir un certificado TLS, la CA debe asegurarse de que controlas el dominio para el que solicitas el certificado. Se utilizan habitualmente tres métodos de validación:

• DNS-01: la CA solicita publicar un registro TXT específico bajo _acme-challenge.captaindns.com. Luego consulta el DNS para verificar que el registro está presente y contiene el valor esperado. Es el método más utilizado por los sistemas automatizados.
• HTTP-01: la CA solicita colocar un archivo en una URL específica del servidor web del dominio (por ejemplo http://captaindns.com/.well-known/acme-challenge/TOKEN). Luego verifica que el archivo es accesible y contiene el valor correcto.
• Email: la CA envía un email de validación a una dirección administrativa del dominio (admin@, postmaster@, etc.) y espera una confirmación.

El protocolo ACME (Automatic Certificate Management Environment, RFC 8555) automatiza estos intercambios. Estandariza el diálogo entre el cliente (certbot, acme.sh, etc.) y la CA. El método DNS-01 es el más extendido en entornos automatizados porque permite validar certificados wildcard y no requiere exponer un servidor web.

En todos los casos, la CA realiza consultas DNS: para resolver el TXT de validación (DNS-01), para resolver la dirección IP del servidor web (HTTP-01), o para resolver el MX del dominio (email). El DNS es, por tanto, la base de la DCV.

El DNS sin DNSSEC es falsificable

El protocolo DNS, diseñado en 1983, no incluye ninguna autenticación de las respuestas. Un resolver DNS no puede distinguir una respuesta legítima de una respuesta falsificada. Esta debilidad estructural abre la puerta a varios vectores de ataque:

Envenenamiento de caché. Un atacante inyecta respuestas falsas en la caché de un resolver DNS. Las consultas posteriores para el mismo dominio devuelven la dirección IP del atacante en lugar de la del servidor legítimo.

BGP hijacking. Un atacante anuncia rutas BGP fraudulentas para desviar el tráfico de red hacia sus propios servidores. Combinado con una solicitud DCV, puede interceptar la validación y obtener un certificado para un dominio que no controla.

Ataque man-in-the-middle en la red. Un atacante situado en la ruta de red entre la CA y el servidor DNS autoritativo modifica las respuestas DNS en tránsito.

Estos ataques no son teóricos. Varios incidentes importantes han demostrado su viabilidad:

• KLAYswap (febrero 2022): los atacantes desviaron el tráfico BGP de un registro de dominios coreano, obtuvieron un certificado TLS fraudulento mediante BGP hijack y robaron el equivalente a 2 millones de dólares en criptomonedas a través de un sitio falso.
• Celer Bridge (agosto 2022): un ataque similar explotó el BGP hijacking para desviar el tráfico DNS de un puente DeFi. Los atacantes obtuvieron un certificado fraudulento y robaron 235 000 dólares.
• MyEtherWallet (abril 2018): los atacantes desviaron los prefijos BGP de Route 53 de Amazon para redirigir las consultas DNS hacia un servidor fraudulento, obtuvieron un certificado TLS e interceptaron las credenciales de los usuarios del monedero crypto.

La investigación académica ha formalizado estos riesgos. El estudio "Bamboozling Certificate Authorities with BGP" (USENIX Security 2018, Princeton University) demostró que un atacante podía obtener certificados TLS fraudulentos de las cinco mayores CA desviando las consultas DNS mediante BGP, con una tasa de éxito superior al 60 % en sus experimentos.

La conclusión es clara: mientras la DCV dependa de un DNS no autenticado, la emisión de certificados TLS sigue siendo vulnerable.

Ballot SC-085v2: qué cambia en la práctica

El Ballot SC-085v2, titulado "Require Validation of DNSSEC when Present for CAA and DCV Lookups", fue propuesto por Clint Wilson (Apple) y respaldado por Chrome Root Program (Google), Fastly y HARICA. Modifica los Baseline Requirements (BR) del CA/Browser Forum, el documento normativo que todas las CA públicamente aprobadas deben cumplir.

La votación

La votación concluyó con una adopción unánime por parte de los navegadores y casi unánime por parte de las CA:

• 25 votos a favor (entre ellos DigiCert, Sectigo, GlobalSign, Entrust, HARICA, SwissSign)
• 0 votos en contra
• 1 abstención (Entrust, que votó a favor en el plano técnico pero se abstuvo por cuestiones de calendario)
• Navegadores: Apple y Mozilla votaron a favor

Lo que el ballot exige

Desde el 15 de marzo de 2026, las CA deben realizar una validación DNSSEC completa en las consultas DNS utilizadas para:

1. La validación de control de dominio (DCV): todas las consultas DNS relacionadas con la verificación de control (TXT para DNS-01, A/AAAA para HTTP-01, MX para email)
2. Las verificaciones CAA (Certification Authority Authorization): los registros CAA determinan qué CA están autorizadas a emitir certificados para un dominio

La validación DNSSEC debe realizarse hasta el trust anchor IANA (la KSK raíz) en la Primary Network Perspective, es decir, el punto de resolución principal de la CA. El requisito cubre la cadena completa: desde la raíz DNS hasta el dominio objetivo, cada firma RRSIG debe ser verificada.

Lo que el ballot no cambia

Los dominios sin DNSSEC no se ven afectados. Si tu dominio no publica un DS record en el TLD, la CA continúa la DCV exactamente como antes. SC-085v2 no hace que DNSSEC sea obligatorio para obtener un certificado. Simplemente obliga a las CA a respetar DNSSEC cuando está desplegado.

Cronología del despliegue

Las principales CA se anticiparon a la fecha límite:

• DigiCert: validación DNSSEC activa desde el 3 de marzo de 2026, con el código de error dns_sec_validation_error para los dominios en fallo
• Sectigo: despliegue completado el 5 de marzo de 2026
• Fecha límite oficial: 15 de marzo de 2026, todas las CA deben ser conformes

La excepción para la validación por email (SC-094v2)

El Ballot SC-094v2, adoptado por separado, concede una excepción temporal para la DCV por email. Los métodos de validación por email (secciones BR 3.2.2.4.2 y 3.2.2.4.4) están en proceso de discontinuación y se benefician de un plazo adicional antes de que la validación DNSSEC les sea impuesta. Esta excepción reconoce que estos métodos históricos serán progresivamente abandonados.

Cómo DNSSEC asegura la emisión de certificados

DNSSEC añade una capa de autenticación criptográfica al DNS. Cada registro DNS va acompañado de una firma digital (RRSIG) verificable por el resolver. La confianza se propaga desde el trust anchor IANA (la KSK raíz) hasta el dominio objetivo a través de una cadena de DS records y DNSKEY. Para una explicación detallada de este mecanismo, consulta nuestra guía sobre la cadena de confianza DNSSEC.

Aplicación concreta a la DCV

Tomemos un escenario concreto. Un sistema automatizado solicita un certificado para captaindns.com a través de ACME (DNS-01). El cliente ACME publica un registro TXT bajo _acme-challenge.captaindns.com con un token único.

La CA consulta el DNS para recuperar ese TXT. Con SC-085v2, el resolver de la CA realiza ahora una validación DNSSEC completa:

1. Verifica que la zona captaindns.com publica un DS record en el TLD .com
2. Recupera las DNSKEY de la zona captaindns.com y verifica que el DS corresponde al hash de la KSK
3. Verifica que el RRSIG del TXT _acme-challenge.captaindns.com está firmado por una ZSK cuya DNSKEY está a su vez firmada por la KSK
4. Recorre la cadena hasta la raíz IANA para validar cada eslabón

Si todas las firmas son válidas, el resolver devuelve la respuesta con el flag AD (Authenticated Data). La CA puede entonces proceder con la DCV con la garantía de que la respuesta DNS no ha sido falsificada.

Los tres escenarios tras SC-085v2

Escenario 1: dominio sin DNSSEC. Tu dominio no publica un DS record en el TLD. El resolver de la CA constata la ausencia de DNSSEC y procede con la DCV clásica, sin validación criptográfica. Ningún cambio respecto a antes de SC-085v2.

Escenario 2: DNSSEC válido (SECURE). Tu dominio publica DNSSEC y la cadena de confianza está intacta. El resolver valida cada firma, obtiene el flag AD, y la CA procede con la DCV con la certeza de que la respuesta es auténtica. Este es el comportamiento ideal: te beneficias de una protección completa contra el spoofing DNS durante la emisión de tu certificado.

Escenario 3: DNSSEC roto (BOGUS). Tu dominio publica un DS record en el TLD, pero la validación falla. El DS no corresponde a la DNSKEY, las RRSIG están expiradas, o se utiliza un algoritmo no soportado. El resolver marca la respuesta como BOGUS y devuelve un SERVFAIL. La CA no puede obtener una respuesta DNS válida y rechaza emitir el certificado.

El RFC 4035 sección 5 define el algoritmo de validación que los resolvers (y por tanto las CA) deben implementar. Las CA conformes con SC-085v2 aplican este algoritmo en su Primary Network Perspective para toda consulta DCV y CAA.

MPIC y DNSSEC: la defensa en profundidad

SC-085v2 no funciona de forma aislada. Se enmarca en una estrategia de defensa en profundidad iniciada por el CA/Browser Forum, cuyo primer componente es MPIC (Multi-Perspective Issuance Corroboration).

MPIC: la protección de red

El Ballot SC-067v3, efectivo desde marzo de 2025, obliga a las CA a validar la DCV desde al menos dos perspectivas de red geográficamente separadas (mínimo 500 km). En la práctica, cuando solicitas un certificado, la CA lanza la verificación DNS desde varios puntos de presencia en todo el mundo.

El objetivo: contrarrestar los ataques BGP localizados. Si un atacante desvía el tráfico BGP en una región, las perspectivas de red situadas en otras regiones recibirán la respuesta DNS legítima. La CA detecta la inconsistencia y rechaza emitir el certificado.

DNSSEC: la protección a nivel de protocolo

SC-085v2 añade una segunda capa de protección, esta vez a nivel del protocolo DNS. DNSSEC garantiza la autenticidad de las respuestas DNS mediante firmas criptográficas. Incluso si el atacante controla la ruta de red, no puede falsificar una respuesta DNS válida sin poseer las claves privadas de la zona.

Por qué ambos son necesarios

MPIC y DNSSEC abordan vectores de ataque diferentes y se complementan:

• MPIC solo no protege si el servidor DNS autoritativo está comprometido o si el atacante ha envenenado las cachés DNS de forma global. Todas las perspectivas de red recibirían la misma respuesta falsa.
• DNSSEC solo no protege si el resolver de la CA no valida DNSSEC (lo cual ya no es posible con SC-085v2 cuando DNSSEC está publicado), o si el ataque apunta a la ruta de red sin modificar las respuestas DNS.
• Juntos: MPIC cubre el vector de red (BGP hijacking localizado), DNSSEC cubre el vector DNS (spoofing, envenenamiento de caché). Un atacante tendría que comprometer simultáneamente la cadena DNSSEC y desviar el tráfico desde todas las perspectivas de red de la CA para obtener un certificado fraudulento.

Impacto operativo: ¿a quién afecta?

El impacto de SC-085v2 depende directamente de tu situación DNSSEC. Estos son los cuatro perfiles tipo y sus consecuencias.

DNSSEC activo y correctamente configurado

Si tu dominio publica DNSSEC con una cadena de confianza intacta, SC-085v2 no cambia nada en tu flujo operativo. Tus renovaciones de certificados siguen funcionando normalmente. La única diferencia: la CA ahora valida criptográficamente las respuestas DNS, lo que refuerza la seguridad de la emisión. Estás protegido contra ataques de tipo BGP hijacking y DNS spoofing dirigidos a la DCV.

Es el escenario ideal. Tu inversión en DNSSEC se rentabiliza doblemente: protección DNS clásica y protección de la emisión de certificados.

DNSSEC activo pero mal configurado

Este es el escenario de riesgo. Tu dominio publica un DS record en el TLD, lo que indica a los resolvers que la zona está firmada. Pero la configuración DNSSEC es inválida. Varias causas frecuentes:

• DS record caducado tras una migración DNS. Cambiaste de proveedor DNS, el nuevo proveedor generó nuevas claves DNSSEC, pero el DS record en el registrar apunta todavía a las claves antiguas. La cadena está rota.
• RRSIG expiradas. Las firmas DNSSEC tienen una vida útil limitada (normalmente de 7 a 30 días). Si el proceso de re-firma automática falla silenciosamente, las RRSIG expiran y la zona se convierte en BOGUS.
• Rotación KSK/ZSK incorrecta. Una rotación de claves mal secuenciada (nueva clave publicada antes de la propagación del DS, o antiguo DS eliminado antes de la propagación de la nueva clave) rompe temporalmente la cadena.
• Algoritmo no soportado. Algunos algoritmos antiguos (RSA-SHA1, DSA) están obsoletos. Si tu zona utiliza un algoritmo que el resolver de la CA no soporta, la validación falla.

Antes de SC-085v2, una configuración DNSSEC rota provocaba SERVFAIL en los resolvers validantes (1.1.1.1, 8.8.8.8, 9.9.9.9) pero no impedía la emisión de certificados, ya que los resolvers de las CA no validaban sistemáticamente DNSSEC. Ahora, un DNSSEC BOGUS bloquea la DCV y el certificado es rechazado.

Sin DNSSEC desplegado

Si tu dominio no publica un DS record en el TLD, SC-085v2 no tiene ningún impacto inmediato. La CA constata la ausencia de DNSSEC y procede con la DCV clásica. Tus renovaciones siguen funcionando exactamente como antes.

Sin embargo, la adopción de DNSSEC se vuelve cada vez más estratégica. SC-085v2 crea un incentivo fuerte: los dominios con DNSSEC válido se benefician de una DCV protegida contra el spoofing. Los dominios sin DNSSEC siguen siendo vulnerables a los mismos ataques descritos en la sección anterior. La migración de Microsoft 365 hacia el dominio mx.microsoft con DNSSEC automático, la llegada de DMARCbis que recomienda DNSSEC para la protección de los registros MX, y SC-085v2 convergen hacia un ecosistema donde DNSSEC se convierte en la norma esperada.

Certificados automatizados mediante ACME

Este perfil merece atención especial. El método DNS-01 es masivamente utilizado por los sistemas ACME para validar certificados, en particular para certificados wildcard. Si tu infraestructura automatiza la renovación mediante certbot, acme.sh o un operador Kubernetes como cert-manager, el flujo es completamente no interactivo.

El riesgo: un DNSSEC roto provoca un fallo silencioso. La renovación ACME falla, el certificado expira y tu sitio deja de ser accesible por HTTPS. No hay ninguna intervención humana en el proceso para detectar el problema antes de la expiración.

DigiCert ha introducido el código de error dns_sec_validation_error para señalar específicamente un fallo de validación DNSSEC durante la DCV. Si recibes este error, el problema está en tu configuración DNSSEC, no en tu registro de validación.

Adopción de DNSSEC: estado de la situación en marzo de 2026

Comprender el nivel de adopción actual permite medir la magnitud del cambio introducido por SC-085v2.

Validación global

Aproximadamente el 35 % de las consultas DNS mundiales transitan por resolvers que validan DNSSEC. Esta cifra refleja la adopción del lado de los resolvers: los grandes resolvers públicos (1.1.1.1, 8.8.8.8, 9.9.9.9) validan todos DNSSEC. Los resolvers de los ISP son más heterogéneos, pero la tendencia es al alza.

Tasa de firma por TLD

La adopción de DNSSEC por los dominios (del lado de la zona, no del lado del resolver) varía considerablemente según los TLD:

• .nl (Países Bajos): aproximadamente el 60 % de los dominios firmados. Líder mundial gracias al incentivo activo del SIDN (registro del .nl).
• TLD nórdicos (.se, .dk, .no): más del 50 % de adopción, impulsada por registros proactivos.
• .com: aproximadamente del 4 al 5 % de los dominios firmados. El volumen es enorme en valor absoluto, pero el porcentaje sigue siendo bajo.
• El 92 % de los TLD tienen un DS record en la zona raíz, lo que significa que la infraestructura de firma existe a nivel de TLD.

La asimetría entre infraestructura y adopción

La infraestructura de validación DNSSEC está ampliamente desplegada. Los resolvers están listos. Los TLD están firmados. Pero la firma de las zonas individuales sigue siendo minoritaria. Esta asimetría se explica por la complejidad percibida del despliegue DNSSEC y la ausencia hasta ahora de consecuencias visibles para los dominios no firmados.

SC-085v2 cambia esta dinámica. Por primera vez, hay una consecuencia concreta por publicar DNSSEC con una configuración inválida. Y hay un beneficio medible por publicar DNSSEC correctamente: la protección de la DCV.

El efecto dominó es previsible. SC-085v2, combinado con la migración de Microsoft 365 hacia mx.microsoft con DNSSEC automático y las recomendaciones de DMARCbis, va a acelerar la adopción de DNSSEC en los próximos trimestres.

Guía práctica: verificar y corregir tu configuración DNSSEC

Antes de tu próxima renovación de certificado, verifica que tu configuración DNSSEC está intacta. Aquí tienes los comandos y pasos esenciales.

Verificación rápida con dig

Verificar el flag AD (Authenticated Data):

dig +dnssec SOA captaindns.com

En la sección flags:, busca ad. Su presencia significa que el resolver ha validado la cadena DNSSEC con éxito. Su ausencia indica que DNSSEC no está desplegado o que la validación ha fallado.

Verificar los DS records en el TLD:

dig DS captaindns.com +short

Este comando devuelve el o los DS records publicados por el registrar en el TLD. Si la respuesta está vacía, tu dominio no publica DNSSEC. Si hay DS presentes, verifica que corresponden a las claves actuales de tu zona.

Verificar las claves DNSKEY:

dig DNSKEY captaindns.com +short

Debes ver como mínimo dos claves: una con el flag 256 (ZSK) y una con el flag 257 (KSK). El hash de la KSK (flag 257) debe corresponder al DS record publicado en el TLD.

Distinguir un problema DNSSEC de otro problema DNS:

dig captaindns.com +cd

El flag +cd (Checking Disabled) desactiva la validación DNSSEC. Si la consulta funciona con +cd pero falla sin él (SERVFAIL), el problema es DNSSEC.

Qué hacer si DNSSEC está roto

Si tus verificaciones revelan un problema, aquí tienes las acciones correctivas por orden de prioridad:

Verificar el DS record en el registrar. Conéctate a la interfaz de tu registrar y compara el DS record publicado con la DNSKEY (flag 257) de tu zona. Si has migrado de proveedor DNS, el DS debe apuntar a la KSK del nuevo proveedor.

Verificar las RRSIG en la zona. Las firmas tienen una fecha de expiración. Si tu proveedor DNS tiene un problema de re-firma, las RRSIG pueden estar expiradas. Contacta con tu proveedor DNS o verifica los logs de firma si gestionas DNSSEC internamente.

Verificar el algoritmo. Los algoritmos RSA-SHA1 y DSA están obsoletos. Da preferencia a ECDSAP256SHA256 (algoritmo 13) o ECDSAP384SHA384 (algoritmo 14).

Para un diagnóstico detallado de los errores SERVFAIL relacionados con DNSSEC, consulta nuestra guía dedicada: resolver SERVFAIL tras activar DNSSEC. Si necesitas activar DNSSEC por primera vez, sigue nuestra guía de activación DNSSEC paso a paso.

Checklist pre-renovación de certificado

Antes de cada renovación de certificado en un dominio con DNSSEC:

• El DS record en el registrar corresponde a la KSK activa de la zona
• Las RRSIG no están expiradas (verificar la inception y la expiración con dig +dnssec)
• El algoritmo utilizado es soportado (ECDSAP256SHA256 recomendado)
• El resolver devuelve el flag AD para tu dominio
• El monitoring DNSSEC está activo y envía alertas en caso de ruptura de cadena
• Se ha ejecutado un dry-run ACME con éxito en el dominio en cuestión

SC-081 y la aceleración de las renovaciones

El Ballot SC-081, adoptado por el CA/Browser Forum, reduce progresivamente la duración máxima de los certificados TLS:

Fecha de aplicación	Duración máxima
Marzo 2026	200 días
Marzo 2027	100 días
Marzo 2029	47 días

Esta reducción tiene un impacto directo en la criticidad de SC-085v2. Cuanto más corta es la duración de los certificados, más frecuentes son las renovaciones. Y cuanto más frecuentes son las renovaciones, más rápido se detecta un DNSSEC roto, pero también más bloqueante resulta.

Con certificados de 200 días, un problema DNSSEC que dura una semana retrasa una renovación. Con certificados de 47 días, un problema DNSSEC de unos pocos días puede provocar la expiración del certificado antes de que la renovación tenga éxito. El margen de error se reduce drásticamente.

A 47 días, la automatización ACME se vuelve imprescindible. Ninguna organización puede gestionar manualmente renovaciones cada seis semanas en un parque de dominios. Y un pipeline ACME automatizado que falla silenciosamente por un DNSSEC roto es un escenario de incidente grave.

La recomendación es clara: implementa un monitoring DNSSEC continuo en todos tus dominios con certificados TLS. Configura alertas sobre la expiración de las RRSIG (al menos 7 días antes de la expiración) y sobre la correspondencia DS/DNSKEY. Integra la verificación DNSSEC en tu pipeline de renovación ACME, antes de la solicitud de certificado.

Plan de acción: preparar tu infraestructura

1. Verificar el estado DNSSEC de todos tus dominios con el DNSSEC Checker de CaptainDNS
2. Corregir las cadenas rotas: DS record faltante, firma expirada, algoritmo incompatible
3. Auditar los certificados activos: listar los dominios DNSSEC con certificados a renovar en los próximos 90 días
4. Configurar el monitoring: alertas sobre expiración de RRSIG y expiración de certificado
5. Probar la renovación: lanzar un dry-run ACME en los dominios DNSSEC
6. Documentar: añadir la verificación DNSSEC a tu runbook de renovación

FAQ

El Ballot SC-085v2 hace obligatorio DNSSEC para obtener un certificado TLS?

No. SC-085v2 obliga a las CA a validar DNSSEC cuando está presente, pero no hace obligatorio DNSSEC. Si tu dominio no publica un DS record en el TLD, la CA procede con la DCV clásica sin validación DNSSEC. Puedes obtener un certificado TLS sin DNSSEC, exactamente como antes.

Qué ocurre si mi DNSSEC está roto durante la renovación automática?

La renovación falla. La CA devuelve un error de tipo dns_sec_validation_error (en DigiCert) o un SERVFAIL. El cliente ACME no puede completar la validación DNS-01 y el certificado no se renueva. Si el problema persiste hasta la expiración del certificado actual, tu sitio deja de ser accesible por HTTPS. Por eso un monitoring DNSSEC con alertas es indispensable.

Qué CA están afectadas por SC-085v2?

Todas las CA públicamente aprobadas (es decir, cuyo certificado raíz está incluido en los almacenes de confianza de los navegadores). Esto incluye DigiCert, Sectigo, Let's Encrypt, GlobalSign, Entrust, HARICA, SwissSign y todas las demás CA conformes con los Baseline Requirements del CA/Browser Forum. Las CA privadas (internas de una organización) no están afectadas.

Let's Encrypt ya validaba DNSSEC?

Let's Encrypt ya utilizaba resolvers validantes DNSSEC (Unbound) en su infraestructura. En la práctica, un dominio con DNSSEC BOGUS ya podía fallar la validación en Let's Encrypt. SC-085v2 formaliza este requisito en los Baseline Requirements y lo extiende a todas las CA, no solo a las que habían elegido validar DNSSEC.

Cuál es la diferencia entre MPIC (SC-067) y SC-085v2?

MPIC (SC-067) protege la DCV a nivel de red verificando desde varios puntos geográficos. Detecta ataques BGP localizados. SC-085v2 protege la DCV a nivel DNS verificando las firmas DNSSEC. Detecta respuestas DNS falsificadas. Los dos son complementarios: MPIC cubre el vector BGP, DNSSEC cubre el vector DNS.

Se revocará mi certificado actual si DNSSEC se rompe después de la emisión?

No. SC-085v2 se aplica únicamente a la validación en el momento de la emisión. Un certificado ya emitido sigue siendo válido hasta su expiración, incluso si DNSSEC se rompe después de la emisión. En cambio, la próxima renovación fallará mientras DNSSEC esté en estado BOGUS.

Cómo saber si mi dominio publica DNSSEC?

Ejecuta dig DS captaindns.com +short (sustitúyelo por tu dominio). Si el comando devuelve uno o varios registros DS, tu dominio publica DNSSEC. Si la respuesta está vacía, DNSSEC no está activado. También puedes usar el DNSSEC Checker de CaptainDNS para un diagnóstico completo que incluye la validación de la cadena de confianza.

SC-085v2 afecta a los certificados wildcard?

Sí. Los certificados wildcard se validan mediante DNS-01 (el único método ACME compatible con wildcard). La CA consulta el DNS para verificar el TXT _acme-challenge y aplica la validación DNSSEC a esa consulta. Si DNSSEC está en estado BOGUS para tu dominio, el certificado wildcard no se emitirá.

Cuál es la relación con el Ballot SC-081 sobre la reducción de duración de los certificados?

SC-081 reduce la duración máxima de los certificados TLS (200 días en 2026, 100 días en 2027, 47 días en 2029). Certificados más cortos implican renovaciones más frecuentes. Cada renovación desencadena una DCV, y cada DCV incluye ahora la validación DNSSEC (SC-085v2). Un DNSSEC roto bloquea por tanto más a menudo la renovación, con menos margen antes de la expiración.

Debo activar DNSSEC para beneficiarme de la protección de SC-085v2?

Sí. SC-085v2 protege únicamente los dominios que publican DNSSEC. Sin DNSSEC, la CA no puede verificar la autenticidad de las respuestas DNS y la DCV sigue siendo vulnerable al spoofing. Activar DNSSEC en tu dominio es la única forma de beneficiarte de esta protección reforzada durante la emisión de certificados.

Glosario

• CA (Certificate Authority): autoridad de certificación habilitada para emitir certificados TLS. Las CA públicas están incluidas en los almacenes de confianza de los navegadores y están sujetas a los Baseline Requirements del CA/Browser Forum.
• DCV (Domain Control Validation): proceso por el cual una CA verifica que el solicitante de un certificado controla efectivamente el dominio. Métodos habituales: DNS-01, HTTP-01, email.
• CA/Browser Forum: consorcio que agrupa a las CA y los editores de navegadores. Define los Baseline Requirements, el marco normativo que todas las CA públicas deben cumplir.
• MPIC (Multi-Perspective Issuance Corroboration): mecanismo impuesto por el Ballot SC-067, que obliga a las CA a validar la DCV desde al menos dos perspectivas de red geográficamente distantes para contrarrestar el BGP hijacking.
• BOGUS: estado interno del resolver DNSSEC cuando la validación criptográfica falla. Un dominio BOGUS provoca un SERVFAIL para el cliente. Tras SC-085v2, un dominio BOGUS también bloquea la emisión de certificados.
• ACME (Automatic Certificate Management Environment): protocolo estandarizado (RFC 8555) para la automatización de la emisión y renovación de certificados TLS. Utilizado por Let's Encrypt, certbot, acme.sh y cert-manager.
• Baseline Requirements (BR): documento normativo del CA/Browser Forum que define los requisitos mínimos para la emisión de certificados TLS por las CA públicas. SC-085v2 modifica los BR para imponer la validación DNSSEC.

Fuentes

1. Ballot SC-085v2: Require Validation of DNSSEC for CAA and DCV Lookups (CA/Browser Forum)
2. Ballot SC-067v3: Require Multi-Perspective Issuance Corroboration (CA/Browser Forum)
3. DigiCert: Validating DNSSEC for Domain Control and CAA Checks
4. RFC 4035: Protocol Modifications for DNS Security Extensions (IETF)
5. DNSSEC Deployment Statistics (APNIC)