Reading dig Output

Reading dig output

dig is the tool you’ll reach for every time Cathedra reports something surprising. It’s already on every Mac and every Linux server. Windows techs can use nslookup or install dig via WSL.

We’ll work through real output from isidoregroup.com. By the end, you should be able to predict every line.

The basic invocation

dig isidoregroup.com

Output, annotated:

; <<>> DiG 9.10.6 <<>> isidoregroup.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41822
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

The header tells you whether the query succeeded. NOERROR is what you want. The two other status codes you’ll see in the field:

  • NXDOMAIN — the domain doesn’t exist at all. If a tech says “DNS isn’t working” and you see NXDOMAIN, the zone itself is broken or the registrar hasn’t published it.
  • SERVFAIL — the recursive resolver tried but couldn’t get an authoritative answer. Usually means the authoritative nameservers are down or unreachable. Very different from NXDOMAIN.

The flags line

flags: qr rd ra carries useful information:

  • qr — this is a response (always set on a response).
  • rd — recursion was desired by the client. You set this by default with dig.
  • ra — recursion was available at the resolver.
  • aa — not present here, but worth knowing: authoritative answer. Set when you’ve queried an authoritative nameserver directly.

When you query an authoritative nameserver directly (with @), you should see aa. If you don’t, the server isn’t actually authoritative for that zone.

The question and answer sections

;; QUESTION SECTION:
;isidoregroup.com.      IN  A

;; ANSWER SECTION:
isidoregroup.com.   3600    IN  A   203.0.113.45

The answer section is what you came for. Four important fields per row:
1. Name (isidoregroup.com.) — note the trailing dot, which makes it fully-qualified.
2. TTL (3600) — how long this record can be cached, in seconds.
3. Class (IN) — Internet class; you’ll never see anything else.
4. Type and value (A 203.0.113.45).

Reading multiple record types

Most of your debugging will be against specific record types. Common patterns:

MX records:

dig isidoregroup.com MX +short
isidoregroup-com.mail.protection.outlook.com.

+short strips everything except the answer. For MX with priority:

dig isidoregroup.com MX
;; ANSWER SECTION:
isidoregroup.com.   3600    IN  MX  0 isidoregroup-com.mail.protection.outlook.com.

TXT records (the workhorse for security):

dig isidoregroup.com TXT +short
"v=spf1 include:spf.protection.outlook.com -all"
"MS=ms12345678"

Multiple TXT records come back — SPF, M365 verification token, anything else published at the apex.

A specific subdomain:

dig _dmarc.isidoregroup.com TXT +short
"v=DMARC1; p=reject; rua=mailto:dmarc@isidoregroup.com"

_dmarc is always at this exact hostname. Same for _mta-sts, _smtp._tls, etc.

DKIM selector:

dig selector1._domainkey.isidoregroup.com TXT +short
selector1-isidoregroup-com._domainkey.isidoregroup.onmicrosoft.com.

This came back as a CNAME pointer — M365’s standard pattern. To see the underlying key, follow the CNAME:

dig selector1-isidoregroup-com._domainkey.isidoregroup.onmicrosoft.com TXT +short

The +trace option — when caches lie

dig isidoregroup.com +trace

+trace starts at the root and walks the hierarchy step by step. You see the actual referrals from root → TLD → authoritative. Use this when:

  • A record looks wrong everywhere except on the authoritative server (caching issue along the path)
  • You suspect a hijack or misconfigured glue record at the registrar
  • You want to verify the authoritative nameservers really are who the registrar says they are

The output is verbose but readable. Each section ends with the next set of nameservers to query.

Querying a specific server with @

dig @1.1.1.1 isidoregroup.com TXT

Forces the lookup through a specific resolver. Useful when:

  • The resolver the client is using gives a different answer than yours (likely caching)
  • You want a clean, uncached read from a public resolver
  • You’re debugging private DNS where the internal resolver gives a different answer than the public one

Most useful pattern: query the authoritative directly to see what’s actually published:

dig @ns11.domaincontrol.com isidoregroup.com TXT +short

(Get the authoritative NS from dig isidoregroup.com NS +short first.)

NXDOMAIN vs. SERVFAIL — the difference matters

A practical script for triage when something resolves wrong:

  1. Run dig {domain} — what status?
  2. If NXDOMAIN: the domain or record doesn’t exist in the authoritative zone. Fix at the registrar / DNS host.
  3. If SERVFAIL: the authoritative servers aren’t responding correctly. Get the NS records, query each directly to see which one is broken. Often points to a registrar problem (delegation broken) or a DNS host outage.
  4. If NOERROR but no ANSWER SECTION: the record type doesn’t exist for that name (e.g., querying MX for www.acme.com when only A records exist). This is a legitimate “no answer” — not an error.

What you should remember

  • NOERROR + answer is what you want. NXDOMAIN means doesn’t exist. SERVFAIL means servers failed.
  • +short for quick lookups. Full output for debugging.
  • +trace walks the hierarchy from root. Use when caches might lie.
  • @nameserver queries a specific server, bypassing your default resolver.
  • Always query the authoritative directly when you suspect a propagation issue.

The next four lessons (1.4–1.7) walk through specific record-type checks Cathedra runs — NS provider consistency, SOA, CAA, DNSSEC. After that we’ll close Module 1 with TTL sanity, the most under-appreciated DNS hygiene check.

Cathedra alignment: every Cathedra finding can be reproduced manually with dig — this lesson teaches that fluency

Previous Topic
Back to Lesson
Next Topic