DNS «Fallo temporal en la resolución de nombres»: las 5 causas raíz y el orden de corrección

Qué significa realmente el error (y qué no significa)

«Temporary failure in name resolution» suele ser el resolvedor en espacio de usuario diciendo: «No pude obtener una respuesta ahora mismo.»
En Linux con glibc, esto frecuentemente corresponde a EAI_AGAIN de getaddrinfo()—un fallo de consulta transitorio.
Eso es distinto a «el nombre no existe».

Si quieres razonar como SRE, traduce el mensaje a uno de estos cubos:

• No puedo alcanzar un resolvedor (ruta de red, firewall, IP equivocada, resolvedor caído).
• Alcancé un resolvedor pero no responde (timeouts, UDP bloqueado, problemas EDNS, límites de tasa).
• Recibí una respuesta pero el cliente la rechazó (validación DNSSEC, truncamiento, bloqueo de fallback a TCP, caché corrupta).
• Hice la pregunta equivocada (dominios de búsqueda, ndots, sorpresas por split-horizon).

La clave: el error trata sobre el proceso (intento de resolución), no sobre la verdad del nombre.
Por eso los reinicios aleatorios «ayudan» a veces—porque reinicias una caché, un socket o una carrera. También por eso esos mismos reinicios te volverán a fastidiar.

Una cita para tener en la pared:
La esperanza no es una estrategia. — General Gordon R. Sullivan

Las 5 causas raíz (en el orden en que debes arreglarlas)

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

Tu objetivo no es convertirte en filósofo del DNS. Tu objetivo es encontrar el cuello de botella en minutos.
Aquí está el guion que uso cuando producción está ardiendo y la gente escribe «¿DNS cae?» en cada chat.

Primero: confirma si es configuración local, daemon local o la red

• Comprueba qué resolvedor estás usando (resolv.conf, estado de systemd-resolved).
• Intenta una consulta contra la IP de resolvedor configurada directamente con dig.
• Si eso falla, prueba la alcanzabilidad básica al resolvedor (ping no es suficiente, pero es un comienzo).

Segundo: establece un resolvedor de control y compara

• Consulta el mismo nombre vía un resolvedor conocido bueno (uno público o un resolvedor interno diferente).
• Si el control funciona, el problema probablemente es tu resolvedor o tu ruta hacia él.
• Si el control también falla, sospecha del DNS autoritativo o restricciones de red más amplias.

Tercero: decide si tratas con timeouts, SERVFAIL o comportamiento del cliente

• Timeouts sugieren ruta de red/firewall o resolvedor sobrecargado descartando paquetes.
• SERVFAIL sugiere fallo de recursión, problemas DNSSEC o delegación rota upstream.
• Lento y luego falla sugiere expansión por dominios de búsqueda, ndots o bloqueo del fallback a TCP.

Broma #1: DNS es como una guía telefónica que ocasionalmente decide que es una antología de poesía. Técnicamente sigue siendo «texto», emocionalmente inútil.

Tareas prácticas: comandos, salidas, decisiones (12+)

Abajo hay tareas reales que puedes ejecutar en un host Linux. Cada una incluye qué significa la salida y la decisión que tomas.
Ejecútalas en orden hasta que aparezca una contradicción. Las contradicciones son donde vive la verdad.

Tarea 1: Ver qué es realmente /etc/resolv.conf

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Jan  2 10:11 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Significado: Este host usa el listener stub de systemd-resolved (127.0.0.53). Si systemd-resolved está caído, DNS está caído.

Decisión: Comprueba la salud de systemd-resolved a continuación. Si resolv.conf es un archivo regular, inspecciona sus líneas nameserver directamente.

Tarea 2: Inspeccionar nameservers y dominios de búsqueda

cr0x@server:~$ cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search corp.example dev.example

Significado: Las búsquedas pueden expandirse vía search. Los nombres cortos pueden provocar múltiples consultas y demoras.

Decisión: Al probar, siempre intenta el FQDN y evita ambigüedades. Ten en cuenta los dominios de búsqueda ante “lento y luego falla.”

Tarea 3: Comprobar el estado de systemd-resolved y qué DNS upstream usa

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.20.30.53
       DNS Servers: 10.20.30.53 10.20.30.54
        DNS Domain: corp.example

Significado: systemd-resolved está activo y tiene resolvers upstream configurados (10.20.30.53/54).

Decisión: Consulta esos resolvers upstream directamente con dig @10.20.30.53. Si el estado falta o está vacío, arregla la configuración local primero.

Tarea 4: Verificar que el listener stub local realmente esté escuchando

cr0x@server:~$ ss -ulpn | grep ':53 '
UNCONN 0      0         127.0.0.53%lo:53        0.0.0.0:*    users:(("systemd-resolve",pid=812,fd=14))

Significado: El resolvedor stub está escuchando en UDP 53 en loopback.

Decisión: Si no lo ves, reinicia/repara systemd-resolved (o deja de usar el stub y apunta resolv.conf a resolvers reales).

Tarea 5: Consultar un nombre a través del resolvedor del sistema (línea base)

cr0x@server:~$ getent ahosts example.com
93.184.216.34   STREAM example.com
93.184.216.34   DGRAM  example.com
93.184.216.34   RAW    example.com

Significado: La ruta del resolvedor libc funciona (NSS + DNS). Esto está más cerca de lo que usan las aplicaciones que dig.

Decisión: Si getent falla pero dig funciona, sospecha de la configuración NSS, nscd o del comportamiento del resolvedor específico de la aplicación.

Tarea 6: Consultar el resolver upstream configurado directamente (evitar el stub local)

cr0x@server:~$ dig @10.20.30.53 example.com +time=2 +tries=1

; <<>> DiG 9.18.24-1ubuntu1.3-Ubuntu <<>> @10.20.30.53 example.com +time=2 +tries=1
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50612
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; Query time: 14 msec
;; SERVER: 10.20.30.53#53(10.20.30.53) (UDP)
;; WHEN: Tue Jan 02 10:22:48 UTC 2026
;; MSG SIZE  rcvd: 56

Significado: El resolver upstream es accesible y responde rápido.

Decisión: Si esto funciona pero el resolvedor del sistema falla, céntrate en el daemon local, NSS o comportamiento de search/ndots. Si hace timeout, ve a comprobaciones de ruta de red.

Tarea 7: Distinguir timeout vs SERVFAIL vs NXDOMAIN

cr0x@server:~$ dig @10.20.30.53 does-not-exist.example.com +time=2 +tries=1

; <<>> DiG 9.18.24-1ubuntu1.3-Ubuntu <<>> @10.20.30.53 does-not-exist.example.com +time=2 +tries=1
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1243
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Significado: NXDOMAIN es una respuesta definitiva de «el nombre no existe». Eso no es «fallo temporal».

Decisión: Si tu app muestra «fallo temporal» mientras dig muestra NXDOMAIN, sospecha de dominios de búsqueda y de que la app consulta un nombre distinto al que crees.

Tarea 8: Comprobar la alcanzabilidad cruda a la IP del resolver y la selección de ruta

cr0x@server:~$ ip route get 10.20.30.53
10.20.30.53 via 10.20.10.1 dev eth0 src 10.20.10.44 uid 1000
    cache

Significado: El kernel sabe cómo alcanzaría el resolver y qué interfaz usa.

Decisión: Si esta ruta es incorrecta (p. ej., pasa por una interfaz VPN), has encontrado tu «fallo temporal.» Arregla ruteo/split tunneling VPN.

Tarea 9: Probar que UDP 53 funciona (no solo ICMP)

cr0x@server:~$ nc -u -vz 10.20.30.53 53
Connection to 10.20.30.53 53 port [udp/domain] succeeded!

Significado: Puedes enviar UDP al puerto 53. No demuestra que lleguen respuestas, pero es una señal rápida.

Decisión: Si esto falla, deja de debatir registros DNS. Tienes un firewall, grupo de seguridad o problema de ruteo.

Tarea 10: Probar que TCP 53 funciona (necesario para truncamiento/DNSSEC/respuestas grandes)

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

Significado: El fallback a TCP es posible. Si UDP funciona pero TCP no, algunas consultas «fallarán al azar»—especialmente con DNSSEC o muchas entradas.

Decisión: Si TCP está bloqueado, arréglalo. Soluciones como «desactivar DNSSEC» son el último recurso y a menudo equivocadas.

Tarea 11: Detectar truncamiento y comportamiento de fallback a TCP

cr0x@server:~$ dig @10.20.30.53 dnssec-failed.org +dnssec +bufsize=4096

; <<>> DiG 9.18.24-1ubuntu1.3-Ubuntu <<>> @10.20.30.53 dnssec-failed.org +dnssec +bufsize=4096
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 32801
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Significado: SERVFAIL en un dominio conocido por fallar en DNSSEC indica que el resolvedor aplica validación DNSSEC.

Decisión: Si tus dominios internos dan SERVFAIL por DNSSEC, arregla firmas/registros DS. No «apagues DNSSEC» sin entender la magnitud del impacto.

Tarea 12: Rastrear la delegación para ver si los servidores autoritativos están rotos

cr0x@server:~$ dig +trace app.corp.example

; <<>> DiG 9.18.24-1ubuntu1.3-Ubuntu <<>> +trace app.corp.example
.                       518400  IN      NS      a.root-servers.net.
...
example.                172800  IN      NS      ns1.example.
example.                172800  IN      NS      ns2.example.
corp.example.           86400   IN      NS      ns1.corp.example.
corp.example.           86400   IN      NS      ns2.corp.example.
app.corp.example.       60      IN      A       10.50.0.25

Significado: Trace muestra la cadena de delegación. Si se detiene en algún paso, has encontrado dónde se rompe la resolución.

Decisión: Si el trace falla en tu capa autoritativa, céntrate ahí: firewall hacia servidores autoritativos, NS rotos, glue obsoleto o maestros caídos.

Tarea 13: Confirmar la vista del resolver por interfaz (systemd-resolved)

cr0x@server:~$ resolvectl dns eth0
Link 2 (eth0): 10.20.30.53 10.20.30.54

Significado: Los servidores DNS se asignan por enlace; las interfaces VPN pueden sobrescribir esto.

Decisión: Si el enlace equivocado tiene los DNS activos, arregla NetworkManager/VPN o configura dominios de ruteo DNS correctamente.

Tarea 14: Observar tráfico DNS real (demuestra que los paquetes salen y vuelven)

cr0x@server:~$ sudo tcpdump -ni eth0 '(udp port 53 or tcp port 53)' -vv
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:25:11.122334 IP 10.20.10.44.41321 > 10.20.30.53.53: 47924+ A? example.com. (29)
10:25:11.136702 IP 10.20.30.53.53 > 10.20.10.44.41321: 47924 1/0/1 A 93.184.216.34 (45)

Significado: Tienes tráfico bidireccional. Si solo ves consultas salientes y no respuestas, el problema es upstream (resolvedor caído) o de ruta (ACL/seguridad).

Decisión: Usa esto para terminar discusiones. Los paquetes no mienten; la gente sí.

Tarea 15: Comprobar el orden NSS (puede hacer que DNS parezca roto)

cr0x@server:~$ grep '^hosts:' /etc/nsswitch.conf
hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname

Significado: Si mDNS se consulta primero, algunos nombres pueden bloquearse o cortocircuitarse inesperadamente.

Decisión: Para servidores, mantenlo aburrido: típicamente files dns (más lo que tu entorno realmente necesite).

Tarea 16: Detectar «ndots» y opciones del resolvedor que cambian el comportamiento

cr0x@server:~$ grep '^options' /etc/resolv.conf
options edns0 trust-ad

Significado: Las opciones cambian tamaño de paquete, comportamiento de confianza y patrones de reintento.

Decisión: Si Kubernetes está involucrado, revisa su ndots (a menudo 5). ndots alto + muchos dominios de búsqueda puede crear tormentas de consultas y «fallos temporales.»

Broma #2: Lo único más temporal que «Fallo temporal en la resolución de nombres» es la promesa de que «arreglaremos DNS después.»

Tres microhistorias de la vida corporativa (anonimizadas)

Microhistoria 1: El incidente causado por una suposición equivocada

Una empresa SaaS mediana ejecutaba un par de resolvers recursivos internos en dos centros de datos. Los entornos de desarrollo también los apuntaban.
Un viernes, un equipo desplegó un nuevo perfil de cliente VPN «para simplificar el acceso remoto». Se probó. Funcionó. La gente podía acceder a apps internas.
Luego las compilaciones empezaron a fallar, luego los despliegues en producción empezaron a agotar tiempo al buscar paquetes, y el monitor encendió el mensaje clásico.

La suposición equivocada: «DNS es interno, así que enviar DNS por la VPN siempre es correcto.»
El perfil empujó un servidor DNS accesible solo desde dentro de la VPN—bien para laptops—pero el mismo perfil se aplicó por accidente a un conjunto de runners CI.
Esos runners no tenían la interfaz VPN arriba. Simplemente recibieron un nuevo /etc/resolv.conf apuntando a una IP que nunca podían alcanzar.

Los ingenieros pasaron los primeros 45 minutos mirando archivos de zona autoritativos, porque alguien vio «resolución de nombres» y de inmediato culpó los registros.
El avance vino cuando una persona ejecutó ip route get a la IP del resolver y notó que intentaba enrutar por una interfaz que no existía en ese host.

La solución fue aburrida: separar la configuración DHCP/VPN DNS de la infraestructura de servidores, restringir quién puede cambiar la configuración del resolvedor en CI,
y añadir un job canario que ejecute getent hosts contra unos pocos nombres críticos desde la pool de runners.
DNS no estaba «caído». Simplemente nunca fue alcanzable desde las máquinas que importaban.

Microhistoria 2: La optimización que salió mal

Una empresa grande tenía problemas de rendimiento: resolvers internos manejaban un enorme volumen de consultas desde clústeres Kubernetes.
Alguien hizo lo que parecía sensato: afinar el caché agresivamente y aumentar el buffer UDP EDNS «para reducir los fallbacks a TCP.»
También activaron validación DNSSEC «porque seguridad lo pidió», sin hacer un inventario cuidadoso de las zonas internas.

Durante una semana todo parecía bien. Luego empezaron fallos intermitentes de resolución. No en todas partes. Solo para un conjunto de apps que dependían de un dominio de un partner.
El error era «fallo temporal». Las métricas del resolver mostraron un aumento en SERVFAIL para ese dominio partner, pero la latencia era por lo demás buena.

El contragolpe: los servidores autoritativos del partner manejaban mal respuestas EDNS grandes y ocasionalmente enviaban respuestas malformadas.
Antes, los resolvers hacía fallback a TCP con más frecuencia y tenían éxito. Ahora, con UDP más grande y validación DNSSEC, la tasa de fallos aumentó y se volvió SERVFAIL.
Mientras tanto, los reintentos de Kubernetes amplificaron la carga e hicieron que el resolver pareciera «inestable.»

La solución: reducir el buffer EDNS a un valor más seguro, mantener TCP 53 abierto en todas partes e implementar excepciones de reenvío por zona para el dominio problemático.
La lección no fue «no optimices.» La lección fue «trata DNS como un sistema distribuido con muchos bordes rotos.»
Si tu optimización depende de que todos los demás sean perfectos, no es una optimización; es un nuevo modo de caída.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Una organización de servicios financieros ejecutaba resolvers internos en tres sitios. Nada fancy. Dos instancias por sitio. Checks de salud simples.
La parte poco glamurosa: mantenían un pequeño dashboard de «sanidad DNS» que probaba resolución desde cada subred principal contra cada resolver, cada minuto,
usando UDP y TCP. Era de esas cosas que nadie celebraba, lo cual es señal de buena ingeniería.

Una tarde, un cambio en una política de firewall bloqueó TCP 53 desde un subconjunto de subredes de aplicaciones «porque solo usamos UDP para DNS.»
La mayoría de nombres siguieron resolviendo. Luego algunos críticos empezaron a fallar—específicamente aquellos con respuestas grandes y respuestas firmadas DNSSEC.
Las apps reportaron «fallo temporal». Los equipos entraron en pánico porque los fallos eran esporádicos y dependientes del nombre.

El dashboard de sanidad DNS se encendió de inmediato: UDP éxito, TCP fallo, localizado a un conjunto de subredes.
Eso redujo el espacio del problema de «quizá el resolver está muriendo» a «una regla de firewall específica rompió TCP 53.»

Revirtieron la política rápidamente. Sin heroísmos. Sin capturas de paquetes durante la sala de guerra.
La práctica aburrida—probar ambos protocolos y múltiples puntos de vista—convirtió un incidente de tarde en una molestia breve.

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

1) «Funciona en un servidor pero no en otro»

Síntoma: Misma app, misma subred, resultado distinto. Un host resuelve; otro devuelve «fallo temporal».

Causa raíz: Diferentes fuentes de configuración DNS (systemd-resolved vs resolv.conf estático, sobreescritura por VPN, DNS por enlace).

Solución: Compara ls -l /etc/resolv.conf y resolvectl status entre hosts; estandariza la propiedad y evita agentes aleatorios que reescriban la config del resolvedor.

2) «dig funciona, la app falla»

Síntoma: dig devuelve respuestas, pero los logs de la aplicación muestran fallos temporales.

Causa raíz: La app usa la ruta libc/NSS; dig no. El orden NSS, nscd o la expansión search/ndots pueden romper o ralentizar cosas.

Solución: Prueba con getent ahosts; revisa /etc/nsswitch.conf; reproduce con FQDN; reduce dominios de búsqueda; audita ndots en entornos de contenedores.

3) «Fallos intermitentes, especialmente para algunos dominios»

Síntoma: Algunos nombres resuelven, otros hacen timeout; los fallos varían por dominio.

Causa raíz: Fallback a TCP bloqueado, problemas EDNS/fragmentación o inestabilidad autoritativa para ciertas zonas.

Solución: Verifica TCP 53 end-to-end; ejecuta dig +trace; considera bajar el buffer EDNS en los resolvers; confirma que el firewall permita UDP fragmentado o permite TCP.

4) «Todo falla justo después de reinicio / despliegue»

Síntoma: Tras reiniciar, muchos timeouts; luego se estabiliza.

Causa raíz: Tormenta de misses de caché contra una pequeña piscina de resolvers; agotamiento de CPU/sockets del resolver.

Solución: Añade capacidad de resolvedor, habilita caché en la capa correcta, escalona reinicios y monitoriza qps/latencia. No reinicies todos los resolvers a la vez salvo que disfrutes el caos.

5) «Solo dentro de contenedores / solo en pods de Kubernetes»

Síntoma: El nodo resuelve; el pod falla con fallo temporal.

Causa raíz: DNS del clúster (CoreDNS) caído, reenvío upstream roto, ndots + dominios de búsqueda generando tormentas de consultas o políticas de red bloqueando DNS.

Solución: Consulta la IP del servicio CoreDNS directamente desde un pod; revisa la política de red para UDP/TCP 53; reduce ndots si procede; asegura caché local en nodos (si se usa) esté sana.

6) «Usuarios VPN bien, usuarios de oficina rotos (o viceversa)»

Síntoma: La resolución depende de si estás en VPN.

Causa raíz: DNS split-horizon o configuración de split tunneling incorrecta; resolvedor equivocado para el contexto de red.

Solución: Usa ruteo por dominio (DNS routing domains) en lugar de un resolvedor global; asegura que los resolvers sean alcanzables desde cada segmento de red.

7) «SERVFAIL para dominios internos después de habilitar DNSSEC»

Síntoma: Nombres internos devuelven SERVFAIL; los clientes ven fallos temporales.

Causa raíz: Cadena DNSSEC rota (DS equivocado, firmas expiradas, claves desajustadas), o zonas internas no aptas para validación.

Solución: Firma correctamente o deshabilita la validación solo para las zonas internas específicas mediante la política del resolvedor. Deshabilitar a lo bruto es una trampa de seguridad y disponibilidad.

Listas de verificación / plan paso a paso

Lista A: «Fallo temporal» en un solo host

1. Identifica el resolvedor en uso: ls -l /etc/resolv.conf y cat /etc/resolv.conf.
2. Si usa systemd-resolved: resolvectl status y ss -ulpn | grep ':53 '.
3. Prueba la ruta libc: getent ahosts example.com.
4. Prueba la alcanzabilidad directa al resolver: dig @<resolver-ip> example.com +time=2 +tries=1.
5. Diferencia el tipo de fallo: ¿es timeout, SERVFAIL o NXDOMAIN?
6. Valida la ruta de red: ip route get <resolver-ip>, luego comprueba UDP y TCP 53.
7. Prueba a nivel de paquetes si es necesario: tcpdump para ver consultas y respuestas.
8. Sólo entonces mira el DNS upstream o autoritativo con dig +trace.

Lista B: Modo incidente multi-host

1. Elige tres puntos de vista: un host fallando, un host sano, un host en una subred diferente.
2. Compara la configuración del resolvedor entre ellos.
3. Elige dos nombres de prueba: uno interno crítico, uno externo estable.
4. Consulta vía el resolvedor configurado y vía un resolvedor de control.
5. Busca patrones: ¿solo AAAA falla? ¿solo respuestas grandes fallan? ¿solo ciertos dominios?
6. Revisa métricas/logs del resolver si lo posees (qps, latencia, tasa SERVFAIL, memoria, descriptores de archivo).
7. Confirma cambios de firewall para UDP/TCP 53 y problemas de MTU/fragmentación.
8. Comunica claramente: «Timeouts al IP del resolver desde la subred X» es mejor que «DNS parece inestable.»

Resumen del orden de corrección (imprímelo mentalmente)

1. Propiedad y corrección de la configuración del cliente (¿qué resolvedor uso?).
2. Ruta hacia el resolvedor (ruteo + firewall, UDP y TCP).
3. Salud del resolvedor y comportamiento de recursión/reenvío.
4. Comportamiento del cliente: search/ndots/NSS que causan reintentos y demoras.
5. DNS autoritativo y corrección de delegación/DNSSEC.

Datos interesantes y contexto histórico (DNS tiene su lore)

• DNS reemplazó el dolor de escalar HOSTS.TXT: las primeras redes usaban un único archivo hosts distribuido a todos; no escaló cuando las redes crecieron.
• Paul Mockapetris diseñó DNS en 1983, introduciendo el sistema de nombres jerárquico y distribuido que todavía usamos hoy.
• UDP se eligió por velocidad, pero TCP siempre fue parte del protocolo para respuestas más grandes y transferencias de zona.
• Los resolvers cachean también respuestas «no»: el caching negativo existe para reducir carga por misses repetidos, lo que puede hacer que los errores tipográficos se sientan «pegajosos».
• TTL es orientativo pero poderoso: cambios agresivos de TTL pueden amplificar patrones de tráfico y causar tormentas de misses durante outages o despliegues.
• EDNS (Extensión de mecanismos para DNS) llegó para ampliar DNS sin reemplazarlo, incluyendo payloads UDP más grandes—también fuente de problemas de fragmentación.
• DNSSEC añade autenticidad pero también tamaño y complejidad; fallos de validación suelen aparecer como SERVFAIL en lugar de una explicación clara.
• «Lame delegation» es un término real: significa que un nameserver está listado para una zona pero no puede responder autoritativamente por ella.
• Los dominios de búsqueda se diseñaron para conveniencia en entornos empresariales, pero a escala pueden multiplicar el volumen de consultas y la latencia dramáticamente.

Preguntas frecuentes

1) ¿»Fallo temporal en la resolución de nombres» siempre es una caída del servidor DNS?

No. A menudo es local: resolvedor equivocado configurado, systemd-resolved caído o problema de ruta/firewall.
Trátalo como «el intento de resolución falló», no como «los registros DNS están mal.»

2) ¿Por qué reiniciar el servicio a veces lo arregla?

Porque podrías estar limpiando una caché, reabriendo sockets o cambiando temporizaciones. Eso no es la causa raíz; es una moneda al aire con mejor marketing.
Usa los reinicios solo como medida temporal mientras recopilas evidencia (dig/getent/tcpdump).

3) ¿Cuál es la diferencia entre NXDOMAIN y este error?

NXDOMAIN significa que el nombre no existe en DNS (respuesta negativa autoritativa). «Fallo temporal» suele significar timeouts o SERVFAIL durante la recursión.
Llevan a acciones distintas: NXDOMAIN suele ser configuración/typo; fallo temporal es conectividad/salud/delegación.

4) ¿Por qué funciona con dig pero no con curl o mi app?

dig consulta DNS directamente. Muchas apps usan el resolvedor de libc vía NSS, que puede consultar files, mDNS, LDAP u otras fuentes primero,
y puede aplicar dominios de búsqueda y políticas de reintento. Prueba con getent ahosts para imitar el comportamiento de la aplicación.

5) ¿Cómo sé si el problema es UDP o TCP?

Prueba ambos. Usa nc -u -vz <resolver> 53 y nc -vz <resolver> 53, luego confirma con tcpdump.
Si TCP 53 está bloqueado, las respuestas DNS grandes fallarán de forma impredecible.

6) ¿Puede MTU o fragmentación causar «fallo temporal»?

Sí. Respuestas UDP DNS grandes pueden fragmentarse. Si los fragmentos se pierden (común en algunos túneles y firewalls), obtienes timeouts.
Eso parece «temporal» porque las respuestas pequeñas todavía tienen éxito. Permite TCP 53 y considera tamaños EDNS UDP más seguros en los resolvers.

7) ¿Cuál es la forma más rápida de comprobar si es mi resolver o DNS autoritativo upstream?

Consulta un resolvedor de control. Si tu resolvedor configurado falla pero el control funciona, sospecha de tu resolvedor o de la ruta hacia él.
Si ambos fallan, ejecuta dig +trace para ver dónde se rompe la delegación.

8) ¿Cómo empeora esto Kubernetes?

Kubernetes suele usar múltiples dominios de búsqueda y un valor ndots alto, lo que puede multiplicar las consultas DNS por lookup.
Durante problemas parciales de DNS, esa multiplicación amplifica la carga. Soluciona asegurando salud de CoreDNS, permitiendo UDP/TCP 53
y siendo deliberado con la configuración de ndots/search.

9) ¿Deberíamos simplemente codificar IPs para evitar fallos de DNS?

Codificar convierte un sistema dinámico en uno frágil. Evitas un modo de fallo y compras tres nuevos: endpoints obsoletos, failover roto y rotaciones desordenadas.
Si DNS es poco fiable, arregla la capa del resolver y el monitoreo. No esculpas el problema en piedra.

10) ¿Qué monitoreo realmente detecta esto temprano?

Comprobaciones DNS multi-vista contra cada resolvedor, para UDP y TCP, para un conjunto pequeño de nombres críticos (internos y externos).
Rastrea percentiles de latencia y tasas SERVFAIL/timeout. Alerta por tendencia, no solo por fallo total.

Conclusión: próximos pasos prácticos

«Fallo temporal en la resolución de nombres» rara vez es misterioso. Es simplemente por capas.
La solución es dejar de adivinar y trabajar la pila en el orden correcto: configuración del cliente, ruta de red, salud del resolvedor, comportamiento del cliente, DNS autoritativo.

Pasos que puedes hacer hoy:

• Estandariza la propiedad de DNS en hosts (decide: systemd-resolved, NetworkManager o estático; no «todo a la vez»).
• Asegura que tanto UDP como TCP 53 estén permitidos entre clientes y resolvers, y entre resolvers y upstreams.
• Añade una comprobación simple de sanidad DNS desde subredes clave (UDP + TCP) y trata aumentos de SERVFAIL/timeouts como alerta temprana.
• Audita dominios de búsqueda y ndots en plataformas de contenedores; reduce la multiplicación de consultas antes de que reduzca tu sueño.
• Cuando ocurra el próximo incidente, usa el guion: demuestra dónde se detienen los paquetes y luego arregla esa capa—no se requieren sesiones de espiritismo DNS.