Your VPN domain in dnsmasq is not a zone transfer

You look for the corporate zone in the client's dnsmasq configuration, do not find it, and conclude that the VPN failed to push its domain. What was pushed is a routing hint, not a zone. The client records the domain and the resolver that should answer for it, and the managed backend turns that into conditional forwarding. Looking in the wrong place produces a confident and entirely false diagnosis.

What the client accepted is not what the gateway offered

A gateway can offer a resolver, a domain and the route needed to reach that resolver, and the client can accept all three or none of them. An imported profile, a helper script or a policy that ignores pushed options can leave the accepted set empty while the server side looks correct. Start from the client's recorded state rather than the server's configuration, because that state is what the resolver actually receives. If the accepted domain is missing, nothing downstream will matter. Check the connection's DNS properties before you inspect any cache.

That distinction explains most reports of a domain that never arrived. It was offered, and it was not applied.

Two kinds of domain entry

A connection can carry ordinary search domains and route-only domains, and the second kind begins with a tilde. A search domain both routes queries and lets short names expand, which is convenient on a workstation and surprising on a server. A route-only domain states that queries for that suffix should go to specific servers without changing how short names resolve. Writing the same domain both ways is not redundancy, because the two entries do different jobs.

For a private namespace the route-only form is usually the one you want. It keeps the corporate suffix pointing at the corporate resolver and leaves everything else alone.

localhost in resolv.conf is not a bug

When a local caching resolver is in use, the system file points at the loopback address and nothing else. That entry identifies the local listener, not the upstream servers the manager handed to it. The corporate address will legitimately be absent from the file.

Replacing that entry with a public resolver is the classic mis-fix. It restores public name resolution and discards the conditional policy in the same edit.

Do not confuse the backends

A managed dnsmasq instance and a system resolver are different programs with different configuration and different status views. A status command for one reports nothing useful about the other.

Identify which backend the manager is configured to use, then read that backend's generated configuration rather than a distribution-wide file that happens to exist. The manager writes its own instance configuration and supports custom options for that instance, so editing an unrelated global file changes nothing and looks like a change with no effect. Starting a second daemon on port 53 is worse than useless, because now two programs disagree about who owns the port. Establish the owner first, then edit where that owner reads.

Test the namespace, not just the answer

Query one permitted private name and one public control name through the application's normal path. A direct query against the corporate server proves the record exists; it does not prove the client selected that server. The second query is the one that tests policy.

Then repeat after a reconnect and after a disconnect. The association should follow the connection's lifecycle, and the private names should stop resolving when the tunnel is gone rather than falling back to a public resolver that answers for the same suffix. If they do fall back, you have found a leak, which is a different defect from a broken lookup. Write down which backend ran, which domains were applied, and what each query returned.