If you've ever stared at the output of dig example.com and only understood half of it, you're not alone. dig (Domain Information Groper) is the tool most sysadmins and DevOps engineers reach for first when a domain "isn't resolving" — but its output is dense, and knowing which line actually matters saves a lot of guessing.
Here's a quick breakdown of what a dig response is telling you and how to use it for real troubleshooting.
The four things dig output actually tells you
A dig response is split into sections, each answering a different question:
-
HEADER — the response status (
NOERROR,NXDOMAIN,SERVFAIL) plus flags likeaa(authoritative) andrd/ra(recursion desired/available). - QUESTION SECTION — confirms exactly what was asked.
-
ANSWER SECTION — the actual record returned, in
name TTL class type valueformat. - Query time / SERVER / WHEN — how fast the resolver answered, and which resolver it was.
The status code alone usually tells you what's wrong before you read anything else:
-
NOERROR+ empty answer → the domain exists, but has no record of the type you asked for. -
NXDOMAIN→ the domain doesn't exist — typo, expired registration, or a deleted zone. -
SERVFAIL→ the authoritative name servers themselves are broken. That's a registrar/DNS-provider problem, not something on your end.
Picking the right record type
A domain doesn't have one DNS record — it has several, and dig needs to know which one you're asking for:
-
A/AAAA— the IPv4/IPv6 address. -
MX— mail server routing and priority. First thing to check when email bounces. -
TXT— SPF, DKIM, and domain-ownership verification strings. -
NS— the authoritative name servers. Wrong here means nothing else resolves correctly. -
CNAME— an alias pointing one hostname at another. -
SOA— primary name server, admin contact, zone refresh/retry/expire timers. -
PTR— reverse lookup (IP → hostname). Query format is different — more on that below.
+short: skip the noise
Once you know what you're looking for, dig example.com A +short strips the response down to bare values — just the IPs, one per line. No header, no timing info, nothing else.
Querying a specific resolver
dig @1.1.1.1 example.com A sends the query straight to a specific resolver instead of your system default. This is the fastest way to explain "it works for them but not for me" — DNS changes don't propagate everywhere simultaneously, and your ISP's resolver may be serving a stale cached record while a public resolver already reflects the update. Querying two @servers side by side turns a mystery into "oh, it's just caching."
The PTR gotcha
dig 203.0.113.10 PTR doesn't work the way you'd expect, because PTR records live under a reversed, special-purpose domain: 10.113.0.203.in-addr.arpa. If a reverse lookup returns NXDOMAIN for an IP you know is active, check the octet order before assuming reverse DNS isn't configured.
dig vs whois vs host
They answer different questions, and mixing them up wastes time:
-
dig— what does this domain resolve to right now, according to this resolver. -
host— the same core answer, shorter and more script-friendly. -
whois— who registered the domain and when it expires. Registration metadata, not live DNS.
Two real troubleshooting patterns
"We updated DNS an hour ago and some people still see the old value." Query against two different @servers. If they disagree, it's propagation/caching — wait out the TTL rather than touching the config again.
"Email is bouncing." dig yourdomain.com MX +short first. If it's empty, mail has nowhere to go. If MX is fine, check TXT next — a missing or malformed SPF record is a very common silent-bounce cause.
Read more / try it live
This post covers the basics — the full guide goes deeper into DNSSEC validation (+dnssec), why +trace isn't always the tool you want, and includes a live sandboxed dig you can actually run against a real domain, right in the browser, with no install:
