Linux DNS Troubleshooting Made Easy

Linux DNS troubleshooting usually starts the same way: "the site is down," and nobody wants to touch it. Nothing kills a Monday morning faster than realizing the outage is a DNS problem hiding in plain sight. Half the team assumes it's the app, the other half blames the network, and DNS quietly sits in the middle being the actual cause the whole time.

This guide is for anyone running Ubuntu, Rocky Linux, or RHEL who needs a clear way to isolate a DNS failure instead of guessing. By the end you will have a working method to confirm whether it's your resolver, your config file, your firewall, a container, a VPN, or the upstream DNS server, and you will know exactly which command to run at each stage.

You will lean on a handful of tools throughout this guide. dig is the main one, it queries DNS servers directly and gives detailed output. host does the same job with a shorter, easier to script output. nslookup is older but still around, mostly useful if you already know it from Windows. resolvectl is specific to systemd-resolved and shows you which server actually answered a query, which plain dig cannot tell you. You do not need to memorize all four, just know they exist and which one fits which question.

Prerequisites :

Operating System        :   Ubuntu 22.04/24.04, Rocky Linux 8/9, RHEL 8/9
Packages and Dependencies:  bind-utils (dig, host) on RHEL/Rocky, bind9-dnsutils on Ubuntu (the older dnsutils name still works as a transitional alias, but it just pulls in bind9-dnsutils), iputils-ping
User Account            :   root user or a user account with sudo privileges
Recommended to run all administrative commands with sudo instead of logging in as root directly.

If you are not comfortable switching between root and a sudo user yet, walk through how to configure sudo in Linux first, it will save you from a few permission errors below.

If any of this DNS trouble started right after you spun up a fresh VPS, it is worth knowing that resolver defaults vary quite a bit between providers, something we cover briefly when comparing DigitalOcean and Vultr hosting setups.

My Lab Setup :

DNS Test Server:

Operating System    :   Rocky Linux release 9.4
Hostname            :   dns-test01.local
IP Address          :   192.168.1.50

Linux DNS Troubleshooting: Diagnostic Steps

Step 1: Confirm It Is Actually a DNS Problem

Start with a hostname you know should resolve, then fall back to its IP if that fails.

If that fails, try the same test against a raw IP address to confirm the network layer itself is fine.

Do not stop at IPv4 if your network is dual stack. A record can resolve fine while the AAAA record is missing or broken, and some applications will try IPv6 first and time out before ever falling back.

Step 2: Check What Is Actually Managing Your Resolver

Worth knowing up front: on Rocky Linux and RHEL 8/9, NetworkManager manages /etc/resolv.conf by default rather than systemd-resolved. Ubuntu, on the other hand, ships systemd-resolved as the default resolver manager. Same troubleshooting logic applies either way, but the file you actually need to edit differs.

Check the file first, then confirm whether systemd-resolved is the one steering it.

Step 3: Query DNS Directly and Skip the Local Resolver

Point dig straight at a known-good server and bypass whatever your system is configured to use.

That kind of split output is a very clear signal. The domain resolves fine against Google's resolver, your own resolver never answers. Now check the port itself before assuming it's a config typo.

Look at the services line specifically. If dns is not listed there and port 53 is not open under ports either, outbound DNS queries can get silently dropped, and the nc test above confirms whether that is actually happening. Firewall rules block a surprising number of "random" DNS outages. If you have not gone through this before, the firewall-cmd command basics guide covers the commands you will need for that check in more detail.

Other DNS Tools Worth Knowing

dig is not the only option, and sometimes it is not even the fastest one for the question you are actually asking.

host gives you a one-line answer that is easy to script against. resolvectl query is the only one of the four that tells you which specific server actually answered, useful when you have several DNS servers configured and need to know which one is misbehaving. dig +trace walks the whole path from the root servers down, which is the move when a public resolver answers fine but you still suspect something is wrong further up the chain.

Step 4: Check the NSS Order in nsswitch.conf

Do not blindly overwrite that line. Open the file and check it by hand, since a working line usually has other modules on it too, like myhostname or mdns4_minimal, and stomping over them with a rewrite can break local hostname lookups and mDNS. Just confirm that resolve (on systemd-resolved systems) or dns (on plain glibc nss-dns setups) is present alongside files, and add whichever one is genuinely missing without removing anything else.

Step 5: Rule Out DNSSEC and Cache Corruption

Ubuntu's systemd-resolved does not validate DNSSEC locally by default, that is the DNSSEC=no/unsupported line you saw back in Step 2, so this step matters far less on a stock Ubuntu box. It matters a lot more on Rocky Linux and RHEL setups pointed at a validating upstream resolver, or any environment running BIND, which does validate by default.

If +cd resolves the query but a normal dig does not, DNSSEC validation is rejecting a signature it should not be. That is a narrow enough problem that you can now stop guessing and go straight to the resolver's DNSSEC setting.

Step 6: Check DNS Inside Docker Containers

Start by checking whether the container can resolve anything at all, then look at what resolv.conf actually looks like from inside it.

A nameserver of 127.0.0.11 means the container is talking to Docker's embedded DNS, and that in turn forwards to whatever resolver the host itself uses, so if the host's own DNS is broken this will fail too. If you need to hand a container a specific working resolver instead of relying on the default, set it explicitly.

To make that permanent for every container instead of passing flags each time, set it in the daemon config. A quick Docker management command cheat sheet is handy to keep nearby once you start digging into daemon-level settings like this.

Step 7: Fix DNS Behind a VPN Split Tunnel

Check which resolver is actually being used once the VPN is up, per interface.

The tilde in front of a domain marks it as a routing domain, meaning that resolver is only used for names matching that suffix, everything else still goes over the regular interface. If corp.internal names are failing, confirm tun0 actually shows that domain, and if external sites are slow or failing over VPN, confirm eth0 still has the wildcard ~. domain so general lookups are not being forced through the tunnel resolver unnecessarily.

Make Linux DNS Troubleshooting a Non-Event Next Time

Once things are working, a small health check script beats waiting for someone to report the site is down. Drop this in cron to catch a DNS failure before it becomes an incident.

Wire that into cron every five minutes and pipe the log into whatever alerting you already have, and you find out about a DNS outage the same way you find out about any other monitored failure, not from a support ticket.

Conclusion

Working through these layers in order, host and network, resolver ownership, direct queries, NSS order, DNSSEC, containers, and VPN routing, takes the guesswork out of a DNS outage. Once your resolver is stable, review your broader server hardening checklist and keep an eye on service failures with a systemd troubleshooting guide so DNS issues do not blindside you again. For the full command reference, the official dig man page is worth bookmarking. Drop me your feedback/comments. Feel free to share this article with others if you like it.