sudo: unable to resolve host b58d39286a39: Name or service not known means the machine's own hostname has no line in /etc/hosts. Add one, such as 127.0.1.1 your-hostname, and the message goes away.

Run hostname to get the exact name, then append a line that maps it to 127.0.1.1. In the test the next sudo printed nothing.

The error

sudo true
sudo: unable to resolve host b58d39286a39: Name or service not known
exit code: 0

Why it happens

The hostname was b58d39286a39, and the line that named it had been removed from /etc/hosts, leaving only localhost and the IPv6 entries. sudo looked the name up, found nothing and printed the warning. Note the exit code: the command still ran and returned 0. The message is a warning, so a script does not stop on it.

On Ubuntu in WSL, run the same check: compare the output of hostname with the lines in /etc/hosts. If no line carries that exact name, you have the cause shown here.

The fix

hostname
b58d39286a39
echo "127.0.1.1 $(hostname)" >> /etc/hosts
cat /etc/hosts
127.0.0.1	localhost
::1	localhost ip6-localhost ip6-loopback
fe00::	ip6-localnet
ff00::	ip6-mcastprefix
ff02::1	ip6-allnodes
ff02::2	ip6-allrouters
127.0.1.1 b58d39286a39
sudo true
exit code: 0

The commands above ran as root inside the container, where a plain >> redirect can write the file. In WSL you work as a normal user and /etc/hosts belongs to root, so pipe the line through sudo tee -a instead. That form was run in a second pass, with the hostname line removed again first: 

echo "127.0.1.1 $(hostname)" | sudo tee -a /etc/hosts
sudo: unable to resolve host b58d39286a39: Name or service not known
127.0.1.1 b58d39286a39
sudo true
exit code: 0
tail -1 /etc/hosts
127.0.1.1 b58d39286a39

The warning appears once more during the tee itself, because the line is not in the file yet when sudo starts. tee echoes the line it appended, and the next sudo true is silent. A third pass, in a fresh container as a non-root user with sudo rights, matched this: the plain >> /etc/hosts redirect failed with -bash: line 1: /etc/hosts: Permission denied and exit code 1, the sudo tee -a form appended the line with exit code 0, and the next sudo true was silent. Do not be put off by that last warning: check with tail -1 /etc/hosts that the line is there.

How it was reproduced

The capture was made in an ubuntu:24.04 container (Ubuntu 24.04.5 LTS, Sudo 1.9.15p5 installed with apt-get install -y sudo, Docker Engine 29.9.2) standing in for Ubuntu in WSL. The script copied /etc/hosts aside, wrote it back without the line holding the hostname, ran sudo true and got the warning with exit code 0. After appending the 127.0.1.1 line, the same sudo true printed nothing and returned 0; the sudo tee form gave the same result.

Frequently asked

How do I fix sudo unable to resolve host in Ubuntu WSL?
Add a line to /etc/hosts that maps your hostname to 127.0.1.1. Get the name with hostname, then run echo "127.0.1.1 $(hostname)" | sudo tee -a /etc/hosts.
Does sudo unable to resolve host stop my command?
In the test it did not. sudo true printed the warning and still returned exit code 0, so the command ran. It went away once /etc/hosts had a line for the hostname.
When does sudo print unable to resolve host?
In the test the warning appeared exactly when /etc/hosts had no line for the name printed by hostname, and disappeared when that line was added back.

More decoded errors in the Fixes category. For sudo password trouble in WSL see WSL users and passwords.