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

Qué es realmente “sudo lento” (y qué no lo es)

“Sudo lento” por lo general no es tu disco, no es tu CPU y tampoco un módulo PAM encantado invocando demonios.
Normalmente es una llamada de resolución de nombres bloqueante que ocurre antes de que sudo muestre el aviso de contraseña.
Esa llamada puede ser resolución directa DNS, inversa, mDNS, servicios de nombres LDAP/SSSD, o incluso un resolvedor mal configurado que caduca.

La razón por la que parece que sudo es lento es que el humano ve solo una cosa: el aviso de contraseña.
Bajo el capó, sudo realiza trabajo de preparación (búsqueda de políticas, identificación del host, auditoría, registro).
Si alguna dependencia se bloquea—especialmente la resolución de nombres—te quedas esperando.

Cómo se presenta

• La demora ocurre antes de que aparezca el aviso de contraseña (clásico).
• La demora es consistente: ~1–5 segundos, a menudo coincide exactamente con patrones de timeout/reintento de DNS.
• La demora desaparece cuando te desconectas de la VPN / sales de la red corporativa / cambias de Wi‑Fi.
• La demora está presente en la consola y por SSH, no solo en un emulador de terminal.

Qué no es (la mayoría de las veces)

• No es tu configuración de shell. Los prompts del shell ocurren antes de que escribas sudo.
• No es que tu disco sea lento. sudo lee archivos pequeños. Tu NVMe no es el cuello de botella aquí.
• No es un problema de “falta de RAM”. La demora es tiempo de pared, no tiempo de CPU.

Broma #1: DNS es el departamento de “funcionaba ayer” del TI. También es el departamento de “funcionará mañana”, lo cual es menos reconfortante.

Guía rápida de diagnóstico

Quieres el camino más rápido a “en qué se está bloqueando esto?” sin perder tiempo en chucherías.
Aquí está el plan que uso en hosts de producción donde la paciencia es una desventaja.

Primero: mide la demora y confirma que es resolución de nombres

1. Cronometra sudo y reproduce dos veces para confirmar consistencia.
2. Ejecuta strace sobre sudo y busca connect()/sendto() a DNS o llamadas getaddrinfo().
3. Prueba la resolución de hostname local mediante getent (directa e inversa) porque eso es lo que realmente usa libc/NSS.

Segundo: identifica cuál ruta de resolutor se está usando

1. Revisa /etc/nsswitch.conf para la línea hosts:. Esto dicta el orden de búsqueda (files, dns, mdns4_minimal, resolve).
2. Inspecciona resolvectl status (systemd-resolved) o /etc/resolv.conf para ver a dónde van las consultas.
3. Si estás en sistemas corporativos, revisa la integración SSSD/LDAP/AD porque puede engancharse en las búsquedas de host/usuario.

Tercero: arregla lo más simple que garantice una ruta rápida

1. Asegura que tu hostname esté mapeado en /etc/hosts a una entrada de loopback (127.0.1.1 o 127.0.0.1) con nombre corto y FQDN si es necesario.
2. Elimina opciones de resolutor “bonitas” que aumentan el timeout (search domains malos, nameservers rotos).
3. Sólo entonces, ajusta sudo/PAM/logging si tienes una razón probada.

Por qué sudo toca DNS/hostname

sudo es más que “ejecutar un comando como root.” Es un motor de políticas con trazabilidad de auditoría.
Necesita decidir si tú puedes ejecutar este comando aquí.
“Aquí” significa la identidad del host. “Tú” significa un nombre de usuario y grupos. “Auditoría” significa registros que a menudo incluyen nombres de host.

Los culpables habituales de la demora inducida por hostname/DNS

• Resolución de hostname para registro y política.
  Muchos entornos quieren registros con nombres, no IP crudas. Eso puede desencadenar búsquedas inversas.
• Orden de NSS (Name Service Switch).
  Si tu línea hosts: prueba mDNS, WINS, LDAP o daemons de resolutor antes de revisar files,
  puedes pagar por ello en cada llamada.
• systemd-resolved o timeouts de DNS upstream.
  Los timeouts del resolvedor suelen ser de unos segundos—exactamente la demora que ves.
• Desajuste de FQDN.
  Una máquina llamada web-01 cuyo DNS diga que es web-01.corp.example pero /etc/hosts no coincida
  puede enviar las búsquedas por rutas lentas.
• Integración SSSD / AD.
  Si usas usuarios de dominio, SSSD puede añadir latencia cuando intenta contactar controladores—incluso para acciones “locales”.

La postura que recomiendo: trata la identidad del host y el servicio de nombres como dependencias.
Las dependencias fallan de maneras extrañas. Haz que la ruta rápida sea local, determinista y aburrida.

Cita (idea parafraseada) de Werner Vogels (CTO de Amazon): Todo falla todo el tiempo; diseña asumiendo que los componentes se romperán.

Hechos y contexto histórico para usar en discusiones

Esto no es trivia por el gusto de la trivia. Explica por qué la resolución de nombres moderna en Ubuntu puede sentirse como una máquina de Rube Goldberg
si la abordas como si fuera 2009.

1. NSS (Name Service Switch) viene de Solaris y fue adoptado ampliamente en Linux para controlar el orden de búsqueda (files, DNS, LDAP, etc.). Un orden incorrecto sigue causando “lentitud misteriosa”.
2. Ubuntu históricamente usó 127.0.1.1 en /etc/hosts para el hostname local, especialmente en sistemas sin una IP estable. Es extraño, pero evita viajes al resolvedor.
3. systemd-resolved introdujo un resolvedor local stub que cambió cómo se comporta /etc/resolv.conf en muchas distribuciones. La pregunta “quién responde DNS?” se volvió menos obvia.
4. mDNS (multicast DNS) es estupendo para impresoras y portátiles; es una responsabilidad en servidores si está antes que files y tu red filtra multicast de forma extraña.
5. Reverse DNS (PTR) sigue faltando o está mal en redes internas. Eso está bien hasta que algo se bloquea en ello, como el registro/auditoría.
6. Clientes VPN a menudo empujan search domains y listas de nameservers que son correctos para apps internas pero desastrosos para latencia si la ruta de red es inestable.
7. El comportamiento de sudo ha evolucionado con expectativas de seguridad: más auditoría, más contexto de políticas, más lugares donde un hostname termina en registros.
8. Patrones DNS corporativos de la era Windows (WINS, DNS dividido, listas largas de search) aún se filtran en configuraciones Linux vía DHCP y pueden ralentizar búsquedas dramáticamente.

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

Cada tarea incluye: un comando que puedes ejecutar, un ejemplo de qué salida “mala” o “interesante” parece,
y qué decisión tomar a partir de ello. No te saltes las decisiones—ahí está el valor.

Task 1: Cronometra el síntoma como si importarás

cr0x@server:~$ time sudo -n true

real    0m2.312s
user    0m0.008s
sys     0m0.010s

Qué significa: 2.3 segundos de tiempo real, casi cero CPU. Eso grita “bloqueado en I/O”, y DNS es I/O.
Decisión: Deja de adivinar sobre CPU/disco. Pasa al trazado del servicio de nombres.

Task 2: Confirma que es antes del aviso de contraseña (interactivo)

cr0x@server:~$ time sudo true
[sudo] password for cr0x: 

real    0m2.205s
user    0m0.009s
sys     0m0.012s

Qué significa: La demora es antes de que se acepte la entrada de contraseña (el prompt aparece tarde).
Decisión: Revisa resolución de hostname y registro, no verificación de contraseña PAM.

Task 3: Usa strace para atrapar el bloqueo (rápido y rudo)

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

cr0x@server:~$ tail -n 25 /tmp/sudo.trace
12:20:01.101234 connect(6, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.0.0.2")}, 16) = 0
12:20:01.101540 sendto(6, "\252\273\1\0\0\1\0\0\0\0\0\0\6server\4corp\7example\0\0\34\0\1", 36, 0, NULL, 0) = 36
12:20:03.103901 recvfrom(6, 0x7ffd8b2a3f10, 2048, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
12:20:03.104220 close(6) = 0

Qué significa: Una consulta DNS a 10.0.0.2 caducó tras ~2 segundos.
Decisión: Arregla la alcanzabilidad/orden del resolvedor o evita DNS para el hostname local vía /etc/hosts.

Task 4: Inspecciona qué hostname cree que tiene sudo

cr0x@server:~$ hostnamectl
 Static hostname: server
       Icon name: computer-vm
         Chassis: vm
      Machine ID: 8cbe2c8a1b3d4f1e9e6c0c4b3c1c9d2a
         Boot ID: 2f9c9a1de2bf44a6a3a8c5f5f7e38e0a
  Virtualization: kvm
Operating System: Ubuntu 24.04 LTS
          Kernel: Linux 6.8.0-31-generic
    Architecture: x86-64

Qué significa: El hostname estático es server (nombre corto).
Decisión: Asegura que server se resuelva rápido vía /etc/hosts. Decide si también necesitas un FQDN.

Task 5: Comprueba la búsqueda directa a través de NSS (no “dig”, no “nslookup”)

cr0x@server:~$ getent hosts $(hostname)
10.22.1.17      server.corp.example server

Qué significa: NSS devuelve una dirección respaldada por DNS rápidamente (en este ejemplo).
Si este comando se estanca, sudo también puede estancarse.
Decisión: Si es lento, prioriza arreglar /etc/hosts o la configuración del resolvedor.

Task 6: Comprueba la búsqueda inversa para tu IP principal

cr0x@server:~$ ip -br addr show scope global
ens3             UP             10.22.1.17/24

cr0x@server:~$ getent hosts 10.22.1.17
10.22.1.17      server

Qué significa: La búsqueda inversa devuelve server.
Si caduca, tu pila de registro o sudo podría estar desencadenando búsquedas PTR.
Decisión: Si la inversa es lenta, arregla PTR en DNS (mejor) o asegura un mapeo local en /etc/hosts.

Task 7: Revisa /etc/hosts por el mapeo clásico faltante

cr0x@server:~$ sed -n '1,120p' /etc/hosts
127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

Qué significa: No hay entrada para server. Eso fuerza a NSS a consultar fuentes de red.
Decisión: Añade un mapeo de loopback para tu hostname para hacer la resolución local e instantánea.

Task 8: Inspecciona el orden de NSS para búsquedas de host

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

Qué significa: Esto prueba files, luego mDNS, luego DNS.
En servidores, mDNS puede ser un desvío que no quieres.
Decisión: Si mDNS causa demoras, considera quitarlo o moverlo después de dns (con cuidado—ver fixes).

Task 9: Ve si systemd-resolved está a cargo

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

Qué significa: Las consultas van a 10.0.0.2/10.0.0.3. El modo stub significa que /etc/resolv.conf apunta a un stub local.
Decisión: Prueba esos servidores DNS directamente. Si no son alcanzables desde este host/red, arregla DHCP/VPN/configuración de resolutor.

Task 10: Valida que los servidores DNS respondan rápido (consulta directa)

cr0x@server:~$ dig +time=1 +tries=1 @10.0.0.2 $(hostname).corp.example A

; <<>> DiG 9.18.24-0ubuntu0.24.04.1-Ubuntu <<>> +time=1 +tries=1 @10.0.0.2 server.corp.example A
;; global options: +cmd
;; connection timed out; no servers could be reached

Qué significa: El servidor DNS configurado no es alcanzable (o está filtrado).
Decisión: Arregla la lista de resolutores. O, si no puedes, corta la ruta y resuelve el hostname localmente vía /etc/hosts para que sudo no lo necesite.

Task 11: Comprueba /etc/resolv.conf por stub vs resolutores directos

cr0x@server:~$ readlink -f /etc/resolv.conf
/run/systemd/resolve/stub-resolv.conf

Qué significa: Estás usando el stub de systemd-resolved.
Decisión: No “arregles” /etc/resolv.conf a mano a menos que estés optando por salir intencionalmente. Arregla la configuración upstream en su lugar.

Task 12: Mira si SSSD está en la ruta de búsqueda (común en empresas)

cr0x@server:~$ systemctl is-active sssd
active

cr0x@server:~$ getent passwd $USER
cr0x:x:1000:1000:cr0x:/home/cr0x:/bin/bash

Qué significa: SSSD está activo. Puede influir en búsquedas dependiendo de la configuración NSS.
Decisión: Si las demoras de sudo correlacionan con la alcanzabilidad de AD/DC, revisa logs de SSSD y la configuración NSS; no culpes sólo a DNS.

Task 13: Detecta problemas por search domains (búsqueda lenta de NXDOMAIN)

cr0x@server:~$ resolvectl domain
Global: corp.example lab.example dev.example

Qué significa: Múltiples search domains pueden causar múltiples consultas por un nombre, especialmente con nombres no calificados.
Decisión: Prefiere FQDN en configuraciones, recorta las listas de búsqueda cuando sea posible y asegura que tu hostname se resuelva sin caminar por los search.

Task 14: Mide la latencia de búsqueda a través de NSS (repetible)

cr0x@server:~$ /usr/bin/time -f '%e seconds' getent hosts $(hostname) >/dev/null
2.01 seconds

Qué significa: La búsqueda NSS en sí toma ~2 segundos.
Decisión: Arregla la resolución de nombres primero. Sudo solo trae la noticia.

Task 15: Prueba si mDNS está involucrado

cr0x@server:~$ /usr/bin/time -f '%e seconds' getent hosts server.local >/dev/null
1.99 seconds

Qué significa: Las búsquedas .local pueden activar mDNS. Si esto es lento y tu hosts: incluye mdns, tienes una pista.
Decisión: En servidores, deshabilita mDNS o reordénalo a menos que tengas un requisito real.

Task 16: Confirma que la configuración de logs de sudo no obligue a extrañezas FQDN

cr0x@server:~$ sudo -V | sed -n '1,60p'
Sudo version 1.9.15p5
Sudoers policy plugin version 1.9.15p5
Sudoers file grammar version 50
Sudoers I/O plugin version 1.9.15p5
Sudoers audit plugin version 1.9.15p5
Local IP address and netmask pairs:
    10.22.1.17 / 255.255.255.0

Qué significa: Estás viendo enumeración de IPs locales. A veces esa enumeración desencadena búsquedas inversas dependiendo del entorno.
Decisión: Mantén el enfoque: arregla la resolución del hostname/IP localmente. No hagas cambios en sudoers por imitación hasta que hayas medido.

Patrones de corrección que realmente eliminan la demora

Hay docenas de formas de “hacer que se sienta mejor” y dos formas de hacerlo realmente correcto.
Las formas correctas son: (1) hacer que la resolución de hostname sea local e instantánea, y (2) hacer que el DNS upstream sea fiable y alcanzable.
Haz ambas cuando puedas. Haz (1) cuando debas.

Arreglo #1: Pon tu hostname en /etc/hosts (ruta rápida, casi siempre segura)

En Ubuntu, la solución más común también es la menos glamurosa: asegura que el hostname del sistema se resuelva vía files
sin tocar DNS. Eso significa añadir un mapeo de loopback.

Qué hacer (ejemplo para hostname server y FQDN server.corp.example):

cr0x@server:~$ sudoedit /etc/hosts

Contenido de ejemplo para añadir (mantén las líneas existentes):

cr0x@server:~$ sed -n '1,20p' /etc/hosts
127.0.0.1       localhost
127.0.1.1       server.corp.example server

::1             localhost ip6-localhost ip6-loopback

Qué significa: El hostname se resuelve inmediatamente vía files. No hay dependencia de DNS para la identidad local.
Decisión: Si esto elimina la demora, puedes programar la higiene de DNS más adelante en lugar de quemar la tarde.

Orientación con opinión: para un servidor, quiero que /etc/hosts contenga el hostname local.
Sí, incluso si “DNS debería ser la fuente de verdad.” DNS es fuente de verdad hasta que es fuente de llamadas de emergencia.

Arreglo #2: Asegura que las expectativas de hostname y FQDN coincidan

Los problemas ocurren cuando distintas capas no están de acuerdo sobre si el nombre “real” es corto o completamente calificado.
Algunos entornos tratan server como “server.corp.example” vía search domains; otros no.
Tu trabajo es hacerlo explícito.

Decide cuál debe ser el hostname:

• Hostname corto (server): común para VMs, hosts internos y cuando no quieres renombrados.
• Hostname FQDN (server.corp.example): a veces requerido por herramientas, certificados o políticas AD.

Establécelo claramente (si debes cambiarlo):

cr0x@server:~$ sudo hostnamectl set-hostname server.corp.example

Decisión: Solo establece FQDN como hostname estático si tu organización lo necesita. De lo contrario mantiene el hostname corto y mapea el FQDN en /etc/hosts.
Renombrar hosts en producción es una excelente manera de descubrir todo lo que asume que los nombres no cambian.

Arreglo #3: Arregla la alcanzabilidad del resolvedor (evita timeouts a DNS muertos)

Si tus servidores DNS configurados no responden, cada búsqueda se vuelve una lotería de timeouts.
Con systemd-resolved, a menudo heredas resolutores desde DHCP, VPN o la configuración de netplan.

Encuentra los servidores DNS activos:

cr0x@server:~$ resolvectl dns
Global: 10.0.0.2 10.0.0.3
Link 2 (ens3): 10.0.0.2 10.0.0.3

Decisión: Si esos no son alcanzables desde este segmento de red, arregla la configuración de red (alcance DHCP, perfil VPN, netplan).
No “resuelvas” añadiendo DNS públicos al azar en un host corporativo a menos que quieras outages por DNS dividido y problemas de cumplimiento.

Arreglo #4: Recorta search domains (reduce la multiplicación de consultas)

Los search domains pueden causar múltiples consultas para un solo nombre: server se convierte en server.corp.example,
luego server.lab.example, etc. Cuando los resolutores son lentos, eso multiplica el dolor.

Decisión: Prefiere usar FQDN en configuraciones y establece el mapeo del hostname de la máquina para que no dependa del search.
Si gestionas DHCP, mantén la lista de búsqueda corta e intencional.

Arreglo #5: Reordena las búsquedas NSS para que “files” gane rápidamente

La línea hosts: en /etc/nsswitch.conf decide el orden de búsqueda.
Para servidores, quiero files primero, DNS segundo, y mDNS sólo si hay una razón específica.

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

Si mDNS está implicado, un patrón más seguro en servidores suele ser:

cr0x@server:~$ sudo sed -i 's/^hosts:.*/hosts:          files dns/' /etc/nsswitch.conf

Decisión: Haz esto solo si entiendes el entorno. En escritorios, eliminar mDNS puede romper el descubrimiento de dispositivos.
En servidores, usualmente elimina peso muerto.

Arreglo #6: Maneja correctamente el reverse DNS (PTR o mapeo local)

Que el reverse DNS esté mal es común y manejable—hasta que una política de seguridad o una ruta de logs se bloquea en ello.
La solución limpia es crear registros PTR para las IPs de los servidores en el DNS autoritativo.
La solución táctica es asegurar que la propia IP del servidor reverse-resuelva localmente vía /etc/hosts.

Orientación con opinión: si operas la zona DNS, haz PTRs. No es higiene opcional; es deuda operativa con interés.

Arreglo #7: Cuidado con “soluciones rápidas” que ocultan síntomas

Verás consejos como “desactivar búsquedas DNS en sudo” o ajustar logging.
A veces esos cambios ayudan. Más a menudo solo empeoran tu rastro de auditoría mientras dejan DNS roto para todo lo demás.
Úsalos solo cuando tengas una razón medida y un registro de cambios.

Broma #2: Apagar DNS para arreglar la latencia de DNS es como quitar el velocímetro para mejorar el consumo de combustible. Te sentirás mejor brevemente.

Tres mini-historias corporativas (anonimizadas, plausibles, técnicamente precisas)

1) El incidente causado por una suposición equivocada: “Nuestro DNS siempre es alcanzable”

Un equipo ejecutaba una flota de VMs Ubuntu en dos zonas de red: servidores de aplicaciones en una, servicios compartidos (incluido DNS) en otra.
Durante una revisión de seguridad, se endurecieron reglas de firewall. DNS fue “permitido”, pero solo desde subredes listadas en una hoja de cálculo que era—¿cómo decirlo?—optimista.

El primer síntoma no fue una caída de la aplicación. Fueron humanos quejándose en el chat de que sudo “se cuelga a veces.”
El on-call lo desestimó como laptops personales y rarezas de VPN. Luego una ventana rutinaria de actualización de paquetes empezó, y la automatización que usaba sudo empezó a caducar.
Ahí el problema pasó de molestia a incidente.

La suposición equivocada: “Si SSH funciona, DNS debe funcionar.” SSH funcionaba porque las rutas IP estaban bien y los hosts estaban fijos en known_hosts.
DNS no funcionaba porque el firewall estaba descartando UDP/53 silenciosamente, lo que se traduce en “espera el timeout, luego reintenta.”

Arreglar el firewall fue necesario, pero la solución duradera fue añadir mappings locales de hostname en /etc/hosts vía gestión de configuración.
Eso hizo la resolución de identidad local, así que incluso si DNS titubeaba, las acciones administrativas no fallaban.

Post-incidente, también añadieron una comprobación de salud: getent hosts $(hostname) con latencia medida y alertada.
Métrica aburrida. Extremadamente efectiva.

2) La optimización que salió mal: “Añadamos más search domains”

Un equipo de red corporativo intentó mejorar la experiencia del desarrollador empujando una lista generosa de search vía DHCP:
múltiples dominios internos para que la gente escriba hostnames cortos y “simplemente funcionen.”
Parecía inofensivo. Incluso funcionaba—cuando DNS era rápido.

Luego una oficina remota tuvo pérdida de paquetes intermitente hacia los resolutores DNS principales.
Cada búsqueda no calificada (como server) se volvió una serie de intentos: server.corp, server.lab, server.dev, etc.
Multiplica eso por timeouts y reintentos, y de repente comandos triviales tomaban segundos.

Los ingenieros lo notaron primero en herramientas que llaman a NSS repetidamente: sudo, ssh con intentos GSSAPI,
y agentes de monitorización que hacen búsquedas inversas para etiquetado.
La “optimización” del equipo de red había creado un amplificador de latencia.

Revertir la lista de búsqueda ayudó, pero la reparación real fue un nombrado más disciplinado:
sistemas críticos usaron FQDN en configuraciones, y los hosts fijaron su propio nombre localmente.
Los nombres cortos seguían permitidos en shells interactivos, pero la automatización de producción dejó de depender de magia de search.

3) La práctica aburrida pero correcta que salvó el día: entradas estandarizadas en /etc/hosts

Otra compañía tenía una línea base estricta: cada host Linux tenía una entrada en /etc/hosts para su propio hostname,
gestionada por configuración y revisada como cualquier otro cambio.
La gente refunfuñaba porque parecía redundante con DNS.

Durante una migración planificada de DNS, se intercambiaron resolutores y se vaciaron caches.
Un puñado de zonas fue más lento durante unas horas debido a propagación y un par de forwarders mal configurados.
Los desarrolladores se quejaron de que “DNS está lento”, pero el trabajo operacional en servidores continuó sin drama.

La razón: los flujos de trabajo administrativos no requerían DNS para la identidad local.
sudo, el etiquetado local de logs y muchos scripts que usaban hostname -f no se bloqueaban porque el host podía responder “¿quién soy?” desde archivos locales instantáneamente.

Esto no eliminó el problema de DNS. Lo contuvo.
Ese es el punto de las líneas base aburridas: no previenen todo incendio, pero impiden que se extienda a habitaciones no relacionadas.

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

1) Síntoma: sudo se pausa ~2–5 segundos antes del aviso de contraseña

Causa raíz: Servidores DNS en la configuración del resolvedor no alcanzables; libc espera el timeout.

Arreglo: Corrige la lista de servidores DNS (DHCP/VPN/netplan), y añade el mapeo de hostname en /etc/hosts como salvaguarda.

2) Síntoma: sudo es rápido en una red, lento en otra

Causa raíz: DNS dividido/VPN cambia resolutores o search domains; las consultas van a un resolvedor lento desde esa ubicación.

Arreglo: Mide con resolvectl status y dig @server directo. Arregla el perfil VPN o el ruteo DNS; evita listas largas de search.

3) Síntoma: getent hosts $(hostname) cuelga, pero dig funciona

Causa raíz: El orden NSS usa una fuente lenta (mDNS, LDAP/SSSD) antes que DNS; dig evita NSS.

Arreglo: Ajusta /etc/nsswitch.conf para preferir files, luego dns. Confirma con getent cronometrado.

4) Síntoma: hostname -f es lento; sudo es lento; logs muestran búsquedas FQDN

Causa raíz: Desajuste de hostname/FQDN más caminata por search domains; reverse DNS ausente causando búsquedas extra.

Arreglo: Asegura estrategia consistente de hostname y una entrada coincidente en /etc/hosts; añade registros PTR si gestionas DNS.

5) Síntoma: sudo lento solo cuando controladores de dominio no están alcanzables

Causa raíz: Retrasos de SSSD/AD influyen en las rutas NSS/PAM de resolución.

Arreglo: Confirma con systemctl is-active sssd y getent cronometrado. Arregla fallover/timeouts de SSSD, y mantén la resolución local en files.

6) Síntoma: la demora de sudo aparece tras habilitar Avahi o “funciones de escritorio” en un servidor

Causa raíz: mDNS se prueba y caduca o está filtrado, añadiendo demora a las búsquedas.

Arreglo: Quita/deshabilita mDNS en servidores o reordena NSS para evitar mDNS en búsquedas no .local.

7) Síntoma: sudo lento solo en redes con IPv6 habilitado

Causa raíz: Servidores DNS IPv6 o rutas mal configuradas; el resolvedor prueba AAAA luego A con demoras.

Arreglo: Revisa resolvectl status para resolutores v6 y prueba con dig -6. Arregla rutas o deshabilita resolutores v6 rotos; mantén el mapeo local del hostname.

8) Síntoma: “sudo: unable to resolve host …” más lentitud

Causa raíz: El hostname no se resuelve en absoluto vía NSS; sudo se queja y espera en fallback lento.

Arreglo: Añade la entrada correcta en /etc/hosts para el hostname; verifica con getent hosts $(hostname).

Listas de verificación / plan paso a paso

Checklist A: Corrección quirúrgica en un host (10 minutos, sin reuniones)

1. Mide la demora:

   cr0x@server:~$ time sudo -n true
   sudo: a password is required
   
   real    0m2.101s
   user    0m0.008s
   sys     0m0.010s

   Decisión: Si el tiempo real son segundos con pequeña CPU, procede a comprobaciones de resolución de nombres.

2. Cronometra la búsqueda NSS del hostname:

   cr0x@server:~$ /usr/bin/time -f '%e seconds' getent hosts $(hostname)
   2.00 seconds
   10.22.1.17      server.corp.example server

   Decisión: Si esto es lento, arreglar la resolución del hostname probablemente arreglará sudo.

3. Añade el mapeo de hostname si falta:

   cr0x@server:~$ sudo grep -nE '127\.0\.1\.1|127\.0\.0\.1' /etc/hosts
   1:127.0.0.1       localhost

   cr0x@server:~$ sudoedit /etc/hosts

   Decisión: Añade 127.0.1.1 server.corp.example server (o tus nombres reales). Guarda.

4. Vuelve a probar:

   cr0x@server:~$ /usr/bin/time -f '%e seconds' getent hosts $(hostname)
   0.00 seconds
   127.0.1.1       server.corp.example server

   cr0x@server:~$ time sudo -n true
   
   real    0m0.050s
   user    0m0.008s
   sys     0m0.012s

   Decisión: Si está arreglado, detente. Ahora puedes abordar DNS upstream sin que los usuarios noten la diferencia.

Checklist B: Corrección a nivel flota (la que desearías haber hecho antes)

1. Estandariza la identidad de hosts: decide la política short hostname vs FQDN.
2. Aplica baseline de /etc/hosts: mapeo local para el hostname y (si se usa) FQDN.
3. Establece orden NSS intencional: hosts: files dns para servidores salvo requerimiento documentado.
4. Monitorea la latencia de búsqueda: alerta sobre getent hosts $(hostname) tardando > 200ms sostenidos.
5. Arregla registros PTR para subredes de servidores si controlas DNS. Evita la mitología “reverse DNS es opcional”.
6. Prueba cambios de VPN/DHCP contra un host canario midiendo búsquedas NSS y sudo.

Checklist C: Si debes cambiar la configuración de DNS

1. Confirma quién posee los resolutores (equipo de red, equipo de plataforma, proveedor cloud).
2. Verifica la alcanzabilidad (UDP y TCP 53) desde la subred afectada.
3. Mantén listas de resolutores cortas (2–3 servidores) y locales a la región de red.
4. Evita listas largas de search domains; trátalas como multiplicadores en fallo.
5. Despliega gradualmente y mide la latencia NSS, no solo “dig funciona”.

Preguntas frecuentes

¿Por qué a sudo le importa DNS?

Porque es una herramienta de políticas/auditoría, no un simple interruptor de privilegios. Puede resolver hostnames para registro, contexto de política o comprobaciones de identidad vía NSS.
Si NSS golpea DNS y DNS es lento, sudo hereda esa demora.

¿Por qué dig se ve rápido pero sudo es lento?

dig habla con DNS directamente. sudo usa la resolución de nombres de libc vía NSS, que puede consultar files, mDNS, SSSD/LDAP y DNS—en ese orden.
Necesitas medir con getent, no solo con dig.

¿Agregar el hostname a /etc/hosts es “mala práctica”?

Para la autorresolución local, es buena práctica. No estás reemplazando DNS para descubrimiento de servicios; estás asegurando que la máquina pueda identificarse sin la red.
Esto reduce el radio de expansión de problemas DNS.

¿Debo usar 127.0.1.1 o 127.0.0.1?

En Ubuntu, 127.0.1.1 es una convención común para mapear el nombre del host sin secuestrar localhost.
Cualquiera puede funcionar, pero mantiene localhost sensato y evita mapear múltiples nombres no relacionados a 127.0.0.1 a la ligera.

¿Y si la “IP real” del servidor debería estar en DNS, no en loopback?

Pon la IP real en DNS (A/AAAA) y PTR en reverse DNS. Aún así mantén un mapeo de loopback para el hostname si tu entorno lo tolera,
o mapea el hostname a la IP primaria en /etc/hosts si necesitas reflejar la realidad. La meta es resolución rápida y consistente.

¿Systemd-resolved causa esto?

systemd-resolved suele ser el mensajero. Puede mostrar malas listas de resolutores upstream, DNS empujado por VPN, o nameservers no alcanzables.
Usa resolvectl status para ver qué está haciendo antes de culparlo.

¿IPv6 puede ser la causa de la demora?

Sí. Si tu configuración de resolutores incluye rutas IPv6 rotas o servidores DNS IPv6 no alcanzables, las búsquedas pueden detenerse antes de fallback.
Mide con resolvectl y prueba la alcanzabilidad v6; no deshabilites IPv6 a ciegas a menos que controles el entorno y aceptes compensaciones.

¿Es seguro editar /etc/nsswitch.conf para quitar mDNS?

En servidores, generalmente sí si no dependes del descubrimiento .local. En escritorios, quitar mDNS puede romper el descubrimiento de dispositivos.
Haz el cambio intencionalmente y verifica con llamadas getent hosts cronometradas.

¿Cuál es la “prueba” más rápida de que DNS es el cuello de botella?

Cronometra getent hosts $(hostname) y ejecuta strace en sudo buscando timeouts en sockets DNS.
Si la resolución NSS toma segundos, sudo no es tu problema—es el servicio de nombres.

¿Por qué empeora con la VPN?

Las VPNs suelen empujar servidores DNS internos y listas largas de search domains. Si la ruta VPN es inestable o los resolutores no son alcanzables desde tu ubicación actual,
cada búsqueda se convierte en una cadena de timeouts. Arregla el perfil DNS de la VPN o asegura la resolución local del hostname vía /etc/hosts.

Siguientes pasos

Si sudo es lento en Ubuntu 24.04, trátalo como un problema de dependencias, no como un problema de sudo.
Mide con time, prueba con strace, valida con getent.
Luego haz la ruta rápida local: mapea tu hostname en /etc/hosts y asegura que files esté primero en las búsquedas de hosts.

Después de eso, arregla la causa real: resolutores no alcanzables, DNS sobrecargado, search domains ridículos, PTR faltantes o servicios de nombres empresariales que caducan.
Hazlo con calma, con métricas y con un host canario. Tu yo futuro todavía se seguirá quejando del DNS, pero al menos no esperarás a que se muestre un aviso de contraseña.