dig +norecurse: ask a server only what it knows (authoritative and cache checks)
- tool
- DNS
- command
- dig
- flag
- +norecurse (+nordflag)
- default
- +recurse (the RD bit is set, so dig sends recursive queries)
dig @ns1.example.com +norecurse example.com A clears the RD (recursion desired) bit in the query, so the server answers only from its own zones or cache instead of looking the name up elsewhere. The BIND manual states that RD is set by default, "which means dig normally sends recursive queries", and that recursion is disabled automatically with +trace and +nssearch. Use +norecurse to see exactly what an authoritative server publishes, to check whether a delegation is correct, or to peek into a resolver's cache.
Typical commands
dig @ns1.example.com +norecurse example.com A # authoritative answer (aa flag)
dig @a.gtld-servers.net +norecurse example.com NS # the delegation the parent hands out
dig @192.0.2.53 +norecurse www.example.com A # is it in this resolver's cache?
dig +nssearch example.com # SOA serial from every authoritative serverReading non-recursive answers
| Response | Meaning |
|---|---|
| Answer with the aa flag | The server is authoritative for the zone and returned its own data |
| No answer, NS records in the authority section | A referral: the server delegates the name to other servers |
| REFUSED | The server does not answer this client or this zone |
| Answer without aa from a resolver | Cached data, with the TTL remaining in that cache |
| Empty answer from a resolver | Not cached (it would have to recurse) |
A referral is the normal answer of a parent zone's servers; following referrals step by step from the root is what dig +trace does automatically.
When it helps
- After a DNS change. Query each authoritative server with
+norecurseto confirm they all serve the new data and the same SOA serial, before waiting for caches; see check DNS propagation. - Lame delegations. If the parent's NS records name a server that answers REFUSED or without
aafor the zone, the delegation is broken. - Warning in the output. Querying an authoritative-only server without the option prints WARNING: recursion requested but not available;
+norecurseavoids it.
Pitfalls
- Resolvers may refuse. Public resolvers often reject non-recursive queries or answer only from parts of their cache, so cache inspection is unreliable there.
- Choose the server.
+norecursewithout@serversends the query to your configured resolver, which is rarely what you want; see query a specific DNS server.
FAQ
How do I check what the authoritative server publishes, bypassing caches?
Query it directly with recursion off: dig @ns1.example.com +norecurse example.com A. The aa flag in the header confirms an authoritative answer, and the TTL is the configured value.
Why does dig warn recursion requested but not available?
dig sets RD by default, and authoritative-only servers do not recurse. The warning is harmless for those servers; add +norecurse to stop sending RD and to make the intent explicit.
Can +norecurse show whether a resolver has a name cached?
Often, yes: a non-recursive query to a resolver that allows it returns the record only if it is in the cache, with the remaining TTL. Many public resolvers refuse or ignore such queries.