Ubuntu 24.04 «Fallo temporal en la resolución de nombres»: deja de adivinar y arregla DNS correctamente

noviembre 24, 2025 • febrero 3, 2026 • Lectura: 24 min • Views: 11

¿Te fue útil?

Si ves Temporary failure in name resolution en Ubuntu 24.04, ya estás perdiendo tiempo de la peor manera posible: el sistema está arriba, la aplicación no funciona y todo el mundo culpa “a la red”.

Este error casi nunca es místico. Normalmente es una rotura muy específica entre tu aplicación y la cadena de resolución: libc → NSS → systemd-resolved → DNS ascendentes (o un stub local) → enrutamiento/firewall → servidor de nombres real. La solución no es “probar 8.8.8.8 y esperar”. La solución es medir cada salto y luego cambiar la única cosa que realmente está mal.

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

Temporary failure in name resolution suele ser devuelto por la capa de resolución cuando una consulta DNS no se puede completar ahora mismo. En términos POSIX, a menudo es EAI_AGAIN que sale de getaddrinfo(). El sistema está diciendo: “Intenté resolver un nombre y no pude alcanzar una cadena de resolutores funcional.”

Lo que no significa:

“Internet está caída.” Tu ruta por defecto podría estar bien.
“DNS está mal configurado.” A veces las opciones DNS están correctas, pero UDP/53 está bloqueado, el MTU es incorrecto, o estás enrutando por la interfaz equivocada.
“Es definitivamente culpa de systemd-resolved.” A menudo solo es el mensajero.

Lo que usualmente significa en producción:

Tu máquina no sabe qué servidores DNS preguntar (configuración mala, vacía o sobrescrita).
Tu máquina sabe qué servidores preguntar, pero no puede alcanzarlos (enrutamiento, firewall, VPN, enlace roto, caída del servidor DNS).
Tu máquina alcanza un servidor DNS que responde a veces (timeouts, pérdida de paquetes, problemas EDNS/MTU, upstream inestable).
Tu máquina pregunta al servidor DNS equivocado por el nombre (split DNS, dominios de búsqueda, precedencia de interfaz equivocada).

Una cita que vale la pena tener en la pared (idea parafraseada): “La esperanza no es una estrategia” — un máximo de SRE ampliamente repetido atribuido a liderazgo de operaciones. DNS merece la misma energía: medir, no adivinar.

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

Este es el camino más rápido hacia el cuello de botella. Ejecútalo en orden. No saltes a las “soluciones” hasta que puedas nombrar el salto que falla.

Primero: ¿es DNS o es enrutamiento?

Resuelve un nombre vía el resolvedor del sistema (getent). Si falla, continúa.
Resuelve usando un servidor DNS conocido y bueno (dig @x.x.x.x). Si eso funciona, tu red upstream está bien y tu cadena local de resolución está rota.
Haz ping a una IP conocida (como tu gateway por defecto o una IP pública si está permitido). Si la conectividad IP está rota, DNS es un síntoma.

Segundo: ¿systemd-resolved está sano y apunta a algo razonable?

resolvectl status: comprueba qué servidores DNS se usan por enlace y globalmente.
ls -l /etc/resolv.conf: confirma si estás usando el stub resolver o un archivo estático, y si eso coincide con tu intención.
systemctl status systemd-resolved: confirma que está en ejecución y no atascado en un bucle.

Tercero: ¿es alcanzable y responde el servidor DNS elegido?

Prueba la alcanzabilidad UDP/TCP al servidor DNS (los timeouts importan más que “rechazado”).
Consulta con dig registros A y AAAA; compara comportamiento. IPv6 suele “funcionar” lo justo para arruinar tu tarde.
Si hay split DNS: asegúrate de que la consulta salga por la interfaz prevista y con las reglas de enrutamiento de dominio correctas.

Broma seca #1: DNS es el único sistema donde “es solo un nombre” puede tumbar la nómina.

Pila DNS de Ubuntu 24.04 en la práctica

Ubuntu 24.04 (como versiones recientes de Ubuntu) normalmente usa:

Netplan para definir la configuración de red (YAML bajo /etc/netplan/).
systemd-networkd o NetworkManager como backend de red, según servidor/escritorio y tu configuración.
systemd-resolved como el resolvedor stub local en caché, normalmente ligado a 127.0.0.53.
NSS (Name Service Switch) reglas en /etc/nsswitch.conf que determinan si las búsquedas usan DNS, files, mDNS, etc.
/etc/resolv.conf como interfaz de compatibilidad para herramientas legadas. En un Ubuntu moderno, a menudo es un enlace simbólico a un archivo gestionado por systemd.

Aquí está el modelo mental práctico. Cuando una app pregunta “¿qué es repo.internal.corp?”

La app llama a getaddrinfo().
glibc consulta /etc/nsswitch.conf (línea hosts:) y elige métodos.
Para DNS, glibc lee /etc/resolv.conf y usa esa lista de nameservers.
Si ese archivo apunta a 127.0.0.53, las consultas van a systemd-resolved.
systemd-resolved elige un servidor DNS ascendente basado en la configuración por interfaz y dominios de enrutamiento, y luego emite la consulta.

Así que cuando “editas resolv.conf,” podrías estar editando un symlink que se sobrescribe, o podrías estar saltándote la ruta de resolución prevista. Puedes hacerlo funcionar temporalmente y aun así estar construyendo una trampa para el Futuro Tú.

Datos interesantes y contexto histórico (breve pero útil)

DNS es anterior a la carrera de la mayoría. Fue diseñado a principios de los 80 como un reemplazo distribuido para un único archivo HOSTS.TXT que todos tenían que descargar.
“resolv.conf” es un fósil que se niega a morir. Sigue siendo la interfaz universal aunque los sistemas modernos tienen reglas DNS dinámicas por enlace.
systemd-resolved introdujo un stub local por defecto. Por eso a menudo ves nameserver 127.0.0.53: no es “incorrecto”, es una capa de indirección.
DNS por UDP es rápido hasta que deja de serlo. La pérdida de paquetes convierte “rápido” en “misteriosamente lento”, porque reintentos y timeouts pueden acumularse a través de librerías y apps.
El fallback a TCP importa más de lo que la gente admite. Respuestas grandes, DNSSEC o ciertos middleboxes pueden forzar TCP/53, y si TCP está bloqueado obtienes timeouts que parecen fallos aleatorios.
Los dominios de búsqueda son herramientas de productividad y generadores de incidencias. Un punto faltante puede disparar múltiples consultas (api se vuelve api.prod.corp, api.corp, etc.), aumentando latencia y confusión.
El caché negativo existe. Si tu resolvedor cachea “NXDOMAIN” y acabas de crear un registro, puedes pasar el TTL discutiendo con la realidad.
El split DNS se volvió común porque las VPN y el SaaS se volvieron comunes. Tu portátil/servidor puede necesitar DNS público para el mundo y privado para nombres internos, simultáneamente.
Los valores por defecto de Ubuntu cambiaron con el tiempo. Versiones antiguas confiaban en resolvconf o escrituras directas de DHCP; las modernas prefieren herramientas systemd. Copiar y pegar playbooks antiguos puede romper cosas silenciosamente.

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

Estas son tareas reales que ejecutaría en un servidor Ubuntu 24.04 durante un incidente. Cada una incluye: comando, ejemplo de salida, qué significa y la decisión que tomas.

Task 1: Confirmar el síntoma usando el resolvedor del sistema (no ping)

cr0x@server:~$ getent ahosts archive.ubuntu.com
getent: Name or service not known

Significado: Esto usa libc/NSS y refleja lo que experimentan la mayoría de las aplicaciones. “Name or service not known” o timeouts aquí confirma que no es solo ping que se comporta raro.

Decisión: Continúa con la depuración de la cadena de resolución. Si getent funciona pero tu app falla, sospecha configuraciones DNS específicas de la aplicación (contenedores, chroot, librerías de resolución personalizadas).

Task 2: Comprobar si el enrutamiento IP funciona en absoluto

cr0x@server:~$ ip route
default via 10.0.0.1 dev ens3 proto dhcp src 10.0.0.42 metric 100
10.0.0.0/24 dev ens3 proto kernel scope link src 10.0.0.42

Significado: Tienes una ruta por defecto vía 10.0.0.1. Si no hay ruta por defecto, DNS puede fallar porque nada puede alcanzar servidores ascendentes.

Decisión: Si falta o está mal la ruta por defecto, arregla la red primero (Netplan, DHCP, estado de interfaz) antes de tocar DNS.

Task 3: Hacer ping al gateway por defecto (sanidad L2 local)

cr0x@server:~$ ping -c 2 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.391 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.412 ms

--- 10.0.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1024ms
rtt min/avg/max/mdev = 0.391/0.401/0.412/0.010 ms

Significado: L2/L3 hacia el gateway está bien. Las fallas DNS son menos probables que “la tarjeta de red está muerta”.

Decisión: Avanza en la pila: configuración del resolvedor y alcanzabilidad DNS.

Task 4: Inspeccionar /etc/resolv.conf (el symlink cuenta la historia)

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

Significado: Este host usa el resolvedor stub de systemd en 127.0.0.53. Si “arreglas DNS” editando /etc/resolv.conf directamente, probablemente se sobrescribirá o ignorará.

Decisión: Usa resolvectl y la configuración de Netplan/NetworkManager en lugar de editar manualmente el archivo.

Task 5: Verificar que systemd-resolved está en ejecución y no degradado

cr0x@server:~$ systemctl status systemd-resolved --no-pager
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
     Active: active (running) since Wed 2025-12-18 09:51:22 UTC; 2h 13min ago
       Docs: man:systemd-resolved.service(8)
             man:resolvectl(1)
   Main PID: 812 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 18712)
     Memory: 7.9M
        CPU: 1.231s
     CGroup: /system.slice/systemd-resolved.service
             └─812 /usr/lib/systemd/systemd-resolved

Significado: El servicio está activo. Eso no garantiza que el DNS ascendente sea alcanzable, pero elimina “el daemon resolved se cayó” de la lista.

Decisión: Revisa la configuración del resolvedor y la alcanzabilidad upstream a continuación.

Task 6: Comprobar la configuración del resolvedor con resolvectl

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

Link 2 (ens3)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.0.0.53
       DNS Servers: 10.0.0.53 10.0.0.54
        DNS Domain: corp.internal

Significado: Los servidores DNS son 10.0.0.53 y 10.0.0.54; dominio de búsqueda corp.internal. Eso parece plausible. Si aquí no aparecen servidores DNS, has encontrado el problema.

Decisión: Si los servidores DNS están vacíos o son incorrectos, arregla Netplan/DHCP/NetworkManager. Si parecen correctos, prueba la alcanzabilidad y el comportamiento de respuesta.

Task 7: Consultar explícitamente a través de systemd-resolved

cr0x@server:~$ resolvectl query archive.ubuntu.com
archive.ubuntu.com: resolve call failed: Temporary failure in name resolution

Significado: Esto confirma que la falla ocurre en o más allá de systemd-resolved (no en alguna configuración DNS específica de la app).

Decisión: Prueba consultas directas a servidores DNS ascendentes para separar “resolved” de “red upstream”.

Task 8: Consultar directamente al servidor DNS ascendente con dig (evitar el stub)

cr0x@server:~$ dig +time=2 +tries=1 @10.0.0.53 archive.ubuntu.com A

; <<>> DiG 9.18.24-1ubuntu1.1-Ubuntu <<>> +time=2 +tries=1 @10.0.0.53 archive.ubuntu.com A
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Significado: El servidor DNS configurado no es alcanzable (o no responde). Esto no es un problema de “systemd-resolved config”; es un problema de conectividad o del servidor DNS en sí.

Decisión: Revisa el enrutamiento hacia el servidor DNS, reglas de firewall, estado de la VPN y si el servidor DNS está activo.

Task 9: Confirmar que puedes alcanzar el servidor DNS a nivel de red

cr0x@server:~$ ping -c 2 10.0.0.53
PING 10.0.0.53 (10.0.0.53) 56(84) bytes of data.
64 bytes from 10.0.0.53: icmp_seq=1 ttl=63 time=1.12 ms
64 bytes from 10.0.0.53: icmp_seq=2 ttl=63 time=1.09 ms

--- 10.0.0.53 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1014ms
rtt min/avg/max/mdev = 1.09/1.10/1.12/0.015 ms

Significado: El servidor es alcanzable por ICMP. Eso no prueba que UDP/53 o TCP/53 estén permitidos, pero es una buena señal.

Decisión: Prueba explícitamente UDP y TCP para DNS.

Task 10: Probar comportamiento UDP/53 y TCP/53 (porque existen middleboxes)

cr0x@server:~$ dig +time=2 +tries=1 @10.0.0.53 archive.ubuntu.com A +notcp

; <<>> DiG 9.18.24-1ubuntu1.1-Ubuntu <<>> +time=2 +tries=1 @10.0.0.53 archive.ubuntu.com A +notcp
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

cr0x@server:~$ dig +time=2 +tries=1 @10.0.0.53 archive.ubuntu.com A +tcp

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

;; QUESTION SECTION:
;archive.ubuntu.com.          IN      A

;; ANSWER SECTION:
archive.ubuntu.com.   60      IN      A       91.189.91.81

;; Query time: 24 msec
;; SERVER: 10.0.0.53#53(10.0.0.53) (TCP)
;; WHEN: Wed Dec 18 12:06:12 UTC 2025
;; MSG SIZE  rcvd: 59

Significado: Las consultas UDP agotan el tiempo, pero TCP funciona. Eso es clásico “UDP/53 bloqueado en algún lugar” (firewall local, ACL de red, grupo de seguridad, o una política de seguridad DNS demasiado estricta).

Decisión: Arregla la política de firewall/red para UDP/53, o fuerza TCP como medida temporal (no ideal).

Task 11: Revisar reglas de firewall local (UFW y nftables)

cr0x@server:~$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
        chain input {
                type filter hook input priority filter; policy drop;
                ct state established,related accept
                iif "lo" accept
                tcp dport 22 accept
        }
        chain output {
                type filter hook output priority filter; policy accept;
        }
}

Significado: La salida está aceptada, así que el firewall local probablemente no bloquea UDP/53 saliente. Si la política de la cadena de salida fuera drop o tuvieras una denegación explícita, ese sería el culpable.

Decisión: Si el firewall local está limpio, revisa ACLs/ grupos de seguridad/VPC NACLs ascendentes, o el firewall del propio servidor DNS.

Task 12: Confirmar qué backend gestiona el enlace (NetworkManager vs networkd)

cr0x@server:~$ networkctl status ens3
● 2: ens3
                     Link File: /usr/lib/systemd/network/99-default.link
                  Network File: /run/systemd/network/10-netplan-ens3.network
                          Type: ether
                         State: routable (configured)
                  Online state: online
                       Address: 10.0.0.42 (DHCP4)
                       Gateway: 10.0.0.1
                           DNS: 10.0.0.53 10.0.0.54

Significado: Esta interfaz está gestionada por systemd-networkd vía un archivo generado por Netplan. Tus ajustes DNS deben corregirse en Netplan (o DHCP), no en NetworkManager.

Decisión: Edita /etc/netplan/*.yaml adecuadamente y aplica.

Task 13: Inspeccionar la configuración DNS de Netplan (y detectar “parece bien, se comporta mal”)

cr0x@server:~$ sudo netplan get
network:
  version: 2
  ethernets:
    ens3:
      dhcp4: true

Significado: El DNS viene de DHCP, no de una configuración estática. Si DHCP está entregando servidores DNS muertos, fallarás aunque la configuración del host parezca “limpia”.

Decisión: Arregla las opciones DHCP upstream, o anula DNS localmente en Netplan para este rol de host.

Task 14: Anular servidores DNS en Netplan (la manera correcta) y aplicar

cr0x@server:~$ sudo tee /etc/netplan/50-dns-override.yaml >/dev/null <<'EOF'
network:
  version: 2
  ethernets:
    ens3:
      dhcp4: true
      nameservers:
        addresses: [10.0.0.53, 10.0.0.54]
        search: [corp.internal]
EOF

cr0x@server:~$ sudo netplan apply

Significado: Has declarado la intención en la interfaz soportada. Si algo lo sobrescribe más tarde, ahora tienes un artefacto de configuración para auditar.

Decisión: Revisa resolvectl status y ejecuta una consulta de nuevo. Si aún falla, no es un problema de “falta de servidores DNS”.

Task 15: Revisar logs del journal para resolved (los timeouts dejan huellas)

cr0x@server:~$ sudo journalctl -u systemd-resolved --since "20 min ago" --no-pager
Dec 18 11:52:07 server systemd-resolved[812]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 10.0.0.53.
Dec 18 12:02:14 server systemd-resolved[812]: DNS server 10.0.0.53: Timeout while contacting DNS server.
Dec 18 12:02:19 server systemd-resolved[812]: Switching to DNS server 10.0.0.54.

Significado: Resolved está agotando el tiempo y fallando por conmutación. “Degraded feature set” suele apuntar a problemas de MTU/fragmentación, manejo EDNS0 roto o middleboxes.

Decisión: Si múltiples servidores DNS agotan el tiempo, es conectividad. Si solo uno está mal, quítalo/reemplázalo. Si EDNS0 provoca fallos, revisa MTU/path y el soporte EDNS del servidor DNS.

Task 16: Validar el orden NSS (a veces ni siquiera usas DNS)

cr0x@server:~$ grep -E '^\s*hosts:' /etc/nsswitch.conf
hosts:          files mymachines mdns4_minimal [NOTFOUND=return] dns

Significado: DNS se consulta después de files y algo de lógica mDNS. Eso es normal en muchas instalaciones de Ubuntu. Si estás en un entorno servidor y mDNS causa retrasos, esta línea puede importar.

Decisión: Si las búsquedas se cuelgan antes de fallar, considera si mDNS u otros servicios locales de nombres están retrasando. No “optimices” esto sin entender el radio de impacto (ver historias más adelante).

Broma seca #2: Si codificas DNS en todas partes, eventualmente ejecutarás un sistema distribuido hecho enteramente de excepciones.

Tres microhistorias corporativas desde el frente

Incidente causado por una suposición equivocada: “No puede ser DNS porque la IP responde al ping”

Una empresa mediana operaba una flota de servidores Ubuntu en una VPC cloud. Un martes, las compilaciones empezaron a fallar con el familiar error durante instalaciones de paquetes. El canal de incidentes se llenó rápido: los nodos de compilación podían hacer ping al gateway NAT, podían hacer curl a una IP pública, e incluso podían acceder al repositorio de artefactos por IP. Así que la suposición temprana fue: “DNS está bien; el repo está caído”.

El repo no estaba caído. Los nodos de compilación usaban un reenviador DNS corporativo, accesible solo mediante una regla de grupo de seguridad que había sido recientemente “ajustada”. ICMP estaba permitido, TCP/443 estaba permitido, pero UDP/53 saliente desde esa subred se había eliminado. No fue malicioso: simplemente alguien optimizando reglas con una hoja de cálculo.

El equipo perdió horas porque seguían probando lo incorrecto. Hacer ping al servidor DNS tenía éxito, lo que reforzó la suposición. Pero las consultas DNS eran UDP y se descartaban silenciosamente. Las herramientas de compilación reintentaban, alcanzaban timeouts y caían en comportamientos inconsistentes según el lenguaje y librerías. Así que parecía intermitente.

La solución fue aburrida: restaurar UDP/53 egress desde esa subred hacia los reenviadores y documentar que DNS no es “solo alcanzabilidad”. Después añadieron una prueba canaria que ejecutaba dig +notcp y dig +tcp por separado, porque “DNS funciona” no es un booleano único.

Optimización que salió mal: cachear más fuerte (y cachear respuestas equivocadas)

En otra empresa, un equipo de plataforma quería despliegues más rápidos. Notaron muchas consultas DNS repetidas durante pulls de contenedores, descubrimiento de servicios y telemetría. Su idea fue: aumentar agresivamente el caché y reducir la carga en los resolvedores upstream.

Empujaron cambios de resolvedor a gran escala. El volumen de consultas cayó. Las gráficas mejoraron. Luego empezó la rareza: algunos hosts no alcanzaban servicios nuevos durante minutos tras un despliegue. Otros resolvían un servicio a una IP antigua mucho después de que el servicio se hubiera movido. Unos pocos nodos “se arreglaban solos” tras reinicios, lo que hacía sentir el incidente sobrenatural.

La causa raíz no era “el caché es malo”. La causa raíz fue cacheo sin disciplina. Los registros de servicio tenían TTL bajos por una razón (failover rápido, blue/green). Forzando cachés más largos y superponiendo caches (cache del nodo más cache del reenviador), multiplicaron efectivamente el comportamiento del TTL. El caché negativo añadió otra vuelta: respuestas NXDOMAIN transitorias quedaron fijadas.

Revirtieron las configuraciones agresivas de caché y en su lugar atacaron el cuello de botella real: capacidad y latencia de los resolvedores upstream, además de TTLs sensatos alineados con la mecánica de despliegue. El rendimiento mejoró sin hacer que DNS mintiera a la aplicación.

Práctica aburrida pero correcta que salvó el día: configuración DNS por rol y una prueba inequívoca

Una organización financiera ejecutaba servidores Ubuntu 24.04 en múltiples zonas de red: cara al usuario, app interna y datos restringidos. Cada zona tenía necesidades DNS ligeramente distintas. La aproximación tentadora fue “una imagen dorada” con “una configuración de resolvedor”. No lo hicieron así.

Mantuvieron fragmentos Netplan por rol: cada rol declaraba sus servidores DNS y dominios de búsqueda explícitamente, con DHCP permitido para direccionamiento pero no confiable para detalles de resolvedor. El equipo de red aún proveía DNS vía DHCP, pero los hosts no dependían de ello ciegamente.

La parte clave: una comprobación de salud que corría en cada host, cada pocos minutos, y reportaba tres medidas: (1) búsqueda getent a un nombre interno, (2) dig a cada servidor DNS configurado por UDP, y (3) una prueba de fallback TCP. La comprobación producía modos de fallo inequívocos: “resolvedor local roto” vs “servidor DNS inalcanzable” vs “UDP bloqueado”.

Cuando un cambio upstream rompió UDP para una zona, la alarma no decía “resolución de nombres falló”. Decía “UDP/53 bloqueado hacia dns-a; TCP/53 funciona.” El equipo de red arregló el ACL en minutos porque la descripción del problema era precisa, y el equipo de plataforma no perdió tiempo reiniciando servicios como ritual.

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

Estos son los patrones que veo repetidamente en Ubuntu 24.04. Los síntomas se parecen; las soluciones no.

1) Síntoma: `apt update` falla, pero `ping 1.1.1.1` funciona

Causa raíz: cadena del resolvedor rota o DNS upstream inalcanzable, mientras el enrutamiento general funciona.
Solución: Usa resolvectl status para identificar servidores DNS activos; luego dig @server para probar alcanzabilidad. Arregla DHCP/Netplan DNS o firewall/ACL para UDP/TCP 53.

2) Síntoma: `/etc/resolv.conf` muestra nameserver correcto, pero sigue revirtiendo

Causa raíz: /etc/resolv.conf está gestionado (symlink a systemd-resolved o generado por NetworkManager). Las ediciones manuales se sobrescriben.
Solución: Configura DNS en Netplan (networkd) o NetworkManager, o ajusta /etc/systemd/resolved.conf si realmente quieres overrides globales. No luches contra el generador.

3) Síntoma: Nombres internos fallan, nombres públicos funcionan (o viceversa)

Causa raíz: Split DNS enrutado mal (interfaz equivocada, dominios de enrutamiento faltantes, DNS de VPN no aplicado).
Solución: Revisa DNS por enlace y dominios en resolvectl status. Asegura que el enlace correcto tenga el DNS Domain adecuado y que el cliente VPN se integre correctamente (o configura dominios por enlace vía Netplan/NetworkManager).

4) Síntoma: DNS funciona un tiempo tras el reinicio, luego falla

Causa raíz: Renovación DHCP cambia servidores DNS, reconexión VPN cambia prioridad de enlace, o scripts cloud-init/red reescriben la config.
Solución: Identifica quién escribe: revisa journalctl para eventos de red, confirma la configuración Netplan, y si es necesario bloquea DNS en Netplan o NetworkManager. Evita ediciones “puntuales”.

5) Síntoma: `dig` funciona, pero las aplicaciones siguen fallando

Causa raíz: La app usa una ruta de resolvedor distinta (contenedor con su propio resolv.conf, configuración DNS estática, ajustes JVM), o la configuración NSS difiere en ese entorno.
Solución: Prueba con getent en el host y dentro del contenedor. Compara /etc/resolv.conf y /etc/nsswitch.conf en ambos contextos. Arregla en la capa correcta.

6) Síntoma: consultas UDP agotan el tiempo, TCP funciona

Causa raíz: UDP/53 bloqueado o manipulado; a veces MTU/fragmentación/EDNS causa que respuestas UDP grandes fallen.
Solución: Permite UDP/53. Si sospechas EDNS/MTU, busca “degraded feature set” en logs de resolved y valida path MTU o soporte EDNS del servidor DNS.

7) Síntoma: búsquedas muy lentas, luego fallos intermitentes

Causa raíz: Expansión de dominios de búsqueda causando múltiples consultas; pérdida de paquetes; uno de varios servidores DNS está haciendo blackhole.
Solución: Usa resolvectl statistics (si está disponible) y dig con +tries=1 +time=1 contra cada servidor. Quita servidores muertos; reduce dominios de búsqueda para roles de servidor.

Listas de verificación / plan paso a paso (hazlo aburrido y correcto)

Paso a paso: restaurar DNS en un host Ubuntu 24.04 roto

Confirma que es real: ejecuta getent ahosts example.com. Si funciona, tu problema es de nivel superior (proxy, TLS, configuración de app).
Confirma enrutamiento: ip route y ping al gateway.
Revisa el modo del resolvedor: ls -l /etc/resolv.conf.
Inspecciona la configuración de resolved: resolvectl status y anota:
- Servidores DNS globales
- Servidores DNS por enlace
- Dominios de búsqueda/enrutamiento
- Qué enlace está marcado como ruta por defecto
Evita la pila: dig @<dns-server> example.com A con timeout corto. Hazlo para cada servidor configurado.
Prueba UDP vs TCP: dig +notcp y dig +tcp al mismo servidor.
Revisa firewall local: ufw status verbose y nft list ruleset.
Arregla al propietario correcto de la configuración:
- Si la interfaz la gestiona networkd: corrige YAML de Netplan y netplan apply.
- Si la gestiona NetworkManager: usa nmcli para establecer DNS y propiedades de la conexión.
- Si DHCP está errado: corrige la opción 6 de DHCP upstream, luego renueva el lease.
Valida tras el cambio: resolvectl query, getent, y un flujo real (apt update si ese es el camino que fallaba).
Estabiliza: añade una pequeña comprobación DNS en tu monitorización para detectar deriva y fallos parciales antes que los usuarios.

Lista operativa: prevenir el próximo incidente

Estandariza “quién posee la configuración DNS” por rol de host: solo DHCP, anulación Netplan o política NetworkManager. Elige uno.
Asegura al menos dos servidores DNS, pero no listes secundarios muertos “para más tarde”. Un secundario muerto aún puede costarte segundos por búsqueda según el comportamiento de reintento.
Documenta dominios de split DNS y qué interfaz los provee (especialmente con clientes VPN y redes de overlay).
Prueba DNS UDP y TCP en CI para imágenes base si operas en redes fuertemente filtradas.
Mantén los dominios de búsqueda cortos para servidores. Los portátiles de desarrollador pueden permitirse conveniencia; servicios de producción quieren determinismo.
Decide si soportas IPv6. Si está medio soportado, te apuntas a timeouts extraños.

Preguntas frecuentes

1) ¿Por qué Ubuntu muestra `nameserver 127.0.0.53` en `/etc/resolv.conf`?

Ese es el stub local de systemd-resolved. Las aplicaciones consultan localhost; resolved reenvía a los servidores DNS reales según la configuración por enlace y cachea respuestas.

2) ¿Debo desactivar systemd-resolved para “arreglar DNS”?

Sólo si tienes una razón clara y un plan. Desactivarlo puede funcionar, pero es una herramienta contundente que a menudo rompe split DNS, comportamiento de VPN y mantenimiento futuro. Primero arregla la alcanzabilidad upstream o corrige Netplan/NetworkManager.

3) Edité `/etc/resolv.conf` y funcionó—¿por qué se rompió después?

Porque ese archivo a menudo se genera. Tu edición o bien modificó el archivo stub (que se regenera) o reemplazó un symlink que un paquete/servicio espera. La solución duradera correcta está en Netplan, NetworkManager o la configuración de resolved.

4) ¿Por qué algunas herramientas funcionan y otras fallan (por ejemplo, `dig` funciona, `apt` falla)?

dig puede consultar un servidor específico directamente, evitando la ruta del resolvedor del sistema. apt normalmente usa el resolvedor de libc y lo que el host provee vía NSS y /etc/resolv.conf. Prueba con getent para igualar el comportamiento de la aplicación.

5) ¿Cuál es la forma más rápida de distinguir “problema de configuración DNS” vs “servidor DNS inalcanzable”?

Ejecuta resolvectl status para ver qué servidor estás usando, luego dig @ese-servidor example.com con un timeout corto. Si la consulta directa agota el tiempo, el camino al servidor es el problema. Si funciona, tu cadena local de resolved está mal enrutada.

6) ¿Por qué importa UDP si TCP funciona?

La mayoría de consultas DNS usan UDP por defecto por rendimiento. Si UDP/53 está bloqueado, muchos clientes harán timeouts antes de volver a TCP (si lo hacen). Eso parece fallos intermitentes y picos de latencia.

7) ¿Cómo causan las VPNs “Temporary failure in name resolution” tras desconectarse?

Los clientes VPN suelen añadir DNS y dominios de enrutamiento por enlace, y luego fallan al limpiar o restaurar el estado previo. Terminas con servidores DNS inalcanzables tras la desconexión de la VPN, o con otra interfaz convirtiéndose en “predeterminada” para el enrutamiento DNS.

8) ¿Debo poner resolutores públicos (como 1.1.1.1) en servidores como fallback?

No como reflejo. En entornos corporativos puedes filtrar nombres internos o romper controles de política. En producción, prefiere resolvedores destinados a esa zona de red y asegúrate de que sean alcanzables con las reglas de firewall correctas.

9) Mis servidores DNS son alcanzables, pero los logs de resolved dicen “degraded feature set UDP instead of UDP+EDNS0.” ¿Es malo?

Es una pista. Suele apuntar a un path que descarta paquetes UDP fragmentados o maneja mal EDNS0. Podrías seguir “funcionando”, pero estás cerca de fallos intermitentes—especialmente con DNSSEC, registros TXT grandes o resolvedores con mucha carga.

10) ¿Cuál es un “workaround” de emergencia seguro durante una caída?

Usa una anulación temporal de Netplan para apuntar a servidores DNS internos conocidos y buenos para esa zona, aplícalo y valida. Evita editar /etc/resolv.conf a mano salvo que aceptes que puede ser sobrescrito y documentes la desviación.

Conclusión: próximos pasos que puedes hacer hoy

Deja de tratar Temporary failure in name resolution como un evento meteorológico. En Ubuntu 24.04, los fallos DNS son diagnosticables si respetas la cadena: aplicación → NSS → resolv.conf → systemd-resolved → DNS upstream → política de red.

Próximos pasos que rinden de inmediato:

Adopta el guion rápido de diagnóstico y enséñalo a tu rotación on-call.
Estandariza la propiedad de DNS (Netplan vs NetworkManager vs DHCP) por rol de host, y documentalo en el repositorio que construye tus imágenes.
Añade una pequeña comprobación canaria de DNS que distinga: fallo de resolvedor local, fallo del servidor upstream y problemas de política UDP/TCP.
Cuando lo arregles, arréglalo en la capa correcta—para que permanezca arreglado tras renovaciones, reinicios y drama con VPN.