Why is DNS resolution not working on Linux?

What this covers

DNS failures on Linux are misleading: the same "could not resolve host" message appears whether the link is down, the resolver is unreachable, or a stale cache entry is being served. This guide walks through the same order an administrator would use — verify the link, inspect the live resolver, query it directly, then flush the cache or change servers, and finally confirm names resolve again. Every step is read-only or reversible.

Symptom

Confirm the interface actually has an IP address

Name resolution failures are often misdiagnosed connectivity failures. Start by listing every interface in a compact table and check that your active interface is UP and carries a real IPv4 address. If it only shows a 169.254.x.x link-local address, or no address at all, DHCP never completed and the problem is the link, not DNS — fix that first. A valid address (plus a default route) means you can safely move on to looking at the resolver.

$ ip -br a

Check which DNS servers systemd-resolved is really using

On systemd-based distributions the resolver you think you configured is not always the one being applied per interface. Query systemd-resolved for its live status and read the DNS Servers line for your active connection. If the list is empty, contains only a stale address, or points at a router that is no longer reachable, you have found the cause. This also tells you whether the system is using a local stub (127.0.0.53) in front of the real servers.

$ resolvectl status | grep -A2 'DNS Servers'

Query the resolver directly to isolate where it breaks

Do a direct A-record query for a domain you know exists and read the response carefully. A quick answer means the resolver and upstream path work, so the fault is local — a stale cache or a single misbehaving application. A timeout or a SERVFAIL means the configured server is unreachable or refusing queries; comparing against a public resolver such as 1.1.1.1 tells you whether the problem is upstream or inside your machine. Also note the difference between NXDOMAIN (name genuinely does not exist) and no answer at all.

$ dig example.com A +short

Clear the local DNS cache

If queries reach the network fine but you keep getting an old or wrong answer, the stub cache held by systemd-resolved is the usual suspect — entries survive long after the record changed upstream. Flushing it is non-destructive, needs no service restart, and takes effect immediately. This is the cheapest first fix, so try it before touching any configuration; if names start resolving right after, you are done.

$ resolvectl flush-caches

Point the connection at resolvers you trust

When the server handed out by DHCP or your router is down or filtering queries, the fix is to set explicit resolvers on the network profile and re-activate it. Use the exact profile name shown by your NetworkManager connection list — editing the wrong profile silently does nothing. Afterwards, re-check the live resolver status to confirm the new addresses are the ones being applied, rather than the ones from DHCP.

$ nmcli con mod 'MyWiFi' ipv4.dns '1.1.1.1 8.8.8.8' && nmcli con mod 'MyWiFi' ipv4.ignore-auto-dns yes && nmcli con up 'MyWiFi'

$ nmcli con mod 'MyWiFi' ipv4.ignore-auto-dns no && nmcli con mod 'MyWiFi' ipv4.dns '' && nmcli con up 'MyWiFi'

Confirm names resolve again

Re-run a lookup for the domain that failed before and check that the answer section contains an address. Test more than one name, and include a domain you have not queried recently so you are exercising a fresh lookup rather than a warm cache. When those lookups return promptly and consistently, DNS resolution is working and you can close the case.

$ host -t A example.com

How to confirm it worked

Run a lookup for a domain that previously failed and for a domain you have not queried recently; both should return an address promptly. Repeat once more after a few minutes to make sure the result is stable rather than a one-off.

Undo everything

Every command above can be reverted. Run these in order to undo all of it.

$ nmcli con mod 'MyWiFi' ipv4.ignore-auto-dns no && nmcli con mod 'MyWiFi' ipv4.dns '' && nmcli con up 'MyWiFi'

Review before running — some steps may not be independent.

Sources

• ip(8) — Linux manual page
  man7.org · technical · 2026-09-17
  Evidence: Documents `ip -br addr` as the brief, one-line-per-interface output format of the ip command
• resolvectl(1) — manual page
  Arch Linux · community · 2026-09-17
  Evidence: resolvectl status shows the DNS servers and domains configured per link by systemd-resolved.
• systemd-resolved — Arch Wiki
  Arch Linux · community · 2026-09-17
  Evidence: resolvectl status is the way to inspect which DNS servers systemd-resolved is using per interface.
• dig(1) — DNS lookup utility
  Ubuntu manpages · vendor-doc · 2026-09-17
  Evidence: The dig manual documents querying a name for a given type (A, MX, etc.) and the +short option to print a terse answer.
• resolvectl(1) — Linux manual page
  man7.org · technical · 2026-09-17
  Evidence: Documents `resolvectl flush-caches` which flushes all DNS caches of systemd-resolved, and `resolvectl statistics` to view cache size
• NetworkManager — Arch Wiki
  Arch Linux · community · 2026-09-17
  Evidence: Custom DNS servers are set per connection with nmcli con mod <name> ipv4.dns, and ignore-auto-dns stops DHCP-provided DNS overriding them.
• nmcli(1) — Ubuntu manual page
  Ubuntu · community · 2026-09-17
  Evidence: nmcli con mod modifies connection properties such as ipv4.dns and ipv4.ignore-auto-dns; nmcli con up reactivates the profile to apply them.
• host(1) — DNS lookup utility
  Ubuntu manpages · technical · 2026-09-17
  Evidence: Documents host as a simple DNS lookup utility and the -t option for selecting the query type (A, MX, TXT, CNAME).

Last verified: 2026-09-22

Related guides