How to check DNS resolution in Linux

DNS resolution turns hostnames into IP addresses, keeping package downloads, API calls, and outbound connections working normally on Linux. When name lookups fail, many tools report network-style errors even though routing and connectivity are otherwise healthy.

Most applications rely on the glibc resolver through the Name Service Switch (NSS). The hosts database order in /etc/nsswitch.conf decides whether lookups consult /etc/hosts, DNS, mDNS, or other sources, while /etc/resolv.conf supplies DNS servers and search domains (directly or via a local stub such as systemd-resolved).

Search domains can make a short name resolve differently than a fully qualified name, and split-DNS setups (VPN, corporate networks) can return different answers per interface. Comparing a system lookup with a direct query to a known DNS server separates local resolver configuration issues from upstream DNS problems, and timeouts indicate a different failure mode than NXDOMAIN responses.

1. Resolve a hostname through the system resolver.

   $ getent hosts api.example.net
   2001:db8:203:113::50 api.example.net
   2001:db8:203:113::51 api.example.net

   getent hosts follows NSS and matches the lookup path used by most applications.

2. Confirm dns is included in the hosts lookup order.

   $ grep -E '^hosts:' /etc/nsswitch.conf
   hosts:          files dns

   If dns is missing, hostname lookups may only work from /etc/hosts.

3. Review the configured DNS servers and search domains.

   $ cat /etc/resolv.conf
   # This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
   # Do not edit.
   #
   # This file might be symlinked as /etc/resolv.conf. If you're looking at
   # /etc/resolv.conf and seeing this text, you have followed the symlink.
   #
   # This is a dynamic resolv.conf file for connecting local clients to the
   # internal DNS stub resolver of systemd-resolved. This file lists all
   # configured search domains.
   #
   # Run "resolvectl status" to see details about the uplink DNS servers
   # currently in use.
   #
   # Third party programs should typically not access this file directly, but only
   # through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
   # different way, replace this symlink by a static file or a different symlink.
   #
   # See man:systemd-resolved.service(8) for details about the supported modes of
   # operation for /etc/resolv.conf.
   
   nameserver 127.0.0.53
   options edns0 trust-ad
   search example.net

   On many systems, /etc/resolv.conf is generated by a network/resolver service and manual edits may be overwritten.

4. Show the active DNS configuration per interface when resolvectl is available.

   $ 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
   ##### snipped #####

   If resolvectl is not found, the system may not be using systemd-resolved.

5. Query a specific DNS server to compare results.

   $ nslookup api.example.net 192.0.2.53
   Server:		192.0.2.53
   Address:	192.0.2.53#53
   
   Non-authoritative answer:
   Name:	api.example.net
   Address: 203.0.113.50
   Name:	api.example.net
   Address: 203.0.113.51
   Name:	api.example.net
   Address: 2001:db8:203:113::50
   Name:	api.example.net
   Address: 2001:db8:203:113::51

   Some networks block outbound DNS to public resolvers, so timeouts here can be policy-related rather than a local resolver failure.

6. Query a deliberately nonexistent name to distinguish NXDOMAIN from resolver timeouts.

   $ nslookup does-not-exist.api.example.net 192.0.2.53
   Server:		192.0.2.53
   Address:	192.0.2.53#53
   
   Non-authoritative answer:
   *** Can't find does-not-exist.api.example.net: No answer

   NXDOMAIN confirms the DNS server is reachable and responding; timeouts typically indicate a connectivity or firewall issue to the DNS server.