El sistema de autoridades de certificación tiene un problema fundamental: cualquiera de cientos de CA puede emitir un certificado para cualquier dominio. Si una CA se ve comprometida, es hackeada o es coaccionada por un gobierno, puede emitir certificados fraudulentos que los navegadores y servidores de correo confiarán. Ya ha ocurrido—DigiNotar, Comodo, WoSign—y volverá a suceder.
Para la navegación web, hemos desarrollado mitigaciones: registros de Certificate Transparency, registros CAA, supervisión de los proveedores de navegadores. Pero el correo ha sido históricamente más vulnerable. Los servidores de correo que se conectan entre sí no tienen el mismo ecosistema de protecciones.
DANE—Autenticación de Entidades Nombradas basada en DNS—ofrece un enfoque completamente diferente. En lugar de confiar en las autoridades certificadoras, publicas la información de tu certificado directamente en DNS, asegurada por DNSSEC. El servidor remitente no necesita confiar en ninguna CA; solo necesita confiar en DNS, que ya utiliza para todo lo demás.
El problema que DANE resuelve
Cuando tu servidor de correo se conecta a otro servidor para entregar correo, necesita verificar que está hablando con el servidor correcto. Sin verificación, un atacante podría interceptar la conexión e impersonar el destino.
La verificación TLS tradicional utiliza autoridades de certificación. El servidor de destino presenta un certificado, tu servidor comprueba que está firmado por una CA de confianza y, si es así, procede. Pero este modelo de confianza tiene debilidades.
Primero, hay demasiadas CA de confianza. Tu servidor probablemente confía por defecto en cientos de autoridades de certificación. Cualquiera de ellas podría emitir un certificado para cualquier dominio. Una CA comprometida en un país podría emitir certificados usados para interceptar correo en todo el mundo.
Segundo, el cifrado oportunista es vulnerable a ataques de degradación. Si un atacante puede interceptar la conexión inicial, puede eliminar la oferta de TLS y forzar la comunicación en texto plano. Los servidores no saben que deberían exigir cifrado.
DANE aborda ambos problemas. Permite a los propietarios de dominios especificar exactamente qué certificados son válidos para sus servidores, publicados en registros DNS que están criptográficamente firmados. No se requiere confianza en CA. Y, dado que la política está en DNS, los servidores remitentes saben que deben exigir cifrado antes incluso de conectarse.
Cómo funciona DANE
DANE utiliza un tipo especial de registro DNS llamado TLSA (Autenticación de Seguridad de la Capa de Transporte). Este registro especifica qué certificado debe presentar el servidor, publicado en una ubicación específica en DNS.
El nombre DNS sigue un patrón: _port._protocol.hostname. Para un servidor de correo en mail.example.com usando SMTP (puerto 25), el registro TLSA estaría en _25._tcp.mail.example.com. Esta precisión permite especificar diferentes certificados para distintos servicios en el mismo host.
El registro TLSA contiene varios campos. El campo de uso especifica cómo validar el certificado—si comprobarlo frente a una CA, usarlo directamente o utilizarlo como ancla de confianza. El campo selector indica si estás especificando el certificado completo o solo la clave pública. El campo de tipo de coincidencia especifica si incluyes los datos completos o un hash.
La mayoría de las implementaciones de DANE para correo usan el tipo de uso 3 (DANE-EE), que significa «este es el certificado o la clave pública exacta que el servidor presentará, confía en él directamente». Esto evita por completo el sistema de CA: les estás diciendo a los remitentes exactamente qué esperar.
DNSSEC: la base
DANE solo funciona con DNSSEC. Sin DNSSEC, un atacante que pueda manipular respuestas DNS podría publicar registros TLSA falsos apuntando a sus propios certificados. DNSSEC proporciona la autenticación criptográfica que hace que DANE sea confiable.
DNSSEC añade firmas digitales a los registros DNS. Cada registro está firmado por la clave de la zona, que a su vez es autenticada por la clave de la zona padre, hasta llegar a la raíz. Un servidor remitente puede verificar toda la cadena, asegurando que el registro TLSA que recibió es auténtico.
Esta es a la vez la fortaleza y la limitación de DANE. DNSSEC proporciona una fuerte autenticación sin confiar en CA de terceros. Pero el despliegue de DNSSEC sigue siendo incompleto. Muchos dominios no tienen DNSSEC, y muchos resolutores DNS no lo validan. Si tu dominio no tiene DNSSEC, no puedes usar DANE.
Configurar DANE para el correo electrónico
Implementar DANE requiere varios pasos, y el orden importa.
Primero, asegúrate de que tu dominio tenga DNSSEC. Esto suele implicar trabajar con tu proveedor DNS para habilitar la firma y publicar registros DS en la zona padre. Muchos proveedores DNS ya soportan DNSSEC, pero la configuración varía.
En segundo lugar, obtén o identifica el certificado que usa tu servidor de correo. Necesitas el certificado completo o su clave pública, según el tipo de selector que elijas. Usar la clave pública (selector 1) suele ser preferible porque sobrevive a las renovaciones del certificado mientras mantengas la misma clave.
En tercer lugar, genera el registro TLSA. Calcularás el hash del certificado o la clave pública usando SHA-256 (tipo de coincidencia 1) y lo formatearás como un registro TLSA. Existen herramientas para automatizar esto: no necesitas calcular el hash manualmente.
En cuarto lugar, publica el registro TLSA en DNS. Recuerda la convención de nombres: _25._tcp.yourmailserver.example.com para SMTP. El registro debe estar publicado y firmado con DNSSEC antes de que los remitentes lo utilicen.
Por último, prueba exhaustivamente. Los fallos de DANE pueden provocar fallos en la entrega de correo, así que verifica que todo funcione antes de depender de ello. Varias herramientas en línea pueden comprobar tu configuración de DANE e informar de problemas.
DANE vs MTA-STS
DANE y MTA-STS resuelven problemas similares—ambos evitan los ataques de degradación de TLS y la sustitución de certificados. Pero funcionan de manera diferente y tienen distintas compensaciones.
DANE requiere DNSSEC pero proporciona garantías de seguridad más fuertes. La autenticación del certificado es criptográfica y no depende de terceros más allá de la jerarquía DNS. Si se compromete DNSSEC, tienes problemas mayores que la seguridad del correo.
MTA-STS no requiere DNSSEC, pero sí exige alojar un archivo de política sobre HTTPS. Se basa en la PKI de la web (autoridades certificadoras) para autenticar el archivo de política. Esto es, discutiblemente, más débil que DNSSEC, pero hoy es más desplegable.
En la práctica, MTA-STS ha visto una adopción más amplia porque el despliegue de DNSSEC sigue siendo limitado. Google, Microsoft y la mayoría de los grandes proveedores de correo admiten MTA-STS. El soporte de DANE es menos universal, aunque está creciendo.
Si tienes DNSSEC, implementar DANE proporciona la protección más sólida. Si no tienes DNSSEC y no puedes obtenerlo fácilmente, MTA-STS es la opción práctica. Implementar ambos ofrece defensa en profundidad—los remitentes que soportan DANE lo usarán; los demás recurrirán a MTA-STS.
Errores comunes con DANE
El problema más frecuente de DANE son los registros TLSA que no coinciden con el certificado real. Esto ocurre cuando se renuevan certificados sin actualizar DNS, o cuando se publica inicialmente la información de certificado incorrecta. El resultado son fallos de entrega: los servidores remitentes detectan una discrepancia y se niegan a entregar.
La automatización ayuda aquí. Si usas Let's Encrypt u otro sistema automatizado de certificados, integra las actualizaciones de registros TLSA en tu proceso de renovación. Algunas herramientas lo gestionan automáticamente; otras requieren scripting.
Otro problema común son los problemas de configuración de DNSSEC. DANE requiere DNSSEC válido hasta arriba en la cadena. Si expiran tus firmas DNSSEC, o si hay un error de configuración, la validación de DANE falla. Supervisa continuamente el estado de tu DNSSEC.
Publicar registros TLSA antes de que DNSSEC esté completamente desplegado también causa problemas. Los remitentes que soportan DANE intentarán validar, fallarán porque DNSSEC no está funcionando y pueden rechazar el correo. Haz que DNSSEC funcione primero, veríficalo a fondo y luego añade los registros TLSA.
¿Vale la pena implementar DANE?
Para organizaciones con requisitos de alta seguridad e infraestructura DNSSEC existente, DANE es el estándar de oro para la seguridad del transporte de correo. Proporciona autenticación criptográfica sin confiar en autoridades de certificación, lo cual importa si te preocupan atacantes de estados nación o el compromiso de una CA.
Para la mayoría de las organizaciones, la respuesta práctica depende de DNSSEC. Si ya tienes DNSSEC (quizás por otras razones), añadir DANE es relativamente sencillo y proporciona beneficios de seguridad reales. Si no tienes DNSSEC, el esfuerzo para implementarlo solo por DANE puede no estar justificado—MTA-STS ofrece una protección similar con menos infraestructura.
El ecosistema del correo electrónico avanza gradualmente hacia exigir cifrado de transporte. Ya sea mediante DANE, MTA-STS o ambos, la dirección es clara. Implementar uno o ambos ahora te adelanta a la curva y protege tu correo de la interceptación.
Frequently asked questions
¿Puedo usar DANE sin DNSSEC?
No. DANE depende fundamentalmente de DNSSEC para la autenticación. Sin DNSSEC, un atacante podría falsificar registros TLSA, anulando por completo el propósito. DNSSEC es un prerrequisito, no opcional.
¿Qué ocurre si mi registro TLSA es incorrecto?
Los servidores remitentes que admiten DANE no podrán enviarte correo. Verán una discrepancia entre el registro TLSA y tu certificado real y se negarán a conectarse. Por eso las pruebas son fundamentales antes del despliegue.
¿Los principales proveedores de correo electrónico admiten DANE?
El soporte está creciendo, pero no es universal. Algunos proveedores europeos y organizaciones centradas en la seguridad admiten DANE. Google ha indicado soporte en algunos contextos. Comprueba la compatibilidad actual antes de depender de DANE para rutas de correo críticas.
¿Debo usar DANE o MTA-STS?
Si tienes DNSSEC, usa DANE: es más seguro. Si no tienes DNSSEC, usa MTA-STS. Si tienes DNSSEC y quieres la máxima protección, implementa ambos. Son complementarios, no competidores.