Alternative-DNS fallback is one-way: resolved sticks on the second server

mysticalsoap commented

2026-08-20 15:37:07 -04:00

Owner

Found live while verifying #34's recipe. systemd-resolved switches away from a failed server but never returns while the substitute keeps answering — and re-applying an identical server list (which set_dns does on every reconnect) does not reset its selection, only a changed list does.

Observed twice in one afternoon: a ping-restart reconnect blipped queries to the primary for about a second, resolved rotated to the fallback, and the system silently served public answers for split-horizon names from then on. The user-visible failure is nasty precisely because nothing looks broken — e.g. LAN Jellyfin resolves to its public address and streams transcode over the WAN for no apparent reason, with no obvious way to notice or fix it.

For a primary/fallback pair the second slot must be a true fallback: used while the primary is down, abandoned as soon as it answers again.

Fix shape:

A service-side watchdog while a tunnel with alternative DNS is up: read the link's current server (resolve1 D-Bus CurrentDNSServer — no text parsing), and when it is not the primary, probe the primary directly with one UDP query; if it answers, force re-selection (set the primary alone, then the pair) and flush caches so the fallback's answers don't linger. Bounded staleness of one check interval instead of forever.
--strict-order for the bypass dnsmasq, which otherwise has its own favour-the-working-server stickiness.
The no-resolved /etc/resolv.conf path already has true priority semantics (glibc tries nameservers in order per query) and needs nothing.

Found live while verifying #34's recipe. systemd-resolved switches away from a failed server but never returns while the substitute keeps answering — and re-applying an identical server list (which set_dns does on every reconnect) does not reset its selection, only a *changed* list does. Observed twice in one afternoon: a ping-restart reconnect blipped queries to the primary for about a second, resolved rotated to the fallback, and the system silently served public answers for split-horizon names from then on. The user-visible failure is nasty precisely because nothing looks broken — e.g. LAN Jellyfin resolves to its public address and streams transcode over the WAN for no apparent reason, with no obvious way to notice or fix it. For a primary/fallback pair the second slot must be a true fallback: used while the primary is down, abandoned as soon as it answers again. Fix shape: - A service-side watchdog while a tunnel with alternative DNS is up: read the link's current server (resolve1 D-Bus `CurrentDNSServer` — no text parsing), and when it is not the primary, probe the primary directly with one UDP query; if it answers, force re-selection (set the primary alone, then the pair) and flush caches so the fallback's answers don't linger. Bounded staleness of one check interval instead of forever. - `--strict-order` for the bypass dnsmasq, which otherwise has its own favour-the-working-server stickiness. - The no-resolved /etc/resolv.conf path already has true priority semantics (glibc tries nameservers in order per query) and needs nothing.

mysticalsoap referenced this issue from a commit

2026-08-20 15:41:29 -04:00

fix: return DNS selection to the primary once it answers again

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

2026-08-20 15:41:54 -04:00

fix: return DNS selection to the primary once it answers again #96

mysticalsoap closed this issue

2026-08-20 16:36:41 -04:00

mysticalsoap referenced this issue from a commit

2026-08-20 16:36:42 -04:00

fix: return DNS selection to the primary once it answers again

mysticalsoap referenced this issue from a commit