Resumen

  • El RFC 6844 permitió que el titular de un dominio indicara qué autoridades de certificación podían emitir para ese nombre. Su primera regla de búsqueda podía seguir un CNAME o DNAME y luego subir por los padres del destino; así, la política CAA de un proveedor podía entrar en la búsqueda de un cliente.
  • El RFC 8659 mantuvo la resolución DNS normal de alias, pero limitó la subida por etiquetas parentales al FQDN que se está comprobando. La corrección separó con más claridad la política del cliente del árbol DNS del proveedor.

La respuesta DNS no es la última pregunta

Imaginemos www.client.example como un CNAME de tenant.platform.example. El nombre del cliente llega al espacio de nombres de un servicio compartido. Antes de emitir un certificado, una autoridad debe responder otra pregunta: ¿qué conjunto CAA rige www.client.example?

La dificultad aparece cuando la consulta cruza una frontera. El cliente administra un árbol DNS y el proveedor administra otro. El resolvedor puede seguir el alias de uno al otro en un instante. ¿Debe la autoridad subir también por los nombres parentales del proveedor para aplicar una regla que el cliente nunca publicó en su propia zona?

En enero de 2013, el RFC 6844 definió el registro DNS Certification Authority Authorization, tipo 257. El titular de un dominio podía nombrar una o varias autoridades autorizadas a emitir para ese nombre. Antes de emitir, una autoridad que cumpliera el estándar debía comprobar el conjunto CAA pertinente y rechazar una solicitud incompatible, salvo que una excepción de su política de certificación o de prácticas resultara aplicable.

CAA colocó una instrucción en el DNS, donde el titular ya publicaba los demás datos de su nombre. La autoridad obtuvo una política que debía consultar antes de emitir. Pero su alcance dependía de qué significaba «pertinente» cuando la búsqueda recorría nombres DNS.

En 2013, la búsqueda podía recorrer dos árboles

La regla del RFC 6844 no solo subía desde el nombre consultado hasta sus padres. Si una consulta CAA no encontraba un registro en una etiqueta y allí había un alias CNAME o DNAME, el procedimiento podía seguir el destino y repetir la búsqueda. Si tampoco encontraba una política, subía al padre del nombre original.

Los nombres hipotéticos muestran el efecto. Supongamos que www.client.example apunta a tenant.platform.example y el proveedor publica CAA 0 issue "issuer.example" en platform.example. La regla recursiva del RFC 6844 podía seguir el alias, subir hasta platform.example y encontrar esa política. Un registro escrito en la zona parental del proveedor podía entrar en la búsqueda de emisión para el nombre del cliente.

La regla buscaba el conjunto CAA aplicable; no transfería la titularidad del dominio del cliente. Aun así, la resolución y la herencia de políticas avanzaban juntas. El camino del cliente seguía el alias del proveedor y luego podía encontrar los padres del proveedor. En un servicio compartido, cada alias de cliente podía heredar una política colocada arriba en el árbol del anfitrión.

En 2019, la subida se quedó en el árbol solicitado

El RFC 8659, publicado en noviembre de 2019, sustituyó al RFC 6844 y modificó el algoritmo. La autoridad sigue consultando el CAA del FQDN solicitado mediante el comportamiento normal del DNS, que puede resolver alias. Si esa consulta no devuelve un conjunto CAA, el algoritmo sube por las etiquetas parentales del FQDN evaluado. Ya no sube por separado el árbol parental de cada destino CNAME o DNAME que encuentra.

La diferencia es precisa. Una consulta DNS todavía puede devolver un registro CAA situado exactamente en el destino de un alias. Lo que desaparece es la segunda subida independiente por los padres de ese destino. Una política publicada en el árbol del cliente puede seguir cubriendo sus subdominios; la política parental del proveedor ya no entra en la búsqueda del cliente solo porque un CNAME llegue a su espacio de nombres.

El RFC 8659 explica el motivo al comparar ambos textos: subir por el árbol del nombre y por cada árbol de alias era ineficiente ante cadenas largas y podía dificultar que un proveedor fijara políticas para sus propios FQDN sin imponer políticas potencialmente no deseadas a sus clientes. La revisión acotó la pregunta: ¿qué conjunto CAA corresponde a este nombre, con la resolución DNS ordinaria, y qué dicen sus propios padres?

Una decisión de emisión, no una prueba para el navegador

CAA interviene antes de emitir. No le pide al navegador que vuelva a juzgar un certificado ya expedido, y un cambio en el DNS no revoca un certificado existente. El estándar dice que las partes que confían en un certificado no deben usar el CAA actual para validarlo. El registro expresa la autorización vigente al emitir; importa el momento.

El registro tampoco autentica por sí solo la respuesta DNS. El RFC 8659 recomienda encarecidamente DNSSEC para CAA, pero no lo exige. Si una consulta queda bloqueada, la respuesta llega mal formada o se interpreta mal una respuesta vacía, la autoridad todavía no tiene una respuesta de política fiable. El apartado de despliegue del RFC enumera estos problemas porque la regla solo sirve si el emisor puede obtenerla y entenderla.

CAA también tiene varias propiedades. issue cubre certificados ordinarios; issuewild rige solicitudes wildcard cuando aparece. Un valor vacío de emisor puede pedir que ninguna autoridad emita para el nombre. Esas etiquetas describen el contenido de la política. La revisión de 2019 delimita el árbol en el que hay que buscarla.

Ese es el cambio histórico: el primer estándar CAA dio al titular de un dominio un lugar en el DNS para nombrar a sus emisores; su sucesor separó mejor ese árbol del de un proveedor de alojamiento. El DNS sigue resolviendo alias. La búsqueda de autorización ya no trata a todos los padres de cada destino como padres del nombre del cliente.

Los nombres de este ejemplo se construyen a partir de los algoritmos; no describen un incidente. Los RFC establecen la regla prevista. Para medir cómo la aplicó cada autoridad harían falta sus registros de consultas y decisiones de emisión asociados a los nombres y las horas.

Fuentes