Ubuntu 24.04: sudo lento — correcciones de DNS/hostname que eliminan la demora (caso #66)

Qué suele significar “sudo lento” (y qué no significa)

Cuando sudo va lento, rara vez es por “sudo siendo pesado”. Suele ser que sudo invoca la pila de servicios de nombres del sistema—los módulos NSS de glibc—y luego espera en una ruta de resolvedor de la que no te dabas cuenta que dependías.

El patrón clásico en Ubuntu 24.04:

• La demora ocurre antes del prompt de la contraseña: búsqueda/inicialización (hostname, NSS, PAM, DNS, SSSD, LDAP, Kerberos, etc.).
• La demora ocurre después de introducir la contraseña: autenticación de directorio, módulos PAM, directorios home en red, búsquedas de grupos o destinos de registro.
• La demora es de 5 segundos: sospechosamente como una ventana de timeout de DNS o una ruta de reserva esperando a expirar.
• La demora es de 10/15/20 segundos: varios resolvedores consultados en secuencia, o timeouts en A y AAAA, o reintentos.

También: no pierdas el tiempo culpando a CPU, disco o “snap”. Si la máquina responde bien por lo demás y solo la escalada de privilegios va lenta, estás en el terreno de la resolución de nombres y búsquedas de identidad.

Una verdad operativa: sudo es una prueba de fiabilidad. Si la resolución de nombres es inestable, sudo te lo hará notar siendo irritante.

Broma #1: DNS es la dependencia que todos olvidan hasta que falla. Luego se convierte en toda la personalidad de todos.

Guía rápida de diagnóstico

Si estás de guardia o conectado por SSH a una máquina en una ventana de cambios, no necesitas un tour filosófico de resolvedores. Necesitas una secuencia que encuentre el cuello de botella en minutos.

Primero: confirma que es resolución de nombres y no PAM/autenticación

1. Temporiza sudo y compara con sudo -n true.
2. Prueba sudo con un entorno limpio.
3. Observa las llamadas de resolución de nombres con strace (rápido y definitivo).

Segundo: verifica hostname y la sanidad de la resolución local

1. Comprueba que /etc/hostname coincide con hostnamectl.
2. Asegúrate de que /etc/hosts mapea 127.0.1.1 (o 127.0.0.1) a tu hostname/FQDN de forma coherente.
3. Confirma que getent hosts $(hostname) responde instantáneamente.

Tercero: valida la ruta del resolvedor y la alcanzabilidad del servidor DNS

1. Inspecciona resolvectl status, /etc/resolv.conf (symlink) y los dominios de búsqueda.
2. Consulta tu hostname adelante y reverso con resolvectl query y dig.
3. Busca timeouts en journalctl -u systemd-resolved.

Detente cuando tengas la pistola humeante

No estás tratando de “mejorar DNS”. Estás eliminando un timeout determinista en una ruta crítica. Arregla lo que va lento; deja todo lo demás en paz.

Datos interesantes y contexto (las partes que la gente olvida)

• Dato 1: sudo suele resolver el hostname local para registrar “dónde se ejecutó el comando”, y algunas configuraciones también resuelven el usuario invocante y los grupos mediante NSS.
• Dato 2: En Debian/Ubuntu, 127.0.1.1 en /etc/hosts es una convención de larga data para mapear el hostname local en sistemas no exclusivamente loopback, especialmente donde la IP real puede cambiar (portátiles, DHCP).
• Dato 3: NSS de glibc es modular y depende del orden. Un módulo lento (DNS, mdns, sss) en la cadena puede bloquear todo lo que llame a getaddrinfo().
• Dato 4: systemd-resolved introdujo DNS dividido y enrutamiento por enlace para consultas; genial para VPNs, y también excelente para exponer dominios de búsqueda mal configurados.
• Dato 5: Las búsquedas DNS inversas (registros PTR) frecuentemente faltan en redes corporativas—especialmente para rangos de estaciones “aleatorias”—y aun así muchos sistemas las intentan para registro o políticas.
• Dato 6: Una consulta AAAA (IPv6) puede introducir demoras en redes solo IPv4 si el resolvedor intenta v6 primero y espera timeouts en lugar de un NXDOMAIN rápido.
• Dato 7: mDNS (.local vía Avahi) y DNS pueden interactuar mal si tus elecciones de hostname o dominio de búsqueda son descuidadas; “local” es una zona especial en muchos entornos.
• Dato 8: Una lista de dominios de búsqueda demasiado larga puede multiplicar las consultas: cada lookup de nombre simple se expande en varios intentos FQDN.
• Dato 9: La “pausa de cinco segundos” a menudo no es aleatoria: es un timeout por defecto del resolvedor que literalmente puedes contar.

Una idea parafraseada que debería imprimirse en la página interna de cada cuaderno de operaciones: la fiabilidad viene de reducir los traspasos y las dependencias ocultas—especialmente las que expiran por timeout (parafraseado de Gene Kim).

Mídelo correctamente: haz que la demora confiese

Antes de cambiar nada, mide. No porque adoremos las hojas de cálculo, sino porque “se siente más rápido” es la forma en que terminas con una pila de configuraciones que nadie entiende.

Lo que quieres:

• Duración exacta de la demora.
• Si ocurre antes o después de la contraseña.
• Si coincide con timeouts de DNS (5s, 10s, etc.).
• Qué syscall está bloqueando (usualmente connect() a un servidor DNS, o lecturas esperando por él).

Causas raíz: DNS, hostname, NSS y aliados

1) Hostname no resoluble localmente

La máquina conoce su hostname, pero no puede resolverlo a una dirección rápidamente. Entonces los programas que hacen un simple “¿cómo me llamo?” seguido de “¿cuál es mi dirección?” caen en DNS, y DNS cae en timeouts.

La solución habitual en Ubuntu: asegúrate de que /etc/hosts tenga una entrada para el hostname (y opcionalmente el FQDN) en loopback. La idea es rapidez y determinismo, no elegancia.

2) Servidor DNS inalcanzable (o DNS por enlace incorrecto)

Tu resolvedor apunta a servidores DNS que no son alcanzables desde este host (DNS obsoleto de VPN, DNS de oficina antiguo, red de laboratorio muerta). Cada lookup espera timeouts antes de caer en respaldo.

3) Dominios de búsqueda demasiado ambiciosos

Los dominios de búsqueda son útiles—hasta que multiplican consultas. Un lookup de nombre simple como myhost puede convertirse en:

• myhost.corp.example
• myhost.dev.example
• myhost.example
• …y luego quizá el nombre sin sufijo

Si cada paso hace timeout, has creado un generador de demoras. La solución es reducir dominios de búsqueda o usar FQDN donde importe.

4) Orden de NSS que incluye proveedores de identidad de red lentos

Si /etc/nsswitch.conf dice “consulta SSSD/LDAP/DNS para todo”, incluso las búsquedas locales de usuario/grupo pueden bloquearse. sudo frecuentemente comprueba membresías de grupo e identidad de usuario. Eso es normal. Hacerlo a través de una ruta de red rota no lo es.

5) DNS inverso y suposiciones de registro

Algunos entornos usan DNS inverso para auditoría. Otros desencadenan consultas inversas accidentalmente por cómo se resuelven hostnames o se registran eventos. Los PTR faltantes no son fatales, pero los timeouts sí.

6) Desajuste de IPv6 y timeouts de AAAA

Si tu red descarta paquetes IPv6 o bloquea transporte DNS v6, las búsquedas AAAA pueden “fallar lentamente”. Puedes arreglar la red, desactivar IPv6 roto o ajustar el comportamiento del resolvedor. La elección correcta depende de si IPv6 está soportado intencionadamente.

Broma #2: Si quieres sentirte poderoso, arregla un timeout de DNS y observa cómo una queja de “Linux lento” se evapora en menos de un segundo.

Tareas prácticas (comandos, salidas y decisiones)

Estos son comandos reales que puedes ejecutar en Ubuntu 24.04. Cada tarea incluye qué buscar y la decisión que tomas.

Task 1: Time the pain

cr0x@server:~$ time sudo -v

real    0m5.214s
user    0m0.012s
sys     0m0.020s

Qué significa: ~5.2s de tiempo real con CPU despreciable sugiere espera en I/O (a menudo DNS).

Decisión: Trátalo como latencia de dependencia externa, no carga del sistema. Pasa a las comprobaciones de hostname/DNS.

Task 2: Separate auth from lookup with non-interactive sudo

cr0x@server:~$ time sudo -n true

real    0m5.108s
user    0m0.004s
sys     0m0.006s

Qué significa: Sigue lento incluso sin prompt. Esto no es “retraso por tipeo humano” ni manejo de contraseña por PAM.

Decisión: Concéntrate en la inicialización previa a la autenticación: resolución de hostname, NSS, resolvedor, búsquedas en sudoers.

Task 3: Check if the delay is tied to hostname resolution

cr0x@server:~$ hostname
app-node-7

cr0x@server:~$ time getent hosts $(hostname)
10.10.40.77     app-node-7.corp.example app-node-7

real    0m5.014s
user    0m0.003s
sys     0m0.006s

Qué significa: getent también va lento. No es específico de sudo; es servicio de nombres.

Decisión: Arregla la ruta NSS/DNS. Sudo mejorará como efecto secundario.

Task 4: Verify local hostname mapping in /etc/hosts

cr0x@server:~$ grep -nE '^(127\.0\.0\.1|127\.0\.1\.1)' /etc/hosts
1:127.0.0.1 localhost
2:127.0.1.1 ubuntu

Qué significa: El hostname es app-node-7, pero 127.0.1.1 apunta a ubuntu. Ese desajuste a menudo desencadena búsquedas DNS por el hostname real.

Decisión: Actualiza /etc/hosts para mapear 127.0.1.1 a tu hostname real (y opcionalmente FQDN).

Task 5: Confirm what the system thinks its hostname is

cr0x@server:~$ hostnamectl status
 Static hostname: app-node-7
       Icon name: computer-vm
         Chassis: vm
      Machine ID: 7c9d6e4f9c3d4c3a9d3b9d5d8c0c0e1a
         Boot ID: 2a4f4d8a0d824d1c9c4f2a1a7a3d8a9b
  Operating System: Ubuntu 24.04.1 LTS
            Kernel: Linux 6.8.0-41-generic
      Architecture: x86-64

Qué significa: El hostname está estático y correcto. El desajuste probablemente está en la resolución local, DNS o ambos.

Decisión: No cambies el hostname solo para arreglar la resolución; corrige el mapeo.

Task 6: Inspect NSS order (this is where delays hide)

cr0x@server:~$ grep -nE '^(hosts|passwd|group):' /etc/nsswitch.conf
8:passwd:         files systemd sss
9:group:          files systemd sss
12:hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname

Qué significa: La búsqueda de hosts prueba files, luego mDNS minimal, luego DNS, luego myhostname. Ese orden puede forzar búsquedas de red antes del atajo local del hostname.

Decisión: Considera mover myhostname más arriba, o asegúrate de que /etc/hosts esté correcto para que files resuelva instantáneamente.

Task 7: Confirm systemd-resolved is in play and what DNS it uses

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

Link 2 (ens18)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.10.0.53
       DNS Servers: 10.10.0.53 10.10.0.54
        DNS Domain: corp.example

Qué significa: El sistema usa modo stub resolver y apunta a servidores DNS corporativos.

Decisión: Si esos servidores no son alcanzables desde este host/segmento de red, arregla la asignación en netplan/VPN o configura DNS por enlace correcto.

Task 8: Check the /etc/resolv.conf symlink and contents

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

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

Qué significa: Las peticiones van al stub local 127.0.0.53, luego systemd-resolved las reenvía a DNS upstream configurados.

Decisión: Depura la alcanzabilidad y los timeouts upstream vía logs de resolved y consultas directas.

Task 9: Query your hostname via resolved and watch latency

cr0x@server:~$ time resolvectl query $(hostname)
app-node-7: 10.10.40.77                          -- link: ens18

-- Information acquired via protocol DNS in 5.0062s.
-- Data is authenticated: no

Qué significa: El resolvedor tardó ~5 segundos en responder. Es la misma demora que ves en sudo.

Decisión: Confirma por qué el DNS upstream es lento: servidor inalcanzable, firewall, ruta equivocada, dominios de búsqueda rotos o timeouts de DNS inverso.

Task 10: Look for resolved timeouts in journald

cr0x@server:~$ sudo journalctl -u systemd-resolved --since "10 min ago" | tail -n 30
Oct 10 09:55:11 server systemd-resolved[812]: Sending query via TCP since UDP failed.
Oct 10 09:55:16 server systemd-resolved[812]: DNS server 10.10.0.53 unreachable, trying next.
Oct 10 09:55:21 server systemd-resolved[812]: DNS server 10.10.0.54 unreachable, trying next.
Oct 10 09:55:21 server systemd-resolved[812]: Using degraded feature set UDP instead of TCP for DNS server 10.10.0.53.

Qué significa: Los servidores DNS upstream son inalcanzables. Resolved está ciclando servidores y modos de transporte, consumiendo tiempo.

Decisión: Arregla el enrutamiento/firewall/VPN, o cambia los DNS para este enlace a unos alcanzables. No “tunes los timeouts” como primera medida.

Task 11: Prove network reachability to DNS servers

cr0x@server:~$ ping -c 2 10.10.0.53
PING 10.10.0.53 (10.10.0.53) 56(84) bytes of data.

--- 10.10.0.53 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1014ms

cr0x@server:~$ nc -vz -w2 10.10.0.53 53
nc: connect to 10.10.0.53 port 53 (tcp) timed out: Operation now in progress

Qué significa: Sin respuesta ICMP y TCP/53 expira por timeout. Aunque ICMP esté bloqueado, el timeout en TCP/53 es una señal contundente.

Decisión: Confirma las IPs DNS correctas para este subnet/VPC; arregla reglas de security group/firewall; o configura resolvedores alternativos alcanzables.

Task 12: Watch sudo itself with strace (fast, brutal truth)

cr0x@server:~$ sudo strace -f -tt -o /tmp/sudo.trace sudo -n true

cr0x@server:~$ tail -n 25 /tmp/sudo.trace
12:01:10.102345 connect(7, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
12:01:10.102612 sendto(7, "\244\243\1\0\0\1\0\0\0\0\0\0\10app-node-7\4corp\7example\0\0\1\0\1", 40, MSG_NOSIGNAL, NULL, 0) = 40
12:01:15.110991 recvfrom(7, 0x7ffd3b0d9a40, 2048, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
12:01:15.111244 close(7) = 0

Qué significa: El bloqueo es una consulta DNS vía el stub local. Ves un salto de ~5 segundos antes de que recvfrom haga timeout.

Decisión: Deja de debatir. Arregla la alcanzabilidad DNS o el mapeo local del hostname para que sudo no necesite DNS para sí mismo.

Task 13: Validate forward and reverse DNS explicitly

cr0x@server:~$ dig +time=2 +tries=1 app-node-7.corp.example A

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> +time=2 +tries=1 app-node-7.corp.example A
;; connection timed out; no servers could be reached

cr0x@server:~$ dig +time=2 +tries=1 -x 10.10.40.77 PTR

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> +time=2 +tries=1 -x 10.10.40.77 PTR
;; connection timed out; no servers could be reached

Qué significa: No se puede alcanzar DNS en absoluto. El DNS inverso también falla, pero eso es síntoma de la misma falta de alcanzabilidad.

Decisión: Corrige la selección de DNS upstream y la ruta de red; no lo tapes con options timeout: a menos que sea modo emergencia.

Task 14: Confirm netplan DNS configuration (common after upgrades/templates)

cr0x@server:~$ sudo netplan get
network:
  ethernets:
    ens18:
      addresses:
      - 10.10.40.77/24
      gateway4: 10.10.40.1
      nameservers:
        addresses:
        - 10.10.0.53
        - 10.10.0.54
        search:
        - corp.example
  version: 2

Qué significa: Netplan establece explícitamente servidores DNS. Si esos no son alcanzables desde esta red, es un bug de configuración, no un problema transitorio.

Decisión: Cambia nameservers por los correctos para este entorno (o elimina overrides si DHCP debería proveerlos).

Task 15: Quick containment test: add hostname to /etc/hosts

cr0x@server:~$ sudoedit /etc/hosts

cr0x@server:~$ grep -n '127.0.1.1' /etc/hosts
2:127.0.1.1 app-node-7.corp.example app-node-7

cr0x@server:~$ time sudo -n true

real    0m0.085s
user    0m0.004s
sys     0m0.008s

Qué significa: La demora desaparece. Has evitado DNS para la ruta de resolución del hostname local.

Decisión: Mantén este arreglo incluso después de reparar DNS. El mapeo local es un seguro barato contra futuras rarezas del DNS.

Task 16: If SSSD/LDAP is involved, test identity lookup latency

cr0x@server:~$ time id $USER
uid=1001(cr0x) gid=1001(cr0x) groups=1001(cr0x),27(sudo),1002(devops)

real    0m4.932s
user    0m0.000s
sys     0m0.008s

Qué significa: Incluso id va lento. Eso es NSS (posiblemente SSSD) esperando a un proveedor de red.

Decisión: Revisa el estado de SSSD y la alcanzabilidad del directorio upstream; considera dejar cuentas locales con prioridad files y asegurar que los proveedores de directorio estén sanos.

Soluciones que funcionan (y por qué)

Fix 1: Make the hostname resolvable locally (the boring, correct move)

Pon tu hostname en /etc/hosts. Sí, incluso si tienes DNS. Sí, incluso si eres “cloud native”. Se trata de eliminar una dependencia de red de una ruta local de escalado de privilegios.

Patrón recomendado en Ubuntu:

• 127.0.0.1 localhost
• 127.0.1.1 yourhost.yourdomain yourhost

Por qué funciona: NSS consulta files primero (normalmente). Eso resuelve inmediatamente y nunca toca DNS.

Fix 2: Correct DNS servers for the actual network you’re on

Si apuntas a servidores DNS que están detrás de una VPN a la que no estás conectado o en una VPC diferente, tienes timeouts garantizados. Arregla la asignación de DNS en la fuente:

• Config estática en Netplan: establece nameservers alcanzables.
• DHCP: asegura que la opción DHCP entregue DNS correctos para ese subnet.
• VPN split DNS: asegura que el DNS por enlace se active solo cuando la VPN esté arriba.

Fix 3: Reduce search domains (and stop single-label lookups in scripts)

Una lista larga de búsqueda es un fan-out autoinfligido. Si heredaste una lista con cinco sufijos, córtala. Si no puedes, deja de usar hostnames cortos en automatización. Usa FQDN en scripts y configs.

Fix 4: Clean up /etc/nsswitch.conf ordering (with restraint)

Tenga cuidado: los cambios en NSS pueden tener efectos amplios. Pero en entornos con necesidades locales previsibles, puedes reordenar hosts: para evitar módulos lentos.

Objetivos típicos razonables:

• Asegurar que files esté primero.
• Asegurar que myhostname no esté al final si dependes de él.
• Evitar mDNS a menos que lo uses realmente.

Si tu flota depende de mDNS para portátiles de desarrollo, perfecto. ¿En servidores? Normalmente no.

Fix 5: If reverse DNS is required, make PTR records real

Si herramientas de seguridad/auditoría esperan búsquedas PTR, entonces la falta de PTR es un defecto, no una mera excusa. Añade PTR para las IPs de servidores. Haz que forward y reverse coincidan. Tus futuros informes de incidentes serán más cortos y menos iracundos.

Fix 6: Handle IPv6 honestly (don’t half-support it)

Si IPv6 está soportado, haz que DNS y enrutamiento funcionen de extremo a extremo. Si no lo está, desactívalo de forma consistente (o al menos evita que el resolvedor persiga rutas rotas). El soporte parcial de IPv6 es una manera fiable de crear demoras intermitentes que nadie reproduce en laboratorio.

Tres microhistorias del mundo corporativo

Mini-story #1: The incident caused by a wrong assumption

Acababan de migrar un conjunto de runners de build internos a otro segmento de red. El equipo asumió “DNS es universal”, porque el nuevo segmento tenía salida a Internet y podía resolver dominios públicos.

Todo parecía bien hasta el primer día de parches. Ingenieros se conectaron por SSH, ejecutaron sudo apt-get y esperaron. La pausa fue consistente—unos cinco segundos—en cada comando privilegiado. Empezaron a culpar al nuevo kernel, al agente EDR, y una persona incluso sugirió “Ubuntu 24.04 simplemente es más pesado”.

El problema real fue simple y silenciosamente humillante: la plantilla de netplan tenía hardcodeados servidores DNS que solo eran alcanzables desde el segmento antiguo. El DNS público funcionaba a través de un forwarder local, pero las zonas internas no. Y los hostnames eran internos.

Cuando alguien temporizó getent hosts $(hostname) y vio la misma pausa, el misterio se evaporó. Reemplazaron la lista de DNS por los resolvedores correctos por segmento y añadieron el hostname a /etc/hosts como guardarraíl.

Dos lecciones quedaron: “el DNS público funciona” no es “DNS funciona”, y “solo afecta a sudo” a menudo significa “afecta la resolución de nombres en una ruta crítica”.

Mini-story #2: The optimization that backfired

Un equipo de plataforma quería una identidad de host “más limpia”. Eliminó entradas de hostname en 127.0.1.1 de /etc/hosts vía gestión de configuración, insistiendo en que DNS debía ser la fuente de la verdad. Tenían razón técnicamente en un sentido estrecho y estaban operativamente equivocados en un sentido amplio.

Durante un tiempo no pasó nada. Luego una ventana de mantenimiento de DNS temporal afectó una región. No fue una caída completa—solo mayor latencia y timeouts ocasionales. De repente cada acción privilegiada en cientos de instancias se volvió pegajosa. Las demoras en sudo se convirtieron en despliegues más lentos, respuesta a incidentes más lenta y una sensación general de que la región estaba “embrujada”.

La “optimización” también creó una trampa de depuración. Como DNS eventualmente funcionaba, el problema parecía intermitente. No lo era. Era comportamiento determinista del resolvedor bajo latencia upstream transitoria.

Revirtieron: hostname en /etc/hosts, DNS sigue siendo autoritativo para descubrimiento de servicios, y monitoreo estricto de latencia DNS. Nadie lo llamó “retroceso”, porque en realidad se trataba de eliminar una dependencia de la ruta de escalado de privilegios.

Ese equipo adoptó finalmente un principio: la identidad local debe resolverse localmente. Todo lo demás puede ser global.

Mini-story #3: The boring but correct practice that saved the day

Un entorno vinculado a finanzas mantenía controles de cambios estrictos, lo que hacía sus imágenes base conservadoras. Cada servidor tenía una entrada consistente en /etc/hosts para su hostname y FQDN en 127.0.1.1. Sin excepciones, incluso en grupos autoscaling efímeros.

Durante un incidente con un proveedor DNS upstream, muchos equipos vieron fallos en cascada: inicios de sesión lentos, sudo lento y timeouts en cualquier cosa que hiciera búsquedas de identidad o hostname. Ese entorno financiero? Mayormente bien. Sus apps aún dependían de DNS para servicios externos, pero los administradores podían obtener root al instante y ejecutar remediaciones locales sin luchar contra timeouts de resolvedor.

Lo que los salvó no fue heroísmo. Fue higiene de configuración aburrida: resolución local determinista, dominios de búsqueda mínimos y una configuración de resolvedor que no intentaba fallback ingeniosos.

En la revisión post-incidente no se jactaron. Simplemente señalaron sus estándares base y dijeron: “Quitamos dependencias de red de las operaciones locales”. Nadie discutió los resultados.

Errores comunes: síntoma → causa raíz → arreglo

1) Symptom: sudo pauses ~5 seconds before password prompt

Causa raíz: la búsqueda del hostname va a DNS y espera el timeout (resolvedor inalcanzable o mapeo local faltante).

Arreglo: añade el mapeo correcto del hostname en /etc/hosts; asegúrate de que los servidores DNS sean alcanzables con resolvectl status y las reglas de red.

2) Symptom: sudo is slow only on VPN or only off VPN

Causa raíz: split DNS mal configurado; DNS por enlace apunta al resolvedor de la VPN incluso cuando el túnel está abajo (o al revés).

Arreglo: corrige la integración DNS del cliente VPN; asegura que systemd-resolved actualice DNS por enlace; evita hardcodear DNS en netplan si DHCP/VPN debe gestionarlo.

3) Symptom: SSH login is slow and sudo is slow

Causa raíz: búsquedas inversas DNS o proveedor de identidad NSS (SSSD/LDAP) con timeouts afectan tanto el login como sudo.

Arreglo: verifica registros PTR y la alcanzabilidad del directorio; asegura que files esté primero en nsswitch.conf y que las cachés estén sanas.

4) Symptom: getent hosts is slow for everything, including public domains

Causa raíz: servidores DNS upstream inalcanzables; resolved reintenta y cae en fallback.

Arreglo: configura servidores DNS alcanzables; arregla firewall/enrutamiento; valida con dig y journalctl -u systemd-resolved.

5) Symptom: sudo sometimes fast, sometimes slow, correlated with network jitter

Causa raíz: enfoque “DNS autoritativo solamente”; hostname local no está en /etc/hosts, así que sudo depende de la latencia upstream.

Arreglo: restaura el mapeo local del hostname; trátalo como una característica de fiabilidad, no como un apaño.

6) Symptom: sudo slow only when using a short hostname

Causa raíz: los dominios de búsqueda causan intentos múltiples; un sufijo produce timeout.

Arreglo: reduce dominios de búsqueda; usa FQDN en automatización; asegura que el nombre corto resuelva localmente si debe existir.

7) Symptom: after upgrade to 24.04, delays appear where 22.04 was fine

Causa raíz: cambios en defaults de resolved, integración con la pila de red o selección diferente de servidores DNS (especialmente con split DNS/VPN).

Arreglo: verifica el DNS efectivo con resolvectl status; no asumas que tu cadena de resolvedores sobrevivió la actualización sin cambios.

Listas de verificación / plan paso a paso

Step-by-step: fix slow sudo with minimal risk

1. Mide: temporiza sudo -n true y getent hosts $(hostname). Si ambos van lentos, es servicio de nombres.
2. Guardarraíl local: asegura que /etc/hosts mapee 127.0.1.1 al hostname (y FQDN si lo usas).
3. Confirma mejora: vuelve a temporizar sudo -n true. Si ahora es rápido, quitaste el cuello de botella principal.
4. Arregla DNS upstream: revisa resolvectl status; asegura que los servidores DNS sean alcanzables; corrige netplan/DHCP/VPN.
5. Reduce fan-out de consultas: ajusta dominios de búsqueda; evita nombres de una sola etiqueta en scripts.
6. Sanidad NSS: verifica el orden en /etc/nsswitch.conf para hosts; evita módulos lentos a menos que sean necesarios.
7. Prueba de regresión: añade una comprobación de monitoreo para la alcanzabilidad/latencia DNS y una prueba humo “sudo es rápido” en pipelines de aprovisionamiento.

Change-control checklist (for fleets)

• Base /etc/hosts incluye mapeo del hostname en loopback.
• Plantillas de netplan no hardcodean DNS que no existirán en todos los entornos.
• Dominios de búsqueda son cortos e intencionales.
• Configuración NSS es consistente entre hosts, con resolución local primero.
• Proveedores de directorio (SSSD/LDAP) son monitorizados y sus timeouts entendidos.
• IPv6 está soportado de extremo a extremo o deshabilitado consistentemente (sin “IPv6 fantasma”).

Preguntas frecuentes

1) Why does sudo care about DNS at all?

Porque pregunta al sistema quién eres (búsquedas de usuario/grupo) y a menudo resuelve el hostname local para registro, políticas o chequeos de entorno. Esas llamadas pasan por NSS, que puede consultar DNS.

2) I added the hostname to /etc/hosts and sudo is fast now. Is that a hack?

No. Es un patrón de fiabilidad: las operaciones locales no deben depender de servicios de red. Mantén DNS para descubrimiento de servicios; mantén mapeo local para la identidad de la máquina.

3) Why is the delay so often exactly five seconds?

Porque los timeouts y reintentos del resolvedor suelen estar en ese rango, y una consulta fallida puede bloquear al llamador hasta que expire. No es aleatorio; es un temporizador.

4) What’s the difference between /etc/hosts and DNS for hostname resolution?

/etc/hosts es local, inmediato y determinista. DNS depende de la red y puede fallar o quedarse colgado. NSS decide qué fuentes se consultan y en qué orden.

5) Should I disable systemd-resolved to fix this?

Usualmente no. systemd-resolved rara vez es la causa raíz; es el mensajero que te muestra que tu configuración DNS es incorrecta o inalcanzable. Arregla la ruta DNS upstream primero.

6) Can search domains alone cause slow sudo?

Sí. Un nombre corto puede expandirse en múltiples consultas DNS. Si alguna ruta de sufijo hace timeout, obtienes una demora que parece “sudo lento” pero en realidad es “DNS indeciso”.

7) How do I know if SSSD/LDAP is the problem instead of DNS?

Temporiza id $USER y getent passwd $USER. Si eso va lento, la búsqueda de identidad es lenta. Si solo la resolución de hostname es lenta, céntrate en la resolución hosts: y la alcanzabilidad DNS.

8) Why did this show up after moving the VM or changing networks?

Porque los servidores DNS son específicos de la red en muchos entornos. Resolvedores hardcodeados, opciones DHCP obsoletas o políticas DNS de VPN no sobreviven bien a los movimientos.

9) Does IPv6 matter here if I “don’t use IPv6”?

Sí importa si tu resolvedor intenta consultas AAAA y tu red descarta o bloquea IPv6. O bien soportas IPv6 correctamente o lo deshabilitas de forma consistente; las medias tintas crean timeouts.

10) What’s the single best quick fix under pressure?

Añade el mapeo correcto del hostname en /etc/hosts y verifica que getent hosts $(hostname) sea instantáneo. Luego arregla DNS upstream cuando estés fuera de la zona de impacto.

Conclusión: próximos pasos que realmente harás

sudo lento en Ubuntu 24.04 normalmente no es “sudo siendo lento”. Es tu pila de servicios de nombres esperando por DNS, dominios de búsqueda o proveedores de identidad. La buena noticia: esto es diagnosticable con un cronómetro y uno o dos comandos.

Haz esto, en orden:

1. Temporiza sudo -n true y getent hosts $(hostname).
2. Arregla /etc/hosts para que el hostname se resuelva local e instantáneamente.
3. Usa resolvectl status y logs de resolved para encontrar servidores DNS inalcanzables y corregir netplan/DHCP/VPN.
4. Recorta dominios de búsqueda y evita nombres de una sola etiqueta en automatización.
5. Sólo entonces considera ajustes del orden NSS, y hazlos deliberadamente.

Si eliminas el timeout, eliminas el drama. Y tu yo del futuro—mirando un terminal detenido durante un incidente—te lo agradecerá en silencio.