Blank alt_dns2 should mean deliberate single-server DNS #167

New issue

Closed

opened 2026-08-24 23:10:06 -04:00 by mysticalsoap · 0 comments

mysticalsoap commented

2026-08-24 23:10:06 -04:00

Owner

Re-scoped from the original private-address proposal (see below): instead of aqomui deciding when a primary rides alone, the user decides — by clearing the second alternative-server field.

The single-server path already exists internally: dns_2=None is handled by set_dns, repin_dns_primary, dnsmasq, and the watchdog gate (if not server_2: return), and the WireGuard config parser produces it for one-server configs. But a blanked GUI field saves "", not None, and the empty string passes every is not None check: it reaches systemd-resolve --set-dns=, the whole command fails, and the tunnel comes up with no DNS on the link at all — no servers, no ~. routing domain. Same breakage in the dnsmasq (--server=) and resolv.conf (nameserver ) paths.

Fix: normalize blank/whitespace fields to None at the config boundary. A cleared fallback then gives exactly the Proton-app behavior on the tunnel link — one server, resolved's sticky failover has nowhere to strand, the #95 watchdog never starts there — as an opt-in, with nobody's existing pair changed. #166's damping covers everyone who keeps a pair.

Original proposal (superseded): when alt_dns1 is a private/LAN address and a tunnel is up, set it alone on the tunnel link, dropping alt_dns2 from that link. Rejected as too opinionated — an address-class heuristic forces the trade-off on every user with a LAN primary, where a blank field expresses the same intent explicitly.

🤖 Generated with Claude Code

Re-scoped from the original private-address proposal (see below): instead of aqomui deciding when a primary rides alone, the user decides — by clearing the second alternative-server field. The single-server path already exists internally: `dns_2=None` is handled by `set_dns`, `repin_dns_primary`, `dnsmasq`, and the watchdog gate (`if not server_2: return`), and the WireGuard config parser produces it for one-server configs. But a blanked GUI field saves `""`, not `None`, and the empty string passes every `is not None` check: it reaches `systemd-resolve --set-dns=`, the whole command fails, and the tunnel comes up with **no DNS on the link at all** — no servers, no `~.` routing domain. Same breakage in the dnsmasq (`--server=`) and resolv.conf (`nameserver `) paths. Fix: normalize blank/whitespace fields to `None` at the config boundary. A cleared fallback then gives exactly the Proton-app behavior on the tunnel link — one server, resolved's sticky failover has nowhere to strand, the #95 watchdog never starts there — as an opt-in, with nobody's existing pair changed. #166's damping covers everyone who keeps a pair. --- *Original proposal (superseded): when alt_dns1 is a private/LAN address and a tunnel is up, set it alone on the tunnel link, dropping alt_dns2 from that link. Rejected as too opinionated — an address-class heuristic forces the trade-off on every user with a LAN primary, where a blank field expresses the same intent explicitly.* 🤖 Generated with [Claude Code](https://claude.com/claude-code)

mysticalsoap added the

architecture

label

2026-08-24 23:10:06 -04:00

mysticalsoap referenced this issue

2026-08-26 12:12:36 -04:00

alt-DNS at a local address intermittently unreachable on the tunnel link #118

mysticalsoap referenced this issue

2026-08-26 13:39:29 -04:00

alt-DNS at a local address intermittently unreachable on the tunnel link #118

mysticalsoap changed title from ~~Split-horizon recipe: a LAN-address primary should ride the tunnel link alone, without a public fallback~~ to Blank alt_dns2 should mean deliberate single-server DNS

2026-08-26 14:59:14 -04:00

mysticalsoap referenced this issue from a commit

2026-08-26 14:59:35 -04:00

add: a blank fallback DNS field means single-server

mysticalsoap referenced this issue from a pull request that will close it,

2026-08-26 14:59:46 -04:00

add: a blank fallback DNS field means single-server #171

mysticalsoap closed this issue

2026-08-27 11:36:51 -04:00

mysticalsoap referenced this issue

2026-09-16 20:39:18 -04:00

fix: stop logging a literal None for single-server DNS #220