Timeout de DNS frente a SERVFAIL: ¿en qué se diferencian?

No todas las consultas DNS fallidas fallan de la misma manera. Dos de los fallos más habituales que no son NXDOMAIN, un timeout y un SERVFAIL, se parecen vistos desde fuera (no llegó ninguna respuesta utilizable), pero apuntan a causas de fondo muy distintas.

Timeout: no llegó ninguna respuesta a tiempo

Un timeout significa exactamente lo que suena: la consulta se envió y no volvió ninguna respuesta dentro del plazo de espera configurado. Puede ocurrir porque el servidor autoritativo está sobrecargado, por pérdida de paquetes en algún punto de la ruta de red o porque un firewall descarta en silencio el tráfico DNS en lugar de rechazarlo abiertamente. Desde el lado de quien consulta, un timeout y un servidor que simplemente no existe se ven idénticos: en ambos casos solo hay silencio.

SERVFAIL: llegó una respuesta, y decía «no puedo»

SERVFAIL es una respuesta real, no silencio. El servidor que contestó está diciendo de forma explícita que encontró un problema al procesar la consulta: una zona mal configurada, un fallo de validación DNSSEC o un error interno en el resolvedor. Recibir un SERVFAIL te indica que algo concreto ocurrió en el lado del servidor, mientras que un timeout te dice comparativamente poco sobre dónde está realmente el problema.

Como ambos pueden ser transitorios, el tratamiento adecuado es el mismo en la práctica: reintentar unas pocas veces con espera exponencial y notificar un fallo real solo cuando se agotan esos reintentos. Es justo así como esta herramienta trata ambos códigos de forma distinta a un NXDOMAIN definitivo.

REFUSED suele indicar una política, no una avería

REFUSED tiende a meterse en el mismo saco que SERVFAIL porque en ambos casos el servidor «dijo que no» en vez de callar, pero los motivos suelen ser bastante distintos. Un servidor de nombres devuelve REFUSED habitualmente cuando está configurado para responder solo por zonas concretas y le preguntan por algo fuera de su alcance, cuando una lista de control de acceso bloquea la IP que consulta o cuando un resolvedor se ha configurado de forma explícita para rechazar consultas de fuera de su propia red (por ejemplo, un resolvedor recursivo que se niega a dar respuestas recursivas a desconocidos de internet: un comportamiento correcto e intencionado, no un error). Ver REFUSED en un servidor que no controlas rara vez se soluciona con un reintento o una estrategia de espera progresiva; conviene comprobar si estás consultando el servidor correcto.

Una causa concreta y frecuente de SERVFAIL: DNSSEC roto

Uno de los escenarios de SERVFAIL más frustrantes se da en dominios con DNSSEC activado pero mal configurado: una firma caducada, una clave rotada en el servidor de nombres pero no actualizada en el registrador, o una cadena de confianza rota en algún punto entre el dominio y la raíz. Un resolvedor validador que respeta DNSSEC se negará a devolver una respuesta que no puede verificar criptográficamente y devolverá SERVFAIL en lugar de ignorar en silencio la firma rota. Lo inquietante es que el dominio suele funcionar perfectamente con un resolvedor que no valida DNSSEC, lo que hace muy fácil diagnosticar mal esta causa con un «a mí me funciona» mientras el dominio está realmente roto para una parte significativa de los visitantes reales.