is it dns? / wiki ← back to the live monitor

📞 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 zone (example.isitdns.net and the isitdns.net apex) 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: the macOS system dig is 9.10.6, which has no +https and does 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 showsCommandWhere
A record (IPv4), short formdig +short A example.isitdns.netA: IPv4 address record
AAAA record (IPv6), short formdig @1.1.1.1 example.isitdns.net AAAA +shortAAAA: IPv6 address record
A record, explicit resolver (@1.1.1.1)dig @1.1.1.1 example.isitdns.net A +shortA: IPv4 address record
CNAME alias resolving to its targetdig @1.1.1.1 cname.example.isitdns.net ACNAME: canonical name (alias)
The CNAME hop on its owndig @1.1.1.1 cname.example.isitdns.net CNAME +shortCNAME: canonical name (alias)
A two-hop CNAME chaindig +short A chain.example.isitdns.netThe dig-along
MX (mail exchange) + prioritydig @1.1.1.1 mx.example.isitdns.net MX +shortMX: mail exchange
MX + additional section (a recursive leaves it empty)dig @1.1.1.1 mx.example.isitdns.net MX +noall +answer +additionalMX: mail exchange
TXT (arbitrary text)dig @1.1.1.1 txt.example.isitdns.net TXT +shortTXT: arbitrary text
TXT longer than 255 bytes (chunked)dig +short TXT long.example.isitdns.netThe dig-along
CAA (cert-authority authorization)dig @1.1.1.1 caa.example.isitdns.net CAA +shortCAA: certificate authority authorization
SRV (service location)dig @1.1.1.1 _xmpp-server._tcp.example.isitdns.net SRV +shortSRV: service location
SRV + additional section (a recursive leaves it empty)dig @1.1.1.1 _xmpp-server._tcp.example.isitdns.net SRV +noall +answer +additionalSRV: service location
NS (the apex nameservers)dig isitdns.net NS +shortNS: nameserver
SOA (start of authority)dig isitdns.net SOA +shortSOA: start of authority
SOA, one field per linedig @1.1.1.1 isitdns.net SOA +multilinetransfer
HTTPS / SVCB (numeric TYPE65)dig @1.1.1.1 svcb.example.isitdns.net TYPE65 +shortHTTPS / SVCB: service binding hints
TLSA (DANE cert pin)dig @1.1.1.1 _443._tcp.tlsa.example.isitdns.net TLSA +shortTLSA: DANE certificate pinning
SSHFP (SSH host-key fingerprint)dig @1.1.1.1 sshfp.example.isitdns.net SSHFP +shortSSHFP: SSH host key fingerprint
Wildcard: any label resolvesdig +short A literally-anything.wildcard.example.isitdns.netThe dig-along
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 straight from its zone data: the aa bit is set and ra is not, because the server holds the answer itself and offers no recursion (RFC 1034 section 4.3.2). That is true of Cloudflare's coleman and hera at the isitdns.net apex and of BIND authoritative servers like the ones behind the probe.isitdns.net demo alike. If a direct @server query instead comes back with ra set, no aa, or a REFUSED / SERVFAIL, that reply came from an in-path port-53 interceptor answering in the server's place, not from the authoritative server; see the warning below.

What it showsCommandWhere
The apex NS setdig @1.1.1.1 isitdns.net NSDNS fundamentals: refresher
Ask an authoritative server directly (RD=0)dig @coleman.ns.cloudflare.com isitdns.net SOA +norecQuery types: recursive, iterative, forwarding
Authoritative SOA, directdig @coleman.ns.cloudflare.com isitdns.net SOA +shorttransfer
Authoritative answer with the aa bit (RD=0)dig @pns1.isitdns.net probe.isitdns.net SOA +norecdelegations
Real NXDOMAIN from a BIND auth serverdig anything.does-not-exist.probe.isitdns.netWhen it actually is DNS
Full delegation walk from the rootdig +trace example.isitdns.netAnatomy of a DNS query
The delegated probe child zone (NS)dig @coleman.ns.cloudflare.com probe.isitdns.net NSDelegated zones
Ask the delegated child's own serverdig @pns1.isitdns.net probe.isitdns.net SOADelegated zones
Glue: child's NS A record, from parentdig @coleman.ns.cloudflare.com pns1.isitdns.net ADelegated zones
AXFR (refused on a managed zone)dig @coleman.ns.cloudflare.com isitdns.net AXFRZone 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 showsCommandWhere
The zone's DNSKEY setdig @1.1.1.1 isitdns.net DNSKEY +shortDNSSEC, signed and validated
The parent DS recorddig @1.1.1.1 isitdns.net DS +shortDNSSEC, signed and validated
RRSIG riding along with the answerdig @1.1.1.1 isitdns.net A +dnssecDNSSEC, signed and validated
SERVFAIL from failed validationdig @1.1.1.1 dnssec-failed.org A +dnssecDNSSEC troubleshooting: keeping out of BOGUS
Same query, validation disabled (+cd)dig @1.1.1.1 dnssec-failed.org A +dnssec +cdDNSSEC troubleshooting: keeping out of BOGUS
A second validating resolver agreesdig @9.9.9.9 dnssec-failed.org AAnatomy of a DNS query
Signed CAA at the apexdig @1.1.1.1 isitdns.net CAA +dnssec +shortCAA: 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)#

The system dig (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 showsCommandWhere
DoH (DNS-over-HTTPS), JSON answercurl -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 decodecurl -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 +https @1.1.1.1 iana.org AWorked 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 showsCommandWhere
IPv4 reverse, the -x shortcutdig -x 1.1.1.2 +shortPTR: reverse pointer
The same query, reverse name spelled outdig 2.1.1.1.in-addr.arpa PTR +shortPTR: reverse pointer
IPv6 reverse (dig builds the nibbles)dig @1.1.1.1 -x 2606:4700:4700::1111 +shortPTR: reverse pointer
Private reverse space: NXDOMAIN from the resolver itself (RFC 6303)nslookup -type=NS 168.192.in-addr.arpa 1.1.1.1IP address spaces: public, private, documentation
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::) have no reverse zone, 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 behaves the same way for a different reason: per RFC 6303, resolvers serve zones like 168.192.in-addr.arpa locally, so a public resolver answers NXDOMAIN itself instead of returning a delegated NS set. That is what the -type=NS lookup in the table demonstrates.


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 worked failure on when-its-dns.

What it showsCommandWhere
TTL left on a cached answer (watch it tick)dig @1.1.1.1 example.isitdns.net A +noall +answerWhen it actually is DNS
NXDOMAIN: a name that truly does not existdig @1.1.1.1 definitely-does-not-exist.iana.org ADNS fundamentals: refresher
NOERROR with zero answers: Cloudflare's synthesized "no such record", not NXDOMAINdig @1.1.1.1 nonexistent.isitdns.net AWhen it actually is DNS
Force TCP (catch a firewall that blocks :53/tcp)dig +tcp TXT txt.example.isitdns.netWhen it actually is DNS
Truncation + TCP fallback (an RSA DNSKEY set overflows a 512-byte UDP budget)dig +ignore +bufsize=512 DNSKEY dnssec.worksdig flag reference
+trace from the root (which hop breaks)dig +trace isitdns.netAnatomy of a DNS query
Compare two resolvers' verdictsdig @9.9.9.9 dnssec-failed.org AAnatomy of a DNS query
Name resolves but the service is downdig +short A example.isitdns.netWhen 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. Plain dig shows the folded line; the tool draws the picture.

What it showsCommandWhere
"It was DNS. It is always DNS."dig +short TXT txt.example.isitdns.netThe dig-along
"Yes." (the answer to "is it DNS?")dig +short TXT answer.example.isitdns.netThe dig-along
The hangman, folded in a TXTdig +short TXT itwasdns.example.isitdns.netWorked examples
Kirby dances bydig +short TXT kirby.example.isitdns.netWorked examples

See also#