fix: keep the bypass tunnel's DNS out of resolved #215

Merged
mysticalsoap merged 1 commit from fix/bypass-dns-59 into trunk 2026-09-16 21:24:33 -04:00
Owner

Problem: With double-tunnel mode up, tunnel_up applied the alternative servers to the bypass link with the ~. routing domain - so both tunnels claimed the default route domain and resolved was free to answer unqualified system queries through either exit (#59).

Fix: Only the main role touches resolved, the same rule the hop has followed since #211's era. The bypass link needs no resolved entry at all: bypassed applications resolve through the bypass resolver (dnsmasq), whose upstreams the service already switches when a bypass tunnel is up. The role's dns fields still ride the state update for exactly that switching.

Verification: pinned by test (bypass CONNECTED emits its status, applies nothing to resolved); suite 538 passed. Live check: with main + bypass tunnels both up, resolvectl domain should show ~. on the main link only, a bypassed app should still resolve, and system DNS should stay on the main tunnel.

Closes #59.

🤖 Generated with Claude Code

**Problem**: With double-tunnel mode up, `tunnel_up` applied the alternative servers to the bypass link with the `~.` routing domain - so both tunnels claimed the default route domain and resolved was free to answer unqualified system queries through either exit (#59). **Fix**: Only the main role touches resolved, the same rule the hop has followed since #211's era. The bypass link needs no resolved entry at all: bypassed applications resolve through the bypass resolver (dnsmasq), whose upstreams the service already switches when a bypass tunnel is up. The role's dns fields still ride the state update for exactly that switching. **Verification**: pinned by test (bypass CONNECTED emits its status, applies nothing to resolved); suite 538 passed. Live check: with main + bypass tunnels both up, `resolvectl domain` should show `~.` on the main link only, a bypassed app should still resolve, and system DNS should stay on the main tunnel. Closes #59. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
fix: keep the bypass tunnel's DNS out of resolved
All checks were successful
ci / test (pull_request) Successful in 23s
e8e444ff7c
tunnel_up applied the alternative servers to the bypass link with the
"~." routing domain, so a second tunnel claimed the default route
domain alongside the main one and resolved was free to answer system
queries through either exit. Bypassed applications never needed the
entry - they resolve through the bypass resolver (dnsmasq), whose
upstreams the service already switches to the bypass tunnel.

Only the main role touches resolved now, same rule the hop already
followed.

Closes #59

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
mysticalsoap force-pushed fix/bypass-dns-59 from e8e444ff7c
All checks were successful
ci / test (pull_request) Successful in 23s
to b8045d737e
All checks were successful
ci / test (pull_request) Successful in 22s
ci / test (push) Successful in 26s
2026-09-16 20:50:42 -04:00
Compare
Author
Owner

Live-verified 2026-09-16: with main + OpenVPN bypass tunnels up, resolvectl shows the "." routing domain on tun_aqomui only - the bypass link carries no resolved entry - and bypassed resolution keeps working through dnsmasq (aqomui-bypass curl resolves and returns the bypass exit). First test round was against a build without the fix; both links claimed "." there, confirming the #59 bug live before the fix removed it. Ready to merge.

Live-verified 2026-09-16: with main + OpenVPN bypass tunnels up, resolvectl shows the "~." routing domain on tun_aqomui only - the bypass link carries no resolved entry - and bypassed resolution keeps working through dnsmasq (aqomui-bypass curl resolves and returns the bypass exit). First test round was against a build without the fix; both links claimed "~." there, confirming the #59 bug live before the fix removed it. Ready to merge.
mysticalsoap deleted branch fix/bypass-dns-59 2026-09-16 21:24:33 -04:00
Sign in to join this conversation.
No description provided.