Temporary failure in name resolution means a name lookup could not complete at that moment. It can result from an unreachable resolver, incorrect resolver configuration or a network problem. It does not by itself mean that the destination website is down.

Run checks in the environment showing the error. A Docker container, WSL distribution and its host can use different DNS settings. If APT reports the error while updating packages, solve name resolution before repeating the package installation checks.

Confirm which name fails

Use the actual hostname from the error. For a public reference check, these commands ask the system's configured name-service sources for Ubuntu's address:

getent ahosts ubuntu.com
grep '^hosts:' /etc/nsswitch.conf

getent follows the system's name-service configuration, which can include local hosts-file entries as well as DNS. Compare the affected hostname with a known public hostname. If only a private company name fails, check the VPN and its private DNS configuration rather than replacing it with a public resolver.

A nonexistent name and a temporary resolver failure are different outcomes. Record the exact error instead of applying every DNS repair you find.

Inspect the connection and routes

ip -brief address
ip route

Look for the expected active interface, an address and the routes needed to reach your DNS server. An IPv6-only environment also needs its IPv6 routes inspected with ip -6 route. If the underlying connection or VPN is down, restore that connection first.

Testing an IP address can help separate routing from name lookup, but a failed ping does not prove that a host is unreachable: networks may block ICMP. Conversely, reaching one public IP does not prove that your configured DNS server is reachable or that a private VPN domain resolves correctly.

Identify who manages DNS

ls -l /etc/resolv.conf
cat /etc/resolv.conf
resolvectl status

On Ubuntu systems using systemd-resolved, the last command shows resolver configuration, including per-link settings. A nameserver such as 127.0.0.53 can be the local resolved stub; it is not automatically an invalid DNS address. Check that the local resolver is running and has usable upstream servers.

If resolvectl is absent or cannot connect to its service, identify whether you are in a container or another resolver setup. Use the service-manager environment checklist before assuming every Ubuntu shell runs systemd-resolved.

Do not overwrite /etc/resolv.conf or replace its symlink with a generic file before identifying its owner. NetworkManager, systemd-networkd, cloud provisioning, WSL or a container runtime may regenerate it.

On an Ubuntu host using systemd-resolved

resolvectl query ubuntu.com
systemctl status systemd-resolved --no-pager
journalctl -u systemd-resolved -n 50 --no-pager

Compare this result with getent. If resolved succeeds while getent fails, investigate local name-service integration. If both fail, examine the upstream server and link configuration. Logs may require additional privileges to show all relevant entries.

Use the DNS servers supplied by your network or approved by its administrator. Persistent settings belong in the manager controlling the connection: for example the Ubuntu desktop's network settings or the appropriate Netplan configuration. Corporate VPNs may need split DNS, where only particular domains use a private resolver.

A cache flush is useful only for a suspected stale cached result:

sudo resolvectl flush-caches

It will not repair an absent route, stopped service or unreachable upstream server. Re-query the original hostname after correcting the configuration. If you must change network settings remotely, keep a console or recovery connection available and use the manager's supported validation procedure.

In WSL or a container

Check resolution on the host and inside the affected environment separately. If only the container fails, inspect its network and DNS settings through the runtime. For WSL, check the active distribution and the current Windows/VPN connection; launching the intended distribution matters when comparing results.

Do not copy a loopback resolver address from the host into a container: loopback there refers to the container itself. In our test, pointing the disposable container at a loopback address with no DNS service produced the temporary-resolution error. Restoring its original resolver configuration restored the lookup.

Verify the original task

Resolve the hostname that originally failed and retry the application. For SSH, a later connection or authentication error means a different stage needs attention. Changing the machine's local hostname alone does not repair upstream DNS.

Sources and verification

Tested September 11, 2026 in an isolated Ubuntu 24.04 container: interface/routes and resolver inspection, successful getent lookup, a temporary resolver failure after a container-only DNS change, and successful lookup after restoring the original configuration. systemd-resolved service management, VPN split DNS, Netplan changes and WSL DNS were documentation-reviewed, not executed in this test.