How to check DNS resolution in Linux

DNS failures on Linux often surface as package manager timeouts, API connection errors, or monitoring alerts even when the network interface and route are working. Checking resolution through the system resolver first shows what ordinary applications are likely to see before DNS server changes or cache resets are attempted.

The getent command follows the Name Service Switch order, so it is the best first check for application-facing hostname lookup. A resolver file may point directly at a nameserver or at a local stub managed by systemd-resolved, which keeps the real upstream server list behind resolvectl status.

Direct dig queries answer a different question because they ask a selected DNS server for a selected record type. Comparing getent with dig separates local NSS behavior, search-domain handling, and resolver-manager stubs from the upstream DNS answer, while an .invalid lookup distinguishes a real NXDOMAIN reply from a transport timeout.

Steps to check Linux DNS resolution with getent and dig:

Resolve a fully qualified hostname through the system resolver path.
```
$ getent ahostsv4 one.one.one.one
1.1.1.1         STREAM one.one.one.one
1.1.1.1         DGRAM
1.1.1.1         RAW
1.0.0.1         STREAM
1.0.0.1         DGRAM
1.0.0.1         RAW
```
getent ahostsv4 uses glibc NSS resolution and prints IPv4 socket entries. Use getent ahosts instead when IPv6 answers are part of the problem.
Check the host lookup order used by glibc.
```
$ grep -E '^hosts:' /etc/nsswitch.conf
hosts:          files dns
```
Entries such as files, dns, resolve, myhostname, or mdns4_minimal change which source is consulted and in what order. If neither dns nor resolve appears, ordinary glibc host lookups may skip unicast DNS.
Inspect the resolver file used by the system resolver.
```
$ cat /etc/resolv.conf
nameserver 1.1.1.1
options edns0 trust-ad
search example.net
```
The nameserver line is the DNS server path visible to glibc. A local stub such as 127.0.0.53 usually means systemd-resolved is forwarding queries to upstream servers that are not listed directly in this file.

Show the active upstream servers on hosts managed by systemd-resolved.

$ 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: 1.1.1.1
       DNS Servers: 1.1.1.1 1.0.0.1
        DNS Domain: example.net

If resolvectl is unavailable or reports that systemd-resolved is not running, continue with the /etc/resolv.conf nameserver or the resolver manager used by that distribution.

Query the hostname directly against the active DNS server.
```
$ dig @1.1.1.1 one.one.one.one A +noall +answer
one.one.one.one.        80899   IN      A       1.1.1.1
one.one.one.one.        80899   IN      A       1.0.0.1
```
When dig returns the expected answer but getent does not, look at /etc/nsswitch.conf, search-domain expansion, local resolver services, and cached host entries before changing public DNS records.
Query a reserved-invalid name to confirm that the DNS server can return a negative answer.
```
$ dig @1.1.1.1 no-such-name.invalid A +noall +comments +answer
;; Got answer:
;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NXDOMAIN, id: 50552
;; 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 means the DNS server answered the query, while a timeout or no servers could be reached points to transport, firewall, or resolver reachability.