A registro TLSA asocia un servicio TLS con un certificado o datos de clave pública. no es un registro TXT, un sustituto de un registro MX o evidencia que cada remitente utiliza DANE. Para SMTP , el comportamiento relevante de descubrimiento y aplicación se define en RFC 7672 .
Comience con el nombre de host del servicio MX
Referencias: RFC 7672 §2.2, RFC 7672 §3.1.1, RFC 6698 §2.1.
Para un servicio en el puerto TCP 25 en mx.example.com, el propietario de TLSA convencional es _25._tcp.mx.example.com. Derive el nombre del nombre de host de intercambio SMTP real, no automáticamente del vértice visible del dominio o de la zona. Verifique cada punto final MX que la implementación pretende proteger y el DNSSEC estado a lo largo del camino de descubrimiento.
Los campos de datos de TLSA son uso de certificado, selector, tipo coincidente y datos de asociación. Para esta ruta sencilla sin alias, el propietario que se muestra es suficiente; Los alias requieren el manejo del dominio base TLSA autenticado en RFC 7672 §2.2. Un perfil SMTP DANE comúnmente recomendado es 3 1 1: Uso de DANE-EE, selección de SubjectPublicKeyInfo y coincidencia SHA-256. Estos números son opciones de protocolo significativas, no un prefijo genérico para un texto de certificado arbitrario. RFC 7672 y RFC 7671 describen usos admitidos y consideraciones operativas; Mantenga las combinaciones no admitidas fuera de una receta de implementación.
Derivar los bytes exactos
Referencias: RFC 6698 §2.1.2, RFC 6698 §2.1.3.
Para un archivo de certificado PEM local certificado.pem, en un shell Bash primero habilite set -o error de tubería; Luego se crea una canalización de resumen SPKI reproducible. openssl x509 -in cert.pem -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256. Exija cada etapa para tener éxito. Hash la representación de la clave pública DER, no el texto PEM, la huella digital mostrada o el certificado completo cuando se utiliza el selector 1.
Construir _25._tcp.mx.example.com. 300 IN TLSA 3 1 1 HEXDIGEST, reemplazando HEXDIGEST con el resumen real. Esta es una plantilla, no un registro publicable. Obtenga el certificado presentado por el punto final SMTP previsto a través de un control STARTTLS inspección y comparar sus bytes seleccionados. Un archivo local puede diferir del certificado que realmente sirve el servidor.
Pruebe un cambio clave antes de retirar la antigua asociación
Referencias: RFC 7672 §4, RFC 7671 §8.
El dispositivo sintético A utiliza un certificado de prueba con la clave A y una asociación TLSA derivada de A. La comparación de bytes esperada es una coincidencia. El dispositivo B entrega un certificado con la clave B conservando solo la asociación de A; La comparación esperada no coincide. El Accesorio C publica ambas asociaciones aceptables para una transición planificada y verifica el punto final previsto con respecto a B antes de retirar A.
El tiempo debe tener en cuenta los datos TLSA almacenados en caché y todas las instancias de servidor activas. Un certificado renovado con la misma clave pública puede conservar la misma 3 1 1 asociación, mientras que una nueva clave la cambia. Una comparación de resumen exitosa es una verificación criptográfica local, no un resultado de interoperabilidad SMTP DANE . Las pruebas DNSSEC y SMTP en vivo siguen siendo requisitos de evidencia separados.
Verifique el transporte en lugar de una etiqueta en el tablero
Referencias: RFC 7672 §2.2, RFC 7672 §3.
Utilice una ruta de validación de DNSSEC para establecer datos TLSA utilizables y luego pruebe el protocolo de enlace SMTP real y la asociación con una implementación compatible con DANE. Conserve las respuestas DNS , el seguimiento de validación, la cadena de certificados, la asociación seleccionada y el resultado del remitente. Un remitente de apoyo no debe tratar silenciosamente una autenticación DANE requerida fallida como una entrega segura exitosa. No reclame protección de transporte universal: la asistencia del remitente y el resultado exacto del descubrimiento autenticado son importantes.
Comprobaciones de asociación y descubrimiento observadas.
Referencias: RFC 4035 §5.
El dispositivo firmado retenido el 7 de noviembre de 2026, inspeccionado pero no vuelto a ejecutar para esta revisión, valida un TLSA RRset a través de un padre anclado, un DS autenticado y una DNSKEY secundaria. Un servicio TLS de bucle invertido separado en realidad presentó el certificado de prueba A y luego B. La extracción de SPKI de cada certificado de protocolo de enlace recibido produjo una coincidencia para A contra A, una discrepancia para B contra A solo, una coincidencia para B durante una superposición A/B y una coincidencia para B después de retirar A. La transcripción registra marcas de tiempo, puntos finales de bucle invertido, protocolo TLS y resúmenes. Esto valida los ingredientes criptográficos separados; el servicio era TLS normal, no SMTP STARTTLS , y no se reclama ningún cliente de correo DANE integrado ni prueba de resolución DNS en vivo.