Registros DNS CAA: la guía completa para controlar quién emite tus certificados
Por CaptainDNS
Publicado el 9 de junio de 2026
- Un registro DNS CAA declara qué autoridades de certificación tienen derecho a emitir un certificado TLS para tu dominio. Sin CAA, cualquier CA pública puede hacerlo.
- La sintaxis se reduce a tres campos:
flag tag value. Los tags útiles sonissue(certificados clásicos),issuewild(wildcards) eiodef(notificación de intentos no autorizados). - La CA verifica el CAA en el momento de la emisión ascendiendo por el DNS del subdominio hacia el apex (tree climbing), y se detiene en el primer registro encontrado (RFC 8659).
- La RFC 8657 añade
accounturiyvalidationmethodspara fijar la emisión a una cuenta ACME concreta y a métodos de validación autorizados. - Una configuración CAA mal planteada (issuewild olvidado, punto y coma mal entendido, CA ausente) puede bloquear tus renovaciones ACME automáticas.
El modelo de confianza de los certificados TLS se apoya en un centenar de autoridades de certificación (CA) reconocidas por los navegadores. El problema es estructural: por defecto, cualquiera de estas CA puede emitir un certificado válido para tu dominio, sin tu consentimiento y sin siquiera informarte. Un atacante que consiga engañar a una sola CA, o una CA que se equivoque, puede producir un certificado perfectamente reconocido para captaindns.com.
El registro DNS CAA (Certificate Authority Authorization), definido por la RFC 8659, cierra una parte de esa puerta. Actúa como una lista blanca publicada en tu zona DNS: antes de emitir un certificado, una CA conforme debe consultar el DNS y comprobar que figura realmente en tus registros CAA. Si no aparece, se niega a emitir. Es una barrera a la emisión, no una detección posterior.
Esta guía está dirigida a administradores de sistemas, equipos DevOps y SRE, y responsables de seguridad. Cubre el modelo de amenaza, la sintaxis completa de un registro CAA (tags issue, issuewild, iodef, flag crítico), el mecanismo exacto de validación por ascenso del árbol, los parámetros avanzados de la RFC 8657 para el ecosistema ACME, la configuración concreta en los principales proveedores y los errores que rompen las renovaciones automáticas.
¿Tus registros CAA y DNSSEC están correctamente configurados?
El problema: cualquier CA puede emitir un certificado
Cuando tu navegador abre una conexión HTTPS, comprueba que el certificado presentado esté firmado por una autoridad de certificación presente en su almacén de confianza. Ese almacén contiene un centenar de CA raíz, gestionadas por organizaciones muy diversas, repartidas en numerosos países.
Una confianza horizontal y sin compartimentación
El defecto de diseño es sencillo de enunciar: la confianza es horizontal. El navegador confía en todas las CA de su almacén de manera equivalente. Nada, en el protocolo de base, restringe una CA determinada a un subconjunto de dominios. En concreto, una CA situada al otro lado del mundo, que nunca has utilizado, está técnicamente habilitada para emitir un certificado reconocido para tu dominio.
Mientras todas las CA funcionen perfectamente, este modelo se sostiene. Pero basta con que una sola falle, por error operativo o por compromiso, para que se produzca un certificado fraudulento y sea aceptado por todos los navegadores.
Incidentes muy reales
La historia de los certificados TLS está jalonada de incidentes de emisión incorrecta (mis-issuance):
- DigiNotar (2011): esta CA neerlandesa fue comprometida. Los atacantes emitieron más de 500 certificados fraudulentos, entre ellos un wildcard para
*.google.com, utilizado para interceptar el tráfico de ciudadanos iraníes. DigiNotar perdió la confianza de los navegadores y quebró. - Symantec (2015 a 2017): una serie de emisiones no conformes, incluidos certificados de prueba para dominios de terceros emitidos sin autorización, llevó a Google y Mozilla a programar la revocación de la confianza concedida a la antigua infraestructura Symantec. La actividad de CA se cedió a DigiCert.
- Secuestros BGP: varios ataques combinaron el secuestro de rutas de red y la validación de dominio para obtener certificados fraudulentos. El caso MyEtherWallet (2018) vio cómo unos atacantes desviaban el tráfico DNS para obtener un certificado y robar fondos.
Estos incidentes comparten un punto en común: se emitió un certificado técnicamente válido para un dominio sin el consentimiento de su propietario. La investigación académica ha confirmado que este riesgo no es anecdótico. El estudio "Bamboozling Certificate Authorities with BGP" (USENIX Security 2018) demostró que un atacante podía obtener certificados fraudulentos en las mayores CA desviando las consultas de validación de dominio mediante BGP, con una tasa de éxito elevada.
La lección es que un solo fallo en cualquiera de las CA de confianza basta para comprometer cualquier dominio. Es precisamente la magnitud de esta superficie de ataque lo que el CAA viene a reducir, al limitar la lista de CA habilitadas para emitir para un dominio dado.
La detección no basta
La Certificate Transparency (CT) impone desde 2018 que todo certificado público quede registrado en repositorios públicos y verificables. Es un avance importante: un propietario de dominio puede vigilar esos logs y detectar un certificado emitido sin su conocimiento.
Pero la Certificate Transparency es un mecanismo de detección posterior. En el momento en que detectas un certificado fraudulento en un log, ya ha sido emitido y puede haberse usado ya. El CAA aborda el problema de antemano: impide la emisión en lugar de constatarla a posteriori. Ambos mecanismos son complementarios, como detallamos más adelante.
¿Qué es un registro CAA?
Un registro DNS CAA (Certificate Authority Authorization, RFC 8659) indica qué autoridades de certificación están autorizadas a emitir certificados TLS para un dominio. Antes de cada emisión, la CA consulta el DNS del dominio y se niega a emitir si no figura en la lista publicada. Es una autorización previa, controlada por el propietario del dominio a través de su zona DNS.
Un tipo de registro DNS dedicado
El CAA es un tipo de registro DNS por derecho propio, el tipo 257. Se publica en tu zona exactamente igual que un registro A, MX o TXT. Puedes colocarlo en el apex de la zona (captaindns.com) o en un subdominio concreto (api.captaindns.com).
Aquí tienes un ejemplo mínimo que solo autoriza a Let's Encrypt a emitir certificados para el dominio:
captaindns.com. IN CAA 0 issue "letsencrypt.org"
Este registro declara una sola cosa: la única CA autorizada a emitir un certificado para captaindns.com es Let's Encrypt, identificada por su dominio letsencrypt.org. Cualquier otra CA conforme que reciba una solicitud para este dominio la rechazará.
Un punto esencial sobre la semántica: la presencia de un solo registro issue transforma la política implícita. Sin CAA, todas las CA están autorizadas por defecto. En cuanto existe un issue, el valor por defecto se invierte: solo las CA listadas explícitamente están autorizadas, y todas las demás quedan implícitamente prohibidas. Añadir una CA a tu política consiste, por tanto, en publicar un registro issue adicional; olvidar una equivale a bloquearla.
Una historia en dos RFC
El CAA fue definido primero por la RFC 6844 en 2013. Esta primera versión incluía un mecanismo de ascenso del árbol (tree climbing) considerado ambiguo, sobre todo en la gestión de errores y de los alias CNAME/DNAME.
La RFC 8659, publicada en 2019, sustituye a la RFC 6844 y constituye la referencia actual. Aclara el algoritmo de ascenso y corrige las zonas grises de la primera versión. Una RFC complementaria, la RFC 8657 (2019), añade dos parámetros orientados a ACME: accounturi y validationmethods. Tratamos estos parámetros en una sección dedicada.
Una barrera, no una garantía absoluta
El CAA se apoya en la cooperación de las CA. Todas las CA reconocidas públicamente, sujetas a los Baseline Requirements del CA/Browser Forum, están obligadas a verificar el CAA antes de emitir. Es una exigencia del referencial, no una opción. En la práctica, las CA principales aplican esta verificación.
El CAA, por tanto, no protege contra una CA deshonesta que decida ignorar deliberadamente tus registros, ni contra una CA privada interna de una organización. Pero eleva considerablemente la barrera: para emitir un certificado fraudulento a pesar de un CAA bien configurado, un atacante tendría que comprometer la CA que has autorizado explícitamente, o falsificar tus respuestas DNS en el momento del control. Este último punto nos lleva a la relación entre CAA y DNSSEC, que abordamos más adelante.
Anatomía de un registro CAA
Un registro CAA se compone de tres campos, siempre en el mismo orden. Dominar esta sintaxis es indispensable para no equivocarse de configuración.
La estructura flag tag value
Cada registro CAA se compone de tres elementos:
| Campo | Función | Valores |
|---|---|---|
flag | Entero de control | 0 (no crítico) o 128 (crítico) |
tag | Propiedad afectada | issue, issuewild o iodef |
value | Valor de la propiedad | Identificador de la CA, o URL de notificación |
Leído de izquierda a derecha, el registro 0 issue "letsencrypt.org" se traduce como: flag no crítico, propiedad issue, valor letsencrypt.org. El valor siempre va entre comillas rectas en la representación textual.
El tag issue: autorizar una CA para los certificados clásicos
El tag issue autoriza a una CA a emitir certificados no wildcard para el dominio. El valor es el identificador de la CA, generalmente un nombre de dominio.
captaindns.com. IN CAA 0 issue "letsencrypt.org"
captaindns.com. IN CAA 0 issue "digicert.com"
Este ejemplo autoriza dos CA: Let's Encrypt y DigiCert. Cuando coexisten varios registros issue, se suman: toda CA listada está autorizada. Es una lista blanca acumulativa.
Un caso particular merece atención: el valor ";" (un simple punto y coma). Prohíbe toda emisión.
captaindns.com. IN CAA 0 issue ";"
Este registro declara que ninguna CA está autorizada a emitir certificados clásicos para el dominio. Es útil para un dominio que nunca debe llevar un certificado (un dominio de parking, por ejemplo), pero también es una fuente frecuente de errores cuando se coloca por descuido.
El tag issuewild: el caso de los wildcards
El tag issuewild controla específicamente la emisión de los certificados wildcard (del tipo *.captaindns.com). Su sintaxis es idéntica a la de issue.
La regla de prioridad es esencial: issuewild prevalece sobre issue para los certificados wildcard. Si hay un registro issuewild presente, es este el que cuenta para las solicitudes wildcard, y los registros issue se ignoran en ese caso. Si no hay ningún issuewild, los certificados wildcard recaen en las reglas issue.
captaindns.com. IN CAA 0 issue "letsencrypt.org"
captaindns.com. IN CAA 0 issuewild "digicert.com"
En este ejemplo, los certificados clásicos solo puede emitirlos Let's Encrypt, mientras que los certificados wildcard solo puede emitirlos DigiCert. Para prohibir lisa y llanamente cualquier certificado wildcard, se utiliza el punto y coma:
captaindns.com. IN CAA 0 issuewild ";"
Esto bloquea toda emisión de wildcard a la vez que deja que los certificados clásicos sigan las reglas issue.
El tag iodef: notificar los intentos no autorizados
El tag iodef (Incident Object Description Exchange Format) indica dónde debe notificar una CA una solicitud de certificado que viole tu política CAA. El valor es una URL, ya sea un correo en formato mailto: o una URL HTTPS.
captaindns.com. IN CAA 0 iodef "mailto:security@captaindns.com"
captaindns.com. IN CAA 0 iodef "https://captaindns.com/caa-report"
Cuando una CA recibe una solicitud que rechaza a causa de tu CAA, puede enviar un informe a la dirección iodef. Es una señal valiosa: un intento de emisión no autorizado puede indicar un ataque en curso o un servicio interno mal configurado. El soporte de iodef varía según las CA; hay que considerarlo un extra de visibilidad, no una garantía de notificación.
En la práctica, un informe iodef merece una investigación inmediata. O bien uno de tus servicios intenta emitir un certificado a través de una CA que has olvidado autorizar (problema de configuración), o bien un actor externo intenta obtener un certificado para tu dominio (problema de seguridad). En ambos casos, el iodef te da una visibilidad que ni la Certificate Transparency ni los logs de tu infraestructura proporcionan, porque capta el intento en el momento preciso del rechazo.
El flag crítico: 0 frente a 128
El primer campo, el flag, es un octeto del que solo el bit de mayor peso (valor 128, es decir 0x80) tiene un significado definido: es el flag crítico (issuer critical).
- Flag 0: registro no crítico. Si una CA no entiende el tag, lo ignora y continúa.
- Flag 128: registro crítico. Si una CA encuentra un tag que no entiende con este flag activado, debe negarse a emitir.
El flag crítico sirve para protegerse contra la introducción futura de tags que las CA antiguas no sabrían interpretar. Al colocar el flag 128 sobre un tag, exiges que toda CA que no lo entienda se abstenga, por seguridad, en lugar de ignorarlo. En la inmensa mayoría de las configuraciones, el flag permanece en 0: los tags issue, issuewild e iodef son universalmente comprendidos.
Los identificadores de las CA habituales
El valor de un tag issue o issuewild es el identificador de la CA, definido por cada autoridad en su documentación. Aquí tienes los identificadores de las principales CA:
| Autoridad de certificación | Identificador CAA |
|---|---|
| Let's Encrypt | letsencrypt.org |
| DigiCert | digicert.com |
| Sectigo | sectigo.com |
| GlobalSign | globalsign.com |
| Google Trust Services | pki.goog |
| Amazon (AWS Certificate Manager) | amazon.com (y amazontrust.com, amazonaws.com, awstrust.com) |
Utiliza siempre el identificador exacto publicado por la CA, y no una aproximación. Un valor incorrecto equivale a no autorizar la CA, y el certificado será rechazado. En caso de duda sobre el identificador de una CA que no aparezca aquí, consulta su documentación oficial en lugar de adivinarlo.
Cómo funciona la validación CAA
La fuerza del CAA reside en su mecanismo de validación en el momento de la emisión. Comprender este mecanismo evita la mayoría de los errores de configuración.
El ascenso del árbol (tree climbing)
Cuando una CA procesa una solicitud de certificado para un nombre dado, no se limita a mirar el CAA de ese nombre concreto. Asciende por la jerarquía DNS, etiqueta por etiqueta, desde el nombre solicitado hacia el apex de la zona, hasta encontrar un conjunto de registros CAA. Es el tree climbing, definido en la sección 3 de la RFC 8659.
Tomemos una solicitud para api.captaindns.com. La CA procede así:
- Consulta el CAA de
api.captaindns.com. Si hay un conjunto CAA publicado, lo utiliza y se detiene. - Si no, asciende un nivel y consulta
captaindns.com. Si hay un conjunto CAA publicado, lo utiliza y se detiene. - El ascenso continúa hasta encontrar un conjunto CAA, o hasta alcanzar la raíz sin encontrar nada.
El punto clave: la CA se detiene en el primer nombre que tenga registros CAA. Los registros de los niveles superiores ya no se consultan.
La herencia y sus consecuencias
Esta mecánica tiene una consecuencia importante: un subdominio hereda la política CAA de su padre, pero solo si no define la suya propia.
Si publicas un CAA en el apex captaindns.com y nada en api.captaindns.com, entonces api.captaindns.com queda sometido a la política del apex. Pero en cuanto publicas un solo registro CAA en api.captaindns.com, la CA se detiene en ese nivel e ignora por completo el apex. La herencia es binaria: o el subdominio no tiene ningún CAA y hereda, o lo tiene y reemplaza íntegramente la política del padre. No hay fusión entre los dos niveles.
Es una fuente de error clásica: se añade un CAA específico en un subdominio para autorizar una CA adicional, sin darse cuenta de que ese registro reemplaza la política del apex en lugar de sumarse a ella. El subdominio debe entonces listar todas las CA que necesita, incluidas las ya autorizadas a nivel del padre.
La interacción con los wildcards
El caso de los certificados wildcard combina dos reglas. Primero, la prioridad de issuewild sobre issue vista más arriba. Después, el ascenso del árbol. Para una solicitud de *.captaindns.com, la CA busca primero un conjunto CAA ascendiendo por el árbol, y luego aplica dentro de ese conjunto la prioridad issuewild. Si el conjunto encontrado contiene un issuewild, este cuenta para el wildcard; si no, el wildcard recae en los issue del mismo conjunto.
El caso de los alias CNAME
Cuando el nombre procesado para la validación CAA apunta a un alias CNAME, la búsqueda CAA sigue ese alias. La RFC 8659 precisa que, si un nombre es un alias CNAME, la búsqueda CAA continúa sobre el destino del alias. Es un detalle que a veces sorprende: un subdominio en CNAME hacia un servicio de terceros puede, según la configuración, depender del CAA del destino en lugar del de tu zona. Cuando delegas un subdominio a un proveedor externo mediante CNAME, comprueba qué política CAA se aplica realmente.
Lo que la CA verifica realmente en la emisión
En el momento de emitir, una CA conforme a los Baseline Requirements realiza el control CAA dentro de una ventana temporal limitada (como máximo 8 horas antes de la emisión, según el referencial). Pasado ese plazo, el control debe rehacerse. Esta restricción evita que una autorización obtenida mucho tiempo antes siga siendo válida después de que hayas retirado una CA de tu política.
La CA también debe, desde el despliegue de la validación multiperspectiva (MPIC, Ballot SC-067), realizar el control CAA y la validación de dominio desde varios puntos de presencia de red geográficamente distintos. El objetivo es contrarrestar los secuestros BGP localizados: si un atacante desvía el tráfico en una región para falsificar la respuesta CAA, las demás perspectivas recibirán la respuesta legítima y la CA detectará la incoherencia. MPIC protege, por tanto, el control CAA a nivel de red, mientras que DNSSEC lo protege a nivel del protocolo DNS. Ambos mecanismos se refuerzan mutuamente.
En concreto, la secuencia de emisión se parece a esto: la CA recibe la solicitud, valida el control de dominio (DNS-01, HTTP-01 o TLS-ALPN-01), consulta el CAA ascendiendo por el árbol, confirma que figura en la lista autorizada, y luego emite. Si el CAA la rechaza, la emisión se detiene de inmediato y, si hay un iodef presente, puede enviarse un informe.
La relación con DNSSEC
El control CAA se apoya en respuestas DNS. Si un atacante puede falsificar tus respuestas DNS en el momento en que la CA consulta el CAA, puede engañar el control. DNSSEC responde a este riesgo autenticando criptográficamente las respuestas DNS.
El CA/Browser Forum ha formalizado esta relación con el Ballot SC-085v2, en vigor desde el 15 de marzo de 2026, que obliga a las CA a validar DNSSEC, cuando está presente, durante las consultas CAA y de validación de dominio. En concreto, si tu zona está firmada y la cadena de confianza está intacta, la CA obtiene la garantía de que los registros CAA que lee son auténticos. Hemos dedicado un artículo completo a este cambio normativo: las CA ahora verifican DNSSEC antes de emitir un certificado. Puedes comprobar el estado de firma de tu zona con nuestro verificador DNSSEC. Para activar DNSSEC en un dominio que aún no lo tiene, sigue nuestra guía de activación paso a paso.
Parámetros avanzados: la RFC 8657 y ACME
La RFC 8657 amplía el CAA con dos parámetros que se integran en el tag issue o issuewild. Son especialmente útiles en un ecosistema ACME automatizado.
accounturi: fijar una cuenta ACME
El parámetro accounturi restringe la emisión a una cuenta ACME concreta. En lugar de autorizar a cualquier cuenta de una CA dada a emitir para tu dominio, fijas la autorización al URI de una única cuenta ACME.
captaindns.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678"
Este registro autoriza a Let's Encrypt a emitir, pero únicamente para la cuenta ACME numerada 12345678. Una solicitud procedente de otra cuenta Let's Encrypt será rechazada. Es una protección fuerte: aunque un atacante use la misma CA que tú, no podrá emitir con su propia cuenta.
validationmethods: restringir los métodos de validación
El parámetro validationmethods limita los métodos de validación ACME autorizados para el dominio. Los valores corresponden a los tipos de desafío ACME: dns-01, http-01 y tls-alpn-01.
captaindns.com. IN CAA 0 issue "letsencrypt.org; validationmethods=dns-01"
Aquí, solo se acepta la validación por registro DNS (dns-01). Un intento de emisión mediante http-01 (colocación de un archivo en el servidor web) será rechazado. Esto endurece la configuración: si sabes que tus certificados siempre se validan por dns-01, prohibir los demás métodos reduce la superficie de ataque, por ejemplo un servidor web comprometido que intentara una validación http-01.
Los tres métodos de validación ACME tienen perfiles de riesgo distintos. El método dns-01 exige el control de la zona DNS y permite los certificados wildcard. El método http-01 exige el control del servidor web en el puerto 80. El método tls-alpn-01 valida mediante una extensión TLS en el puerto 443. Restringir validationmethods al único método que usas realmente impide que un atacante que solo controlara uno de esos vectores obtenga un certificado por una vía que no habías previsto.
Combinar los parámetros para un dominio reforzado
Los parámetros se acumulan en un mismo registro, separados por puntos y coma. Una configuración reforzada típica combina CA, cuenta y método:
captaindns.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678; validationmethods=dns-01"
Este registro solo autoriza a Let's Encrypt, únicamente a través de la cuenta ACME 12345678, y únicamente por el método dns-01. Es el nivel de control más fino que ofrece el CAA. Cuidado, no obstante: cuanto más estricta es la configuración, más probable es que un error (cambio de cuenta, migración de método de validación) bloquee una renovación. El soporte de la RFC 8657 depende también de la CA; Let's Encrypt lo implementa, pero comprueba la documentación de tu CA antes de desplegar accounturi o validationmethods.
Guía práctica: configurar CAA en tu proveedor
La sintaxis CAA es estándar, pero cada proveedor DNS expone una interfaz diferente. Algunos piden los tres campos por separado (flag, tag, value), otros una cadena completa. El tipo de registro es siempre CAA (tipo 257). Aquí tienes los pasos en los proveedores habituales.
Cloudflare
En el panel de control de Cloudflare, ve a DNS y luego a Records, y añade un registro de tipo CAA. La interfaz presenta tres campos distintos:
- Flags: deja 0 en la mayoría de los casos.
- Tag: elige
issue,issuewildoiodefen la lista desplegable. - CA domain name (o Value): introduce el identificador, por ejemplo
letsencrypt.org.
Cloudflare ofrece también una API y su herramienta de línea de comandos para automatizar la creación de registros CAA en una infraestructura como código. Ten en cuenta que Cloudflare a veces añade automáticamente registros CAA para sus propios certificados gestionados; comprueba la lista completa después de modificar para no sobrescribir una entrada necesaria para un servicio de Cloudflare.
AWS Route 53
En la consola de Route 53, selecciona tu zona alojada y crea un registro de tipo CAA. Route 53 espera el valor en formato completo, una línea por registro:
0 issue "amazon.com"
0 issue "letsencrypt.org"
Si tus certificados los gestiona AWS Certificate Manager (ACM), Amazon documenta varios identificadores aceptados: amazon.com, amazontrust.com, amazonaws.com y awstrust.com. Puedes autorizarlos todos para cubrir el conjunto de casos. Recuerda conservar las demás CA que necesites para los servicios fuera de AWS.
OVHcloud
En el área de cliente de OVHcloud, abre la zona DNS de tu dominio y añade una entrada. Selecciona el tipo CAA. OVHcloud suele pedir el flag, el tag y el destino (el valor) en campos distintos. Introduce 0 para el flag, el tag deseado y el identificador de la CA como destino. Valida y luego espera la propagación.
Gandi
En la interfaz de gestión DNS de Gandi (LiveDNS), añade un registro de tipo CAA. Gandi espera el valor en formato textual completo:
0 issue "letsencrypt.org"
Como en los demás proveedores, puedes añadir varias líneas CAA para autorizar varias CA, o para añadir issuewild e iodef. La validación de los certificados Gandi para los dominios alojados con ellos se apoya en las CA que utilizan; recuerda incluirlas si cuentas con sus certificados.
Verificar la propagación tras la configuración
Sea cual sea el proveedor, no des por terminada la configuración hasta que no hayas confirmado que el registro es visible públicamente. Consulta el DNS desde fuera de tu red y confirma que el CAA aparece con el flag, el tag y el valor esperados. Ten en cuenta el TTL: un registro modificado puede permanecer en caché durante la duración del TTL anterior. En un dominio firmado con DNSSEC, comprueba también que el nuevo registro CAA está correctamente firmado, ya que de lo contrario un resolvedor validante lo rechazará.
Configurar iodef para la notificación
Sea cual sea el proveedor, el tag iodef se configura como issue, pero su valor es una URL de notificación en lugar de un identificador de CA. Utiliza una dirección de correo supervisada por tu equipo de seguridad:
0 iodef "mailto:security@captaindns.com"
Comprueba que la dirección se consulta realmente. Un iodef que apunta a un buzón abandonado no sirve de nada.
Probar antes de bloquear
Una recomendación prudente: empieza por una política permisiva que liste todas tus CA realmente utilizadas, despliégala, comprueba que las renovaciones pasan y luego endurece progresivamente. Ten en cuenta el TTL de tus registros: un TTL elevado ralentiza la asimilación de un cambio de CA. Antes de una migración de CA, baja el TTL del CAA para acelerar la propagación.
Verificar y auditar tus registros CAA
Una vez desplegado el CAA, comprueba que está correctamente publicado y que refleja tu intención. Dos enfoques se complementan: la línea de comandos y las herramientas de auditoría.
Leer el CAA con dig
La herramienta dig consulta directamente el DNS. Para mostrar los registros CAA de un dominio:
dig CAA captaindns.com +short
La salida se parece a esto:
0 issue "letsencrypt.org"
0 issuewild "digicert.com"
0 iodef "mailto:security@captaindns.com"
Cada línea corresponde a un registro CAA, en el orden flag tag value. Si el comando no devuelve nada, el dominio no publica ningún CAA en ese nivel. No olvides el ascenso del árbol: un subdominio sin CAA hereda del apex. Para comprobar qué hereda realmente api.captaindns.com, consulta sucesivamente el subdominio y luego el apex.
Para ver el detalle completo, incluidos el TTL y la sección de autoridad, omite la opción +short:
dig CAA captaindns.com
Las herramientas de CaptainDNS
La línea de comandos muestra el registro en bruto, pero no dice si es coherente. CaptainDNS ofrece dos niveles de verificación.
El verificador CAA dedicado muestra tus registros y su interpretación, teniendo en cuenta la herencia por ascenso del árbol. Te indica con claridad qué CA está autorizada para los certificados clásicos y para los wildcards.
Para una visión más amplia, nuestra auditoría de seguridad y entregabilidad integra ahora el CAA en su puntuación. El pilar Seguridad DNS combina dos señales: DNSSEC, que pesa 80 puntos, y CAA, que pesa 20 puntos. Esta ponderación refleja su papel respectivo: DNSSEC autentica el conjunto de tus respuestas DNS, el CAA restringe específicamente la emisión de certificados. Un dominio que publica un CAA coherente gana esos 20 puntos y mejora su postura de seguridad global.
Lo que hay que verificar
Durante la auditoría, controla algunos puntos concretos:
- Coherencia issue e issuewild: ¿la CA que emite tus wildcards está realmente autorizada por un
issuewild, o cuentas con el repliegue haciaissue? - Ninguna CA huérfana: ¿cada CA que utilizas realmente (incluidas las de servicios de terceros, CDN, pasarelas de correo) figura en la lista?
- iodef accesible: ¿la dirección de notificación está supervisada?
- Ningún punto y coma involuntario: un
issue ";"colocado por error bloquearía toda emisión.
Errores frecuentes que hay que evitar
La mayoría de los incidentes relacionados con el CAA provienen de algunos errores recurrentes. Conocerlos permite anticiparlos.
Olvidar issuewild. Publicas un issue para Let's Encrypt y todo funciona, hasta el día en que solicitas un certificado wildcard. Si no hay ningún issuewild presente, el wildcard recae en issue, lo cual pasa. Pero si has colocado un issuewild para otra CA, o un issuewild ";", el wildcard será rechazado. Comprueba siempre la coherencia entre issue e issuewild.
Bloquear tu propia CA. El error más directo: olvidar listar la CA que utilizas realmente. Si tus certificados vienen de Let's Encrypt pero tu CAA solo autoriza a DigiCert, la próxima renovación fallará. Este error surge a menudo tras un cambio de CA o la incorporación de un nuevo servicio.
Romper la renovación ACME con una política demasiado estricta. Los parámetros accounturi y validationmethods son potentes pero rígidos. Si fijas una cuenta ACME y luego recreas esa cuenta (nuevo identificador), o si migras de http-01 a dns-01 sin actualizar el CAA, las renovaciones automáticas fallarán silenciosamente. En una infraestructura ACME automatizada, este tipo de fallo solo se ve al expirar el certificado.
Entender mal la herencia. Añadir un registro CAA en un subdominio no completa la política del apex, la reemplaza para ese subdominio. Un subdominio con su propio CAA debe listar todas las CA que necesita. Olvidar este punto lleva a autorizar una CA mientras se bloquea accidentalmente la del apex.
El punto y coma mal interpretado. issue ";" prohíbe toda emisión. Es algo deseado en un dominio que nunca debe llevar un certificado, pero es una trampa cuando se piensa que se trata de un separador o de un valor vacío. Relee cada registro después de introducirlo.
El flag equivocado. Colocar el flag crítico 128 sin entender su efecto puede bloquear CA que no reconozcan un tag. En la gran mayoría de los casos, el flag debe permanecer en 0. No pases a 128 a menos que tengas una razón concreta y entiendas qué CA se verán afectadas.
Creer que el CAA actúa a posteriori. El CAA es una barrera a la emisión, no un mecanismo de revocación. No revoca un certificado ya emitido y no actúa sobre los certificados existentes. Para vigilar los certificados ya producidos, es la Certificate Transparency la que cumple ese papel.
El CAA en el ecosistema de la seguridad DNS
El CAA no se basta a sí mismo. Se inscribe en un conjunto de mecanismos que protegen distintas etapas del ciclo de vida de un certificado. Confundirlos lleva a expectativas erróneas.
Cuatro mecanismos, cuatro funciones
| Mecanismo | Lo que protege | Momento de actuación |
|---|---|---|
| CAA | Qué CA puede emitir | Antes de la emisión |
| Certificate Transparency | Visibilidad de los certificados emitidos | Después de la emisión |
| DANE / TLSA | Qué certificado debe aceptar el cliente | En la conexión |
| DNSSEC | Autenticidad de las respuestas DNS | En cada resolución |
El CAA actúa de antemano: restringe quién puede producir un certificado. La Certificate Transparency actúa después: hace público y, por tanto, detectable todo certificado emitido. DANE (DNS-based Authentication of Named Entities) actúa del lado del cliente: publica en el DNS, mediante registros TLSA, la huella del certificado que el cliente debe esperar, lo que permite rechazar un certificado válido pero ilegítimo. DNSSEC sostiene el conjunto: sin respuestas DNS autenticadas, ni el CAA ni DANE son fiables.
Una defensa en profundidad
Estos mecanismos no compiten entre sí, se complementan. El CAA impide la emisión no autorizada. Si una emisión fraudulenta pasa a pesar de todo, la Certificate Transparency permite detectarla. DANE permite al cliente rechazar un certificado que no corresponda al que has publicado. Y DNSSEC garantiza que los registros CAA y TLSA leídos por las CA y los clientes son auténticos.
Para profundizar en la complementariedad entre CAA y DANE, consulta nuestra guía completa sobre DANE y TLSA. Para entender en detalle cómo DNSSEC autentica las respuestas DNS sobre las que se apoya todo el edificio, lee nuestro artículo sobre la cadena de confianza DNSSEC.
La estrategia recomendada es clara: publica un CAA coherente para restringir la emisión, firma tu zona con DNSSEC para autenticar tus respuestas, vigila la Certificate Transparency para detectar cualquier emisión inesperada, y despliega DANE si tu ecosistema lo permite (en particular para el correo con MTA-STS y DANE).
Plan de acción recomendado
- Inventaría tus CA reales: lista todas las autoridades que emiten certificados para tus dominios, incluidos los servicios de terceros (CDN, pasarelas de correo, plataformas cloud).
- Publica un CAA permisivo: declara primero todas tus CA mediante
issue, añadeissuewildsi utilizas wildcards, y uniodefhacia un buzón supervisado. - Comprueba la asimilación: controla con
dig CAAy confirma que tus renovaciones siguen pasando. - Endurece progresivamente: considera
accounturiyvalidationmethodsen los dominios críticos, tras comprobar el soporte de tu CA. - Firma tu zona con DNSSEC: para que el control CAA sea fiable y conforme a las exigencias SC-085v2.
- Vigila: integra la verificación CAA y DNSSEC en tu supervisión, y revisa los informes iodef.
FAQ
¿Qué es un registro CAA y para qué sirve?
Un registro DNS CAA (Certificate Authority Authorization, RFC 8659) declara qué autoridades de certificación están autorizadas a emitir certificados TLS para un dominio. Antes de cada emisión, una CA conforme consulta el DNS y se niega a emitir si no figura en la lista. El CAA reduce así el riesgo de emisión de certificados fraudulentos por una CA no autorizada.
¿Es obligatorio un registro CAA?
No. El CAA es opcional. Sin CAA, cualquier CA reconocida públicamente puede emitir un certificado para tu dominio. Publicarlo es una buena práctica de seguridad muy recomendable, porque restringe explícitamente la lista de CA autorizadas y limita la superficie de ataque vinculada a la emisión incorrecta.
¿Qué ocurre si no hay ningún registro CAA presente?
En ausencia de CAA, una CA considera que no se impone ninguna restricción y procede a la emisión tras sus controles habituales de validación de dominio. En concreto, cualquier CA pública puede entonces emitir un certificado para tu dominio. El CAA solo tiene efecto restrictivo si se publica explícitamente.
¿Cuál es la diferencia entre los tags issue e issuewild?
El tag issue autoriza a una CA a emitir certificados clásicos (no wildcard). El tag issuewild controla específicamente los certificados wildcard como *.captaindns.com. Si hay un issuewild presente, prevalece sobre issue para las solicitudes wildcard. Si está ausente, los wildcards recaen en las reglas issue.
¿Un registro CAA impide realmente la emisión de un certificado fraudulento?
Lo impide con fuerza, pero no de manera absoluta. El CAA se apoya en la cooperación de las CA, que están obligadas por los Baseline Requirements del CA/Browser Forum a verificarlo. No protege contra una CA que ignorara deliberadamente tus registros, ni contra una falsificación de tus respuestas DNS. Combinado con DNSSEC, que autentica esas respuestas, se vuelve mucho más sólido.
¿Cómo verificar un registro CAA con dig?
Utiliza el comando dig CAA captaindns.com +short sustituyendo por tu dominio. Muestra los registros CAA en el formato flag tag value, por ejemplo 0 issue "letsencrypt.org". Si el comando no devuelve nada, no hay ningún CAA publicado en ese nivel, pero el dominio puede heredar la política de un nombre padre por ascenso del árbol.
¿Cómo funciona la herencia CAA en los subdominios?
Durante una solicitud, la CA asciende por la jerarquía DNS del subdominio hacia el apex y se detiene en el primer nombre que tenga registros CAA (tree climbing, RFC 8659). Un subdominio sin CAA hereda, por tanto, la política de su padre. Pero en cuanto un subdominio publica su propio CAA, reemplaza íntegramente la política del padre para ese subdominio, sin fusión.
¿Hay que configurar CAA si ya uso DNSSEC?
Sí. DNSSEC y CAA responden a necesidades distintas. DNSSEC autentica la integridad de tus respuestas DNS, pero no restringe qué CA puede emitir un certificado. El CAA, por su parte, declara explícitamente las CA autorizadas. DNSSEC hace más fiable el control CAA (la CA lee registros auténticos), no lo reemplaza. Ambos son complementarios.
¿Qué norma define el registro CAA?
El registro CAA está definido por la RFC 8659 (2019), que sustituye a la RFC 6844 (2013). La RFC 8657 (2019) añade los parámetros accounturi y validationmethods para el ecosistema ACME. La verificación CAA por parte de las CA está además impuesta por los Baseline Requirements del CA/Browser Forum.
Descarga las tablas comparativas
Los asistentes pueden reutilizar las cifras accediendo a los archivos JSON o CSV.
Glosario
- CAA (Certificate Authority Authorization): tipo de registro DNS (tipo 257) que declara qué autoridades de certificación están autorizadas a emitir certificados para un dominio.
- CA (Certificate Authority): autoridad de certificación habilitada para emitir certificados TLS reconocidos por los navegadores.
- CA/Browser Forum: consorcio de las CA y los editores de navegadores que define los Baseline Requirements, el referencial que toda CA pública debe respetar, incluida la obligación de verificar el CAA.
- Tree climbing (ascenso del árbol): algoritmo por el cual una CA asciende por la jerarquía DNS del nombre solicitado hacia el apex para encontrar los registros CAA aplicables.
- issuewild: tag CAA específico de los certificados wildcard, prioritario sobre
issueen ese caso. - iodef: tag CAA que indica una URL (mailto o HTTPS) donde notificar los intentos de emisión no autorizados.
- ACME (Automatic Certificate Management Environment): protocolo (RFC 8555) de automatización de la emisión y la renovación de certificados, utilizado en particular por Let's Encrypt.
- Mis-issuance (emisión incorrecta): emisión de un certificado válido para un dominio sin el consentimiento de su propietario, por error o por compromiso de la CA.
Fuentes
- RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record (IETF)
- RFC 8657: Certification Authority Authorization (CAA) Record Extensions for Account URI and ACME Method Binding (IETF)
- CA/Browser Forum: Baseline Requirements
- Ballot SC-085v2: Require Validation of DNSSEC for CAA and DCV Lookups (CA/Browser Forum)
- Let's Encrypt: CAA (documentación oficial)
