Domain-Based VPN Routing vs IP Routes: Which One Fits?
A hostname in a split-tunnel box is not a route. Compare domain rules and explicit prefixes on refresh, subdomain scope and what happens when DNS changes.
An IP route matches an address prefix, and the kernel applies it without asking further questions. A domain-based VPN rule matches a name, which means something in the stack has to decide which addresses that name currently means and keep the decision current. Those are different mechanisms with different failure modes, and vendors use the same word for both. Comparing them on feature lists misses the point; compare them on what happens when the answer changes.
The useful split is between a rule that resolves and a rule that does not.
What each rule actually matches
A prefix rule matches destination addresses in a routing table. Nothing resolves, nothing expires, and the match is exact for every packet. A domain rule matches an application's request for a name, which RFC 1034 defines as a tree of labels rather than an address. Some products resolve the name once and install the resulting addresses as routes, which makes the rule an IP rule with a refresh timer attached.
Know which of those you have before you debug it, because the failure looks completely different in each case.
Where the domain rule lives in the stack
If the product implements domain rules through a local proxy, traffic has to reach that proxy, and applications that ignore the system proxy bypass the rule entirely. If it implements them by resolving names and adding routes, the addresses are only as fresh as the last refresh. If it hooks the resolver, DNS behaviour becomes part of the routing policy, and a fallback resolver can quietly undo it.
Read the vendor's model rather than the settings label. Two clients with a box called Split Tunnel can be doing three different things.
Compare what breaks
Three things break differently. Address churn: a CDN hostname can resolve to a different address set within minutes, so a copied list ages badly. Subdomain scope: a rule for example.com may or may not cover api.example.com, and the documentation is usually explicit about which. Resolution failure: when the resolver fails, a resolving client may fall back to tunnelling the traffic, or to sending it direct.
Only the second one is a configuration question. The other two are design questions about how much the product is willing to guess.
| Behaviour | Prefix rule | Domain rule |
|---|---|---|
| Match basis | destination address | requested name or resolved addresses |
| Staleness | none | depends on refresh policy |
| Subdomain scope | not applicable | product-defined |
| Resolver outage | unaffected | product-defined fallback |
| Where to debug | routing table | client log plus resolver state |
When the prefix is the better answer
For a stable private subnet, an explicit prefix is clearer, faster and easier to audit. It also survives a resolver outage, because nothing has to resolve. Reach for a domain rule when the service is hosted, when addresses rotate, or when you genuinely cannot enumerate the destination set. Do not reach for it just because the hostname is the thing you happen to know.
A guessed static list is the worst of both: it looks maintained, and it silently misses traffic the day the provider adds a host.
Verify with a fresh request
Test with a cold request after a normal reconnect, because a cached page may never touch the rule. Resolve the name, then check where the connection actually went. dig +short app.example.com gives the current address set, and the client's connection listing tells you which interface carried the flow.
Repeat after the refresh interval the product documents. If the address set drifts and the rule does not follow, you have found the real behaviour.
Keep resolver policy separate as well. A domain rule needs correct name data, but it does not by itself decide which resolver answers the query.