Troubleshoot Linux DNS Resolution

When a Linux service cannot resolve a hostname, first determine which resolver configuration the host actually uses. Then query that resolver directly and compare the answer with the system’s normal name-service path.

Use an approved internal name and resolver for private zones. Avoid replacing /etc/resolv.conf by hand on a managed host; NetworkManager, DHCP, or systemd-resolved may own that file.

---

01

Check the Resolver, Link, and Search Domains

Configuration

Check the name-service switch order, resolver file target, global DNS entries, and active resolver service. The commands branch when systemd-resolved is not active and show NetworkManager-provided DNS when nmcli is available. Replace ens160 with the interface name from ip -brief link; do not assume a particular resolver implementation.

grep '^hosts:' /etc/nsswitch.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf
if systemctl is-active --quiet systemd-resolved; then
  resolvectl status
elif command -v nmcli >/dev/null 2>&1; then
  nmcli device show ens160 | grep -E 'GENERAL.STATE|IP[46].DNS|IP[46].DOMAIN'
else
  echo 'Use the network manager that owns this host to identify the configured DNS servers.'
fi

❯ View Expected Console Output

Link 2 (ens160)
    Current Scopes: DNS
    DNS Servers: 10.20.30.10 10.20.30.11
    DNS Domain: corp.example

Figure 1: Compare the active link resolver with a direct DNS query.

---

02

Test the Name Through Both Lookup Paths

Name Resolution

getent follows the configured name-service path. For direct DNS queries, install dig if it is missing, then replace the example resolver address with one shown by Step 1. Test the fully qualified name before relying on search suffix behavior.

Debian / Ubuntu

sudo apt install dnsutils

Fedora / RHEL

sudo dnf install bind-utils

DNS_SERVER=10.20.30.10  # replace with the resolver for this network
getent ahosts app01.corp.example
dig @"$DNS_SERVER" app01.corp.example A
dig @"$DNS_SERVER" app01.corp.example A +tcp

❯ View Expected Console Output

status: NOERROR
app01.corp.example. 300 IN A 10.20.40.15

---

03

Distinguish a DNS Answer from a Network Failure

Transport Check

A timeout may point to routing, firewall, or resolver availability trouble; NXDOMAIN means a DNS server answered that the name does not exist in its view. ip route get reports the selected route but does not test reachability. Compare a direct query to the normal system lookup and inspect resolver logs only when systemd-resolved is active.

DNS_SERVER=10.20.30.10  # replace with the resolver for this network
ip route get "$DNS_SERVER"
dig @"$DNS_SERVER" app01.corp.example A +time=2 +tries=1
getent ahosts app01.corp.example
if systemctl is-active --quiet systemd-resolved; then
  resolvectl query app01.corp.example
  journalctl -u systemd-resolved --since '30 minutes ago' --no-pager
fi

❯ View Expected Console Output

app01.corp.example: 10.20.40.15
Information acquired via protocol DNS in 18.4ms.

---

04

Apply a Targeted Resolver Fix

Controlled Change

Correct the authoritative record, DHCP-provided resolver, NetworkManager profile, or resolved link configuration that caused the mismatch. Make persistent changes through the component that owns the connection. Flush a cache only when you have confirmed which local resolver is caching the answer; clearing the systemd-resolved cache does not clear a different DNS cache.

DNS_SERVER=10.20.30.10  # replace with the resolver for this network
if systemctl is-active --quiet systemd-resolved; then
  sudo resolvectl flush-caches
  resolvectl query app01.corp.example
fi
getent ahosts app01.corp.example
dig @"$DNS_SERVER" app01.corp.example A

❯ View Expected Console Output

app01.corp.example: 10.20.40.15

Keep resolver ownership intact

Use the network manager that owns the interface to make persistent changes. Direct edits to a generated resolver file can disappear at DHCP renewal or network restart.