Recursion Not Available: A DNS Policy, Not a Broken Tunnel

The internal name resolves, and the same server answers an external name with a refusal about recursion. That combination is not a contradiction. Publishing its own zones and resolving the whole internet are separate services a server may offer, and it can do the first without the second. Treat the refusal as a policy statement, then check whether the policy matches the design.

A Refusal and a Timeout Are Different Answers

Record the name, the query type, the responding server, the status and the records returned. A recursion warning does not automatically invalidate an authoritative answer that arrived with it. Write the status down before you interpret it. A status reconstructed from memory an hour later is a different fact.

The DNS header carries a request for recursion and an indication of whether the server offers it, and the protocol specification keeps those flags separate from the answer data. That is why a response can be useful and still carry a complaint. A timeout, a negative answer and a refusal are three different results. Each one points at a different layer, and only the refusal is the server telling you about policy.

Read the status code first, then decide whether the warning matters for this query. An authoritative answer that names the zone is usable even when the recursive bit is refused. A refusal with no answer is a policy result, not a broken packet path.

What the Resolver Recorded as Your Source

The client may arrive from an address pool outside the server's permitted recursive ranges, or a translation may make it look like a gateway. The client's own adapter address is not evidence about what the resolver received. Ask the server's administrator for the observed source rather than inferring it from your side of the path. The two addresses can differ at every hop that translates.

Query the same name from the client and from a host the server already trusts. The difference between the two answers is the source condition, and it is more useful than either answer alone.

dig +short host.corp.example
dig +short example.com

If the deployment wants recursion for VPN clients, the administrator authorizes the appropriate source range through the server's own controls. Opening recursion to every network to make one test pass is a much larger change than the one being tested. Write the authorized range next to the rule, because the next reviewer will ask which sources the policy was meant to serve. A source range without an owner is how a temporary test becomes permanent.

Split DNS Is a Design, Not a Fault

Some deployments send only work domains to the private resolver and everything else to a different approved resolver. That is a query-routing design, and it is not evidence that the private server needs a looser policy. Under that design, an external name failing through the private resolver is the intended result rather than a fault. The refusal is the design working, not a symptom to suppress.

A public resolver can restore browsing while breaking internal names or sending private queries somewhere they should not go. Write the intended behaviour down before changing any resolver address.

Verify the Policy With Two Queries

After the intended correction, query a permitted private name and an external name from the actual client. What comes back should be what the policy promises, not just a quieter diagnostic. Record the responding server with each answer, then compare the pair with the policy. The comparison is the test, and a single successful lookup is not.

resolvectl query host.corp.example
resolvectl query example.com

If the private name works and the public name is refused, the policy is doing what it says. If the private name fails too, the problem is the zone, the route or the source authorization, and recursion is a distraction. Both outcomes are useful, and each one rules out half the remaining hypotheses.

Read the Refusal as Evidence

A refusal is an answer. It means the server received the query and declined to perform the requested work, which is different from a packet that never arrived. That distinction is the whole diagnosis. Log it as a response rather than as a connectivity failure.

That distinction tells you where to look: the server's logs, its access policy and the source it recorded. A firewall change cannot fix a policy refusal, and a policy change cannot fix a missing route. Keep the two hypotheses apart until one of them has evidence.

Write the outcome and the policy owner into the ticket, so the next person starts from the decision rather than the warning. Name the source range that was authorized and the two names you tested. A ticket with those three facts can be re-run; one that says "recursion is broken" cannot.