How to Read Per-Link VPN DNS Routing From resolvectl status
resolvectl status shows servers, domains and the default route per link. Read them together, then query the name and note which link answered.
Run resolvectl status and you get a wall of per-link blocks, each with its own servers and its own domain line. The line that decides routing is the domain list, not the nameserver address, because the local stub forwards every query to whichever link claims the name. Read those claims before reading the answer, then query the name and check which link produced it. A wrong answer from the right link is a different problem from a right answer from the wrong one.
What each per-link block tells you
Every block lists the servers the resolver will use for that interface, the domain list, and whether the link is the default route. The domain list is a set of claims, and the resolver applies longest-suffix match: a query for host.corp.example is claimed by a link carrying corp.example ahead of one carrying only the default route. Two links claiming the same suffix leave the outcome to priority and ordering, which is why duplicates deserve attention first. The current server line shows which of the listed servers is in use at that moment.
A stub address such as 127.0.0.53 in /etc/resolv.conf says only that the stub is in front. It does not name the upstream that answered, which is why a diagnosis based on resolv.conf alone stalls.
Read the three kinds of domain entry correctly
| Entry | What it claims | Usual mistake |
|---|---|---|
| corp.example | routing domain and search suffix: names under it go to this link, and the string is appended to bare names | removed because routing seems to work anyway |
| ~corp.example | route-only: names under it go to this link, but the suffix is not appended | assumed to be required for routing |
| ~. | default route: claims queries no other link matches | left active on a split profile, so public names follow the tunnel |
The tilde changes search behaviour, not routing. An entry without a tilde is both a routing domain and a search domain, so names under it are sent to that link and single-label names get the suffix appended. A tilde entry routes the same suffix while keeping it out of the search list. That is why removing a tilde changes which bare names resolve, and why a missing tilde is a search problem rather than a split-DNS failure.
The default route entry claims everything no other link matches. A full-tunnel profile usually wants it and a split profile usually does not, because public names then travel to the private resolver and may fail there. Read the table against the profile's intent instead of copying flags between profiles. When two links claim the same suffix, settle the priority question before editing anything else.
Query a name and see which link answered
The query subcommand prints the address, the protocol and the link or scope that produced the answer. Test one name that should be claimed by the private suffix and one ordinary public name, then compare the reported sources. If the private name answers from the wireless link, the claim is missing or the tunnel is down; if a public name answers from the tunnel on a split profile, the default route is too broad. Those two failures look identical in a browser and opposite in this output.
resolvectl status
resolvectl query host.corp.exampleWatch the reported protocol too, because a cached or host-file answer can arrive without any upstream being consulted. An answer from cache proves the name resolved at some point, not that the current policy routes it correctly.
Keep name routing apart from packet routing
A resolver decision does not create a path. The chosen server still needs a route to its address, and the returned address still needs a route into the private network, so a correct DNS policy can coexist with a connection that never opens. When a name resolves and the application fails, inspect the address and the route instead of changing DNS again. Name resolution and reachability are two questions with two different owners.
Applications can bypass the system resolver entirely through their own secure DNS setting or a bundled resolver. The resolvectl result describes the system path, and a browser that ignores it will disagree with every test you run. Check that setting before concluding the policy is broken.
Record the address the name resolved to alongside the link. A correct name pointing at the wrong address is a record problem rather than a routing one.
Re-check after the link changes
A reconnect or a wireless switch rebuilds link state, and a network manager may reinstall its domains and servers over anything set by hand. Query the same two names afterwards and compare with the recorded baseline. If a manual edit disappeared, the fix belongs in the connection profile rather than in a shell command. Recording before and after is what makes that visible.
Share only the names and server context the report needs, since internal suffixes disclose topology. The systemd-resolved documentation on domain routing covers the longest-match rule and the tilde behaviour, and reading it once prevents most of the table mistakes above: systemd-resolved query routing.