← RFC Reference

DANE — Autenticación basada en DNS para SMTP TLS

Por Qué Existe

SMTP con STARTTLS tiene dos problemas fundamentales:

1. Sin autenticación. Un servidor de envío no tiene forma confiable de verificar que el certificado TLS del servidor receptor sea legítimo. SMTP no usa el modelo de confianza de CA de la web — históricamente, la mayoría de servidores de correo usaban certificados autofirmados, así que los remitentes aprendieron a aceptar cualquiera.
2. Ataques de degradación. Un atacante en la red activa puede eliminar el anuncio STARTTLS de la respuesta EHLO, forzando entrega en texto plano.

MTA-STS (RFC 8461) resuelve estos problemas usando HTTPS y la Web PKI. DANE los resuelve usando DNSSEC y registros TLSA. Los dos enfoques son complementarios: DANE es criptográficamente más fuerte (sin necesidad de confianza en CA), mientras que MTA-STS es más fácil de implementar (sin DNSSEC requerido).

Cómo Funciona

DANE para SMTP (definido en RFC 7672, basándose en la especificación DANE base en RFC 6698) funciona en tres pasos:

Paso 1: Zona Firmada con DNSSEC

La zona DNS del dominio receptor — y la zona del objetivo MX — deben estar firmadas con DNSSEC. Esto es innegociable. Sin DNSSEC, un atacante podría falsificar registros TLSA, haciendo DANE peor que inútil.

Paso 2: Publicar Registros TLSA

El dominio publica registros TLSA para cada puerto SMTP del host MX. Un registro TLSA vincula un certificado TLS (o su clave pública, o su CA) a un servicio específico.

Campos del Registro TLSA

Paso 3: El Remitente Valida

Cuando un servidor de envío compatible con DANE entrega correo a example.com:

1. Resuelve registros MX para example.com con validación DNSSEC.
2. Para cada host MX (p. ej., mail.example.com), busca _25._tcp.mail.example.com TLSA con validación DNSSEC.
3. Si existen registros TLSA validados con DNSSEC: se conecta, realiza STARTTLS y valida el certificado del servidor contra los datos TLSA.
4. Si la validación falla: no entrega. El mensaje se pone en cola para reintentar.
5. Si no existen registros TLSA (o DNSSEC no está implementado): retrocede a TLS oportunista como antes.

Detalles Técnicos Clave

Configuración TLSA Recomendada

Para servidores SMTP, RFC 7672 recomienda DANE-EE(3) SPKI(1) SHA-256(1):

Esta es la opción más robusta porque:

• Uso 3 (DANE-EE) omite la validación de CA completamente. El certificado no necesita estar firmado por una CA pública — autofirmado funciona bien.
• Selector 1 (SPKI) coincide con la clave pública, no el certificado completo. Puedes renovar tu certificado (cambiando número de serie, vencimiento) sin actualizar el registro TLSA, mientras el par de claves se mantenga igual.
• Tipo de coincidencia 1 (SHA-256) almacena un hash en lugar de la clave completa, manteniendo el registro DNS compacto.

Generar un Registro TLSA

# Extrae el hash SHA-256 de la clave pública del servidor
openssl x509 -in server.crt -noout -pubkey | \
  openssl pkey -pubin -outform DER | \
  openssl dgst -sha256 -hex
(stdin)= 2a9f8e3b1c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f

# El registro TLSA resultante:
_25._tcp.mail.example.com. IN TLSA 3 1 1 2a9f8e3b1c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f

DANE vs. MTA-STS

Errores Comunes

• Publicar TLSA sin DNSSEC. Si tu zona no está firmada con DNSSEC, se ignoran los registros TLSA. Peor, algunas implementaciones pueden interpretar TLSA sin firmar como una señal para no requerir TLS, degradando la seguridad.
• Olvidar actualizar TLSA en rotación de claves. Si usas selector 0 (certificado completo) y renuevas tu certificado con una clave nueva, el registro TLSA debe actualizarse antes de que el nuevo certificado entre en vigor. Usa selector 1 (SPKI) y mantén el mismo par de claves entre renovaciones para evitar esto.
• TLSA en el dominio, no en el host MX. El registro TLSA va en el nombre de host objetivo MX (p. ej., _25._tcp.mail.example.com), no en el dominio mismo. Si tu MX apunta a un host de terceros, el registro TLSA debe estar en su zona.
• Rotar registros TLSA incorrectamente. Al rotar claves, publica registros TLSA para claves nuevas y antiguas simultáneamente. Elimina el registro antiguo solo después de que el certificado se haya rotado y los cachés DNS hayan expirado.
• Ignorar la cadena de confianza DNSSEC. Cada zona en la cadena desde la raíz hasta el registro TLSA debe estar firmada con DNSSEC. Una ruptura en cualquier lugar invalida toda la cadena.

Impacto en Entregabilidad

• Garantía de TLS más fuerte. DANE proporciona prueba criptográfica de la identidad del servidor solo desde DNS. Sin compromiso de CA, sin ventana TOFU — seguro desde la primera conexión.
• Ampliamente implementado en Europa. Los Países Bajos, Alemania y República Checa tienen alta adopción de DANE para correo gubernamental e institucional. Si entregas a estas regiones, el soporte DANE es una ventaja significativa.
• Soporte nativo de Postfix. Postfix tiene soporte DANE integrado (smtp_tls_security_level = dane). Para remitentes usando Postfix, DANE "funciona automáticamente" cuando el dominio receptor tiene registros TLSA.
• Complementario con MTA-STS. Implementa ambos. Los remitentes que soportan DANE lo usarán (garantías más fuertes); los remitentes que solo soportan MTA-STS usarán eso. Ambos son mejores que TLS oportunista solo.

Related RFCs