Cuando DANE la entrega comienza a fallar después de un cambio de certificado, primero establezca si la clave cambió, si el TLSA la asociación utiliza esa clave y qué certificado sirve realmente cada receptor. Una advertencia de certificado genérica puede ocultar una DNSSEC fracaso, un error selector o un despliegue parcial. Arreglar la capa incorrecta puede dejar el correo en cola y hacer que la evidencia sea más difícil de interpretar.
Preservar la observación fallida.
Referencias: RFC 7672 §2, RFC 7672 §3.
Registre la implementación del remitente, la marca de tiempo, el dominio del destinatario, el host MX seleccionado, el puerto, la IP de recepción y el error observado. Conserve el resultado de la validación DNSSEC y la respuesta TLSA relevante junto con el certificado o su huella digital pública. Si el remitente vuelve a intentarlo con otro host, manténgalo como una observación separada. Un panel que resuma todo el dominio no puede reemplazar la evidencia a nivel de punto final.
Distinga el error de protocolo de enlace del error de autenticación después de un protocolo de enlace. Un tiempo de espera de red no prueba que el resumen de TLSA no coincida. Por el contrario, recibir un certificado no demuestra ni una cadena DNSSEC confiable ni una autenticación DANE exitosa. RFC 7672 define los pasos de descubrimiento y validación por separado. RFC 7672 secciones 2 y 3.
Verifique el uso y el selector antes de comparar bytes
Referencias: RFC 6698 §2.1.2, RFC 6698 §2.1.3, RFC 7672 §4.
Para una asociación 3 1 1, extraiga el DER SPKI del certificado servido y calcule SHA-256. Una renovación de certificado que reutiliza la misma clave puede dejar este resumen sin cambios. Una rotación de claves no puede. Con un selector de certificado completo, un certificado renovado cambia la asociación incluso si se conserva la clave. No utilice la huella digital del certificado de un navegador de manera intercambiable con una huella digital SPKI.
El dispositivo OpenSSL retenido del 7 de noviembre de 2026, inspeccionado pero no vuelto a ejecutar aquí, creó los certificados A y B con claves diferentes y una reedición A2 con la clave de A. Sus cálculos registrados muestran que A y A2 comparten el resumen SPKI seleccionado, mientras que B difiere. Luego compara deliberadamente la asociación de B con la de A y registra el fracaso. La prueba utiliza bytes de certificado generados reales, pero es evidencia sintética local en lugar de un incidente de producción capturado.
Reconstruir DNS y sincronización de puntos finales
Referencias: RFC 7671 §8.1, RFC 7672 §2.1.
Compare el tiempo de activación de la nueva clave con la publicación del conjunto de asociaciones superpuestas y la expiración de los datos almacenados en caché anteriores. Si B se implementó mientras un remitente retenía registros solo A, un remitente correcto puede rechazar B. Consultar DNS autorizado después del incidente y ver B no refuta ese estado de caché anterior.
Verifique todos los backends y familias de direcciones. Un servidor que no pudo recargar podría conservar A mientras que otros servidores usan B. Un conjunto TLSA solo nuevo fallaría solo en una parte del tráfico. Las fallas DNSSEC tienen otra línea de tiempo: las firmas, la delegación y la validación del solucionador deben examinarse sin tratar casualmente los datos falsos como si no estuvieran firmados. RFC 7672 secciones 2.1 y 4.
Restaurar la coherencia en lugar de desactivar las comprobaciones
Referencias: RFC 7672 §3.1.1, RFC 7672 §4.
Cuando la clave no está comprometida, puede ser apropiado restaurar un certificado previamente cubierto o superponer correctamente las asociaciones, sujeto al estado real de la caché y la implementación. Coordine los propietarios de correo y DNS y verifique la reparación desde el lado emisor. No asuma que eliminar TLSA eliminará inmediatamente los requisitos almacenados en caché y no convertirá una falla de seguridad en una entrega no autenticada como solución alternativa predeterminada.
Para DANE-EE, no importe todas las reglas PKIX del navegador en el diagnóstico: el uso de su certificado tiene una semántica de autenticación específica, incluido el requisito de no coincidir con el nombre del certificado y la caducidad del certificado ignorada para el uso 3 de DANE-EE según RFC 7672 §3.1.1. No extienda esta regla específica a todos los usos de TLSA. Eso no excusa los certificados operativos vencidos cuando otros remitentes usan PKIX o MTA-STS. Por otra parte, la evidencia de revisión retenida del 7 de noviembre de 2026 contiene un bucle invertido con marca de tiempo. STARTTLS sesiones. Las sesiones fueron inspeccionadas pero no se volvieron a ejecutar para esta revisión. Un cliente controlado observa el certificado B en un puerto 127.0.0.1 registrado, extrae el SPKI del mismo nivel y rechaza una asociación solo A. El control A-más-B superpuesto corregido acepta la ruta. Por otra parte, la verificación del certificado Python/OpenSSL rechaza B frente al material confiable A, mientras que A tiene éxito. El paquete de revisión privada conserva siete transcripciones y bytes de certificados de pares para los cuatro casos que llegan a la captura del certificado. Los casos de protocolo de enlace fallido y sin STARTTLS no contienen bytes de certificado de pares capturados. Este es un pequeño cliente de laboratorio con entradas TLSA configuradas, no un resultado o producción DNSSEC de Internet. MTA incidente. No se envió ningún mensaje; La aceptación de producción aún necesita el punto final previsto y el seguimiento del remitente.