Cómo diagnosticar SERVFAIL por DNSSEC con dig
Por DNSRadar
Un SERVFAIL después de un cambio DNS suele confundirse con propagación, pero un fallo DNSSEC no se arregla simplemente esperando. Si los resolvers validadores rechazan la zona, algunos usuarios fallarán aunque otras redes parezcan funcionar.
Empieza comparando resolvers validadores
Los resolvers públicos pueden diferir porque algunos validan DNSSEC y otros tienen distintos estados de caché. Compara el mismo nombre entre resolvers independientes antes de volver a cambiar la zona.
dig @1.1.1.1 example.com A +dnssec
dig @8.8.8.8 example.com A +dnssec
dig @9.9.9.9 example.com A +dnssecComprueba el DS del dominio padre
Un DS antiguo en el registrador es una causa frecuente. Si se desactivó DNSSEC o cambió el proveedor DNS, el dominio padre puede seguir publicando un DS que apunta a claves que la zona hija ya no sirve.
dig example.com DS +short
dig +trace example.com DSConsulta los autoritativos directamente
- Confirma que cada servidor autoritativo responde por la zona.
- Compara seriales SOA para saber si todos sirven la misma versión.
- Revisa DNSKEY si existe DS en el dominio padre.
- Diferencia entre SERVFAIL recursivo y respuestas autoritativas directas.
Errores habituales con DNSSEC
Cambiar proveedor DNS sin quitar DS
El padre sigue indicando a resolvers validadores que esperen claves antiguas.
Publicar DNSKEY y DS que no coinciden
La cadena de confianza se rompe aunque los registros normales parezcan correctos.
Fiarse de resolvers no validadores
Un camino sin validación puede ocultar problemas DNSSEC.
Hacer cambios repetidos durante la caché
Complica leer el patrón real del fallo.
Interpreta +dnssec y +cdflag sin tratarlos como solución
La opción +dnssec solicita datos DNSSEC; no convierte dig en un validador. Un recursivo validador puede marcar AD cuando considera autenticada la respuesta. Que falte AD no prueba por sí solo un fallo: la zona podría no estar firmada o la ruta de consulta podría no aportar validación.
Compara la respuesta normal con +cdflag en el mismo resolver. Si SERVFAIL pasa a devolver datos al desactivar la comprobación, sospecha de la validación y revisa DS en el padre, DNSKEY en la hija, firmas y tiempos de rotación. Es una pista para investigar, no una razón para desactivar la validación a tus usuarios.
Si fallan las dos consultas, puede haber problemas de acceso a autoritativos, delegación u otros errores. Anota estado, flags, IP del resolver y errores DNS extendidos si existen. Confirma quién controla el DS del padre antes de coordinar cambios. No retires DS ni rotes claves solo porque un comprobador indique SERVFAIL.
dig @1.1.1.1 example.com A +dnssec
dig @1.1.1.1 example.com A +dnssec +cdflag
dig example.com DS +dnssec
dig @ns1.example.net example.com DNSKEY +dnssecFuentes y criterio editorial
Documentación técnica de DNSRadar. Los ejemplos con example.com y direcciones de documentación son ilustrativos; adapta los comandos a tu zona y contrasta la respuesta autoritativa antes de cambiar producción.
Cómo medimos y qué límites tiene la herramienta · Comunicar una corrección