The essentials

Quick reference

One focused task per row. Jump to the related section for complete, working examples.

UseSyntaxExamples
Resolve through NSSgetent ahosts example.comView examples
Inspect hosts lookup ordergrep -E '^[[:space:]]*hosts:' /etc/nsswitch.confView examples
Identify resolv.conf ownerreadlink -f /etc/resolv.confView examples
Show resolver directivesgrep -E \ '^[[:space:]]*(nameserver|search|domain|options)[[:space:]]' \ /etc/resolv.confView examples
Query an A recorddig example.com A +noall +answerView examples
Query an AAAA recorddig example.com AAAA +noall +answerView examples
Query one DNS serverdig @192.0.2.53 example.com A +noall +answer +commentsView examples
Run a reverse lookupdig -x 192.0.2.25 +noall +answerView examples
Retry DNS over TCPdig +tcp @192.0.2.53 example.com AView examples
Trace delegationdig +trace www.example.comView examples
Show effective DNS policyresolvectl statusView examples
Query through systemd-resolvedresolvectl query example.comView examples
Inspect resolver statisticsresolvectl statisticsView examples
Bypass the local cacheresolvectl --cache=no query example.comView examples
Flush resolved cachessudo resolvectl flush-cachesView examples
Request DNSSEC recordsdig example.com A +dnssec +multiView examples
Show per-link domainsresolvectl domainView examples
Set transient split DNSsudo resolvectl domain tun0 '~corp.example'View examples
Set a per-link DNS serversudo resolvectl dns tun0 192.0.2.53View examples
Revert transient link DNSsudo resolvectl revert tun0View examples

Linux name resolution is a pipeline rather than one command. Applications commonly use the C library and Name Service Switch, which may consult files, systemd-resolved, DNS, or another source; dig queries DNS independently. Start with the same lookup path as the failing application, then inspect resolver policy and query a known server only when you need to isolate a layer. Commands that alter per-link DNS or flush caches need privilege and can interrupt production resolution, so capture the current state first.

Step by step

Detailed examples

01

Test the application's resolution path first

getent ahosts calls the NSS-backed address lookup path used by many dynamically linked applications. That path can honor /etc/hosts and modules such as myhostname, resolve, or dns in the order and with the actions configured on the hosts line in /etc/nsswitch.conf. A successful dig query alongside a failed getent query therefore points toward NSS, a local resolver service, search policy, or application-specific behavior rather than authoritative DNS. NSS details are libc- and distribution-dependent: musl, containers, statically linked binaries, browsers, and language runtimes may use a different path.

Compare the application path with its NSS policy
getent ahosts example.com
grep -E '^[[:space:]]*hosts:' /etc/nsswitch.conf
Output
93.184.216.34  STREAM example.com
93.184.216.34  DGRAM
93.184.216.34  RAW
hosts: files systemd dns
Back to quick reference ↑
02

Determine who manages resolver configuration

/etc/resolv.conf is an interface consumed by the libc stub resolver and DNS tools, but NetworkManager, systemd-resolved, resolvconf, a DHCP client, or an administrator may own its contents. Inspect the symlink target before editing it. On systemd-resolved hosts, 127.0.0.53 commonly identifies the local stub, while a generated file under /run may expose upstream servers. Search suffixes can expand single-label names and ndots can change query order, latency, and information exposure. Direct edits to a generated file are usually overwritten; persistent configuration belongs in the active network manager.

Inspect ownership and resolver inputs
readlink -f /etc/resolv.conf
grep -E '^[[:space:]]*(nameserver|search|domain|options)[[:space:]]' /etc/resolv.conf
Output
/run/systemd/resolve/stub-resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search corp.example
Back to quick reference ↑
03

Ask focused DNS record questions with dig

dig talks DNS and does not reproduce the full NSS application path. Specify the record type and use documentation addresses for examples. An @server argument isolates one server, but that server name is resolved before the query if it is not already an IP address. Compare response status, flags, authority, and the responding SERVER line rather than relying only on +short output. NXDOMAIN means the queried name does not exist, while NOERROR with an empty answer can mean the name exists but lacks that record type. Reverse DNS is a PTR query and does not establish forward ownership or trust.

Compare address records and one server
dig example.com A +noall +answer
dig example.com AAAA +noall +answer
dig @192.0.2.53 example.com A +noall +answer +comments
dig -x 192.0.2.25 +noall +answer
Output
example.com.  300  IN  A     93.184.216.34
example.com.  300  IN  AAAA  2001:db8::34
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24001
example.com.  300  IN  A     93.184.216.34
25.2.0.192.in-addr.arpa.  300  IN  PTR  host.example.
Back to quick reference ↑
04

Separate delegation problems from transport failures

A normal recursive query hides the delegation walk. dig +trace starts at a root server and follows referrals, making it useful for parent-zone NS and glue mistakes, but it sends queries to multiple Internet authorities and can fail on networks that block direct DNS. DNS ordinarily starts over UDP and retries over TCP when a response is truncated; testing +tcp can reveal firewalls that permit UDP 53 but block TCP 53. Both commands generate network traffic and should be approved before use on restricted production networks.

Test delegation and TCP independently
dig +trace www.example.com
dig +tcp @192.0.2.53 example.com A
Output
.                 518400  IN  NS  a.root-servers.net.
com.              172800  IN  NS  a.gtld-servers.net.
example.com.       86400   IN  NS  ns1.example.net.
;; SERVER: 192.0.2.53#53(192.0.2.53) (TCP)
Back to quick reference ↑
05

Inspect systemd-resolved's effective decision

When systemd-resolved is active, resolvectl status shows global and per-link settings that a stub resolv.conf cannot express. resolvectl query reports the selected interface, protocol, and whether the answer was authenticated. Authenticated can also describe trusted local data such as /etc/hosts, so interpret it with the reported source. resolvectl commands and fields are versioned systemd features and may be absent on older releases or systems using another resolver. A container may also see a different resolver service and namespace than its host.

Inspect policy and one resolved lookup
resolvectl status
resolvectl query example.com
Output
Global
       Protocols: -LLMNR -mDNS +DNSOverTLS DNSSEC=yes/supported
Link 3 (tun0)
    DNS Servers: 192.0.2.53
     DNS Domain: ~corp.example
example.com: 93.184.216.34 -- link: eth0
-- Information acquired via protocol DNS in 24.8ms.
-- Data is authenticated: yes
Back to quick reference ↑
06

Treat caching and DNSSEC as separate diagnostic dimensions

TTL-valid cache entries are expected and can make repeated tests differ from upstream state. Prefer a one-query cache bypass when supported; flushing the whole cache requires privilege, affects every local client, and temporarily increases upstream traffic. dig +dnssec requests DNSSEC records by setting the DO bit, but the presence of RRSIG data or an AD flag received from a recursive resolver is not the same as independently validating the chain. With systemd-resolved, use query authentication state and statistics together with configured DNSSEC mode. Private split-horizon zones may need correct signing or a narrowly scoped negative trust anchor; weakening validation globally hides genuine failures.

Observe, bypass, then flush only if justified
resolvectl statistics
resolvectl --cache=no query example.com
dig example.com A +dnssec +multi
sudo resolvectl flush-caches
Output
Transactions
  Current Transactions: 0
Cache
  Current Cache Size: 42
DNSSEC Verdicts
  Secure: 318
example.com: 93.184.216.34 -- link: eth0
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2
Back to quick reference ↑
07

Route private suffixes without hijacking all DNS

systemd-resolved route-only domains begin with a tilde. Assigning ~corp.example and the corporate DNS server to a VPN link sends matching names there without appending the suffix to single-label queries. The special ~. domain makes a link preferred for all otherwise unmatched DNS traffic and should be used deliberately. resolvectl dns and domain changes are transient, privileged, and can immediately break resolution if the interface or server is wrong. Record resolvectl status before changing anything, keep an existing privileged session available, and use revert to remove all transient resolver properties for that link. For persistence, configure NetworkManager, systemd-networkd, or the actual link manager instead.

Apply and remove a narrowly scoped transient route
resolvectl domain
sudo resolvectl dns tun0 192.0.2.53
sudo resolvectl domain tun0 '~corp.example'
resolvectl query host.corp.example
sudo resolvectl revert tun0
Output
Global:
Link 3 (tun0): ~corp.example
host.corp.example: 192.0.2.80 -- link: tun0
-- Information acquired via protocol DNS in 18.1ms.
Back to quick reference ↑

Sources and further reading

References

Authoritative documentation used to verify and expand this cheat sheet.

  1. systemd projectresolvectl — Resolver Inspection and Configurationfreedesktop.org
  2. systemd projectresolved.conf — Network Name Resolution Configurationfreedesktop.org
  3. Internet Systems Consortiumdig — DNS Lookup Utilitybind9.readthedocs.io
  4. Linux man-pages projectresolv.conf(5) — Resolver Configuration Fileman7.org
  5. Linux man-pages projectnsswitch.conf(5) — Name Service Switch Configurationman7.org
  6. Linux man-pages projectgetent(1) — Query Name Service Switch Databasesman7.org

Help us improve

Found a typo or missing example?

Tell us what would make this cheat sheet clearer, more complete, or more useful.

Share feedback