Por qué usar un validador offline
Un registro TLSA mal formado es ignorado sin aviso por los MTA conformes. Crees que tu despliegue DANE protege tu flujo SMTP entrante; en la práctica, ningún servidor emisor verifica nada. La avería es silenciosa hasta la próxima auditoría, o hasta que un incidente de entrega revele la grieta.
El validador de sintaxis DANE TLSA analiza tu registro sin publicar ni consultar el DNS. Ningún dato sale de tu navegador, ninguna señal se filtra a un resolutor externo. Este enfoque offline cubre cuatro casos de uso que la auditoría en directo no puede tratar.
Casos de uso típicos:
- Antes del despliegue: validar un borrador antes de publicarlo en DNS, para evitar un registro silenciosamente ignorado.
- Salida de generador: verificar la sintaxis de un registro producido por una herramienta de terceros, un wiki interno o una plantilla compartida.
- Depuración offline: reproducir y corregir un error sin tocar el DNS público, por ejemplo en preproducción.
- Revisión de configuración: examinar un registro recibido de un partner o exportado desde una infraestructura cliente antes de aplicarlo.
El validador aplica la especificación RFC 6698 sobre la estructura y la RFC 7671 sobre las restricciones operativas. Ninguna consulta DNS, ninguna conexión externa.
Cómo usar este validador en 3 pasos
Paso 1: pegar el registro TLSA
Copia el valor de tu registro en el campo previsto:
3 1 1 2bb183af2e2b295b444c1fd4072f2b59a8c1c9abf7f3f1e9b0d4c7e8f1a2b3c4
También puedes pegar la línea completa con el owner name:
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 2bb183af...
El validador extrae los cuatro campos y analiza cada uno de forma independiente. En este paso no se realiza ninguna conexión de red.
Paso 2: leer el veredicto
Los resultados se clasifican por gravedad:
- Error: problema bloqueante, el registro será ignorado o rechazado por los MTA conformes
- Aviso: combinación no recomendada, funcional pero que expone a riesgos operativos
- Válido: sintaxis conforme a los RFC 6698 y 7671
Cada mensaje incluye el campo afectado, el valor inválido y la corrección esperada.
Paso 3: corregir antes de publicar
Ajusta tu registro según las recomendaciones. Una vez la sintaxis está limpia, publica el registro TLSA en _25._tcp.<host-mx> en la zona firmada con DNSSEC del host MX, espera la propagación y confírmalo en directo con el DANE TLSA Checker.
Validador o verificador: cuándo usar cada herramienta
Las dos herramientas son complementarias. Intervienen en momentos distintos del ciclo de vida de un registro TLSA.
| Dimensión | Validador (esta herramienta) | Verificador |
|---|---|---|
| Momento de uso | Antes de publicar en DNS | Después de publicar |
| Resolución DNS | Ninguna | Resolución _25._tcp.<mx> en directo |
| Verificación DNSSEC | No | Sí, cadena completa |
| Comparación del certificado en directo | No | Sí, vía STARTTLS en puerto 25 |
| Origen del registro | Manual (pegado) | DNS público |
| Datos enviados al servidor | Ninguno | Dominio analizado |
Flujo de trabajo recomendado:
- Diseña o genera el registro y usa el validador para verificar la sintaxis
- Publica el registro TLSA en la zona DNSSEC del host MX y espera la propagación
- Lanza el verificador para confirmar DNSSEC y la coincidencia de certificado en directo
El validador detecta los errores de entrada antes de publicar. El verificador detecta las desviaciones y confirma que el DNS público servido coincide con el certificado presentado actualmente por STARTTLS.
Anatomía de un registro TLSA
El registro TLSA contiene cuatro campos estrictamente especificados.
Estructura general
_25._tcp.mail.captaindns.com. IN TLSA <usage> <selector> <matching> <datos>
| Campo | Valores | Descripción |
|---|---|---|
| Usage | 0-3 | Anclaje de confianza |
| Selector | 0-1 | Parte del certificado hasheada |
| Matching type | 0-2 | Algoritmo de comparación |
| Datos | hex | Hash o bloque binario |
Usage (campo 1)
| Valor | Nombre | Descripción |
|---|---|---|
| 0 | PKIX-TA | Restricción CA: el certificado debe estar firmado por esta CA Y pasar la validación PKIX |
| 1 | PKIX-EE | Restricción de certificado: coincidencia exacta + validación PKIX |
| 2 | DANE-TA | Anclaje de confianza: cualquier certificado firmado por esta CA es aceptado |
| 3 | DANE-EE | Certificado de dominio: coincidencia exacta, sin validación PKIX |
Recomendación para SMTP: DANE-EE (3). El anclaje está en tu clave, independientemente de cualquier autoridad externa.
Selector (campo 2)
| Valor | Nombre | Descripción |
|---|---|---|
| 0 | Cert | Certificado completo (DER) |
| 1 | SPKI | SubjectPublicKeyInfo (solo la clave pública) |
Recomendación: SPKI (1). El registro sigue siendo válido mientras se conserve la clave pública, independientemente de las renovaciones de certificado.
Matching type (campo 3)
| Valor | Nombre | Longitud hex esperada |
|---|---|---|
| 0 | Full | Variable (certificado o clave en bruto) |
| 1 | SHA-256 | 64 caracteres (32 bytes) |
| 2 | SHA-512 | 128 caracteres (64 bytes) |
Recomendación: SHA-256 (1). Soportado universalmente, suficientemente robusto, compacto.
La combinación recomendada para SMTP
3 1 1 es el estándar de facto para SMTP DANE.
3 1 1 <sha256-de-la-spki>
- Usage 3 (DANE-EE): sin dependencia de una CA, anclaje directo en tu clave
- Selector 1 (SPKI): invariante frente a la renovación de certificado mientras se conserve la clave
- Matching type 1 (SHA-256): 32 bytes, perfectamente adaptado
Las demás combinaciones son posibles pero desaconsejadas:
| Combinación | Estado | Por qué |
|---|---|---|
| 3 1 1 | Recomendada | Estándar SMTP, robusta, invariante a las renovaciones |
| 3 0 1 | Tolerada | Hash sobre el certificado completo, cambia en cada renovación |
| 2 0 1 | Aceptable | DANE-TA sobre CA, sin actualización DNS al renovar |
| 2 1 1 | Aceptable | DANE-TA sobre SPKI de la CA |
| 3 1 0 | Rechazada | Matching type 0 expone el certificado en bruto, tamaño DNS enorme |
| 1 x x | Rechazada en SMTP | PKIX-EE rara vez desplegable en MTAs |
| 0 x x | Rechazada en SMTP | PKIX-TA inadecuada para SMTP |
El validador señala explícitamente las combinaciones fuera de recomendación y sugiere la combinación estándar.
Errores de sintaxis comunes y correcciones
Usage fuera de rango
Causa: valor de usage superior a 3.
Corrección:
- 4 1 1 2bb183af...
+ 3 1 1 2bb183af...
Selector inválido
Causa: selector distinto de 0 o 1.
Corrección:
- 3 2 1 2bb183af...
+ 3 1 1 2bb183af...
Matching type fuera de rango
Causa: matching type superior a 2.
Corrección:
- 3 1 3 2bb183af...
+ 3 1 1 2bb183af...
Datos hexadecimales inválidos
Causa: caracteres fuera del rango hex (0-9, a-f, A-F).
Corrección:
- 3 1 1 2bg183zf...
+ 3 1 1 2bb183af...
Longitud de hash incorrecta
Causa: la longitud de los datos no coincide con el matching type.
Corrección SHA-256:
- 3 1 1 2bb183
+ 3 1 1 2bb183af2e2b295b444c1fd4072f2b59a8c1c9abf7f3f1e9b0d4c7e8f1a2b3c4
SHA-256 (matching type 1) exige exactamente 64 caracteres hex. SHA-512 (matching type 2) exige exactamente 128 caracteres.
Combinación usage/selector frágil
Causa: DANE-EE (3) + Cert completo (0) provoca un hash que cambia en cada renovación de certificado.
Corrección recomendada: pasar a SPKI (1) para que el registro sea invariante a las renovaciones (con la opción --reuse-key en el lado ACME).
- 3 0 1 <hash-del-certificado-completo>
+ 3 1 1 <hash-de-la-clave-publica>
Owner name incorrecto
Causa: registro publicado en el apex del dominio en vez del host MX, o en el puerto equivocado.
Corrección: _25._tcp.<host-mx> exactamente. Para un MX mail.captaindns.com, es _25._tcp.mail.captaindns.com.
Preparar una rotación de clave
Varios registros TLSA en la misma zona no son un error: es de hecho el patrón recomendado para una rotación de clave sin interrupción.
Procedimiento de rotación limpio
- D-7: genera la siguiente clave, calcula su hash SPKI y publícalo en doble:
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <hash-clave-actual>
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <hash-clave-siguiente>
-
D-0: ejecuta la rotación de certificado con la nueva clave. Los MTA conformes aceptan la conexión si al menos uno de los dos registros coincide con el certificado presentado.
-
D+7 (o el doble del TTL): elimina el registro antiguo. La rotación está terminada.
Lo que verifica el validador
El validador procesa cada registro de forma independiente y confirma que:
- Cada hash respeta la longitud esperada por su matching type
- Ningún campo sale del rango válido
- Las combinaciones se mantienen dentro de las recomendaciones
Un registro doble nunca se señala como error cuando los dos son sintácticamente correctos.
DANE y MTA-STS: enfoques complementarios
| Criterio | DANE | MTA-STS |
|---|---|---|
| Mecanismo | DNSSEC + registro TLSA | HTTPS + política de texto |
| Dependencia | DNSSEC requerido | HTTPS requerido |
| Confianza | Criptográfica (DNS firmado) | PKI (CA HTTPS) |
| Soporte Postfix / Exim | Excelente | Bueno |
| Soporte Microsoft 365 / Google Workspace | Parcial a inexistente | Completo |
| Despliegue | Complejo (DNSSEC) | Más sencillo |
Recomendación: no elijas, despliega los dos. Valida aquí tu registro TLSA y publica también una política MTA-STS. La cobertura máxima impone la combinación.
Herramientas complementarias y recursos
| Herramienta | Cuándo usarla |
|---|---|
| DANE TLSA Checker | Auditoría en directo del registro publicado en DNS, con validación DNSSEC y coincidencia de certificado |
| Generador DANE TLSA | Crear un registro TLSA a partir de un certificado o una clave pública |
| Validador sintaxis MTA-STS | Validar la política MTA-STS asociada offline |
| Validador sintaxis TLS-RPT | Validar el registro TLS-RPT asociado offline |
| Auditoría email-authentication | Vista general de las herramientas de autenticación de correo |
Guías relacionadas
- DANE TLSA: la guía completa - Comprender DANE de extremo a extremo, de DNSSEC al despliegue SMTP.
- DANE TLSA en Postfix, BIND y Let's Encrypt - Instalación paso a paso con rotación de clave.
- DANE TLSA y Microsoft 365 Exchange Online - Soporte de DANE entrante y saliente en Exchange Online.
- DANE TLSA, resolución de incidencias: 12 casos prácticos - Diagnóstico y resolución de incidentes DANE.
- MTA-STS vs DANE: comparativo detallado - Elegir o combinar los dos protocolos.
Especificaciones
- RFC 6698 - DANE TLSA (especificación original)
- RFC 7671 - Updates to DANE (aclaraciones operativas)
- RFC 7672 - SMTP Security via DANE (DANE para SMTP)