dig
asking the DNS directlydig builds one DNS query, sends it, and shows everything that came back — header flags, the question, the answer records and how long it took. Because it talks to the resolver itself and ignores the host's own lookup rules, it tells you what the DNS says rather than what the machine concluded.
When a name will not resolve, dig separates what the DNS answered from what the host did with the answer.
At the terminal
Read the session first, then the notes: each numbered line in the output is answered by the note with the same number.
What the numbered lines are telling you
NOERROR means the query was answered. NXDOMAIN means the name does not exist; SERVFAIL means the resolver could not get an answer at all.
qr marks this as a response, rd that recursion was requested, ra that the server offers it. An "aa" flag would mean the answer came from the authoritative server itself.
Name, time-to-live in seconds, class, type, value. 3600 is how long any resolver may cache this before asking again.
Run it twice: a second answer in 0 msec came from the resolver's cache, and its TTL will have counted down.
127.0.0.53 is the local systemd-resolved stub, not the upstream resolver. Add @server to ask a specific one.
Switches
A switch changes how the command behaves. These are the ones used day to day; man dig lists the rest. Single-letter switches can usually be joined, so -l -a may be written -la.
+short- Print only the answer — the address or name — and nothing else.
+trace- Follow the delegation from the root servers down, one step at a time.
-x ADDR- Reverse lookup: find the name for an IP address.
@SERVER- Ask this DNS server instead of the system’s configured one.
-t TYPE- Ask for a record type: A, AAAA, MX, NS, TXT. The type can also be given bare.
+noall +answer- Hide every section except the answer.
+tcp- Use TCP instead of UDP for the query.
Variations worth knowing
The same tool, pointed at a narrower question. These four cover most of what it is reached for day to day.
dig +short example.com AAAAJust the IPv6 addresses, one per line — the form for scripts.
dig @192.0.2.53 example.com MXAsks a named resolver for the mail exchangers, bypassing the one the host is configured with.
dig +trace example.comWalks the delegation from the root servers down, showing which server handed off to which.
dig -x 192.0.2.10A reverse lookup: the PTR record that maps an address back to a name.
In cybersecurity
DNS decides where every connection goes, and by default nothing in the answer is authenticated. dig is the tool for checking whether the answer you received is the one that was published.
Ask the local resolver and an independent one. Different answers for the same name mean something is rewriting DNS.
"dig +dnssec" returns the signatures. An "ad" flag in the response means a validating resolver checked them.
"dig axfr" against a misconfigured server returns the whole zone — every hostname the organisation has.
A very short TTL on a record that should be stable is a mark of fast-flux hosting and of hijacked records.
Data can be smuggled out in DNS queries and replies. Unusual TXT volume to one domain deserves a look.
MX, NS, TXT and SPF records describe an organisation's mail and hosting to anyone who asks. Publish only what must be public.