dig Warning: Recursion Requested but Not Available

The short answer

dig sets the Recursion Desired flag, shown as rd, by default. A recursive resolver that offers recursion to your client normally returns the Recursion Available flag, shown as ra. When rd is present and ra is absent, dig prints the warning.

The warning does not automatically invalidate the response. An authoritative-only server is expected to answer from the zones it hosts without looking up unrelated names. If the response contains aa and the requested record appears in the answer section, the server has probably done exactly what it was designed to do.

Read the flags together

;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

In this example, qr identifies a response, aa says the answer is authoritative, and rd shows that the client requested recursion. There is no ra. The combination is normal when querying an authoritative server directly for a record in one of its own zones.

Compare that with a typical recursive answer:

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

Here the server accepted the recursive request and returned an answer. The lack of aa means this response is not being presented as authoritative. It may have been resolved and cached by the recursive service.

When the warning is expected

You queried an authoritative name server

Public authoritative name servers generally should not provide open recursion. They answer for the zones they host and return referrals or negative answers where appropriate. Use +norecurse when you intentionally test one:

dig @ns1.example.net example.net SOA +norecurse
dig @ns1.example.net www.example.net A +norecurse

This clears the recursive request and removes the mismatch that produces the warning. It also makes your testing intent explicit.

The resolver restricts recursion by client address

A DNS server can be authoritative for public clients while offering recursion only to trusted internal networks. A query from an unapproved address may receive an authoritative answer for a local zone but no recursive service for other names. BIND configurations commonly express this with recursion and access-control settings such as allow-recursion, views, or client-based matching.

You are testing a split DNS view

The same DNS address can expose different behavior to internal and external clients. VPN state, source subnet, forwarding path, and view selection can decide whether recursion is available. Record the server address from the final SERVER line and the network context in which you ran the query.

When the warning points to a real problem

Investigate further when you expected a normal recursive resolver, especially if applications also fail to resolve unrelated public names. Possible causes include querying an authoritative service by mistake, resolver access controls that exclude your client, a changed VPN or subnet, a DNS listener bound to the wrong interface, or a forwarding service that is not the server you expected.

Compare the same name across the intended resolver, a known external resolver, and an authoritative server:

dig @192.0.2.53 www.example.net A
dig @1.1.1.1 www.example.net A
dig @ns1.example.net www.example.net A +norecurse

These are different questions. The first tests your selected recursive service. The second provides an external comparison. The third checks the zone data at its source. A disagreement tells you where to investigate without assuming that one response alone is correct.

Do not confuse the warning with SERVFAIL

The recursion warning describes server capability or policy. SERVFAIL is a DNS response code indicating that the server failed to complete the operation. DNSSEC validation, broken delegation, unreachable authoritative servers, and forwarding failures can all produce SERVFAIL even when recursion is available.

Likewise, NOERROR with zero answers does not necessarily mean recursion failed. It can mean the name exists but has no record of the requested type, or it can be a referral. Read the authority section and flags before deciding.

Use the answer and authority sections to classify the response

The answer section contains records that directly answer the question, plus records reached through aliases where applicable. The authority section provides context about the zone responsible for the name. An SOA record in a negative response can identify the authoritative zone and supply timing used for negative caching. NS records in the authority section can instead indicate a referral to another set of name servers.

This distinction matters when ANSWER: 0. If the status is NOERROR and the authority section contains an SOA, the name can exist while the requested type does not. If the status is NXDOMAIN, the server is saying the queried name itself does not exist. If the response contains delegation NS records, continue with those authoritative servers or use trace mode to inspect the chain.

Account for caching before judging a recent change

Recursive resolvers can cache positive answers, referrals, and negative answers. A record added after an NXDOMAIN response may not appear through every resolver immediately because the earlier negative result can remain cached. Compare the authoritative answer with multiple recursive resolvers and read the relevant TTL values. Repeatedly editing the zone does not force third-party caches to expire sooner.

If every authoritative server returns the new data but one resolver does not, the remaining problem may be cache age or resolver behavior. If authoritative servers disagree, correct zone distribution and serial consistency before troubleshooting recursive caches.

A reliable diagnostic sequence

1. Confirm the exact server in the SERVER line.
2. Read status, then the aa, rd, and ra flags together.
3. Decide whether the selected server should be authoritative, recursive, or both for this client.
4. Repeat intentional authoritative tests with +norecurse.
5. Compare with the intended recursive resolver and query the authoritative servers directly.
6. Only then change recursion policy, access controls, forwarding, or client DNS settings.

Authoritative references

The BIND 9 DNSSEC guide includes an authoritative response with this exact warning and explains the aa and ra distinction. The BIND dig manual documents +recurse, +norecurse, and the response flags used during testing.