Split Tunnel Excludes the Browser, Not Its DNS Queries

Browser excluded from the tunnel, public-IP page confirming that its traffic leaves by the home connection, and the internal wiki still will not open. Name resolution went somewhere else, and that somewhere is usually the resolver the VPN configured. Data path and resolver path are separate decisions in most split-tunnel designs. Check which one the browser actually used before calling the exclusion broken.

Data Path and Resolver Path Split

An exclusion removes an application's packets from the tunnel, which is a routing and firewall decision on the data path. Name resolution is a different lookup: a process asks the system's resolver, and that resolver decides which server receives the question.

Both can be intentional and different. A work deployment may keep internal namespaces on the corporate resolver while sending selected public browsing outside the tunnel, precisely because internal names do not resolve anywhere else. The confusing case is the reverse: a public site failing because the browser never asked the resolver the deployment expected. Record the route and the resolver separately, and half the arguments disappear.

Find Which Process Asks the Question

A browser can use the system resolver, its own encrypted DNS service, or a resolver the operating system assigns per network. The first follows platform policy, the second bypasses that policy entirely, and the third depends on which link the query is routed to.

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

Read the effective configuration before testing: which links carry DNS servers, which namespaces they claim, and whether a per-name policy overrides the default. On Linux, split DNS uses routing domains; on Windows the name resolution policy table does the same job for namespaces. Neither is visible from a leak-test page.

Decide Which Resolver Should See Which Name

Write the intended mapping before changing anything: internal names to the corporate resolver, public names to whichever service policy allows, and exceptions with an owner. Without that list, every leak-test label becomes a policy argument nobody can settle.

Then check the browser's own setting, because encrypted DNS in a browser is applied before the operating system receives the query. A user who enabled it to get around a captive portal has quietly overridden the resolver the deployment chose. That is a configuration decision rather than a leak, and it deserves a decision rather than a blocklist.

Do not rewrite every DNS field to make one test label turn green. The label describes one query from one process at one moment.

Verify Query and Connection Separately

Test the two paths independently. The connection test shows the data route, and the resolver test shows who received the name.

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

Query the resolver explicitly as well, so a failure can be attributed to the server rather than to the path. Then restart the browser and repeat, because applications cache negative answers and a stale failure looks persistent.

After an approved change, record the data route and the resolver recipient as two separate lines with the date. If the behaviour returns at the next reconnect, the profile that supplies it is the thing to fix, not the browser.