When a name does not resolve — or resolves to something surprising — dig asks the DNS system directly: which records exist, who answered, and how long the answer is good for. It is the difference between "the internet is down" and "the resolver returns a stale A record".
The basic query #
$ dig aospix.com +short
104.21.5.10
172.67.132.9
$ dig aospix.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; ANSWER SECTION:
aospix.com. 300 IN A 104.21.5.10+short strips to the answer — perfect in scripts. The full output's two key lines: status: NOERROR (asked and answered — NXDOMAIN would mean "no such name") and the TTL, 300 seconds: how long this answer may be cached.
Records you will actually query #
| Query | Answer | Use |
|---|---|---|
dig a host | IPv4 addresses | Does it resolve at all? |
dig aaaa host | IPv6 addresses | Dual-stack checks |
dig cname host | The alias target | What does this name really point to? |
dig mx domain | Mail servers | Why is mail bouncing? |
dig txt domain | Text records | SPF/DKIM/verification tokens |
dig ns domain | Authoritative servers | Who actually serves this zone? |
dig -x 1.2.3.4 | Reverse lookup | What hostname owns this IP? |
The TXT record is the quiet workhorse — domain verification tokens, SPF, and DKIM all live there, and dig txt domain +short prints them raw for exactly the copy-paste moments.
TTL: the number that explains "it works for everyone else" #
$ dig aospix.com | grep -E 'ANSWER SECTION' -A2
aospix.com. 300 IN A 104.21.5.10Every resolver between you and the authoritative server caches answers for the TTL. A DNS change you just made propagates when caches expire — five minutes at TTL 300, up to a day at 86400. Before a planned switchover, lower the TTL in advance; during an unplanned one, query the authority directly to see the truth:
$ dig @ns1.cloudflare.com aospix.com +shortThe @server form is dig's superpower — it targets any specific resolver (yours, the authoritative one, a public one like @1.1.1.1) and compares answers, which is how split-brain DNS and stale-cache problems get diagnosed in seconds.
For the resolver your system actually uses, resolvectl status shows it; connectivity below the name layer is ping territory. The network series continues.