Fixing the 'Temporary failure in name resolution' Error on Linux

The Error Message

You’re trying to run a quick update or check your connection, but Linux stops you in your tracks. You type sudo apt update or ping google.com, and instead of a stream of data, you get hit with this frustrating block:

ping: google.com: Temporary failure in name resolution

Essentially, your system has lost its "phonebook." It knows how to reach the internet, but it can’t translate human-readable domain names like google.com into the machine-readable IP addresses needed to route traffic. If you can't resolve the name, you can't connect.

Common Culprits

Most of the time, the problem hides in one of three places:

• The /etc/resolv.conf file is empty, missing, or misconfigured.
• The systemd-resolved service has crashed or failed to start.
• Your local firewall (like UFW) is silently blocking DNS traffic on UDP port 53.

Step 1: Start with a Connectivity Reality Check

Before diving into complex config files, verify that your physical or virtual network is actually alive. Try to ping a public IP address directly. I always use Google’s 8.8.8.8 because it is reliable and easy to remember:

ping -c 4 8.8.8.8

A successful connection—usually returning pings in under 30ms on a decent fiber line—means your hardware and gateway are fine. The issue is strictly DNS. If this ping fails with "Network is unreachable," you have a deeper routing or hardware problem to solve first.

Step 2: Inspect /etc/resolv.conf

Traditionally, Linux looks at /etc/resolv.conf to find its DNS servers. On modern systems like Ubuntu 22.04 or 24.04, this file is typically a symbolic link managed by a background service. Start by checking the current contents:

cat /etc/resolv.conf

If you don't see a nameserver line, you've found the gap. You can temporarily inject a public DNS server to see if it restores access:

sudo nano /etc/resolv.conf

Add these lines to the file:

nameserver 8.8.8.8
nameserver 1.1.1.1

Test your ping again. If it works, you’ve identified the issue. However, keep in mind that many distributions will overwrite this file automatically upon reboot or network restart. To make the fix permanent, you must address the service managing it.

Step 3: Repair systemd-resolved

Most modern distributions use systemd-resolved to handle name resolution. If this service stalls, your DNS dies with it. Verify its heartbeat with this command:

sudo systemctl status systemd-resolved

Is it inactive? Fire it up and ensure it starts automatically every time you boot:

sudo systemctl start systemd-resolved
sudo systemctl enable systemd-resolved

Sometimes the link between the system configuration and the runtime file breaks. You can force-reset this connection by recreating the symbolic link:

sudo rm /etc/resolv.conf
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

Step 4: Update Netplan (Server Environments)

On Ubuntu Server, DNS settings usually live in Netplan configuration files. Look inside the /etc/netplan/ directory for YAML files, often named 01-netcfg.yaml or 50-cloud-init.yaml.

ls /etc/netplan/

Open the relevant file and ensure your nameservers block is correctly defined under your network interface:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true
      nameservers:
        addresses: [8.8.8.8, 1.1.1.1]

Apply the new settings immediately to see if they take effect:

sudo netplan apply

Verification: Confirming the Fix

Don’t just assume it’s fixed because one website loaded. Use dig to confirm that resolution is fast—ideally under 50ms for cached queries—and reliable:

dig google.com

Check the "ANSWER SECTION" in the output. If you see an IP address list, you are back online. If the dig command is missing, you can install it using the dnsutils package once your temporary fix in Step 2 is active.

Pro-Tips for Prevention

When configuring static IPs for new servers, it is incredibly easy to make a typo in the gateway or subnet mask. A wrong digit can prevent your system from reaching its DNS provider even if your config files look perfect.

I find it helpful to keep a tool like the Subnet Calculator from ToolCraft open during deployments. It helps me double-check CIDR ranges and broadcast addresses in seconds, ensuring that a simple routing typo doesn't masquerade as a DNS error. It’s browser-based and private, which is perfect for production environment setups.

Final Check: The Firewall

If your configuration is flawless but resolution still fails, your firewall might be dropping the packets. DNS typically uses UDP port 53. If you use ufw, test this theory by disabling it for 10 seconds:

sudo ufw disable

If the error vanishes, simply add a rule to allow DNS traffic out and then re-enable the firewall: sudo ufw allow out 53/udp.