Ubuntu 24.04: sudo is slow — DNS/hostname fixes that remove the delay (case #66)

What “slow sudo” usually means (and what it isn’t)

When sudo is slow, it’s rarely “sudo being heavy.” It’s usually sudo calling into the system’s name service stack—glibc NSS modules—then waiting on a resolver path you didn’t realize you depended on.

The classic pattern on Ubuntu 24.04:

• Delay happens before password prompt: lookup/initialization (hostname, NSS, PAM, DNS, SSSD, LDAP, Kerberos, etc.).
• Delay happens after password entry: directory auth, PAM modules, network home dirs, group lookups, or logging targets.
• Delay is 5 seconds: suspiciously like a single DNS timeout window or a fallback path waiting to expire.
• Delay is 10/15/20 seconds: multiple resolvers queried in sequence, or both A and AAAA timeouts, or retries.

Also: don’t waste time blaming CPU, disk, or “snap.” If the box is otherwise responsive and only privilege escalation is laggy, you’re in the realm of name resolution and identity lookups.

One operational truth: sudo is a reliability test. If name resolution is flaky, sudo will faithfully report it by being annoying.

Joke #1: DNS is the one dependency everyone forgets until it fails. Then it becomes everyone’s entire personality.

Fast diagnosis playbook

If you’re on-call or you’re SSH’d into a box in a change window, you don’t need a philosophical tour of resolvers. You need a sequence that finds the bottleneck in minutes.

First: confirm it’s name resolution and not PAM/auth

1. Time sudo and compare with sudo -n true.
2. Test sudo with a clean environment.
3. Watch name resolution calls with strace (quick and definitive).

Second: verify hostname and local resolution sanity

1. Check /etc/hostname matches hostnamectl.
2. Ensure /etc/hosts maps 127.0.1.1 (or 127.0.0.1) to your hostname/FQDN consistently.
3. Confirm getent hosts $(hostname) returns instantly.

Third: validate resolver path and DNS server reachability

1. Inspect resolvectl status, /etc/resolv.conf (symlink), and search domains.
2. Query your hostname forward and reverse with resolvectl query and dig.
3. Look for timeouts in journalctl -u systemd-resolved.

Stop when you have the smoking gun

You’re not trying to “improve DNS.” You’re removing a deterministic timeout on a hot path. Fix what’s slow; leave everything else alone.

Interesting facts & context (the parts people forget)

• Fact 1: sudo often resolves the local hostname to log “where the command ran,” and some configurations also resolve the invoking user and groups through NSS.
• Fact 2: On Debian/Ubuntu, 127.0.1.1 in /etc/hosts is a long-standing convention for mapping the local hostname on non-loopback systems, especially where the real IP may change (laptops, DHCP).
• Fact 3: glibc’s NSS (Name Service Switch) is modular and order-dependent. One slow module (DNS, mdns, sss) in the chain can stall everything that calls getaddrinfo().
• Fact 4: systemd-resolved introduced split DNS and per-link routing of queries; great for VPNs, and also great at exposing misconfigured search domains.
• Fact 5: Reverse DNS lookups (PTR records) are frequently missing in corporate networks—especially for “random” workstation ranges—yet many systems still try them for logging or policy.
• Fact 6: An AAAA (IPv6) query can introduce delays on IPv4-only networks if the resolver tries v6 first and waits for timeouts instead of fast NXDOMAIN.
• Fact 7: mDNS (.local via Avahi) and DNS can interact badly if your hostname or search domain choices are sloppy; “local” is a special zone in many environments.
• Fact 8: A search domain list that’s too long can multiply queries: each single-name lookup expands into several FQDN attempts.
• Fact 9: The “five second pause” is often not random: it’s a resolver timeout default you can literally count.

One paraphrased idea that should be printed on the inside of every ops notebook: paraphrased idea from Gene Kim: reliability comes from reducing handoffs and hidden dependencies—especially the ones that time out.

Measure it properly: make the delay confess

Before changing anything, measure. Not because we love spreadsheets, but because “it feels faster” is how you end up with a config pile that nobody understands.

What you want:

• Exact delay duration.
• Whether it’s pre-password or post-password.
• Whether it tracks DNS timeouts (5s, 10s, etc.).
• Which syscall is blocking (usually connect() to a DNS server, or reads waiting on it).

Root causes: DNS, hostname, NSS, and friends

1) Hostname not resolvable locally

The machine knows its hostname, but can’t resolve it to an address quickly. Then programs that do a simple “what is my name?” followed by “what is my address?” fall into DNS, which falls into timeouts.

Ubuntu’s usual fix: ensure /etc/hosts has an entry for the hostname (and optionally FQDN) on loopback. The point is speed and determinism, not elegance.

2) DNS server unreachable (or wrong per-link DNS)

Your resolver points at DNS servers that are unreachable from this host (stale VPN DNS, old office DNS, dead lab network). Every lookup waits for timeout(s) before falling back.

3) Overly ambitious search domains

Search domains are handy—until they’re a query multiplier. A single-name lookup like myhost can become:

• myhost.corp.example
• myhost.dev.example
• myhost.example
• …and then maybe the bare name

If each step times out, you’ve built a delay generator. The fix is to reduce search domains or use FQDNs where it matters.

4) NSS order pulls in slow network identity providers

If /etc/nsswitch.conf says “consult SSSD/LDAP/DNS for everything,” then even local user/group lookups can stall. sudo frequently checks group memberships and user identity. That’s normal. Doing it over a broken network path is not.

5) Reverse DNS and logging assumptions

Some environments use reverse DNS for auditing. Others accidentally trigger reverse lookups because of how hostnames are resolved or logged. Missing PTR records aren’t fatal, but timeouts are.

6) IPv6 mismatch and AAAA timeouts

If your network drops IPv6 packets or blocks v6 DNS transport, AAAA lookups can be “slow fail.” You can fix the network, disable broken IPv6, or tune resolver behavior. The correct choice depends on whether IPv6 is intentionally supported.

Joke #2: If you want to feel powerful, fix one DNS timeout and watch a “slow Linux” complaint evaporate in under a second.

Practical tasks (commands, outputs, and decisions)

These are real commands you can run on Ubuntu 24.04. Each task includes what to look for and the decision you make.

Task 1: Time the pain

cr0x@server:~$ time sudo -v

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

What it means: ~5.2s wall time with negligible CPU suggests waiting on I/O (often DNS).

Decision: Treat as external dependency latency, not system load. Move to hostname/DNS checks.

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

What it means: Still slow even without prompting. This is not “human typing delay” or PAM password handling.

Decision: Focus on pre-auth initialization: hostname resolution, NSS, resolver, sudoers lookups.

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

What it means: getent is slow too. That’s not sudo-specific; it’s name service.

Decision: Fix NSS/DNS path. Sudo will improve as a side effect.

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

What it means: Hostname is app-node-7, but 127.0.1.1 maps to ubuntu. That mismatch often triggers DNS lookups for the actual hostname.

Decision: Update /etc/hosts to map 127.0.1.1 to your real hostname (and optionally 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

What it means: Static hostname is set correctly. The mismatch is likely in local resolution, DNS, or both.

Decision: Don’t change hostname just to fix resolution; fix the mapping.

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

What it means: Hosts lookup tries files, then mDNS minimal, then DNS, then myhostname. That ordering can force network lookups before the local hostname shortcut.

Decision: Consider moving myhostname earlier, or ensure /etc/hosts is correct so files resolves instantly.

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

What it means: The system uses stub resolver mode and points at corporate DNS servers.

Decision: If those servers aren’t reachable from this host/network segment, fix netplan/VPN DNS assignment or set correct per-link DNS.

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

What it means: Requests go to the local stub 127.0.0.53, then systemd-resolved forwards to configured upstream DNS.

Decision: Debug upstream reachability and timeouts via resolved logs and direct queries.

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

What it means: The resolver took ~5 seconds to answer. This is the same delay you see in sudo.

Decision: Confirm why upstream DNS is slow: unreachable server, firewall, wrong route, broken search domains, or reverse lookup timeouts.

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.

What it means: Upstream DNS servers are unreachable. Resolved is cycling servers and transport modes, burning time.

Decision: Fix routing/firewall/VPN, or change DNS servers for this link to reachable ones. Don’t “tune timeouts” as your first move.

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

What it means: No ICMP reply and TCP/53 times out. Even if ICMP is blocked, TCP/53 timeout is a strong signal.

Decision: Confirm correct DNS IPs for this subnet/VPC; fix security group/firewall rules; or set alternate reachable resolvers.

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

What it means: The stall is a DNS query via the local stub. You see a ~5 second gap before recvfrom times out.

Decision: Stop debating. Fix DNS reachability or local hostname mapping so sudo doesn’t need DNS for itself.

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

What it means: DNS can’t be reached at all. Reverse DNS is dead too, but that’s a symptom of the same reachability issue.

Decision: Fix upstream DNS selection and network path; don’t paper over with random options timeout: unless you’re in emergency mode.

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

What it means: Netplan explicitly sets DNS servers. If those aren’t reachable from this network, it’s a config bug, not a transient issue.

Decision: Change nameservers to the right ones for this environment (or remove overrides if DHCP should provide them).

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

What it means: The delay disappears. You’ve bypassed DNS for the local hostname resolution path.

Decision: Keep this fix even after you repair DNS. Local mapping is cheap insurance against future DNS weirdness.

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

What it means: Even id is slow. That’s NSS (possibly SSSD) waiting on a network provider.

Decision: Check SSSD status and upstream directory reachability; consider making local accounts files-first and ensuring directory providers are healthy.

Fixes that work (and why)

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

Put your hostname in /etc/hosts. Yes, even if you have DNS. Yes, even if you’re “cloud native.” This is about removing a network dependency from a local privilege escalation path.

Recommended pattern on Ubuntu:

• 127.0.0.1 localhost
• 127.0.1.1 yourhost.yourdomain yourhost

Why it works: NSS checks files first (usually). That resolves immediately and never touches DNS.

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

If you’re pointing to DNS servers that live behind a VPN you’re not connected to, or in a different VPC, you’re guaranteed timeouts. Fix DNS assignment at the source:

• Netplan static config: set reachable nameservers.
• DHCP: ensure the DHCP option hands out correct DNS servers for that subnet.
• VPN split DNS: ensure per-link DNS is set only when the VPN is up.

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

A long search list is a self-inflicted query fan-out. If you inherited a search list with five suffixes, cut it down. If you can’t, then stop using short hostnames in automation. Use FQDNs in scripts and config.

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

Be careful here: NSS changes can have broad effects. But in environments with predictable local needs, you can reorder hosts: to avoid slow modules.

Typical safe-ish goals:

• Ensure files is first.
• Ensure myhostname is not last if you rely on it.
• Avoid mDNS unless you actually use it.

If your fleet depends on mDNS for developer laptops, fine. On servers? Usually no.

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

If security/audit tooling expects PTR lookups, then missing PTR is a defect, not a shrug. Add PTRs for server IPs. Make forward and reverse match. Your future incident reports will be shorter and less angry.

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

If IPv6 is supported, make DNS and routing work end-to-end. If it isn’t supported, disable it consistently (or at least prevent the resolver from chasing broken paths). Half-supported IPv6 is a reliable way to create intermittent delays that nobody reproduces in the lab.

Three corporate-world mini-stories

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

They’d just migrated a set of internal build runners from one network segment to another. The team assumed “DNS is universal,” because the new segment had outbound internet and could resolve public domains.

Everything looked fine until the first patch day. Engineers SSH’d in, ran sudo apt-get, and waited. The pause was consistent—about five seconds—on every privileged command. People started blaming the new kernel, the EDR agent, and one person even suggested “Ubuntu 24.04 is just heavier.”

The actual problem was simple and quietly humiliating: the netplan template hardcoded DNS servers that were only reachable from the old segment. Public DNS worked through a local forwarder, but internal zones did not. And the hostnames were internal.

Once someone timed getent hosts $(hostname) and saw the same stall, the mystery evaporated. They replaced the DNS server list with the correct per-segment resolvers and added the hostname to /etc/hosts as a guardrail.

Two lessons stuck: “public DNS works” is not “DNS works,” and “it only affects sudo” is often “it affects name resolution on a hot path.”

Mini-story #2: The optimization that backfired

A platform team wanted “cleaner” host identity. They removed 127.0.1.1 hostname entries from /etc/hosts via configuration management, insisting that DNS should be the source of truth. They were technically right in a narrow sense and operationally wrong in a wide one.

For a while nothing bad happened. Then a temporary DNS maintenance window hit one region. Not a full outage—just higher latency and occasional timeouts. Suddenly every privileged action on hundreds of instances became sticky. Sudo delays cascaded into slower deploys, slower incident response, and a general sense that the region was haunted.

The “optimization” also created a debugging trap. Since DNS eventually worked, the problem looked intermittent. It wasn’t. It was deterministic resolver behavior under transient upstream latency.

They rolled back: hostname in /etc/hosts, DNS still authoritative for service discovery, and strict monitoring for DNS latency. Nobody framed it as “going backward,” because it was really about removing a dependency from the privilege escalation path.

That team eventually adopted a principle: local identity must be locally resolvable. Everything else can be global.

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

A finance-adjacent environment ran tight change controls, which meant their base images were conservative. Every server had a consistent /etc/hosts entry for its hostname and FQDN on 127.0.1.1. No exceptions, even in ephemeral autoscaling groups.

During an upstream DNS provider incident, many teams saw cascading failures: slow logins, slow sudo, and timeouts from anything doing identity or hostname lookups. That finance environment? Mostly fine. Their apps still depended on DNS for external services, but administrators could still get root instantly and execute local remediations without fighting resolver timeouts.

What saved them wasn’t heroism. It was dull configuration hygiene: deterministic local resolution, minimal search domains, and a resolver config that didn’t attempt clever fallbacks.

When the post-incident review happened, they didn’t brag. They just pointed at their baseline standards and said, “We remove network dependencies from local operations.” Nobody argued with the results.

Common mistakes: symptom → root cause → fix

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

Root cause: hostname lookup hits DNS and waits for timeout (unreachable resolver or missing local mapping).

Fix: add correct hostname mapping to /etc/hosts; ensure DNS servers are reachable via resolvectl status and network rules.

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

Root cause: split DNS misconfigured; per-link DNS points at VPN resolver even when tunnel is down (or the opposite).

Fix: correct VPN client DNS integration; ensure systemd-resolved link-specific DNS is updated; avoid hardcoding DNS in netplan if DHCP/VPN should manage it.

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

Root cause: reverse DNS lookups or NSS identity provider (SSSD/LDAP) timeouts impact both login and sudo.

Fix: verify PTR records and directory provider reachability; ensure files is first in nsswitch.conf and caches are healthy.

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

Root cause: upstream DNS servers unreachable; resolved retries and falls back.

Fix: set reachable DNS servers; fix firewall routing; validate with dig and journalctl -u systemd-resolved.

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

Root cause: “DNS authoritative only” approach; local hostname not in /etc/hosts, so sudo depends on upstream latency.

Fix: restore local hostname mapping; treat it as a reliability feature, not a hack.

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

Root cause: search domains cause multiple attempts; one suffix times out.

Fix: reduce search domains; use FQDN in automation; ensure the short name resolves locally if it must exist.

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

Root cause: changes in resolved defaults, network stack integration, or different DNS server selection (especially with split DNS/VPN).

Fix: verify actual effective DNS with resolvectl status; don’t assume your old resolver chain survived the upgrade unchanged.

Checklists / step-by-step plan

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

1. Measure: time sudo -n true and getent hosts $(hostname). If both are slow, it’s name service.
2. Local guardrail: ensure /etc/hosts maps 127.0.1.1 to hostname (and FQDN if you use one).
3. Confirm improvement: retime sudo -n true. If it’s now fast, you’ve removed the main bottleneck.
4. Fix upstream DNS: check resolvectl status; ensure DNS servers are reachable; correct netplan/DHCP/VPN settings.
5. Reduce query fan-out: tighten search domains; stop using single-label hostnames in scripts.
6. NSS sanity: verify /etc/nsswitch.conf hosts ordering; avoid slow modules unless required.
7. Regression-proof: add a monitoring check for DNS reachability/latency and a simple “sudo is fast” smoke test in provisioning pipelines.

Change-control checklist (for fleets)

• Baseline /etc/hosts includes hostname mapping on loopback.
• Netplan templates do not hardcode DNS that won’t exist in all environments.
• Search domains are short and intentional.
• NSS configuration is consistent across hosts, with local-first resolution.
• Directory providers (SSSD/LDAP) are monitored, and timeouts are understood.
• IPv6 is either supported end-to-end or disabled consistently (no “ghost IPv6”).

FAQ

1) Why does sudo care about DNS at all?

Because it asks the system who you are (user/group lookups) and often resolves the local hostname for logging, policy, or environment checks. Those calls go through NSS, which may consult DNS.

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

No. It’s a reliability pattern: local operations should not depend on network services. Keep DNS for service discovery; keep local mapping for the machine’s own identity.

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

Because resolver timeouts and retries are commonly set in that range, and a single failed query can block the caller until it expires. It’s not random; it’s a timer.

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

/etc/hosts is local, immediate, and deterministic. DNS is network-dependent and can fail or stall. NSS decides which sources are consulted and in what order.

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

Usually no. systemd-resolved is rarely the root cause; it’s the messenger showing you your DNS configuration is wrong or unreachable. Fix the upstream DNS path first.

6) Can search domains alone cause slow sudo?

Yes. A short name can expand into multiple DNS queries. If any suffix path times out, you get a delay that looks like “sudo is slow” but is really “DNS is indecisive.”

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

Time id $USER and getent passwd $USER. If those are slow, identity lookup is slow. If only hostname resolution is slow, focus on hosts: resolution and DNS reachability.

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

Because DNS servers are network-specific in many environments. Hardcoded resolvers, stale DHCP options, or VPN DNS policies don’t survive moves cleanly.

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

It matters if your resolver tries AAAA queries and your network drops or blackholes IPv6. Either support IPv6 properly or disable it consistently; half measures create timeouts.

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

Add the correct hostname mapping to /etc/hosts and verify getent hosts $(hostname) is instant. Then fix upstream DNS when you’re out of the blast radius.

Conclusion: next steps you’ll actually do

Slow sudo on Ubuntu 24.04 is usually not “sudo being slow.” It’s your name service stack waiting on DNS, search domains, or identity providers. The good news: this is diagnosable with a stopwatch and one or two commands.

Do this, in order:

1. Time sudo -n true and getent hosts $(hostname).
2. Fix /etc/hosts so the hostname resolves locally and instantly.
3. Use resolvectl status and resolved logs to find unreachable DNS servers and correct netplan/DHCP/VPN configuration.
4. Trim search domains and avoid single-label names in automation.
5. Only then consider NSS ordering tweaks, and do them deliberately.

If you remove the timeout, you remove the drama. And your future self—staring at a stalled terminal during an incident—will quietly approve.