Ubuntu 24.04: Desajuste entre hostname y /etc/hosts rompe sudo/ssh — la solución aburrida que ahorra horas

Qué se rompe realmente (y por qué parece DNS)

La conclusión: sudo y sshd no están “haciendo DNS” por aburrimiento. Llaman a funciones de la biblioteca del sistema
que a menudo resuelven nombres de host como parte de registros, comprobaciones de políticas y funciones de seguridad. Cuando el hostname de tu máquina no se resuelve
rápidamente a una dirección (o no se resuelve), pagas ese tiempo en esperas por timeouts.

En Ubuntu, la resolución de nombres la gobierna Name Service Switch (NSS), configurado en /etc/nsswitch.conf.
La mayoría de las configuraciones por defecto comprueban files (es decir, /etc/hosts) antes que DNS. Eso es bueno: hace que las consultas locales sean rápidas y predecibles.
Pero si /etc/hosts no contiene tu hostname actual, o contiene el equivocado, la resolución cae a DNS.
En una red de laboratorio con DNS inestable—o en una VPC de nube donde la resolución inversa es lenta—obtienes ese comportamiento de bloqueo.

El mensaje clásico de error es:
sudo: unable to resolve host somehost: Name or service not known
Pero no siempre lo verás, porque dependiendo de tu terminal, configuración de registros y la ruta exacta de la llamada, puede simplemente sentirse como “sudo está lento”.

La razón por la que SSH está en el radio de impacto: el servidor a menudo realiza DNS inverso para la IP del cliente, y tu host puede hacer consultas directas también.
Si UseDNS yes está habilitado (o los valores por defecto difieren entre compilaciones), el servidor puede pasar tiempo esperando DNS. Añade un hostname local desajustado
y puedes acabar con retrasos compuestos—avisos de autenticación lentos, establecimiento de sesión lento, registros lentos.

Esto no es un fallo glamuroso. Es un fallo de arena en los engranajes. Esos son los que te roban toda la tarde.

Una cita que funciona en trabajo de ops: La esperanza no es una estrategia. (idea parafraseada comúnmente atribuida al liderazgo de ingeniería en círculos de confiabilidad)
La solución aburrida es estrategia. Haz la solución aburrida.

Broma #1: DNS es el único sistema donde “probablemente es solo una línea” es a la vez cierto y sigue arruinando tu día.

Datos históricos e contexto interesante (lo que explica la rareza)

• /etc/hosts precede a DNS generalizado. Los archivos de hosts locales fueron el “servicio de directorio” original en sistemas de la era ARPANET. DNS llegó después para escalar el problema.
• El patrón “127.0.1.1” es una costumbre específica de Debian/Ubuntu. Debian históricamente usó 127.0.1.1 para mapear el hostname del sistema sin atarlo a la dirección de una interfaz de red específica.
• glibc NSS es modular por diseño. La línea hosts: en /etc/nsswitch.conf controla no solo DNS vs files, sino también mDNS y los hooks del resolvedor de systemd.
• Los retrasos de DNS inverso han sido una molestia de SSH durante décadas. El servidor SSH puede hacer búsquedas PTR para las IPs cliente; si DNS es lento, parece que “SSH está lento”.
• systemd cambió cómo se gestiona el “hostname”. Con systemd, hostnamectl es la puerta de entrada, y el hostname se persiste en /etc/hostname (y a veces lo influencia cloud-init).
• Las imágenes en la nube adoran renombrarse. cloud-init y los metadatos del proveedor pueden establecer hostnames al arrancar, a veces sin actualizar /etc/hosts como esperarías.
• sudo intenta ser seguro, no rápido. Registra, comprueba políticas y a veces desencadena búsquedas de hostname para auditoría y visualización. La demora es una propiedad emergente, no una característica.
• “localhost” no es solo una sensación. 127.0.0.1 localhost (y IPv6 ::1) son esperados por mucho software; romper esas asignaciones causa caos de formas sutiles.

Guía de diagnóstico rápido (comprueba esto en orden)

Cuando sudo se cuelga o las conexiones SSH se estancan, quieres obtener señales rápido. Aquí está el orden que minimiza la agitación y maximiza la claridad.

1) Confirma que el síntoma es latencia de resolución de nombres, no CPU, disco o entropía

Si la demora es consistentemente ~5s, ~10s, ~30s, eso grita timeout. Los picos de CPU y los bloqueos de disco se ven más desordenados.

2) Comprueba hostname vs /etc/hosts inmediatamente

Esta es la comprobación de 30 segundos que te ahorra tres horas. Si el hostname del sistema no está presente en una línea de loopback en /etc/hosts, arréglalo.

3) Valida el orden de NSS y el estado de systemd-resolved

Si /etc/nsswitch.conf intenta DNS antes que files (o está modificado), puedes manufacturar latencia incluso con un archivo hosts correcto.

4) Para lentitud en SSH: comprueba el comportamiento DNS en el servidor

Si el servidor está esperando por DNS inverso de los clientes, puedes arreglarlo con configuración (UseDNS no) o con registros PTR correctos.
Prefiere DNS real en entornos corporativos estables; prefiere UseDNS no en entornos desechables.

5) Solo entonces persigue DNS upstream, firewalls, split-horizon, clientes VPN y metadatos de nube

Esos son problemas reales—pero son la rama cara del árbol de decisiones. Gánate el derecho a llegar allí.

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

Estas son las comprobaciones exactas que ejecuto en on-call. Cada tarea tiene: comando, salida plausible, lo que significa y la decisión que impulsa.
Ejecútalas como usuario normal salvo indicación.

Task 1: Measure how bad the delay is (sudo)

cr0x@server:~$ time sudo -n true

real    0m12.184s
user    0m0.014s
sys     0m0.010s

What it means: sudo took 12 seconds to do essentially nothing. That’s almost never “CPU”.
This is classic lookup timeout territory.

Decision: Pivot to hostname resolution checks before touching packages, disks, or kernel parameters.

Task 2: See the current hostname (and whether it looks like a cloud rename)

cr0x@server:~$ hostname
ip-10-24-3-17

What it means: That pattern looks provider-assigned. It might have been set by cloud-init or metadata.

Decision: Verify that /etc/hosts contains this name. If not, fix locally first.

Task 3: Check the “official” hostname source via systemd

cr0x@server:~$ hostnamectl
 Static hostname: ip-10-24-3-17
       Icon name: computer-vm
         Chassis: vm
      Machine ID: 3b9f6a0c6f2847b7a62c1234c77d9a1e
         Boot ID: 1bd3b7d21f7f48f1bdf7c7fcb43b17a2
  Virtualization: kvm
Operating System: Ubuntu 24.04.1 LTS
          Kernel: Linux 6.8.0-41-generic
    Architecture: x86-64

What it means: The hostname the system thinks it has is ip-10-24-3-17. That’s what services will try to resolve.

Decision: Make sure this name resolves quickly via files (hosts), not DNS.

Task 4: Inspect /etc/hosts for the mismatch

cr0x@server:~$ cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 ubuntu-template

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

What it means: The hostname is ip-10-24-3-17, but /etc/hosts still maps ubuntu-template.
So when something tries to resolve the current hostname, it falls through to DNS.

Decision: Update the 127.0.1.1 line (or add one) to include the current hostname and optional FQDN.

Task 5: Prove resolution is slow (getent is your friend)

cr0x@server:~$ time getent hosts "$(hostname)"
10.24.3.17      ip-10-24-3-17

real    0m10.008s
user    0m0.000s
sys     0m0.004s

What it means: Even a simple lookup takes 10 seconds. That’s an NSS path waiting on something (often DNS).

Decision: Fix /etc/hosts so this lookup becomes instantaneous. If it remains slow, inspect nsswitch.conf and DNS.

Task 6: Check NSS order (the actual resolution policy)

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

What it means: The system should consult files first. Good. So a correct /etc/hosts entry will short-circuit the problem.

Decision: If files isn’t first, put it first unless you have a very specific reason not to (and you probably don’t).

Task 7: See what sudo is waiting on (strace, fast and surgical)

cr0x@server:~$ sudo strace -f -tt -o /tmp/sudo.strace sudo -n true
sudo: unable to resolve host ip-10-24-3-17: Name or service not known

What it means: You got the explicit error. The trace file will show calls like getaddrinfo() and the time spent.

Decision: Stop guessing. Fix hostname resolution locally. If policy requires DNS correctness, fix DNS next—but don’t skip the local mapping.

Task 8: Confirm what /etc/hostname contains (persistence across boots)

cr0x@server:~$ cat /etc/hostname
ip-10-24-3-17

What it means: The persistent hostname matches hostnamectl. Good. The mismatch is specifically in /etc/hosts.

Decision: Edit /etc/hosts, not /etc/hostname, unless you actually want to rename the box.

Task 9: Check systemd-resolved status (are you even using it?)

cr0x@server:~$ systemctl is-active systemd-resolved
active

What it means: Resolved is active, so DNS configuration might be managed via /run/systemd/resolve and /etc/resolv.conf may be a stub.

Decision: Don’t hand-edit /etc/resolv.conf blindly; check what it points to first.

Task 10: Confirm whether /etc/resolv.conf is a stub symlink

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

What it means: DNS is mediated by systemd-resolved. Your “DNS is slow” might be upstream, but your hostname mismatch can still be fixed locally.

Decision: Treat DNS as a separate issue. First, ensure local hostname resolves without DNS.

Task 11: Check the local hosts mapping quickly (what does localhost resolve to?)

cr0x@server:~$ getent hosts localhost
127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback

What it means: Localhost is sane. Your problem is not “someone deleted localhost”. Good news.

Decision: Focus on mapping your actual hostname, not rebuilding the whole file.

Task 12: Fix /etc/hosts (safely) and verify lookup speed

cr0x@server:~$ sudo cp -a /etc/hosts /etc/hosts.bak.$(date +%F-%H%M%S)
cr0x@server:~$ sudo sed -i 's/^127\.0\.1\.1\s\+.*/127.0.1.1 ip-10-24-3-17/' /etc/hosts
cr0x@server:~$ cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 ip-10-24-3-17

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

What it means: You replaced the stale template hostname with the real one. Minimal change, maximal effect.

Decision: Re-run the slow commands. If they’re now instant, stop. Don’t “also tweak DNS” out of superstition.

Task 13: Validate the fix with getent and sudo timing

cr0x@server:~$ time getent hosts "$(hostname)"
127.0.1.1       ip-10-24-3-17

real    0m0.003s
user    0m0.000s
sys     0m0.003s
cr0x@server:~$ time sudo -n true

real    0m0.118s
user    0m0.012s
sys     0m0.011s

What it means: The lookup is now local and instant; sudo returns to normal human timescales.

Decision: Close the incident. If SSH is still slow, handle it separately with server-side DNS settings.

Task 14: If SSH is slow, test from the server’s perspective (auth log timing)

cr0x@server:~$ sudo tail -n 20 /var/log/auth.log
Dec 30 10:22:11 server sshd[2194]: Connection from 10.24.3.50 port 51344 on 10.24.3.17 port 22 rdomain ""
Dec 30 10:22:21 server sshd[2194]: Accepted publickey for cr0x from 10.24.3.50 port 51344 ssh2: ED25519 SHA256:1q2w3e4r5t...
Dec 30 10:22:21 server sshd[2194]: pam_unix(sshd:session): session opened for user cr0x(uid=1000) by (uid=0)

What it means: There’s a 10-second gap between connection and acceptance. That often points to DNS or GSSAPI delays.

Decision: Inspect sshd_config for UseDNS and GSSAPIAuthentication if your environment doesn’t need them.

Task 15: Check SSH daemon config for DNS-related slow paths

cr0x@server:~$ sudo sshd -T | egrep 'usedns|gssapiauthentication'
usedns yes
gssapiauthentication no

What it means: Reverse DNS is enabled. In some networks that’s fine; in others it’s a guaranteed stall.

Decision: If you don’t rely on PTR-based logging or access controls, set UseDNS no and restart SSH.

Task 16: Apply UseDNS no (if appropriate) and confirm reload

cr0x@server:~$ sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F-%H%M%S)
cr0x@server:~$ echo 'UseDNS no' | sudo tee -a /etc/ssh/sshd_config
UseDNS no
cr0x@server:~$ sudo systemctl restart ssh
cr0x@server:~$ sudo systemctl is-active ssh
active

What it means: SSH has been restarted with the new setting. New connections should no longer wait on reverse DNS.

Decision: If you’re in a corporate environment where reverse DNS is mandated, fix PTR records instead of disabling it.

Tres microhistorias corporativas reales

Mini-story 1: El incidente causado por una suposición equivocada

Un equipo SaaS mediano desplegó Ubuntu 24.04 para un conjunto de runners internos. Estas máquinas no atendían tráfico de clientes directamente,
pero eran la grasa en la canalización: trabajos de CI, firma de artefactos, compilación de contenedores. Nadie prestó atención hasta que los despliegues empezaron a agotar tiempos.

La suposición fue simple y muy humana: “Si SSH funciona, la máquina está bien.” Los ingenieros podían iniciar sesión eventualmente, así que la historia se volvió
“la red está lenta hoy” y luego “el VPN está fallando” y luego “quizá el nuevo kernel está raro.” A la gente le encanta una causa raíz de moda.

El detalle letal fue que cada comando privilegiado—instalar paquetes, reiniciar servicios, obtener registros como root—tenía una demora de 10–15 segundos.
Multiplicado en pasos de automatización, el tiempo de trabajo de CI se disparó. Alguien finalmente midió sudo -n true y vio el patrón: demora consistente, sin pico de CPU.

La solución fue una edición de dos líneas en /etc/hosts. La imagen de la nube se había plantillado con 127.0.1.1 ubuntu-template,
y cloud-init renombró el host al arrancar sin actualizar esa línea. El sistema caía a DNS cada vez que intentaba resolverse a sí mismo.

La lección no fue “sé más inteligente”. Fue “deja de asumir que el síntoma te dice la capa”. Que SSH esté “disponible” no significa que la resolución de nombres
no te esté matando dentro de herramientas privilegiadas.

Mini-story 2: La optimización que salió mal

Una empresa del sector financiero tuvo una “iniciativa de reducción de latencia” que incluía recortar servicios en tiempo de arranque de imágenes base.
Alguien decidió que las entradas locales de host eran “legado” y que todo debería ser “DNS real”, porque “tenemos DNS”.
La imagen dorada quedó con un /etc/hosts minimalista con solo localhost y el boilerplate de IPv6.

En laboratorio funcionó. En producción, el equipo de red tenía DNS split-horizon con vistas distintas para segmentos diferentes,
y algunos segmentos no tenían registros directos para hostnames efímeros. Existía DNS inverso para auditoría, pero el DNS directo era incompleto por diseño.
De repente, servidores aleatorios se pausaban en sudo y servicios ocasionales arrancaban lentamente porque sus scripts de inicio hacían búsquedas de host.

La “optimización” también empeoró el troubleshooting. Cuando un servidor no pudo alcanzar los resolvers corporativos (un problema de deriva de firewall),
los comandos administrativos básicos empezaron a bloquearse. Los operadores tuvieron que pelear con la máquina para arreglarla. Eso es lo operativo equivalente a pisar rastrillos.

Revirtieron a la práctica aburrida: mantener un mapeo local correcto del hostname en /etc/hosts. DNS siguió siendo la autoridad para nombres reales,
pero la máquina siempre pudo resolverse instantáneamente. Esa entrada local se convirtió en una característica de fiabilidad.

Conclusión: eliminar la resolución de nombres local no es “modernización”. Es externalizar tu arranque a la red y rezar porque la red sea perfecta.
La red nunca es perfecta.

Mini-story 3: La práctica aburrida que salvó el día

Una gran empresa con flota mixta (físicos, VMs, contenedores) tenía una regla simple integrada en su pipeline de construcción:
cada nodo debe pasar una comprobación de “auto-resolución” antes de declararse saludable. Era poco emocionante y universalmente impopular entre quienes equiparan
política con burocracia.

La comprobación era literalmente: confirmar que getent hosts $(hostname) devuelve en menos de 100ms y mapea a loopback o a la interfaz primaria,
dependiendo del rol. Si no, la instancia fallaba el aprovisionamiento y se reciclaba.

Durante una ventana de mantenimiento de DNS, un cambio malo aumentó la latencia del resolvedor para un subconjunto de segmentos. Muchos sistemas tuvieron problemas.
Pero los nodos Ubuntu 24.04 recién aprovisionados no se sumaron al incendio porque siempre tuvieron auto-resolución local funcionando.

El equipo on-call todavía tuvo una noche complicada. No tuvieron la noche adicional que habrían tenido si cada nodo recientemente escalado
se hubiera unido a la fiesta del outage colgándose en sudo y en SSH lentos.

La práctica aburrida no evitó incidentes de DNS. Evitó que los incidentes de DNS se convirtieran en “todo está lento y nadie puede administrar nada.”
Esa distinción es donde vive tu sueño.

Broma #2: La parte más fiable de muchas infraestructuras sigue siendo un archivo de texto editado en 1983.

La solución aburrida: hacer que hostname y /etc/hosts concuerden

Tu objetivo es simple: cuando el sistema pregunte “¿quién soy?”, debe obtener una respuesta al instante sin tocar DNS.
Eso significa que el hostname actual debe estar presente en /etc/hosts en un mapeo de loopback (o una dirección local apropiada).

Cómo es “correcto” en Ubuntu

Para la mayoría de servidores Ubuntu, el enfoque conservador y de bajo drama es:

• Mantener 127.0.0.1 localhost y las entradas de loopback IPv6 intactas.
• Usar 127.0.1.1 para el hostname del sistema (y opcionalmente su FQDN).
• Asegurarse de que $(hostname) aparezca en esa línea.

Patrón de ejemplo:

cr0x@server:~$ sudo sed -n '1,5p' /etc/hosts
127.0.0.1 localhost
127.0.1.1 ip-10-24-3-17 ip-10-24-3-17.internal

¿Por qué 127.0.1.1 y no 127.0.0.1? Ubuntu/Debian históricamente reservan localhost para localhost y mapean el hostname a 127.0.1.1.
Esto evita algunas suposiciones de software más antiguo y mantiene la semántica ordenada. ¿Es la única manera? No. ¿Es la que evita casos sorprendentes en Ubuntu? Sí.

Cuando deberías mapear a la IP real de la interfaz en su lugar

Si la máquina ejecuta software que enlaza a direcciones resueltas por hostname (algunas apps Java, algunos sistemas clusterizados, ciertos demonios de almacenamiento),
mapear el hostname a loopback puede estar mal. En esos casos:

• Mapea el FQDN a la IP de la interfaz primaria (la que los servicios deberían anunciar).
• Mantén una entrada de alias de loopback para el hostname corto si necesitas velocidad local, pero hazlo intencionalmente.

Aquí es donde los clusters de almacenamiento y los sistemas distribuidos se vuelven exigentes. No quieres que los nodos del cluster “se descubran” a sí mismos en loopback.
Si ejecutas Ceph, identidades de nodos de Kubernetes, o cualquier cosa con gossip/peer advertisements, confirma lo que espera antes de elegir el mapeo.

Hostnames en la nube: decide quién puede renombrar la máquina

Ubuntu en la nube suele involucrar cloud-init. Si cloud-init puede establecer el hostname al arrancar, necesitas asegurar
que el resto de tu configuración sea consistente:

• Si el hostname cambia, /etc/hosts debe seguirle la pista.
• La automatización debe establecer ambos en el momento del aprovisionamiento o desactivar los cambios de hostname provocados por el proveedor.

El modo de fallo es predecible: la imagen dorada tiene ubuntu-template, la instancia se convierte en ip-10-..., y ahora la resolución de nombres va a DNS.
Tu ticket de incidente lo llamará “sudo roto” porque los humanos son honestos así.

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

1) Symptom: “sudo takes 10–30 seconds”

Root cause: $(hostname) does not resolve locally; NSS falls through to DNS and waits on timeouts.

Fix: Add/update 127.0.1.1 your-hostname (and optionally FQDN) in /etc/hosts, then retest with time sudo -n true.

2) Symptom: “sudo: unable to resolve host …” appears after renaming

Root cause: /etc/hostname or hostnamectl changed, but /etc/hosts still contains the old name.

Fix: Edit /etc/hosts to include the new hostname; don’t revert the rename unless you meant to.

3) Symptom: SSH login prompt appears slowly, but once logged in it’s fine

Root cause: Server-side reverse DNS lookups for the client IP are slow (UseDNS yes) or DNS resolvers are unreachable.

Fix: In disposable environments, set UseDNS no. In audited environments, fix PTR records and resolver reachability instead.

4) Symptom: Local services start slowly at boot; logs show “Temporary failure in name resolution”

Root cause: Services call hostname resolution early; if DNS is used and not ready, they stall.

Fix: Ensure hostname resolves via /etc/hosts and that hosts: in nsswitch.conf has files first.

5) Symptom: Everything works on one network, breaks on another (VPN vs office vs cloud)

Root cause: Your system is depending on upstream DNS to resolve its own hostname; different networks provide different DNS views/latency.

Fix: Make self-resolution local. Then decide whether DNS for the hostname is also required for external systems.

6) Symptom: You “fixed” /etc/hosts, but it still hangs

Root cause: NSS order was modified, or the hostname being resolved is not what you think (FQDN vs short name), or the lookup is for the client IP reverse DNS (SSH).

Fix: Check hostnamectl, sudo sshd -T, and grep '^hosts:' /etc/nsswitch.conf. Use time getent hosts ... to isolate which name is slow.

7) Symptom: “sudo” is fast, but some storage/cluster component can’t bind or advertises 127.0.1.1

Root cause: You mapped a service identity hostname to loopback, but the service expects a routable address.

Fix: Map the service/FQDN to the real interface IP. Keep loopback mapping only for a local-only alias if needed.

Listas de verificación / plan paso a paso

Checklist A: Fix sudo slowness caused by hostname/hosts mismatch (safe and fast)

1. Measure: time sudo -n true. If it’s consistently slow, proceed.
2. Identify hostname: hostname and hostnamectl. Write it down.
3. Check local mapping: grep -n '127.0.1.1' /etc/hosts and cat /etc/hosts.
4. Back up: copy /etc/hosts to a timestamped file.
5. Edit: ensure a line like 127.0.1.1 your-hostname exists (optionally add FQDN).
6. Validate: time getent hosts "$(hostname)" must be < 0.1s in normal conditions.
7. Validate again: time sudo -n true should drop to sub-second.
8. Stop. Don’t touch DNS unless you still have symptoms.

Checklist B: Fix slow SSH session setup (server-side)

1. Confirm the delay: check timestamps in /var/log/auth.log around connection and authentication.
2. Inspect effective config: sudo sshd -T | egrep 'usedns|gssapiauthentication'.
3. If reverse DNS is not required: set UseDNS no, restart ssh, retest.
4. If reverse DNS is required: fix PTR records and make sure resolvers are reachable with low latency from the server.
5. Retest from a client and watch logs again.

Checklist C: Prevent it in automation (the part future-you will thank you for)

1. In your provisioning pipeline, add a health check: getent hosts $(hostname) must return quickly.
2. Enforce /etc/hosts correctness in the image build (template hostnames are fine; leaving them uncorrected is not).
3. Decide whether cloud-init is allowed to rename the host; if yes, ensure it also updates hosts or your tooling does.
4. Standardize on short name vs FQDN usage; mixed expectations create phantom bugs.
5. Document the exception cases (clusters that must resolve to routable IPs).

FAQ (las preguntas que te harán cinco minutos después de arreglarlo)

1) Why does a hostname mismatch affect sudo at all?

Because sudo (and libraries it uses) may resolve the local hostname for logging, audit records, policy evaluation, or display.
If resolution falls through to slow DNS, sudo inherits the wait.

2) Why is this showing up on Ubuntu 24.04 specifically?

The behavior isn’t new, but 24.04 deployments often involve cloud-init, templated images, and systemd-resolved defaults.
That combination makes hostname drift more common, and the resulting timeouts more visible.

3) Do I need to reboot after fixing /etc/hosts?

No. Name resolution via /etc/hosts is read at lookup time. Once the file is corrected, lookups should be immediately fast.
If you changed the hostname itself, services may need restarts, but the hosts fix doesn’t require rebooting.

4) Should the hostname map to 127.0.1.1 or 127.0.0.1?

On Ubuntu/Debian, mapping it to 127.0.1.1 is the conventional, low-surprise choice.
Keep 127.0.0.1 for localhost.

5) Should I put the hostname on the machine’s real IP instead of loopback?

Sometimes. If the hostname represents a network identity used by other hosts or cluster members, map it to the real interface IP and ensure DNS matches.
If the hostname is mostly local identity and you just want sudo fast, loopback mapping is fine.

6) If I add the hostname to /etc/hosts, am I “lying” to DNS?

You’re providing a local override for local correctness. That’s not lying; it’s bootstrapping.
If other systems need to reach this host by name, you still need proper DNS. Local hosts entries don’t replace that.

7) SSH is slow only for some client networks. Is that still hostname mismatch?

It could be, but it’s more commonly reverse DNS on the server for the client IP. Different client subnets have different PTR behavior.
Check server logs for gaps and confirm UseDNS behavior.

8) What’s the safest way to rename an Ubuntu server without breaking sudo?

Use hostnamectl set-hostname (or edit /etc/hostname carefully), then immediately update /etc/hosts
so the new name resolves locally. Verify with getent hosts $(hostname).

9) Can systemd-resolved cache the wrong thing and keep it slow?

Caching can affect DNS lookups, but a correct /etc/hosts entry with files first in NSS should bypass DNS entirely.
If it’s still slow, your NSS order or the name being looked up is different than you think.

10) Is disabling SSH reverse DNS (UseDNS no) always safe?

Safe enough in many environments, but not always appropriate. If you rely on host-based controls, auditing that requires PTR, or strict logging policies,
fix DNS instead of disabling checks.

Pasos siguientes para evitar que se repita

La verdad operativa: el desajuste hostname/hosts no es un “bug raro”. Es una consecuencia rutinaria de plantillas, metadatos en la nube y humanos que renombran servidores
sin completar el papeleo.

Haz la solución aburrida: asegúrate de que $(hostname) se resuelva al instante vía /etc/hosts. Valida con getent.
Luego, y solo entonces, persigue problemas de calidad de DNS o comportamiento de DNS inverso en SSH si aún tienes síntomas.

Pasos prácticos que realmente pondría en un runbook:

• Añadir una comprobación automatizada de “auto-resolución” a los pipelines de aprovisionamiento.
• Estandarizar la imagen base: línea correcta en /etc/hosts, sin hostname de plantilla obsoleto.
• Decidir si SSH debe hacer DNS inverso en tu entorno; elige una política, documéntala y hazla cumplir.
• Cuando renombres un host, trata a /etc/hosts como parte del renombrado, no como un accesorio opcional.

No te llevas medallas por arreglar esto. Recuperas tu tarde. Ese es el mejor premio.