dig
Overview
dig (Domain Information Groper) queries DNS servers and prints detailed answers. It is the preferred CLI for debugging resolution on Ubuntu/Debian (package dnsutils / bind9-dnsutils). Use it to inspect A/AAAA/MX/TXT/NS/CNAME records, compare resolvers, and validate changes after DNS edits.
Syntax
dig [@server] [name] [type] [options]
dig [options] name typeDefault type is A. If @server is omitted, dig uses the system resolver configuration (often systemd-resolved stub on Ubuntu).
Common Options
| Option | Description |
|---|---|
@server |
Query this nameserver (IP or hostname) |
-t type / positional type |
Record type: A, AAAA, MX, TXT, NS, CNAME, SOA, ANY (limited), … |
+short |
Minimal answer only |
+noall +answer |
Show answer section only (structured) |
+trace |
Iterative resolve from root hints |
+dnssec |
Request DNSSEC records |
+tcp |
Use TCP instead of UDP |
+time=T |
Timeout seconds |
+tries=N |
Number of tries |
-p port |
Nameserver port (default 53) |
-x addr |
Reverse lookup (PTR) convenience |
-4 / -6 |
Transport IPv4 / IPv6 only |
+subnet=… |
EDNS client subnet (advanced) |
Examples with Explanations
Basic A record
dig example.com
dig example.com AShort output for scripts
dig +short example.com
dig +short example.com AAAAQuery a specific resolver
dig @1.1.1.1 example.com
dig @8.8.8.8 example.com AAAA
dig @127.0.0.53 example.com # systemd-resolved stub on many Ubuntu hostsComparing @1.1.1.1 vs system resolver isolates “DNS server cache/policy” vs “local stub” issues.
MX and TXT
dig example.com MX +short
dig example.com TXT +shortReverse DNS (PTR)
dig -x 1.1.1.1 +short
# equivalent idea:
dig 1.1.1.1.in-addr.arpa PTR +shortAnswer section only (readable)
dig +noall +answer example.com A
dig +noall +answer www.example.comTrace from the root (find where delegation breaks)
dig +trace example.comShows root → TLD → authoritative path. Heavy but excellent when “some resolvers see X, others Y.”
Follow CNAME manually
dig www.example.com +short
dig +noall +answer www.example.comIf you get a CNAME, dig again on the target name for the final A/AAAA.
TCP query (firewall / large answers)
dig +tcp example.com TXTNon-standard port (lab DNS)
dig @127.0.0.1 -p 5353 test.lab ABatch mode
dig -f names.txt +shortnames.txt lists one name per line.
Understanding Output
Default output sections: - HEADER — opcode, status (NOERROR, NXDOMAIN, SERVFAIL, REFUSED), flags (aa authoritative, rd recursion desired, ra recursion available). - QUESTION — what you asked. - ANSWER — records for the name. - AUTHORITY — NS/SOA when relevant. - ADDITIONAL — glue / extras. - Query time / SERVER / WHEN / MSG SIZE — which server answered and how fast.
Status guide: | Status | Meaning | |——–|———| | NOERROR | Query ok (answer may still be empty for that type) | | NXDOMAIN | Name does not exist | | SERVFAIL | Resolver failure (upstream, DNSSEC, timeout) | | REFUSED | Server refused the query |
Notes & Pitfalls
- Ubuntu’s
127.0.0.53is often a stub — it forwards to real resolvers. Debugging “wrong answer” may need@the upstream (resolvectl status) or a public resolver. ANYis deprecated/restricted on many public resolvers; query specific types instead.- TTL in answers is remaining TTL from that resolver’s cache, not necessarily the zone’s configured TTL.
- Split-horizon DNS returns different answers by client network; VPN on/off can change results.
digsuccess does not mean your application uses the same resolver path — checkresolvectl,/etc/nsswitch.conf, and app-specific DNS settings.- For quick human checks,
hostis shorter; for operators,digis the right default.
Additional Resources
man digman resolvectl(Ubuntu resolver integration)