El primer campo de un registro TLSA.
Fuente: DNS-Based Authentication of Named Entities (DANE) Parameters (IANA), consultada el 2026-10-20. Licencia de los datos: CC0-1.0. TLSA Certificate Usages
Notas sobre entradas destacadas
PKIX-TA (0) exige una cadena hasta una CA pública y que esa CA coincida con el registro TLSA; el RFC 7672 lo desaconseja para SMTP.
Los usos 0 y 1 añaden una restricción de DNS a la validación habitual de la Web PKI. Para SMTP entre servidores de correo, el RFC 7672 §3.1.3 establece que los registros TLSA no deberían (SHOULD NOT) usarlos: un atacante capaz de falsificar el DNS puede sustituirlos de todos modos, y los servidores de correo no comparten ninguna lista común de CA de confianza.
DANE-TA (2) fija en DNS un ancla de confianza, normalmente la CA emisora.
Con el uso 2, la cadena del servidor debe llevar hasta el certificado o la clave del registro TLSA, que no tiene por qué ser una CA pública. El RFC 7672 §3.1.2 exige que el servidor envíe el ancla de confianza en su cadena cuando el registro coincide con una clave y no con un certificado completo.
DANE-EE (3) fija en DNS el propio certificado o la propia clave del servidor; no se comprueban los nombres ni la caducidad del certificado.
Con el uso 3, el registro TLSA por sí solo vincula la clave al nombre: el RFC 7672 §3.1.1 establece que el servidor queda autenticado aunque ningún nombre del certificado coincida y que la fecha de caducidad del certificado debe (MUST) ignorarse. El registro habitual «3 1 1» (DANE-EE, SPKI, SHA-256) sobrevive a las renovaciones del certificado mientras la clave siga siendo la misma.