dig

The DNS records module already used dig throughout, showing its answer section for A, AAAA, MX, and the rest. What none of those articles stopped to explain is everything else dig's output actually contains, or the handful of flags that turn it from "one query, one answer" into a genuine diagnostic tool — the reason ISC's own documentation recommends it over nslookup in the first place.

The full output, section by section

dig example.com MX

; <<>> DiG 9.18.24-1ubuntu1 <<>> example.com MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47213
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;example.com.                  IN      MX

;; ANSWER SECTION:
example.com.            300     IN      MX      10 mail.example.com.

;; Query time: 22 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Jul 27 09:41:02 UTC 2026
;; MSG SIZE  rcvd: 67

Reading it from the top down:

HEADER — opcode: QUERY is the kind of DNS message this is (almost always QUERY for a lookup); status: NOERROR is the actual result code, and this is the field to check first when a lookup seems to fail. NXDOMAIN means the name doesn't exist at all; SERVFAIL means the server hit an internal problem answering; REFUSED means the server declined to answer this particular query. Each demands a different next step, and none of them look like a normal successful answer, so the difference matters immediately.
flags — qr marks this as a response (query/response bit set); rd means recursion was requested; ra means the server receiving the query is willing to do recursion on the client's behalf. A response missing ra from a server you expected to recurse for you is itself a clue — that server may only be authoritative for its own zone and not built to chase referrals for a client.
QUESTION SECTION — the query as sent, echoed back exactly.
ANSWER SECTION — the actual record, in the same NAME/TTL/CLASS/TYPE/RDATA shape the DNS records module already covered.
Query time — how long this specific query took, useful for spotting a slow or overloaded resolver.
SERVER — which resolver actually answered, same idea as nslookup's Server: line.

+short, for scripting

dig example.com MX +short

10 mail.example.com.

+short strips everything down to just the answer data — the form to reach for the moment a lookup's result needs to feed into a script rather than a human eyeball, since parsing the full header-and-sections output for one value is unnecessary work either way.

+trace: watching the actual referral chain

Every dig query so far went straight to a resolver and took whatever cached or recursively-fetched answer it returned. +trace does something different: it starts at the root servers and follows the referral chain itself, one delegation at a time, showing exactly which servers were asked along the way:

dig example.com A +trace

;; global options: +cmd
.                       518400  IN      NS      a.root-servers.net.
;; Received 239 bytes from 192.168.1.1#53(192.168.1.1) in 12 ms

com.                    172800  IN      NS      a.gtld-servers.net.
;; Received 833 bytes from 198.41.0.4#53(a.root-servers.net) in 34 ms

example.com.            172800  IN      NS      a.iana-servers.net.
;; Received 168 bytes from 192.5.6.30#53(a.gtld-servers.net) in 28 ms

example.com.            86400   IN      A       93.184.216.34
;; Received 56 bytes from 199.43.135.53#53(a.iana-servers.net) in 45 ms

This is the same root-to-authoritative delegation walk a full resolution process performs — the root servers refer to the .com servers, which refer to example.com's own authoritative servers, which finally answer with the actual record. +trace is worth reaching for specifically when a name resolves to the wrong thing and the question is where in that chain the wrong answer is coming from — a stale or misconfigured delegation at any one of those steps, rather than at the authoritative zone itself.

Querying a specific server, and reverse lookups

dig @1.1.1.1 example.com A

Prefixing a server with @ sends the query directly there instead of through the system's configured resolver — the same move nslookup's trailing server argument makes, just with different syntax. And dig handles the reverse direction too — given an address, which name is registered for it:

dig -x 93.184.216.34 +short

example.com.

-x builds the special reverse-lookup query automatically — you supply the address, and dig constructs the in-addr.arpa query internally. What that namespace is and why the octets end up reversed is the subject of the PTR record article.

NXDOMAIN and SERVFAIL are not the same failure

A newly registered domain returns nothing useful, and the difference between two specific status codes tells two very different stories:

dig newsite.example NS

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8842
;; QUESTION SECTION:
;newsite.example.              IN      NS

;; AUTHORITY SECTION:
example.               10800   IN      SOA     ns1.example. hostmaster.example. 2026072601 3600 900 604800 3600

NXDOMAIN here means exactly what it says — the domain simply doesn't exist yet from this resolver's point of view, most likely because registration hasn't propagated or the delegating NS records at the registrar haven't been set. Compare that against a domain that does exist but whose own authoritative servers are failing:

dig brokenzone.example NS

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9013

SERVFAIL with no answer section at all points somewhere completely different — the domain's delegation exists, but the authoritative name servers themselves are failing to answer, misconfigured, or unreachable. Mistaking one status for the other sends you down the wrong troubleshooting path entirely: NXDOMAIN means check the registration and delegation; SERVFAIL means check the authoritative servers' own health.

Practice exercises

Run dig <any-domain> +trace and identify each server in the referral chain — root, TLD, and authoritative — and how long each hop took.
Compare dig example.com A against dig @8.8.8.8 example.com A and note whether Query time or the returned TTL differs between your local resolver and Google's public one.
Given the two scenarios above, write one sentence each explaining what NXDOMAIN and SERVFAIL specifically rule in or out.

Reachability, configuration, and naming are three of the four questions this module set out to answer. The fourth is what's actually running on a remote host at all — which ports are open, and what's listening on them from the outside, rather than from a command run locally on the machine itself.

dig