jochen
0ab47b9417
The laptop's VPN client replaces the mesh's resolver file on every connect and the node-engine writes it back minutes later, so either the mesh's names or the corporate ones fail for whole sessions. Measure how the client sets DNS and weigh how names can be routed by domain without breaking ADR 0223's one-answer rule.
3.9 KiB
status, initiated, touches
| status | initiated | touches | |||||
|---|---|---|---|---|---|---|---|
| active | 2026-10-07 |
|
033 — Split DNS with a VPN client
What is investigated
How a machine of the mesh resolves three kinds of name at once — the mesh's (*.internal), a
corporate network's reached through a VPN client, and public ones — when the VPN client writes
/etc/resolv.conf itself.
ADR 0223 gives every machine one resolver file listing the mesh's two resolvers and nothing else, written by the holder of the machine's uplink (ADR 0117). On the laptop, a corporate VPN client replaces that file when it connects, with its own servers and eight search domains. The node-engine finds the file changed and writes the mesh's back on its next reconcile. From then on, for the rest of the session, the corporate names do not resolve; in the minutes before it, the mesh's names did not. Neither program knows the other exists.
The questions:
- How the VPN client sets DNS on Linux: does it overwrite the file, use
resolvconf, or talk to systemd-resolved or NetworkManager; what it backs up and restores; whether it re-asserts its file. - What it pushes: how many servers, which domains, over which link, and what routes.
- How often the two collide on the live mesh, and what each collision costs.
- The options: per-link routing in systemd-resolved, adding the VPN's servers to the mesh's file, forwarding the corporate domains from the mesh's resolvers, standing back while the VPN is up, and any other — and what each means for ADR 0223 and for the machines that run no VPN.
Why
The operator uses the VPN for work, every working day. While it is up the laptop is either cut off from the mesh (agents saw lookups fail) or cut off from the corporate network, depending on which program wrote the file last. A rule of the mesh that a machine's own work program silently breaks — or that breaks the machine's owner's work — is a rule that cannot be kept as stated.
A sibling decision proposed alongside this effort, ADR 0241 (machine network health), makes the node-engine detect and report an outside writer of the resolver file. That says the fault; this effort asks how it stops being one.
What it touches
ADR 0223's rule that a machine lists only the mesh's resolvers, and its rejection of a local forwarder; ADR 0117's list of what an uplink holder declares; the networkmanager module (the uplink holder on the laptop); the node-engine's correction of a file changed on the machine; connectivity §2.
Where it stands
Evidence gathered read-only on the laptop and options weighed, 2026-10-07:
- 01 — The evidence: the VPN client always moves the resolver file aside and writes its own (two servers, eight search domains), restores its backup on disconnect, and never re-asserts; it does not configure systemd-resolved or NetworkManager per link on this machine. In every one of the nine sessions since the node-engine's journal begins, the node-engine wrote the mesh's file back within 1 s to 3.5 min; once the VPN client's restore of a stale backup was itself corrected.
- 02 — Options: six, from systemd-resolved per-link routing to replacing the VPN client.
- 03 — Recommendation: on a machine that declares a VPN client, the uplink's holder runs systemd-resolved as a local router on the machine's private address, and hands it the VPN's servers and domains the moment the VPN client writes them; every other machine is unchanged. A proposed decision text with how each rule is checked.