DNS Not Working on Linux? Check the Resolver Before Changing Settings

A browser says it cannot find a server. A package update fails with a name-resolution error. Changing DNS servers is tempting, but those symptoms do not yet tell you which part of the lookup failed. A few read-only checks can narrow it down before you change a working network configuration.

This Linux DNS troubleshooting walkthrough covers machines that use systemd-resolved. If resolvectl is missing or the service is inactive, use your distribution’s network documentation instead of installing or enabling another resolver just to follow these steps.

Start with the resolver the machine is using

resolvectl status

The resolvectl manual documents this view of global and per-interface DNS settings. Look at the active connection’s servers and domains, particularly if a VPN is connected. A laptop can have different DNS settings on its wireless and VPN interfaces; one server address does not describe the whole setup.

Keep that output available, then try a public hostname and the name that actually fails:

resolvectl query example.com
resolvectl query affected-host.example

Replace affected-host.example with the real hostname, without https:// or a path. If the public lookup succeeds but the affected name fails, investigate that name or its network context first. A company-only hostname, for example, may depend on the company VPN. Record the error rather than treating every failed lookup as the same problem.

Compare it with the system’s hostname lookup

getent ahosts example.com

Run the same command with your affected hostname, too. According to the getent documentation, ahosts uses the system’s getaddrinfo lookup through the Name Service Switch configuration. That gives you a useful comparison with resolvectl, which talks to systemd-resolved.

If these checks disagree, investigate the system lookup configuration before blaming the upstream DNS server. If both return addresses but a browser still fails, the remaining problem could be elsewhere: the browser’s own DNS settings, a proxy, or the destination service. Resolving a name successfully does not prove that a website is reachable.

Do not mistake the local stub for a broken DNS server

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

Seeing nameserver 127.0.0.53 can be completely normal. The systemd-resolved documentation identifies it as the local DNS stub, which accepts requests on your machine and handles resolution. It is not supposed to be the address of your router or a public DNS provider.

The same documentation describes several supported ways to manage /etc/resolv.conf, including a symbolic link to a generated stub configuration. Check the link destination before editing anything. Overwriting a managed file can hide the real issue and leave settings that your network tools replace later.

Make the next change match the evidence

At this point you should have three useful facts: which interface and DNS configuration are involved, whether systemd-resolved can answer the lookup, and whether the system lookup agrees. Save the relevant error alongside those details.

Then make one targeted change through the tool that manages the connection, and repeat the same lookup. Switching servers, removing VPN settings and rewriting resolv.conf all at once makes it much harder to learn which change helped—or to restore the original setup if nothing improves.