Cómo diagnosticar SERVFAIL por DNSSEC con dig
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.