Config Delivery: How a Broken Subscription Locks a User Out
Any service that hands out settings over a link has a state it cannot leave on its own. It arises rarely, but escaping it costs more than preventing it. The essence of it is that the delivery channel coincides with the broken one: restoring access requires the very access you do not have.
Here is the mechanics of that state and what closes it.
The circular trap#
The shape is unpleasantly simple.
1. the subscription domain is blocked
│
▼
2. the client cannot fetch updated settings
│
▼
3. the client runs on its CACHED configuration
│
▼
4. the cached addresses stop working
│
▼
5. fixing it requires updating the settings
│
└──────► back to step 2
The key property: the service is healthy, the server runs, a new configuration exists — and all of it is useless, because the delivery channel coincided with the channel that broke.
What the user sees is not “update your settings” but simply “nothing works”. They have no reason to suspect delivery specifically.
Why is this not rare?#
It is tempting to treat the scenario as unlikely. In practice it grows out of natural economy. Each decision is sensible on its own, and the circle emerges only from their combination.
| Design decision | Looks like | Turns out to be |
|---|---|---|
| Subscription on the same domain as the site | saving a domain | one block breaks both |
| Updates only through the app | simplicity | the channel coincides with what breaks |
| A single delivery channel | less to support | a point of failure with no way around |
Each decision is sensible on its own. The circle emerges from their combination, and the combination assembles itself.
The mechanism that closes it#
There is a simple remedy: a header in the subscription response telling the client the new address to use for subsequent requests.
On its next refresh the client receives, alongside the settings, an instruction on where to go next, and switches on its own.
NORMAL REFRESH
client ──► domain-A/subscription
│
├── settings
└── header: next address is domain-B
│
client remembers domain-B ◄─────────────┘
AFTER DOMAIN-A IS BLOCKED
client ──► domain-B/subscription ✓ already knows where to go
The circle is broken not by fixing the blocked domain but by handing out the next address in advance.
The condition without which the mechanism is useless#
Here is the crucial detail, easily missed.
The header must point at a live backup address permanently, not be set at the moment of blocking.
The reason is obvious once stated: if the backup address is announced when the primary is already unreachable, the announcement is not delivered. It would travel over the channel that is broken.
Hence the rule: the backup address is announced before the incident. A mechanism switched on in response to a block no longer works.
And a corollary about ordering: an empty or dead backup address is worse than none — it leads clients somewhere that does not exist, irreversibly. First the backup is stood up, then it is announced.
Channel independence#
The second requirement, verified less often than it should be.
A backup channel is worth exactly as much as it does not share the fate of the primary. It helps to lay out the levels at which channels can coincide:
| Level | Coincides? | What happens on failure |
|---|---|---|
| Domain name | usually not | the whole point of the backup |
| Registrar | often yes | a registrar problem takes both |
| DNS provider | often yes | a provider problem takes both |
| Hosting | sometimes | depends on placement |
| Certificate, ACME account | often yes | account compromise takes both |
The bold rows are where a “backup” typically turns out to be a copy. Different domain, everything else shared.
Full independence is expensive and not always warranted. But knowing at which level your channels coincide is mandatory — otherwise the backup manufactures false confidence.
Signed configurations#
A related topic: since the configuration arrives from outside, its authenticity becomes a question.
If a client accepts settings from an address it was told about, then substituting the address substitutes the settings. Cryptographically signing configurations and pinning the key on the client side closes that class: the client accepts only what a known key signed, regardless of where it came from.
That is what makes the migration mechanism safe: being able to tell a client “go here now” without signatures would be being able to send it anywhere.
What to check in your own service#
A short list applicable to any solution that distributes settings:
Is the subscription domain separated from the site domain. If not, one block breaks both access and the means of restoring it.
Does a backup address exist and is it announced in advance. Not “we plan to register one” but working and already handed out.
At which level the channels coincide. Registrar, DNS provider, ACME account — the three places where a backup most often turns out not to be one.
Is the configuration signature verified. Otherwise the migration mechanism becomes a vector itself.
Conclusion#
Settings delivery is not an auxiliary function but part of the access path. If it shares the fate of the channel it is supposed to restore, the service acquires a state it cannot leave under its own power.
The remedy is cheap: a backup address, announced in advance and permanently. Only one thing is expensive — announcing it after you need it.
Terms#
- Circular delivery trap - the state where restoring access requires the very access you do not have.
- Migration header - a field in the subscription response telling the client the next address to use.
- Channel independence - the absence of shared failure points between the primary and backup delivery paths.
FAQ#
Why can a backup address not be announced after the block?#
Because the announcement would travel over the channel that has already failed. The backup must be handed out in advance and permanently.
Is registering a second domain enough?#
No. Channels frequently coincide at the registrar, the DNS provider or the certificate-issuance account.
Why sign configurations?#
Otherwise substituting the address substitutes the settings: the client accepts whatever arrives from the address it was told about.
Further reading#
- Whitelists: What They Are and Why They Change
- Chains and Multihop
- Upgrades as a Source of Failure
- Walk the route from setup to diagnosis in the GigaTap VPN guides.
- Pick your next step with the VPN start helper.
- Device-specific profile import lives in the client setup hub.