Fixing "sudo: unable to resolve host"

2026-06-06 Reading time: About 9 min Difficulty: Intermediate

What Does "sudo: unable to resolve host" Mean?

Conclusion: It is a warning, not an error. It means sudo could not resolve its own host name at startup. The command usually still runs, but each invocation waits a few seconds for the lookup to time out. The cause almost always reduces to a mismatch between hostname and /etc/hosts.

When you run sudo, a line like this appears before the command's output.

$ sudo apt update
sudo: unable to resolve host myserver: Name or service not known
[sudo] password for user:

The message means "the host name myserver cannot be resolved". The key point is that sudo usually still runs to completion even when you see it. Nothing is "broken" — sudo is simply reporting that its own host name is not registered anywhere on the name-resolution path.

There is a side effect, though. sudo waits for the resolver to time out before giving up, so every sudo invocation incurs a few seconds of delay. The warning itself is harmless, but that delay is what makes it worth fixing.

Why Does sudo Resolve Its Own Host Name?

Conclusion: sudo needs to know which host it is running on to evaluate Host rules in sudoers and to write log entries. So it resolves its own host name at startup, and warns when that fails.

sudoers supports Host / Host_Alias rules that enable a rule only on specific hosts. To evaluate them, sudo must know "which host am I running on right now". It takes the name from gethostname(2) and resolves it through the resolver to identify the host.

# Example Host specs in sudoers (used in NIS / central management)
user  ALL=(ALL)  ALL          # all hosts
user  web01=(ALL)  ALL        # only on web01

A single-server setup often does not use Host specs, but sudo attempts the resolution at startup regardless. It also references the host name to log "who ran what on which host" to syslog. So when the host name itself cannot be resolved, the warning appears before the real work.

Where Does the Cause Lie?

Conclusion: The cause is almost always a mismatch between /etc/hostname (the current host name) and /etc/hosts (the static name table). The classic case: you changed the hostname but never updated /etc/hosts.

Resolving your own host name normally checks /etc/hosts first (because files comes first in the hosts: line of /etc/nsswitch.conf). If the current host name has no entry there, the lookup falls through to DNS, fails there too, and gives up. The causes organized:

Triage is simple: just check whether "the current host name" and "the name written in /etc/hosts" match. If they do not, that is the cause.

How Do You Confirm It?

Conclusion: Compare the current name from hostname against the names in cat /etc/hosts, then confirm with getent hosts <name> whether it actually resolves. If getent is empty, that is the direct cause.

First, check the host name in use.

$ hostname

myserver

Next, look inside /etc/hosts. Whether the name above appears here is the crux.

$ cat /etc/hosts

127.0.0.1   localhost
::1         localhost ip6-localhost ip6-loopback

In this example there is no line for myserver anywhere. localhost is present, but the all-important self-host name is not registered. Finally, confirm whether it actually resolves through the resolver with getent.

$ getent hosts myserver

(no output = it does not resolve)

If getent hosts <name> returns nothing, that name does not exist anywhere on the resolution path. This is the direct trigger for sudo: unable to resolve host. On a healthy host, it instead prints the IP and the name.

$ getent hosts web01
127.0.1.1       web01

How Do You Fix It?

Conclusion: Just add a line for the current host name to /etc/hosts. On the Debian/Ubuntu family, the convention is to add 127.0.1.1 <hostname> as a line separate from 127.0.0.1 localhost.

Register the name from hostname into /etc/hosts. If sudo still works (even with the delay), you can use it to edit.

# Take the current host name
$ hostname
myserver

# Edit /etc/hosts (with any editor)
$ sudo nano /etc/hosts

The edited /etc/hosts should look like this. Note the added 127.0.1.1 line.

127.0.0.1   localhost
127.0.1.1   myserver
::1         localhost ip6-localhost ip6-loopback

After saving, confirm that it resolves immediately.

$ getent hosts myserver

127.0.1.1       myserver

If it returns the IP and host name, the fix is complete. Subsequent sudo runs show neither the warning nor the delay. The setting takes effect the moment you write the file — no reboot or service restart needed.

$ grep -q "$(hostname)" /etc/hosts || echo "127.0.1.1   $(hostname)" | sudo tee -a /etc/hosts

How Do You Change the Host Name for Good?

Conclusion: When changing the host name, always update hostnamectl set-hostname and /etc/hosts together. Doing only one of them is exactly how you create this warning yourself.

If you want to change the host name itself (and that change caused the warning), use systemd's hostnamectl. It rewrites /etc/hostname and applies the change to the running system immediately.

# Change to the new host name
$ sudo hostnamectl set-hostname web01

# Confirm the change
$ hostnamectl status

   Static hostname: web01
         Icon name: computer-vm
            ...

hostnamectl updates /etc/hostname but does not update /etc/hosts automatically. So after the change, fix the old host name in /etc/hosts to the new one.

127.0.0.1   localhost
127.0.1.1   web01
::1         localhost ip6-localhost ip6-loopback

Finally, confirm the new name resolves.

$ getent hosts "$(hostname)"

127.0.1.1       web01

On cloud-init environments, the host name can revert on reboot unless you set preserve_hostname: true in /etc/cloud/cloud.cfg. If your hand-edits disappear, suspect this management path.

Checklist When It Still Fails

Conclusion: If the warning persists, check in order whether hostname and /etc/hosts match exactly, and whether the hosts: line in nsswitch.conf has files. Typos and stray whitespace are the classic traps.

• [ ] Do the hostname output and the /etc/hosts entry match character for character?
• [ ] Did you add the 127.0.1.1 <hostname> (or real IP) line to /etc/hosts?
• [ ] Does getent hosts "$(hostname)" now return an IP?
• [ ] Does the hosts: line in /etc/nsswitch.conf start with files (hosts: files dns)?
• [ ] For an FQDN, did you list both forms, e.g. 127.0.1.1 web01.example.com web01?
• [ ] If it reverts after reboot on cloud / container, did you check cloud-init's preserve_hostname?
• [ ] After editing, did you drop the auth cache with sudo -k and recheck?