Start

📞 The dig phonebook

A navigation index of every dig and nslookup command covered in this wiki, gathered onto one page and sorted by what you are trying to see. The lookups point at the live demo names (example.isitdns.net and its siblings, all inside the isitdns.net zone) or at a stable public anchor (Cloudflare's 1.1.1.2 reverse, the permanently-broken dnssec-failed.org, the root). Each entry links to the source page that walks the same lookup through its full annotated output.

Tools note: check your build with dig -v. Older system builds (the macOS system dig, still 9.10.6 as of mid-2026) have no +https and do not know the HTTPS type by name. Where a record needs newer tooling or the AD bit, the phonebook gives you a curl DoH form that works from any machine. See nslookup-and-dig for the tool-by-tool reference and dot-doh for encrypted transport.

Records#

The bread and butter: one query per record type, each pointing at a live demo record. Per-type deep dives live under the record-type cheat sheet.

What it shows	Command	Where
A record (IPv4), short form	`dig +short A example.isitdns.net`	A: IPv4 address record
AAAA record (IPv6), short form	`dig @1.1.1.1 example.isitdns.net AAAA +short`	AAAA: IPv6 address record
A record, explicit resolver (`@1.1.1.1`)	`dig @1.1.1.1 example.isitdns.net A +short`	A: IPv4 address record
CNAME alias resolving to its target	`dig @1.1.1.1 cname.example.isitdns.net A`	CNAME: canonical name (alias)
The CNAME hop on its own	`dig @1.1.1.1 cname.example.isitdns.net CNAME +short`	CNAME: canonical name (alias)
A two-hop CNAME chain	`dig +short A chain.example.isitdns.net`	How do I use dig? Every record type, live
MX (mail exchange) + priority	`dig @1.1.1.1 mx.example.isitdns.net MX +short`	MX: mail exchange
MX + additional section (a recursive leaves it empty)	`dig @1.1.1.1 mx.example.isitdns.net MX +noall +answer +additional`	MX: mail exchange
TXT (arbitrary text)	`dig @1.1.1.1 txt.example.isitdns.net TXT +short`	TXT: arbitrary text
TXT longer than 255 bytes (chunked)	`dig +short TXT long.example.isitdns.net`	How do I use dig? Every record type, live
CAA (cert-authority authorization)	`dig @1.1.1.1 caa.example.isitdns.net CAA +short`	CAA: certificate authority authorization
SRV (service location)	`dig @1.1.1.1 _xmpp-server._tcp.example.isitdns.net SRV +short`	SRV: service location
SRV + additional section (a recursive leaves it empty)	`dig @1.1.1.1 _xmpp-server._tcp.example.isitdns.net SRV +noall +answer +additional`	SRV: service location
NS (the apex nameservers)	`dig isitdns.net NS +short`	NS: nameserver
SOA (start of authority)	`dig isitdns.net SOA +short`	SOA: start of authority
SOA, one field per line	`dig @1.1.1.1 isitdns.net SOA +multiline`	transfer
HTTPS by number (`TYPE65`; SVCB is `TYPE64`)	`dig @1.1.1.1 svcb.example.isitdns.net TYPE65 +short`	HTTPS / SVCB: service binding hints
TLSA (DANE cert pin)	`dig @1.1.1.1 _443._tcp.tlsa.example.isitdns.net TLSA +short`	TLSA: DANE certificate pinning
SSHFP (SSH host-key fingerprint)	`dig @1.1.1.1 sshfp.example.isitdns.net SSHFP +short`	SSHFP: SSH host key fingerprint
Wildcard: any label resolves	`dig +short A literally-anything.wildcard.example.isitdns.net`	How do I use dig? Every record type, live

Example The nslookup equivalents (no flags, just the answer)

nslookup does not show header flags, but it confirms a record exists. These are the macOS / Linux (BIND) spellings; Windows ships its own nslookup implementation whose type parser knows fewer types (no CAA, TLSA, SSHFP, or TYPE65).

nslookup -type=A    example.isitdns.net 1.1.1.1
nslookup -type=AAAA example.isitdns.net 1.1.1.1
nslookup -type=CNAME cname.example.isitdns.net 1.1.1.1
nslookup -type=MX   mx.example.isitdns.net 1.1.1.1
nslookup -type=TXT  txt.example.isitdns.net 1.1.1.1
nslookup -type=CAA  caa.example.isitdns.net 1.1.1.1
nslookup -type=SRV  _xmpp-server._tcp.example.isitdns.net 1.1.1.1
nslookup -type=NS   isitdns.net 1.1.1.1
nslookup -type=SOA  isitdns.net 1.1.1.1
nslookup -type=SSHFP sshfp.example.isitdns.net 1.1.1.1
nslookup -type=TLSA _443._tcp.tlsa.example.isitdns.net 1.1.1.1
nslookup -type=TYPE65 svcb.example.isitdns.net 1.1.1.1

Zones and transfer#

Walking the apex, poking authoritative servers directly, and the transfer commands. An authoritative server answers an iterative (RD=0) query for a name inside a zone it serves straight from its zone data: the aa bit is set and ra is not (RFC 1035 section 4.1.1). A referral to a delegated child, like the probe.isitdns.net NS lookup below, legitimately comes back without aa: the parent is pointing you at the child's servers, not answering from its own data. A direct @server query that comes back with ra set and no aa is a sign that something on the path answered in the server's place, but on its own it is not proof: REFUSED is also the normal reply from a real authoritative server for a zone it does not serve, and SERVFAIL can be a genuine server failure. Before concluding anything, run the same query over an encrypted transport (dot-doh) and compare; see the warning below.

What it shows	Command	Where
The apex NS set	`dig @1.1.1.1 isitdns.net NS`	DNS fundamentals: refresher
Ask an authoritative server directly (RD=0)	`dig @coleman.ns.cloudflare.com isitdns.net SOA +norec`	Query types: recursive, iterative, forwarding
Authoritative SOA, direct	`dig @coleman.ns.cloudflare.com isitdns.net SOA +short`	transfer
Authoritative answer with the `aa` bit (RD=0)	`dig @pns2.isitdns.net probe.isitdns.net SOA +norec`	delegations
Full delegation walk from the root	`dig +trace example.isitdns.net`	Anatomy of a DNS query
The delegated `probe` child zone (NS)	`dig @coleman.ns.cloudflare.com probe.isitdns.net NS`	Delegated zones
Ask the delegated child's own server	`dig @pns2.isitdns.net probe.isitdns.net SOA`	Delegated zones
The child's NS address, asked of the parent	`dig @coleman.ns.cloudflare.com pns2.isitdns.net A`	Delegated zones
AXFR (refused on a managed zone)	`dig @coleman.ns.cloudflare.com isitdns.net AXFR`	Zone transfer: AXFR / IXFR / SOA

DNSSEC#

The signed-zone chain, and the permanently-broken anchor that proves validation works. isitdns.net is signed (algorithm 13, ECDSAP256SHA256); dnssec-failed.org is a public zone that is deliberately, permanently BOGUS.

What it shows	Command	Where
The zone's DNSKEY set	`dig @1.1.1.1 isitdns.net DNSKEY +short`	DNSSEC, signed and validated
The parent DS record	`dig @1.1.1.1 isitdns.net DS +short`	DNSSEC, signed and validated
RRSIG riding along with the answer	`dig @1.1.1.1 isitdns.net A +dnssec`	DNSSEC, signed and validated
`SERVFAIL` from failed validation	`dig @1.1.1.1 dnssec-failed.org A +dnssec`	Check DNSSEC validation with dig
Same query, validation disabled (`+cd`)	`dig @1.1.1.1 dnssec-failed.org A +dnssec +cd`	Check DNSSEC validation with dig
A second validating resolver agrees	`dig @9.9.9.9 dnssec-failed.org A`	Anatomy of a DNS query
Signed CAA at the apex	`dig @1.1.1.1 isitdns.net CAA +dnssec +short`	CAA: certificate authority authorization

Example Seeing the AD bit reliably (curl DoH)

dig sets the AD bit on its queries by default (it has since at least BIND 9.10: "This bit is set by default"), and a validating resolver echoes ad in the answer when the query carried AD=1 or DO=1 (RFC 6840 section 5.8). So a plain dig @1.1.1.1 isitdns.net A normally shows ad already; +adflag or +dnssec ask explicitly if your build or wrapper differs, and nslookup never prints header flags at all. The tool-independent check is Cloudflare's DoH JSON, which always reports the validation result in the AD field:

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=isitdns.net&type=A'

Look for "AD": true in the JSON. The same call against dnssec-failed.org returns "Status": 2 (SERVFAIL), no answer, and an Extended DNS Error comment naming the failure (EDE(9): DNSKEY Missing).

Encrypted transport (DoT / DoH / DoQ)#

An older system dig (like macOS's 9.10.6) cannot speak DoH or DoT, so the portable path is curl against a DoH JSON endpoint. dig +https needs 9.18+; kdig covers DoT and DoQ. Background and the kdig recipes live on dot-doh.

What it shows	Command	Where
DoH (DNS-over-HTTPS), JSON answer	`curl -s -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.isitdns.net&type=A'`	DoT, DoH, DoQ: encrypted DNS
DoH for a record `dig 9.10` cannot decode	`curl -s -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=svcb.example.isitdns.net&type=HTTPS'`	HTTPS / SVCB: service binding hints
Wire-format DoH (needs `dig` 9.18+)	`dig @1.1.1.1 +https iana.org A`	How do I read dig output? Live examples

Example The DoH JSON form, spelled out

Swap name= and type= for any record. Every demo record answers; the JSON Status is the rcode as a number (0 = NOERROR, 2 = SERVFAIL, 3 = NXDOMAIN).

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=txt.example.isitdns.net&type=TXT'

DoT and DoQ are not reachable from the stock dig; see the kdig examples on DoT, DoH, DoQ: encrypted DNS.

Reverse DNS#

IP back to name. The 1.1.1.2 and 2606:4700:4700::1111 reverses are stable public Cloudflare records, so the lookups answer live. The full tree walk is on reverse-dns.

What it shows	Command	Where
IPv4 reverse, the `-x` shortcut	`dig -x 1.1.1.2 +short`	PTR: reverse pointer
The same query, reverse name spelled out	`dig 2.1.1.1.in-addr.arpa PTR +short`	PTR: reverse pointer
IPv6 reverse (`dig` builds the nibbles)	`dig @1.1.1.1 -x 2606:4700:4700::1111 +short`	PTR: reverse pointer
Private reverse space, answered by the resolver itself instead of AS112 (RFC 6303)	`nslookup -type=NS 168.192.in-addr.arpa 1.1.1.1`	Reverse DNS: in-addr.arpa and ip6.arpa
The `NXDOMAIN` RFC 6303 actually asks for: a name inside the block	`dig @1.1.1.1 1.1.168.192.in-addr.arpa PTR`	Reverse DNS: in-addr.arpa and ip6.arpa

Example nslookup, reverse form

nslookup 1.1.1.2 1.1.1.1
nslookup -type=PTR 2.1.1.1.in-addr.arpa 1.1.1.1
nslookup 2606:4700:4700::1111 1.1.1.1

Note: RFC 5737 / RFC 3849 documentation addresses (192.0.2.x, 2001:db8::) carry no PTRs, so dig -x 192.0.2.1 returns NXDOMAIN. Use a routed address for live reverse lookups. See Reverse DNS: in-addr.arpa and ip6.arpa.

Private address space returns the same code for a different reason: per RFC 6303, resolvers serve zones like 168.192.in-addr.arpa locally, and the RFC asks for NXDOMAIN on names inside the block while leaving SOA and NS answerable at the zone name itself. 1.1.1.1 and 8.8.8.8 are stricter and return NXDOMAIN at the zone name too, which is what the -type=NS lookup in the table demonstrates: AS112 would have handed back an NS set.

Troubleshooting: when it actually is DNS#

The checks that tell a real DNS failure apart from something wearing a DNS costume. Each one pairs with a live failure on when-its-dns.

What it shows	Command	Where
TTL left on a cached answer (watch it tick)	`dig @1.1.1.1 example.isitdns.net A +noall +answer`	When it actually is DNS
`NXDOMAIN`: a name that truly does not exist	`dig @1.1.1.1 definitely-does-not-exist.iana.org A`	DNS fundamentals: refresher
`NOERROR` with zero answers: Cloudflare's synthesized "no such record", not `NXDOMAIN`	`dig @1.1.1.1 nonexistent.isitdns.net A`	When it actually is DNS
Force TCP (catch a firewall that blocks `:53/tcp`)	`dig +tcp TXT txt.example.isitdns.net`	When it actually is DNS
Truncation: `tc` set when an RSA `DNSKEY` set overflows a 512-byte UDP budget (`+ignore` keeps `dig` from retrying over TCP, so you see the truncated reply itself)	`dig +ignore +bufsize=512 DNSKEY dnssec.works`	dig flag reference
`+trace` from the root (which hop breaks)	`dig +trace isitdns.net`	Anatomy of a DNS query
Compare two resolvers' verdicts	`dig @9.9.9.9 dnssec-failed.org A`	Anatomy of a DNS query
Name resolves but the service is down	`dig +short A example.isitdns.net`	When it actually is DNS

Just for fun#

The demo zone hides a few TXT records that draw ASCII art. Each one is an ordinary one-line TXT value with ~ standing in for the line breaks (past 255 bytes the wire format also chunks it into extra strings, as the hangman shows), and the front-page dig tool unfolds them (manual: dig-tool). Plain dig shows the folded line; the tool draws the picture.

What it shows	Command	Where
"It was DNS. It is always DNS."	`dig +short TXT txt.example.isitdns.net`	How do I use dig? Every record type, live
"Yes." (the answer to "is it DNS?")	`dig +short TXT answer.example.isitdns.net`	How do I use dig? Every record type, live
The hangman, folded in a `TXT`	`dig +short TXT itwasdns.example.isitdns.net`	How do I read dig output? Live examples
Kirby dances by	`dig +short TXT kirby.example.isitdns.net`	How do I read dig output? Live examples