Una búsqueda de autenticación puede fallar incluso cuando un panel de control DNS muestra el valor esperado registro TXT. Un solucionador de validación también debe establecer si la respuesta es confiable. un roto DNSSEC Por lo tanto, la cadena puede interrumpir el acceso a SPF, DKIM o datos de seguridad del transporte sin cambiar su texto visible.
Separar el síntoma de la causa.
Referencias: RFC 4035 §3.2.2, RFC 4035 §5.5.
Capture el nombre exacto del propietario, el tipo de consulta, la resolución, la hora y la respuesta. SERVFAIL no es un diagnóstico DNSSEC en sí mismo. Los tiempos de espera, las autoridades inalcanzables y otras fallas de resolución pueden producir el mismo código de respuesta. Compare una consulta de validación normal con diagnósticos de validación del mismo solucionador confiable e inspeccione la cadena de delegación.
Una consulta usando excavar +dnssec solicita registros DNSSEC ; no hace que cavar sea un validador local completo. Una consulta con verificación deshabilitada puede ayudar a revelar datos que la validación rechazó, pero una respuesta obtenida sin la validación no es prueba de que la dependencia de producción sea saludable. Mantenga ese resultado de diagnóstico separado del resultado de la aplicación ordinaria.
Rastree a padres e hijos juntos
Referencias: RFC 4035 §5, RFC 7208 §4.6.2, RFC 6376 §6.1.2, RFC 7672 §2.1.
Inspeccione el DS principal, la DNSKEY secundaria, las firmas que cubren los registros solicitados y sus intervalos de validez. Verifique el reloj del validador y la configuración de confianza. Un DS principal obsoleto después de un reemplazo de clave, firmas caducadas o datos DNSKEY no disponibles son fallas diferentes que requieren reparaciones diferentes. Una delegación intencionalmente no firmada con prueba autenticada de que no hay DS es insegura y no es automáticamente falsa.
Para el correo electrónico, registre lo que hizo la implementación afectada. Un error DNS SPF puede provocar temperror; un error de búsqueda DKIM no establece que el mensaje haya sido falsificado. SMTP DANE tiene consecuencias de transporte más estrictas cuando se requiere autenticación TLSA Los datos no se pueden validar. No colapsar estos resultados en una afirmación universal de que DNSSEC rechaza todo el correo.
Utilice un dispositivo de rotura y reparación controlado
Referencias: RFC 4035 §5.2, RFC 6698 §2.1.
En una jerarquía desechable, firme mailtest.example con la clave A e instale el DS principal correspondiente. Consulta su MX y _25._tcp.mx.mailtest.example TLSA a través de un validador anclado al padre de prueba. Guarde la línea de base segura, el conjunto de DNSKEY, el DS y las horas de firma. Reemplace la clave secundaria con B mientras deja deliberadamente solo el DS de A en el padre. El resultado esperado es una validación fallida, no una transición inofensiva sin firmar.
Restaure una cadena firmada compatible y repita las mismas consultas después de tener en cuenta la delegación en caché y el material de claves. Compare el DER SubjectPublicKeyInfo SHA-256 de un certificado con un 3 1 1 Asociación TLSA por separado: los bytes coincidentes no reparan una cadena DNS rota. Esto especifica el comportamiento de resolución y SMTP ; las comprobaciones criptográficas fuera de línea retenidas a continuación no ejecutan esas rutas de red.
Cerrar el incidente con pruebas acotadas
Referencias: RFC 6781 §4.3.5.
Reparar la cadena real o fallo de firma a través del operador DNS autorizado. No elimine los datos de DS como solución alternativa universal improvisada; eso cambia la protección y tiene consecuencias dependientes de la caché. Conserve las respuestas del antes y el después de los servidores autorizados y las rutas de validación relevantes, luego pruebe el flujo de correo afectado. El cierre debe indicar qué nombres se validaron y qué pruebas de correo tuvieron éxito, con marcas de tiempo y límites de cobertura restantes.
Evidencia de validación aislada retenida
Referencias: RFC 4035 §5.
El laboratorio sintético retenido el 7 de noviembre de 2026, inspeccionado pero no vuelto a ejecutar para esta revisión, ejecutó verificaciones criptográficas de dnspython 2.9.2 contra una DNSKEY principal de prueba anclada. Verificó las firmas DNSKEY y DS principales, comparó la DNSKEY secundaria con la DS autenticada y verificó las firmas DNSKEY y TLSA secundarias. La línea base compatible y la cadena restaurada validadas. Una clave secundaria nueva bajo el DS principal solo antiguo no pudo coincidir con el DS explícito. El seguimiento conserva DS, DNSKEY, RRSIG, la época de validación y cada verificación. Se trata de una validación de cadena firmada fuera de línea, no de un seguimiento SERVFAIL de un solucionador recursivo ni de una interrupción del correo en vivo. Las comparaciones de claves de certificados locales se conservan por separado; Los resultados de producción y SMTP aún no se han probado.