Consigna y contexto
La empresa desea reducir el riesgo de degradación (downgrade) de SMTP STARTTLS y de ataques de intermediario (man-in-the-middle) publicando registros DNSSEC y TLSA para su dominio de envío. No todos los destinatarios admiten DANE y los certificados rotan con regularidad. Diseña el descubrimiento de MX, la validación de TLSA, la compatibilidad con degradación controlada (fallback), la rotación, el monitoreo y la reversión (rollback) ante incidentes.
Qué evalúa el entrevistador
- Comprender que SMTP DANE depende de DNSSEC, el destino MX y TLSA, no solo de una autoridad de certificación (CA).
- Distinguir entre DANE oportunista, TLSA estricto (enforced), MTA-STS y reportes de TLS.
- Diseñar la generación de TLSA, el TTL, la rotación de certificados y el manejo de fallos de DNSSEC.
- Incluir el éxito en la entrega, degradaciones, fallos de validación y la compatibilidad de destinatarios en un despliegue canary.
Preguntas para aclarar primero
- ¿Se está protegiendo el dominio emisor, el dominio receptor o ambos? ¿El MTA emisor valida a sus pares?
- ¿Es confiable la cadena de DNSSEC, el resolver y el comportamiento de la caché?
- ¿Qué porcentaje de destinatarios admite DANE, MTA-STS o solo STARTTLS?
- ¿Los certificados son emitidos por una CA o son autofirmados, y cuáles son las ventanas de rotación y rollback?
- En caso de fallo, ¿se puede retrasar la entrega o debe recurrir a texto sin formato (plaintext)?
Marco de respuesta de 30 segundos
El MTA emisor resuelve el MX, valida TLSA mediante DNSSEC y verifica el certificado o clave del par utilizando el uso de certificado, selector, tipo de coincidencia y datos de asociación de TLSA. Un fallo de DNSSEC o una falta de coincidencia de TLSA no debe tratarse como un éxito común de STARTTLS; la política debe retrasar o rechazar la entrega. Comienza en modo de observación, realiza pruebas canary por dominios, combina MTA-STS con reportes de TLS y rota con registros superpuestos y una ventana de rollback.
Respuesta detallada paso a paso
Paso 1: Rastrear la ruta del protocolo
El emisor obtiene el host de transporte de los registros MX del dominio destinatario y negocia STARTTLS. DANE utiliza registros TLSA protegidos por DNSSEC para vincular el dominio, el puerto y el certificado o clave de destino. No trata el nombre del MX como el nombre del certificado ni elude el protocolo de enlace (handshake) TLS y las reglas de hostname.
Paso 2: Elegir la semántica de TLSA
El uso de certificado, el selector y el tipo de coincidencia de TLSA definen qué se compara. Un registro puede coincidir con el certificado completo, SubjectPublicKeyInfo o un resumen (digest). Una opción más flexible facilita la rotación; una más estricta proporciona un mayor control. Los registros deben representar la cadena de despliegue real y considerar una clave de respaldo en lugar de simplemente copiar una huella digital actual.
Paso 3: Diseñar DNSSEC y TTL
Verifica la cadena de DNSSEC desde la zona raíz hasta TLSA y monitorea la expiración de firmas, los cambios de DS y los errores de resolución. El TTL controla la propagación de la rotación y la velocidad de revocación, por lo que se deben superponer los registros durante la ventana requerida. Distingue entre fallos de DNSSEC, SERVFAIL y NXDOMAIN frente a "sin TLSA" para evitar degradaciones falsas tras fallos de resolvers o de caché.
Paso 4: Construir la política de compatibilidad
Valida TLSA para destinos compatibles con DANE. Para otros, aplica una política de dominio para MTA-STS, STARTTLS ordinario o puesta en cola. La aplicación estricta no debe recurrir silenciosamente a texto sin formato. Registra el motivo del fallo, el destino, el estado de DNSSEC y el tiempo de reintento en la cola y en el reporte de TLS en lugar de registrar un único error de conexión genérico.
Paso 5: Rotar certificados y claves
Publica los registros TLSA nuevos y antiguos, despliega el nuevo certificado o clave, espera a que transcurra el TTL y una ventana de observación, y luego elimina el registro antiguo. Verifica la vista desde varios resolvers y MTA en cada paso. Para la coincidencia por digest, registra la herramienta, el algoritmo y la entrada. Una rotación fallida restaura tanto los registros antiguos como el certificado antiguo.
Paso 6: Canary y observación
Comienza con dominios de destinatarios internos o de bajo riesgo en modo de observación, y luego aplica la política estrictamente de forma gradual. Monitorea el éxito en las entregas, coincidencias de TLSA, fallos de DNSSEC, discrepancias de certificados, antigüedad de la cola y degradaciones a texto sin formato. Agrega y anonimiza los reportes de TLS; no envíes direcciones de destinatarios ni metadatos completos de mensajes a terceros.
Paso 7: Ejercitar incidentes y recuperación
Realiza simulacros de firmas DNSSEC expiradas, publicación incorrecta de TLSA, rotación anticipada de certificados, cambios de MX, fallos de resolvers y pares sin DANE. Congela la aplicación estricta, extiende los reintentos en cola y revierte los cambios de DNS o certificados; descongela solo después de que MTA independientes y múltiples resolvers públicos confirmen la recuperación.
Respuesta de ejemplo de alta calidad
Haría que MX, DNSSEC, TLSA y SMTP TLS fueran pasos observables independientes: resolver MX, validar DNSSEC y luego verificar el certificado o clave del par utilizando el uso de certificado, selector y tipo de coincidencia de TLSA. Un fallo de DNSSEC o una discrepancia de TLSA deriva en un rechazo por política de dominio o puesta en cola, nunca en texto sin formato silencioso. Implementaría en modo de observación, con aplicación progresiva mediante canary, combinando MTA-STS con reportes de TLS. Publicaría registros TLSA superpuestos antes del nuevo certificado, esperaría a que pase el TTL y luego eliminaría el registro antiguo. Mantendría rutas de rollback para DNS y certificados, y realizaría simulacros de expiración de firmas, cambios de MX y fallos de resolvers.
Errores comunes
- Tratar DANE únicamente como una verificación de CA o una comprobación de hostname de MX.
- Continuar con STARTTLS ordinario o texto sin formato después de que falle la validación de DNSSEC.
- Eliminar el registro TLSA antiguo antes de desplegar el certificado de reemplazo.
- Probar con un solo resolver y emisor, ignorando la propagación en caché.
- Incluir direcciones de destinatarios y metadatos completos de mensajes en los reportes de TLS.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿En qué se diferencian DANE y MTA-STS?
DANE depende de DNSSEC y TLSA, y es adecuado para MTA que validan DNSSEC. MTA-STS publica políticas a través de HTTPS y depende de certificados de CA. Pueden coexistir; la elección se basa en las capacidades del par y los límites operativos en lugar de tratar a uno como el fallback silencioso del otro.
Pregunta de seguimiento 2: ¿TLSA coincide con una clave pública o con un certificado?
El selector y el tipo de coincidencia lo deciden. Una clave o digest puede reducir la sensibilidad a los cambios en la cadena de certificados, pero se debe conservar la entrada exacta, el algoritmo y el registro de rotación para evitar un digest erróneo.
Pregunta de seguimiento 3: ¿Puede la entrega recurrir a texto sin formato tras un SERVFAIL de DNSSEC?
No cuando la política del dominio requiere DANE. Se debe retrasar o rechazar y generar una alerta. Solo una política de compatibilidad explícitamente permitida puede elegir otra ruta, y debe registrar la degradación.
Pregunta de seguimiento 4: ¿Cómo se revierte una publicación de TLSA incorrecta?
Restaura el TLSA y certificado anteriores, espera a que el DNS autoritativo, las cachés de TTL y múltiples resolvers recursivos converjan, y luego libera el congelamiento de la cola. Conserva el registro erróneo, los dominios afectados y el tiempo de recuperación para fines de auditoría.
Pregunta de seguimiento 5: ¿Cómo se demuestra que no hubo degradación a texto sin formato?
Registra la negociación TLS, el estado de TLSA y los recuentos de degradación por dominio de destino, y verifica periódicamente desde un MTA independiente. Trata los intentos de texto sin formato como alertas de alta prioridad y concílialos con los reportes de TLS y los registros de entrega.