How to check DNS resolution in Linux

DNS resolution keeps package downloads, API calls, monitoring checks, and outbound service connections working by translating hostnames into reachable IP addresses on Linux. When lookups fail, the visible symptom is often a generic timeout or connection error even though interface state, routing, and remote reachability are otherwise intact.

Most applications use the glibc resolver, which follows the Name Service Switch order in /etc/nsswitch.conf before consulting the resolver settings exposed through /etc/resolv.conf. On many current distributions, systemd-resolved sits behind that file as a local stub on 127.0.0.53, while direct tools such as dig can query a chosen DNS server without going through the full NSS path.

Short names depend on search domains, split-DNS can return different answers per interface, and generated resolver files are often replaced by systemd-resolved, NetworkManager, or DHCP clients. Starting with a fully qualified hostname, checking the active DNS servers, and then querying one of those servers directly separates local resolver behavior from upstream DNS results before any configuration is changed.

Steps to check Linux DNS resolution with getent, resolvectl, and dig:

Resolve the fully qualified hostname through the system resolver path.

$ getent ahosts api.example.net | head -n 6
203.0.113.50    STREAM api.example.net
203.0.113.50    DGRAM  
203.0.113.50    RAW    
203.0.113.51    STREAM 
203.0.113.51    DGRAM  
203.0.113.51    RAW

getent ahosts uses the glibc resolver and follows the same NSS order that many applications use for hostname lookups.

Check how the hosts database is ordered in /etc/nsswitch.conf.
```
$ grep -E '^hosts:' /etc/nsswitch.conf
hosts:          files dns
```
Some distributions include entries such as resolve, myhostname, or mdns4_minimal here. If neither dns nor resolve is present, unicast DNS may never be consulted for glibc host lookups.

Inspect the current resolver file and any configured search domain.

$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Apr 23  2024 /etc/resolv.conf -&gt; ../run/systemd/resolve/stub-resolv.conf
$ cat /etc/resolv.conf
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
##### snipped #####
nameserver 127.0.0.53
options edns0 trust-ad
search example.net

A stub listener such as 127.0.0.53 means a local resolver service is forwarding queries upstream. Editing a generated /etc/resolv.conf file directly is usually temporary and may be overwritten by the next network change.

Show the active DNS servers and search domains when systemd-resolved is managing DNS.

$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.0.2.53
       DNS Servers: 192.0.2.53 192.0.2.54
        DNS Domain: example.net

If resolvectl is unavailable or the command reports that systemd-resolved is not running, the system is likely using a static /etc/resolv.conf file or another resolver manager.

Query the hostname directly against the active DNS server to bypass the local NSS path.
```
$ dig @192.0.2.53 api.example.net A +noall +answer
api.example.net.        300     IN      A       203.0.113.50
api.example.net.        300     IN      A       203.0.113.51
```
Matching answers here but failed getent results point to the local resolver stack, search domains, or NSS behavior rather than missing records on the DNS server. Replace A with AAAA when the problem is specific to IPv6 answers.
Query a reserved-invalid hostname to distinguish NXDOMAIN replies from timeouts.
```
$ dig @192.0.2.53 no-such-name.invalid A +noall +comments +answer
;; Got answer:
;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NXDOMAIN, id: 28829
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
```
The .invalid top-level domain is reserved and should not resolve. NXDOMAIN proves the DNS server answered, while a timeout or no servers could be reached error points to a transport, firewall, or server-reachability problem.