A VPN domain rule breaks when a CDN changes its addresses
One DNS answer is a snapshot, not an inventory. Three conditions decide whether a name-based rule or an explicit prefix fits a CDN-backed service.
You copy the address from one lookup into your routing rule, the site works, and a week later it does not. Nothing about the rule changed. The service moved to a different edge address, the client resolved a different hostname, or the session switched to IPv6. The decision in front of you is whether a name-based rule or an explicit range is the right instrument for this service, and three conditions settle it. What follows separates the name from the address, because only one of them is stable.
Why one lookup is not an inventory
A content-delivery network answers with an address chosen for the resolver, the region and the moment. Ask twice from different networks and you can get different answers. Ask once and treat the answer as the service's address list, and the rule you write is a snapshot rather than a rule. That is the whole problem with treating a DNS answer as configuration.
There is a second gap. One visible hostname rarely covers the whole application, because login, media and API traffic often use separate names. A rule built from the address bar's hostname can cover the page and miss the video, which reads as a partial failure rather than a routing error.
The third gap is the address family. A v4-only rule says nothing about the AAAA record the client may prefer.
Three conditions that decide domain rule or ranges
First, does the service publish a stable set of prefixes you can own and document? If it does, explicit ranges are honest and cheap. If it does not, a domain rule is the only mechanism that can follow the service.
Second, does your client's domain mechanism refresh? A rule that resolves once at connect time and never again is a snapshot with better branding. Third, does the mechanism cover subdomains and both address families, or only the names you typed?
Answer those three and the choice is usually obvious. Guessing produces a rule that works in testing and fails in production.
Test a session, not a page
Load the page, then perform the operation that matters: sign in, start playback, upload a file. Each of those can reach a different host, and the one that fails is the one your rule missed.
Enumerate what the session actually contacts rather than what the page displays:
dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5Keep the resolver visible during the comparison, because a rule that works from one resolver and fails from another is telling you about the CDN's answer, not about the tunnel. A short TTL also means the answer you recorded has a shelf life.
What each mechanism actually covers
The two mechanisms look interchangeable in a settings page and behave differently underneath.
| Mechanism | What it matches | How it fails |
|---|---|---|
| Domain rule | Names the client resolves, then their addresses | Misses subdomains, or goes stale when refresh is off |
| Address route | A prefix you wrote down | Keeps matching an address the service has left |
A kernel address route matches prefixes. It has no idea what a hostname is, so it cannot follow a service that changes addresses. A domain rule resolves names and routes the result, which follows the service but depends on the resolver, the refresh behaviour and the client's handling of subdomains, so a rule that follows names has to be tested with the resolver the client actually uses.
Neither one is a superset of the other, which is why mixing them without a note produces confusion later.
Recheck after the service changes
After a client update or a service change, run the same session test again. A previously working address list is evidence about that period, not a permanent inventory of the service's infrastructure.
Write down which mechanism covers which hostname, and the date you last verified it.
That note is the difference between a rule you can defend and a rule nobody dares touch. If the service publishes its own prefix list, use it and cite the date. If it does not, say so, and keep the domain rule with its refresh behaviour written next to it.