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.

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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:
   ;; ->>HEADER<<- 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.