SERVFAIL de DNS desde el proveedor: cómo demostrar que el proveedor es el problema

Qué significa realmente SERVFAIL (y qué no significa)

SERVFAIL es el código de respuesta DNS 2. Es intencionadamente vago: “el servidor de nombres no pudo procesar esta consulta debido a un problema con el servidor de nombres.” En la práctica, para resolutores recursivos, a menudo significa: “intenté recursión y encontré un error interno, un bloqueo por política, fallo de validación DNSSEC, tiempo de espera o fallo ascendente”.

SERVFAIL no es NXDOMAIN

NXDOMAIN es un “no existe” claro. SERVFAIL es “algo me impidió decidir”. Trátalos de forma diferente. NXDOMAIN es dato. SERVFAIL es un evento de fiabilidad.

SERVFAIL puede ser culpa tuya, incluso si parece venir de arriba

Si reenvías todas las consultas a un proveedor y tu resolutor local en caché está configurado como un reenviador puro, has creado un punto único de estrangulamiento. Cuando ese resolutor ascendente se porta mal, tu servidor local informa SERVFAIL y parecerá que pierdes la cabeza. Pero la causa raíz puede seguir siendo tu elección de diseño: sin fallbacks, sin diversidad, MTU incorrecto, trust anchors DNSSEC rotos o políticas demasiado estrictas.

No estamos aquí para filosofar. Estamos aquí para probar dónde vive la culpa y qué hacer al respecto.

Broma #1: DNS es el único sistema donde “está en caché” puede significar “está bien”, “está roto” o “está roto pero de otra manera”.

Guion de diagnóstico rápido (primero/segundo/tercero)

Primero: decide si es local, recursivo ascendente o autoritativo

• Consulta tu resolutor local (el que realmente usan tus hosts). Si devuelve SERVFAIL, sigue adelante.
• Consulta un resolutor público conocido y bueno desde el mismo host. Si funciona allí, el dominio probablemente está bien y la ruta ascendente es sospechosa.
• Traza hasta el autoritativo (caminata no recursiva). Si las respuestas autoritativas están sanas, probablemente el problema sea recursión/validación ascendente.

Segundo: diferencia fallos DNSSEC vs fallos de transporte vs bloqueos por política

• DNSSEC: SERVFAIL en resolutores validadores; funciona con +cd (comprobación deshabilitada) o desde resolutores no validadores.
• Transporte/MTU/fragmentación: respuestas UDP truncadas o descartadas; fallback a TCP falla; intermitente según la ruta de red.
• Política/RPZ/filtrado: SERVFAIL/NXDOMAIN consistentes solo en resolutores del proveedor; otros resolutores tienen éxito; a veces el proveedor admite “filtrado de seguridad”.

Tercero: captura pruebas con tiempo, IPs de resolutor y trazas de paquetes

• Registra la IP exacta del resolutor que devolvió SERVFAIL, marcas temporales, nombre/tipo de consulta y si se intentó TCP.
• Recopila salidas de dig con +stats y +dnssec.
• Ejecuta un breve tcpdump dirigido para mostrar respuestas ascendentes (o su ausencia).

Si solo haces una cosa de este artículo: prueba que la cadena autoritativa responde correctamente, y muestra que solo los resolutores recursivos de tu proveedor fallan. Eso convierte “quizá” en “ticket”.

Hechos e historial que importan en incidentes reales

1. DNS es anterior a la web. Se diseñó a principios de los años 80 como una base de datos distribuida para reemplazar HOSTS.TXT; las suposiciones de fiabilidad eran… optimistas.
2. RCODE 2 (SERVFAIL) siempre fue vago por diseño. El protocolo no quería filtrar detalles internos, lo cual es estupendo para la simplicidad y pésimo para la respuesta a incidentes.
3. EDNS0 (1999) cambió los modos de fallo. Paquetes UDP más grandes redujeron el uso de TCP, pero introdujeron problemas de fragmentación/MTU que aún causan comportamientos “aleatorios” de SERVFAIL/timeout.
4. DNSSEC (2000s) convirtió la integridad de datos en una característica principal. También hizo que “dominios perfectamente accesibles” fallen la validación cuando las firmas, los registros DS o los relojes están mal.
5. El caché negativo se estandarizó. Cachear NXDOMAIN y otras respuestas negativas mejora el rendimiento pero puede prolongar el dolor después de una corrección si los TTL son altos.
6. Los resolutores anycast cambiaron la depuración. “8.8.8.8” no es una sola caja; los resolutores de proveedor suelen anycastear también, así que el comportamiento puede variar por geografía y tiempo.
7. Los registros glue son una fuente recurrente de caídas. Delegaciones que dependen de glue pueden romperse de formas sutiles cuando registradores/parents se actualizan incorrectamente.
8. El fallback a TCP para DNS no es opcional en la práctica. Firewalls que bloquean DNS sobre TCP crean fallos que parecen SERVFAIL ascendentes.
9. Los resolutores implementan capas de política. RPZ, bloqueo de malware, “filtros familiares” y políticas empresariales pueden convertir una consulta normal en SERVFAIL o NXDOMAIN —por diseño.

Modelo mental: stub → recursivo → autoritativo

La mayoría de los incidentes se vuelven confusos porque la gente no se pone de acuerdo sobre qué “servidor DNS” están hablando. Necesitas un modelo mental claro:

• Stub resolver: la librería cliente en tu host (a menudo a través de systemd-resolved), pidiendo a otro que haga la recursión.
• Resolutor recursivo: tu servidor de caché/validación (Unbound, BIND, Knot Resolver) o el resolutor gestionado de tu proveedor, que realiza la recursión y almacena en caché los resultados.
• Servidores autoritativos: los servidores del dominio, respondiendo desde los datos de zona (a menudo detrás de proveedores DNS, balanceadores y anycast).
• Zona padre: la delegación y los registros DS viven por encima (.com, .net, etc.). Muchos “problemas autoritativos” son en realidad problemas del padre/registrador.

“SERVFAIL desde arriba” suele significar: tu stub preguntó a tu recursivo, y tu recursivo preguntó a su reenviador ascendente. Ese reenviador ascendente devolvió SERVFAIL o expiró. Tu recursivo entonces devolvió SERVFAIL al stub. El truco es probar exactamente qué salto falló y por qué.

Una idea parafraseada a menudo atribuida a un líder de operaciones: “La esperanza no es una estrategia; mide y verifica.” (idea parafraseada, Gene Kim)

Tareas prácticas: comandos, salida esperada y decisiones (12+)

Estas tareas están diseñadas para construir una cadena de evidencia. Ejecútalas desde: (1) un host afectado, (2) un host en un segmento de red distinto y, idealmente, (3) un punto limpio como una pequeña VM fuera de tu proveedor.

Task 1: Identify what resolver the host is actually using

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.0.0.53
       DNS Servers: 10.0.0.53 10.0.0.54

Qué significa: Tu host está enviando DNS a 10.0.0.53/10.0.0.54. Esos son tus primeros sospechosos, no “Internet”.

Decisión: Todas las pruebas posteriores deben consultar explícitamente a esos resolutores. Si te saltas esto, “probarás” lo equivocado.

Task 2: Reproduce the SERVFAIL against the resolver in use

cr0x@server:~$ dig @10.0.0.53 www.example.com A +norecurse

; <<>> DiG 9.18.24 <<>> @10.0.0.53 www.example.com A +norecurse
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41277
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; QUERY SECTION:
;www.example.com.                IN      A

;; Query time: 58 msec
;; SERVER: 10.0.0.53#53(10.0.0.53) (UDP)
;; WHEN: Tue Dec 31 12:04:55 UTC 2025
;; MSG SIZE  rcvd: 40

Qué significa: El resolutor devolvió SERVFAIL rápidamente (58 ms). Eso no es un timeout genérico; es una ruta de fallo activa.

Decisión: Ahora prueba el mismo nombre contra múltiples otros resolutores para aislar el alcance.

Task 3: Compare with a known-good public resolver from the same host

cr0x@server:~$ dig @1.1.1.1 www.example.com A +stats

; <<>> DiG 9.18.24 <<>> @1.1.1.1 www.example.com A +stats
; (1 server found)
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5013
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
www.example.com.         300     IN      A       93.184.216.34

;; Query time: 14 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Tue Dec 31 12:05:08 UTC 2025
;; MSG SIZE  rcvd: 60

Qué significa: El dominio resuelve bien en otro lugar. Esto apunta alejando del fallo autoritativo y hacia el comportamiento de tu ruta recursiva/proveedor.

Decisión: Comienza a construir evidencia de “solo estas IPs de resolutor fallan”.

Task 4: Check if it’s DNSSEC-related (the classic SERVFAIL trap)

cr0x@server:~$ dig @10.0.0.53 www.example.com A +dnssec +multi

; <<>> DiG 9.18.24 <<>> @10.0.0.53 www.example.com A +dnssec +multi
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60172
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Qué significa: Sigue siendo SERVFAIL. No es concluyente aún.

Decisión: Prueba +cd (comprobación deshabilitada). Si eso funciona, probablemente tienes fallo de validación DNSSEC en el camino del resolutor ascendente.

Task 5: Query with checking disabled to isolate validation failures

cr0x@server:~$ dig @10.0.0.53 www.example.com A +cd +stats

; <<>> DiG 9.18.24 <<>> @10.0.0.53 www.example.com A +cd +stats
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28212
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
www.example.com.         300     IN      A       93.184.216.34

;; Query time: 31 msec
;; SERVER: 10.0.0.53#53(10.0.0.53) (UDP)
;; WHEN: Tue Dec 31 12:06:01 UTC 2025
;; MSG SIZE  rcvd: 60

Qué significa: Con la comprobación DNSSEC deshabilitada, resuelve. Eso sugiere fuertemente fallo de validación DNSSEC en la ruta del resolutor (trust anchor, DS malo, firmas expiradas, desajuste de reloj o bug ascendente).

Decisión: Junta evidencia de la cadena DNSSEC y revisa los logs del resolutor; prepárate para decir al proveedor “valida incorrectamente” en lugar de “DNS está caído”.

Task 6: Walk the delegation chain using trace (authoritative path proof)

cr0x@server:~$ dig +trace www.example.com A

; <<>> DiG 9.18.24 <<>> +trace www.example.com A
.                       518400  IN      NS      a.root-servers.net.
...
com.                    172800  IN      NS      a.gtld-servers.net.
...
example.com.            172800  IN      NS      a.iana-servers.net.
example.com.            172800  IN      NS      b.iana-servers.net.
www.example.com.        300     IN      A       93.184.216.34

Qué significa: Puedes alcanzar la cadena autoritativa y obtener un registro A. Este es tu recibo de “autoritativo está bien”.

Decisión: Si +trace funciona de forma fiable mientras el resolutor de tu proveedor devuelve SERVFAIL, tienes un caso sólido contra el resolutor ascendente.

Task 7: Confirm the provider resolver is the one failing (query it directly)

cr0x@server:~$ dig @203.0.113.53 www.example.com A +stats

; <<>> DiG 9.18.24 <<>> @203.0.113.53 www.example.com A +stats
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1400
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; Query time: 22 msec
;; SERVER: 203.0.113.53#53(203.0.113.53) (UDP)
;; WHEN: Tue Dec 31 12:06:44 UTC 2025
;; MSG SIZE  rcvd: 40

Qué significa: Una IP recursiva ascendente específica devolvió SERVFAIL rápidamente. Esto es oro para la escalación: es preciso y reproducible.

Decisión: Repite contra los resolutores secundarios del proveedor. Si solo uno falla, probablemente hayas golpeado un POP anycast o una caída parcial.

Task 8: Check whether TCP fallback works (fragmentation/MTU suspicion)

cr0x@server:~$ dig @203.0.113.53 www.example.com DNSKEY +tcp +dnssec +stats

; <<>> DiG 9.18.24 <<>> @203.0.113.53 www.example.com DNSKEY +tcp +dnssec +stats
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32999
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; Query time: 35 msec
;; SERVER: 203.0.113.53#53(203.0.113.53) (TCP)
;; WHEN: Tue Dec 31 12:07:18 UTC 2025
;; MSG SIZE  rcvd: 1102

Qué significa: TCP funciona y devuelve DNSKEY. Si UDP da SERVFAIL pero TCP tiene éxito, podrías estar ante problemas de ruta UDP, caída de fragmentos o rarezas de firewall.

Decisión: Si TCP funciona pero UDP no, céntrate en MTU/tamaño EDNS0 y filtrado de red en lugar de “el servidor DNS está caído”.

Task 9: Force small EDNS0 buffer to avoid fragmentation

cr0x@server:~$ dig @203.0.113.53 www.example.com A +bufsize=1232 +stats

; <<>> DiG 9.18.24 <<>> @203.0.113.53 www.example.com A +bufsize=1232 +stats
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49811
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
www.example.com.         300     IN      A       93.184.216.34

;; Query time: 20 msec
;; SERVER: 203.0.113.53#53(203.0.113.53) (UDP)
;; WHEN: Tue Dec 31 12:07:47 UTC 2025
;; MSG SIZE  rcvd: 60

Qué significa: Con un tamaño de buffer conservador, tiene éxito. Eso implica problemas de fragmentación/PMTUD entre tú y el resolutor o entre el resolutor y los autoritativos.

Decisión: Tu proveedor puede estar bien pero la ruta de red (posiblemente su borde) está descartando fragmentos. Sigue siendo su problema, pero ahora puedes describirlo en paquetes, no en sensaciones.

Task 10: Inspect your local caching resolver/forwarder configuration (Unbound example)

cr0x@server:~$ sudo unbound-control status
version: 1.19.0
verbosity: 1
threads: 2
modules: 2 [ subnetcache validator ]
uptime: 38122 seconds
options: control(ssl)
unbound (pid 1221) is running...

Qué significa: Unbound está validando (módulo validator cargado). Si el ascendente falla solo en consultas validadas, esto importa.

Decisión: Si estás reenviando a un ascendente validador mientras también validas localmente, no lo hagas. Elige un punto de validación y hazlo predecible.

Task 11: Check resolver logs for validation failures (systemd-journald)

cr0x@server:~$ sudo journalctl -u unbound --since "10 min ago" | tail -n 8
Dec 31 12:05:59 server unbound[1221]: info: validation failure <www.example.com. A>: signature expired
Dec 31 12:06:00 server unbound[1221]: info: error: SERVFAIL <www.example.com. A>: validation failure

Qué significa: Esto es explícito: firmas expiradas (o que aparecen como expiradas). Eso puede ser genuino o debido a desajuste de reloj.

Decisión: Verifica inmediatamente la hora del sistema y la salud de NTP en el resolutor. Si la hora está bien, esto se convierte en un problema autoritativo/proveedor DNSSEC.

Task 12: Verify time sync (DNSSEC cares, a lot)

cr0x@server:~$ timedatectl
               Local time: Tue 2025-12-31 12:08:21 UTC
           Universal time: Tue 2025-12-31 12:08:21 UTC
                 RTC time: Tue 2025-12-31 12:08:21
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Qué significa: El reloj está sincronizado. Bien. Una menos que puede fallar.

Decisión: Si las fallas DNSSEC persisten con tiempo correcto, la falla está arriba o en la cadena de firma/DS del dominio.

Task 13: Check for TCP/53 being blocked (locally or by network policy)

cr0x@server:~$ nc -vz 203.0.113.53 53
Connection to 203.0.113.53 53 port [tcp/domain] succeeded!

Qué significa: TCP/53 es accesible. Si fallara, esperarías que la truncación UDP se convierta en SERVFAIL/timeouts en respuestas grandes.

Decisión: Si TCP/53 está bloqueado, arréglalo antes de culpar a nadie. Si no puedes, debes ajustar EDNS0 a la baja agresivamente.

Task 14: Packet capture to prove the upstream behavior

cr0x@server:~$ sudo tcpdump -ni eth0 host 203.0.113.53 and port 53 -vv -c 6
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:09:01.120001 IP 10.0.1.20.53422 > 203.0.113.53.53: 41277+ A? www.example.com. (33)
12:09:01.141883 IP 203.0.113.53.53 > 10.0.1.20.53422: 41277 ServFail 0/0/1 (40)
12:09:02.001220 IP 10.0.1.20.39511 > 203.0.113.53.53: 5013+ A? www.example.com. (33)
12:09:02.015430 IP 203.0.113.53.53 > 10.0.1.20.39511: 5013 1/0/1 A 93.184.216.34 (60)
6 packets captured
6 packets received by filter
0 packets dropped by kernel

Qué significa: Tienes un registro con marca de tiempo y en la red que muestra que el resolutor del proveedor a veces emite SERVFAIL y a veces tiene éxito. Si ves comportamiento intermitente, así lo pruebas.

Decisión: Si el SERVFAIL llega rápido desde arriba, no es tu firewall descartando respuestas. Si no llega ninguna respuesta, pivota a pruebas de alcance/pérdida de paquetes/problemas de anycast.

Task 15: Test multiple anycast paths by querying from another network namespace or host

cr0x@server:~$ dig @203.0.113.53 www.example.com A +stats
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 21001
;; Query time: 19 msec
;; SERVER: 203.0.113.53#53(203.0.113.53) (UDP)

cr0x@server:~$ ssh cr0x@bastion 'dig @203.0.113.53 www.example.com A +stats'
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10442
;; Query time: 12 msec
;; SERVER: 203.0.113.53#53(203.0.113.53) (UDP)

Qué significa: Misma IP de resolutor, distinto punto de vista, distinto resultado. Eso es clásico de inconsistencia de POP anycast o filtrado regional.

Decisión: Tu escalación debe incluir “falla desde ASN/ubicación A, funciona desde ASN/ubicación B”, más marcas temporales.

Task 16: Confirm whether your resolver is forwarding (and to whom)

cr0x@server:~$ sudo grep -R "forward-addr" /etc/unbound/unbound.conf /etc/unbound/unbound.conf.d 2>/dev/null
/etc/unbound/unbound.conf.d/forward.conf:forward-addr: 203.0.113.53
/etc/unbound/unbound.conf.d/forward.conf:forward-addr: 203.0.113.54

Qué significa: Tu recursión está tercerizada. Eso no es intrínsecamente incorrecto, pero ahora el resolutor del proveedor es una dependencia que debes tratar como tal.

Decisión: Si el proveedor es inestable y no puedes arreglarlo rápido, cambia a recursión completa local o diversifica los reenviadores (con cuidado).

Cómo construir pruebas útiles para el proveedor (sin drama)

Los proveedores no son malvados. Están ocupados. Además su primera respuesta suele ser “funciona para nosotros”. Tu trabajo es volver esa respuesta imposible.

Cómo ve un equipo de operaciones DNS la “prueba”

• IP exacta del resolutor que devuelve SERVFAIL (no “su DNS”).
• Consulta exacta: nombre, tipo, bits DO/CD si son relevantes, y si fue UDP o TCP.
• Marcas temporales con zona horaria y frecuencia (“1/20 consultas falla” o “falla durante 7 minutos”).
• Datos de comparación: la misma consulta tiene éxito contra otro resolutor recursivo.
• Saneamiento de la ruta autoritativa: dig +trace funciona (o muestra dónde falla).
• Extracto de captura de paquetes mostrando el código SERVFAIL o respuestas ausentes.
• Contexto de red: tu rango IP de origen/ASN, región, si hay NAT implicado.

No les envíes una novela; envía un dossier

Una escalación buena es concisa:

• Un párrafo resumen: qué está roto, impacto, cuándo empezó.
• Una lista con viñetas de las IPs de resolutor probadas y resultados.
• Tres salidas de comando como máximo en el primer mensaje. Adjunta el resto si el sistema de tickets lo permite.
• Un extracto de tcpdump o pcap si lo aceptan.

Qué evitar

• “El DNS está caído.” No. Nombra la IP del resolutor y la consulta.
• “Es aleatorio.” Es intermitente. Proporciona tasa de fallo, ventana temporal y si se correlaciona con tamaño EDNS0.
• “Reiniciamos cosas.” Eso huele mal; no es evidencia.

Broma #2: La forma más rápida de que un proveedor actúe es decir “tengo una captura de paquetes”, porque ahora es su problema en alta definición.

Tres micro-historias corporativas (anonimizadas, técnicamente plausibles y dolorosamente familiares)

Incidente causado por una suposición errónea: “SERVFAIL significa que el autoritativo está caído”

Una compañía SaaS de tamaño medio empezó a recibir alarmas: las tasas de error de la API subieron y algunas regiones informaron fallos de inicio de sesión. El on-call vio SERVFAIL para el hostname del proveedor de identidad e hizo lo que mucha gente hace bajo estrés: asumió que el DNS autoritativo del dominio debía estar roto.

Escalaron al proveedor, abrieron un ticket de severidad y empezaron a redactar un aviso para clientes. El proveedor respondió que sus autoritativos estaban sanos y proporcionó sus propios registros de consulta mostrando tráfico normal. El on-call se atrincheró. “Pero mi dig dice SERVFAIL.”

Un ingeniero más calmado preguntó lo básico: “¿Qué resolutor consultaste?” La respuesta fue el reenviador de la compañía, que a su vez reenviaba a un servicio recursivo gestionado incluido con su proveedor de conectividad. Las consultas a un resolutor público funcionaban al instante. dig +trace mostró la delegación y respuestas autoritativas correctas.

La falla real fue la validación DNSSEC en un POP anycast del servicio gestionado. El resolutor del proveedor devolvía SERVFAIL rápidamente para respuestas que eran válidas DNSSEC durante una ventana de rollover de claves. El reenviador de la compañía no tenía diversidad; reenviaba exclusivamente a ese servicio gestionado.

Arreglaron el incidente inmediato cambiando temporalmente los reenviadores y, de forma permanente, ejecutando recursión local en dos regiones con upstreams diversos. El postmortem tuvo una línea incómoda: “Escalamos a la parte equivocada porque no verificamos la ruta autoritativa.” Esa línea evitó futuras vergüenzas.

Optimización que salió mal: “Enviemos todo a forwarders para reducir latencia”

Una compañía de finanzas tenía un clúster Unbound haciendo recursión completa, con caché y validación DNSSEC. Alguien notó que el proveedor en la nube ofrecía “resolutores de baja latencia” dentro del VPC, y propuso una “optimización simple”: cambiar Unbound para reenviar todas las consultas a esos resolutores en la nube.

En tiempos normales, parecía excelente. La latencia mediana bajó. El uso de CPU del resolutor cayó. Todos felicitaron el cambio en una reunión donde nadie preguntó por los modos de fallo.

Tres semanas después, un subconjunto de dominios empezó a devolver SERVFAIL intermitentemente. No todos los dominios, no todas las consultas. El equipo persiguió fantasmas: reintentos de aplicación, pools de conexión, incluso handshakes TLS. Era DNS, pero solo a veces, y solo vía los resolutores en la nube.

Causa raíz: la flota de resolutores en la nube tenía un problema de fragmentación EDNS0 en una ruta específica hacia ciertos servidores autoritativos. Las respuestas UDP por encima de cierto tamaño se descartaban, y el fallback a TCP era inconsistente debido a una política de un appliance de seguridad. La recursión completa en sus propios Unbound había manejado esto mejor porque tenían ajustes EDNS0 conservadores y comportamiento TCP predecible.

La “optimización” creó un nuevo radio de impacto: una dependencia gestionada que no podían ajustar. Revirtieron a recursión completa y mantuvieron el resolutor en la nube solo como reenviador secundario para zonas internas específicas. La lección no fue “nunca uses DNS gestionado”. Fue: no subcontrates una ruta crítica si no puedes observarla y no tienes fallback.

Práctica aburrida pero correcta que salvó el día: resolutores diversos + sondas continuas

Una plataforma retail había sufrido por DNS antes. No catastróficamente—lo suficiente para que resultara caro. Implementaron una política poco emocionante: cada región tendría dos resolutores recursivos, cada uno capaz de recursión completa, cada uno con conectividad upstream independiente. Los clientes tendrían dos resolutores en resolv.conf, y su malla de servicios también usaría diversidad de resolutores.

Además ejecutaban sondas continuas: cada minuto, desde cada región, consultaban un pequeño conjunto de nombres críticos (sus propios endpoints de auth, gateway de pagos y algunas dependencias externas) contra cada resolutor, registrando RCODE, latencia y si se usó TCP.

Una tarde, un pool de resolutores empezó a devolver SERVFAIL para un dominio de gateway de pagos, pero solo en una región. Como tenían telemetría por resolutor, el problema fue obvio en minutos: el resolutor A en esa región estaba mal; el resolutor B funcionaba. Los clientes fallaron automáticamente, así que el impacto al cliente fue mínimo.

Cuando abrieron un ticket con el proveedor de conectividad, no dijeron “DNS es inestable.” Dijeron: “La IP del resolutor X devuelve SERVFAIL para el nombre Y desde la hora T; la IP del resolutor Z no lo hace. Aquí están los recuentos RCODE minuto a minuto y un extracto de tcpdump.” El proveedor arregló un nodo validador roto en ese POP el mismo día.

No pasó nada heroico. Por eso funcionó.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: SERVFAIL solo en el resolutor de tu proveedor; los resolutores públicos funcionan

Causa raíz: Caída recursiva del proveedor, inconsistencia de POP anycast o política del proveedor (filtrado/RPZ).

Solución: Consulta IPs específicas de resolutor directamente, recopila evidencia con tcpdump y cambia/añade resolutores a corto plazo. Escala con IP del resolutor + marcas temporales.

2) Síntoma: SERVFAIL desaparece al usar +cd

Causa raíz: Fallo de validación DNSSEC (cadena DS mala, firmas expiradas, trust anchor equivocado o reloj del resolutor).

Solución: Verifica sincronización horaria; ejecuta dig +trace e inspecciona la cadena DS/DNSKEY; si el resolutor validador ascendente está mal, escala con “la validación falla en el resolutor IP X; en otros funciona”.

3) Síntoma: Respuestas pequeñas funcionan; respuestas grandes SERVFAIL/timeout

Causa raíz: Fragmentación EDNS0/PMTUD; TCP/53 bloqueado; middleboxes que manipulan fragmentos.

Solución: Prueba con +bufsize=1232 y +tcp. Si eso lo arregla, ajusta el tamaño EDNS0 del resolutor, asegura TCP/53 permitido y escala al equipo de red/proveedor con capturas de paquetes.

4) Síntoma: SERVFAIL intermitente varía por región

Causa raíz: Anycast enruta a nodos distintos; un POP está enfermo; estado de caché/validación inconsistente.

Solución: Prueba desde múltiples puntos de vista; incluye IP/region de origen en la evidencia; pide al proveedor que drene/arregle el POP.

5) Síntoma: SERVFAIL para un dominio que acabas de actualizar

Causa raíz: Delegación/DS rota durante rollover DNSSEC; caché negativo obsoleto; propagación autoritativa inconsistente.

Solución: Revisa dig +trace para delegación/DS correctos; reduce TTLs antes de cambios; si ya está roto, coordina la corrección con registrador/parent y espera a que caduquen cachés.

6) Síntoma: Solo algunos clientes fallan; otros tienen éxito en la misma red

Causa raíz: Resolutores diferentes configurados (DHCP), DNS dividido, VPN que empuja resolutores o diferencias de stub/ cache locales.

Solución: Verifica la configuración del resolutor por cliente (resolvectl), estandariza las opciones DHCP y deja de depender de “el DNS que recibió hoy el portátil”.

7) Síntoma: SERVFAIL pero los logs de tu resolutor están vacíos

Causa raíz: No estás consultando realmente el resolutor que crees; o las consultas son interceptadas por un stub local/sidecar/dispositivo NAT.

Solución: Usa dig @IP explícitamente; captura paquetes en el cliente; confirma que el tráfico llega a la IP de resolutor esperada.

8) Síntoma: SERVFAIL después de cambios de “hardening”

Causa raíz: Bloquear DNS sobre TCP, bloquear fragmentos o deshabilitar EDNS0 incorrectamente; ajustes DNSSEC demasiado estrictos.

Solución: Rehabilita TCP/53 y fragmentos según se necesite; ajusta buffer EDNS0; valida DNSSEC con pruebas controladas antes de aplicar cambios a gran escala.

Listas de verificación / plan paso a paso

Step-by-step: from first alert to provider escalation

1. Confirma el alcance del impacto: ¿es un hostname, un resolutor, una región o global?
2. Identifica el resolutor activo en un host afectado (resolvectl status).
3. Reproduce con consultas explícitas: dig @resolver name type +stats.
4. Compara con un segundo resolutor (público o alternativo interno). Anota diferencias en RCODE y latencia.
5. Ejecuta dig +trace para probar que la cadena autoritativa funciona (o localizar dónde falla).
6. Prueba el ángulo DNSSEC: ejecuta con y sin +cd; revisa logs del resolutor validador; verifica sincronización horaria.
7. Prueba el ángulo de transporte: +tcp, +bufsize=1232, y verifica la accesibilidad TCP/53.
8. Captura paquetes mostrando SERVFAIL desde el resolutor ascendente o respuestas ausentes.
9. Documenta la “matriz” de evidencia: IPs de resolutor × puntos de vista × resultados.
10. Mitiga: cambia a resolutores alternativos, habilita fallback o deshabilita temporalmente la validación DNSSEC solo si entiendes el riesgo y tienes aprobación.
11. Escala: envía un resumen corto más la evidencia clave, pide investigación del POP/nodo si sospechas anycast.
12. Seguimiento: sigue sondando y añade monitorización permanente; escribe un postmortem que incluya “cómo detectaremos esto en 2 minutos la próxima vez”.

Quick mitigation checklist (when production is bleeding)

• Cambia clientes a al menos dos resolutores diversos (de distintos proveedores si es posible).
• En reenviadores, añade múltiples upstreams y saludéalos; prefiere ones con redes anycast independientes.
• Si sospechas fragmentación: reduce el tamaño EDNS0 UDP y asegúrate de que TCP/53 esté permitido.
• Si sospechas DNSSEC: verifica la hora primero; no deshabilites la validación globalmente como primer movimiento.
• Reduce la dependencia en un único resolutor recursivo: es un punto único de fallo aunque sea anycast y tenga un SLA elegante.

Evidence bundle checklist (what to attach to the ticket)

• IPs de resolutor probadas y sus RCODEs (SERVFAIL vs NOERROR) para la misma consulta.
• Marcas temporales y zona horaria.
• Salida de dig +trace mostrando respuestas autoritativas.
• Salida de dig mostrando la diferencia con +cd si sospechas DNSSEC.
• Extracto de tcpdump o pcap mostrando SERVFAIL desde el resolutor ascendente.
• Tu IP de origen/egress pública y región (especialmente si anycast está involucrado).

Preguntas frecuentes

1) ¿Por qué mi resolutor devuelve SERVFAIL en lugar de timeout?

Porque algo ascendente respondió con SERVFAIL o tu resolutor alcanzó una falla de validación/política. Un SERVFAIL rápido suele ser una decisión intencional, no pérdida de paquetes.

2) Si dig +trace funciona, ¿el proveedor aún puede tener la culpa?

Sí. +trace evita la recursión caminando la jerarquía. Si +trace funciona pero el resolutor del proveedor devuelve SERVFAIL, el resolutor del proveedor está fallando en recursión, caché, validación, transporte o política.

3) ¿SERVFAIL siempre significa problemas DNSSEC?

No. DNSSEC es una causa común, pero también lo son caídas ascendentes, limitación por tasa, tiempos de espera hacia autoritativos, fallback TCP roto e interferencia de middleboxes.

4) ¿Qué significa cuando +cd hace que la consulta tenga éxito?

Sugiere fuertemente fallo de validación DNSSEC en el resolutor consultado. No es prueba absoluta de un problema del dominio por sí sola—resolutores mal configurados y relojes malos también pueden causarlo.

5) ¿Debería simplemente desactivar la validación DNSSEC para detener el incidente?

Solo como mitigación con tiempo limitado y aceptación explícita del riesgo. Deshabilitar la validación intercambia integridad por disponibilidad. A veces es la decisión correcta de negocio; a menudo es un movimiento de pánico que se vuelve permanente.

6) ¿Por qué solo algunas regiones ven SERVFAIL cuando los resolutores son anycast?

Anycast te enruta a un POP cercano, y “cercano” puede cambiar con eventos de enrutamiento. Un POP puede estar roto mientras otros están bien. Tu evidencia necesita puntos de vista regionales.

7) ¿Cómo demuestro que no es nuestro firewall/NAT?

Si capturas paquetes que muestran una respuesta SERVFAIL ascendente llegando, no es tu firewall descartando respuestas. Si ves consultas salir pero no volver respuestas, necesitas más pruebas: TCP vs UDP, tamaño EDNS, y comprobaciones desde otra ruta de salida.

8) ¿Por qué reducir +bufsize a 1232 ayuda?

Evita la fragmentación en rutas comunes de Internet y se alinea con la guía operativa moderna para DNS sobre UDP. Si ayuda, probablemente tengas pérdida por fragmentación o problemas de PMTUD.

9) ¿Puede el “DNS de seguridad” del proveedor causar SERVFAIL?

Sí. Algunas implementaciones de filtrado devuelven NXDOMAIN, otras SERVFAIL y otras redirecciones “útiles”. Si los resolutores públicos tienen éxito y los del proveedor fallan consistentemente, sospecha política.

10) ¿Qué debo pedirle al proveedor que haga?

Pídeles que investiguen la IP/POP del resolutor específica por fallos de recursión o validación DNSSEC, verifiquen problemas de fragmentación/fallback TCP y confirmen si aplican filtrado/RPZ.

Conclusión: pasos prácticos siguientes

SERVFAIL no es un diagnóstico. Es una demanda de mejores preguntas. La ruta más rápida a la claridad es una comparación controlada: tu resolutor vs otro resolutor, recursión vs trace, validación activada vs desactivada, UDP vs TCP. Luego capturas la prueba.

Pasos que puedes hacer hoy:

• Apunta las IPs de resolutor que usa realmente tu flota. Ponlas en monitorización.
• Añade un pequeño conjunto de sondas DNS continuas que registren RCODE, latencia y uso de TCP por resolutor y por región.
• Asegura que TCP/53 esté permitido donde haga falta, y ajusta EDNS0 de forma conservadora si operas resolutores.
• Diseña para la diversidad de resolutores. Un único recursivo ascendente es un punto único de fallo, aunque sea anycast y tenga un SLA bonito.
• Cuando el proveedor sea el problema, escala con un dossier: IP del resolutor, consulta exacta, marcas temporales, prueba de trace y paquetes. Conseguirás acción en vez de poesía.