Fix DNS Not Resolving on Linux

Understanding Linux DNS resolution

Unlike Windows or macOS, Linux has no single DNS subsystem. Resolution flows through a chain:

1. Application calls getaddrinfo() via glibc.
2. nsswitch.conf determines the lookup order (usually files, then DNS).
3. /etc/resolv.conf points to nameservers (often 127.0.0.53 for systemd-resolved).
4. systemd-resolved or NetworkManager forwards the query to upstream DNS.

A failure at any layer breaks DNS. The steps below check each layer systematically.

Step 1 — Test with an external DNS server

First, determine whether the problem is your network or your local DNS configuration:

dig example.com @1.1.1.1

This sends a DNS query directly to Cloudflare, bypassing your local resolver entirely.

• If this works — Your internet connection is fine. The problem is your local DNS configuration (continue to Step 2).
• If this also fails — The problem is your network connection or firewall. Check ping 1.1.1.1 and your firewall rules (Step 8).

If dig is not installed, use host example.com 1.1.1.1 or install it with sudo apt install dnsutils (Debian/Ubuntu) or sudo dnf install bind-utils (RHEL/Fedora).

Step 2 — Check /etc/resolv.conf

This file tells the system where to send DNS queries:

cat /etc/resolv.conf

Common states and what they mean:

• nameserver 127.0.0.53 — Normal for systemd-resolved. The stub listener forwards to upstream DNS. Run resolvectl status to see actual upstream servers.
• nameserver 127.0.0.1 — Points to a local resolver like dnsmasq or Unbound. Check if that service is running.
• Empty file or no nameserver lines — DNS will fail completely. Add nameserver 1.1.1.1 as an immediate fix.
• Symlink to /run/systemd/resolve/stub-resolv.conf — Normal for systemd-resolved. Do not break this symlink.

Check whether the file is a symlink: ls -la /etc/resolv.conf

Step 3 — Fix systemd-resolved

Most modern distributions (Ubuntu 18+, Fedora, Arch) use systemd-resolved. Check its status:

resolvectl status

Look at the DNS Servers line for each interface. If no DNS servers are listed, configure them:

1. Edit the configuration file:

   sudo nano /etc/systemd/resolved.conf

2. Under [Resolve], set:

   [Resolve]
   DNS=1.1.1.1 8.8.8.8
   FallbackDNS=9.9.9.9
   DNSSEC=allow-downgrade

3. Restart the service:

   sudo systemctl restart systemd-resolved

4. Verify:

   resolvectl status

If systemd-resolved is not running at all, start it: sudo systemctl enable --now systemd-resolved

For more details, see our Linux DNS setup guide.

Step 4 — Fix NetworkManager DNS

If your distribution uses NetworkManager (common on desktop Linux), DNS is managed per-connection:

List connections:

nmcli connection show

Set DNS for a connection:

nmcli con mod "Wired connection 1" ipv4.dns "1.1.1.1 8.8.8.8"

Prevent DHCP from overwriting your DNS:

nmcli con mod "Wired connection 1" ipv4.ignore-auto-dns yes

Apply the changes:

nmcli con up "Wired connection 1"

Replace "Wired connection 1" with the connection name from nmcli connection show. Wi-Fi connections typically show the SSID as the name.

Step 5 — Flush the DNS cache

Cached DNS entries can become stale or corrupt. The flush command depends on which caching service you run:

• systemd-resolved: resolvectl flush-caches
• nscd (Name Service Cache Daemon): sudo systemctl restart nscd
• dnsmasq: sudo systemctl restart dnsmasq
• No caching service: Nothing to flush. Most minimal Linux installs do not cache DNS.

To verify the cache was flushed with systemd-resolved:

resolvectl statistics

The cache size should show 0 entries immediately after flushing.

Step 6 — Check nsswitch.conf

The file /etc/nsswitch.conf controls the order in which name resolution sources are consulted:

grep ^hosts /etc/nsswitch.conf

Expected output:

hosts: files dns or hosts: files resolve [!UNAVAIL=return] dns

• files — Check /etc/hosts first (local hostnames).
• resolve — Use systemd-resolved (if installed).
• dns — Use /etc/resolv.conf nameservers.

If the hosts line is missing dns (and resolve if using systemd-resolved), the system will not perform DNS lookups at all. Edit the file to add it:

sudo nano /etc/nsswitch.conf

Step 7 — Test DNSSEC validation

DNSSEC adds cryptographic signatures to DNS responses. If validation fails, you get SERVFAIL instead of an answer:

dig +dnssec example.com

If you see status: SERVFAIL but dig example.com @1.1.1.1 works, DNSSEC validation is failing locally. Common causes:

• Wrong system clock — DNSSEC signatures are time-sensitive. Check with timedatectl and sync: sudo timedatectl set-ntp true.
• Broken trust anchors — Run sudo resolvectl reset-server-features to clear cached DNSSEC state.
• Upstream server does not support DNSSEC — Switch to a DNSSEC-validating resolver like 1.1.1.1 or 9.9.9.9.

As a temporary workaround, set DNSSEC=no in /etc/systemd/resolved.conf to disable validation. Fix the root cause, then re-enable it.

Step 8 — Check firewall rules

DNS uses UDP port 53 (standard queries) and TCP port 53 (large responses, zone transfers). If your firewall blocks these, DNS fails.

iptables:

sudo iptables -L -n | grep -E '53|dns'

nftables:

sudo nft list ruleset | grep -E '53|dns'

firewalld (RHEL/Fedora):

sudo firewall-cmd --list-all

Look for rules that DROP or REJECT outbound traffic on port 53. If you find them, allow DNS:

sudo iptables -A OUTPUT -p udp --dport 53 -j ACCEPT

sudo iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT

Cloud VMs: Also check your provider's security group or network firewall rules. AWS Security Groups, GCP Firewall Rules, and Azure NSGs can all block outbound DNS.

Test your DNS configuration

After resolving your DNS issue, verify your setup is secure and fast:

• DNS Privacy Check — Test for DNS leaks, DNSSEC validation, and encrypted transport.
• DNS Gaming Benchmark — Measure latency to 50+ public DNS servers.
• Browse all public DNS servers — Find the most reliable resolvers for your location.

Frequently asked questions

Should I edit /etc/resolv.conf directly?

Only on minimal systems that do not run systemd-resolved or NetworkManager. On most desktop and server distributions, resolv.conf is managed automatically and your edits will be overwritten. Use systemd-resolved or nmcli to set DNS permanently.

Why does resolv.conf show 127.0.0.53?

That is the systemd-resolved stub listener. It means your system routes DNS through systemd-resolved, which then forwards to the actual upstream DNS servers. This is normal. Run resolvectl status to see the real upstream servers.

How do I make DNS changes survive a reboot?

Use the configuration method that matches your init system: systemd-resolved (edit /etc/systemd/resolved.conf), NetworkManager (use nmcli), or if neither is present, edit /etc/resolv.conf and protect it with sudo chattr +i /etc/resolv.conf to prevent DHCP from overwriting it.

Can Docker or container networking break host DNS?

Yes. Docker creates its own bridge network and modifies iptables rules. If Docker is misconfigured, it can intercept DNS traffic meant for the host. Check docker0 interface rules with iptables -L DOCKER and verify that your host resolv.conf is not pointing to a Docker DNS proxy.