Troubleshooting DNS with dig and online tools
The dig flags worth knowing, tracing delegation, asking authoritative servers directly, reading TTLs and status codes, and spotting inconsistent answers.
dig, properly
dig www.example.com # the default: A record via your resolver
dig www.example.com A AAAA +short # both address families, short form
dig www.example.com @1.1.1.1 # ask a specific public resolver
dig www.example.com @ns1.example.com +norecurse # authoritative, no caching help
dig ANY example.com @ns1.example.com # discouraged: many servers refuse or minimise
dig +trace www.example.com # walk the delegation from the root
dig -x 203.0.113.10 # reverse lookup
dig +tcp www.example.com # force TCP, useful when UDP is filtered
dig +dnssec example.com # request DNSSEC records
dig +noall +answer example.com TXT # just the answer section| Field | What it tells you | Common value |
|---|---|---|
status | The response code | NOERROR, NXDOMAIN, SERVFAIL, REFUSED |
flags | Whether caching was involved | qr aa rd ra - aa means authoritative |
ANSWER: | Number of records returned | Zero is a legitimate answer for some queries |
AUTHORITY: | The zone that would answer | Shows the SOA when nothing matches |
| TTL in the answer | Seconds the resolver may cache it | Decreasing each time you query the same resolver |
ADDITIONAL: | Glue and other helpful records | Missing glue is a real diagnosis |
- Run the query twice against the same resolver. A decreasing TTL proves it is cache-served; a constant TTL near the configured value usually means you reached the authoritative server.
aain the flags is the fastest way to see whether you asked an authoritative server or a cache.- Use
+norecursewhen you want to see exactly what is published rather than what a resolver is willing to do for you.
Diagnosing the usual failures
| Symptom | First command | Likely cause |
|---|---|---|
| NXDOMAIN everywhere | dig +trace name | Delegation broken, or the record does not exist in the zone |
| SERVFAIL | dig name @ns1.example.com | DNSSEC validation broken, or the zone failed to load |
| REFUSED | dig name @ns1.example.com +norecurse | The server is not authoritative for that name |
| Answers only from some regions | dig name @8.8.8.8; @1.1.1.1 | GeoDNS or inconsistent anycast nodes |
| Old value on one network | dig name on that network | A long-lived cache or a corporate resolver |
| Works with www, not the apex | dig example.com | Missing apex record, or a CNAME at the apex |
| Name resolves nowhere but locally | dig @8.8.8.8 vs local | A local hosts entry or split-horizon DNS |
# a five-command triage that answers most tickets
dig +short ns.example.com # 1. what is delegated
dig +short a www.example.com @ns1.example.com # 2. what the authoritative server says
dig +short a www.example.com @1.1.1.1 # 3. what a public resolver says
dig +trace www.example.com # 4. where the chain breaks
dig +short txt _dmarc.example.com # 5. verify email records survived the changeComparing steps two and three is the whole trick. If the authoritative server has the new value and the public resolver has the old one, the change is correct and you are waiting on TTL. If the authoritative server has the old value, the change never happened.
Multiple vantage points
- Public resolvers in different regions reveal anycast and geolocation differences that a single query cannot.
- Propagation checkers that query dozens of resolvers are only useful if they query authoritative servers too - many only report cached results from public resolvers and will show the old value for the full TTL.
- A resolver that has already cached the old answer will not go and ask again. There is no way to force it, short of the TTL expiring.
- Keep a copy of the previous zone. When something breaks, a diff against the last known good file identifies the change in seconds.
# check several public resolvers at once and print only the answer
for r in 1.1.1.1 8.8.8.8 9.9.9.9 208.67.222.222; do
printf '%-18s %s\n' "$r" "$(dig +short +time=2 +tries=1 www.example.com @$r | tr '\n' ' ')"
done
# and compare against the authoritative server
printf '%-18s %s\n' "authoritative" "$(dig +short www.example.com @ns1.example.com | tr '\n' ' ')"💡
Do not chase propagation. Once the authoritative servers answer correctly, the remaining work is arithmetic: wait the TTL that was configured before the change. Refreshing your browser does not clear a resolver cache, and there is nothing to escalate.
FAQ
Why does dig show a different answer from my browser?
The browser uses the operating system resolver, which may use a different upstream server, may have its own cache, and may apply DNS-over-HTTPS. Query each layer separately to find the difference.
Is ANY still usable?
Barely. Most servers now return a minimal response or refuse it outright, and it is often used in amplification attacks. Query the specific record types you need.
Related
TTL, propagation and common mistakes How name resolution works
Last refreshed 2026-09-18.