Split-horizon recipe: a LAN-address primary should ride the tunnel link alone, without a public fallback #167
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The Proton desktop app's custom-DNS setting ran the same split-horizon config (AdGuard at 192.168.0.205 as the tunnel link's DNS) without any of the trouble #118/#166 document — and the installed app source shows the one structural difference: custom DNS is applied as the only server on the tunnel connection (dns-priority -1500, ignore-auto-dns, no fallback, no explicit search domain).
With a single server, resolved's sticky failover (#95) has nowhere to strand: a transient failure is a failed query plus a same-server retry — self-healing, no watchdog needed, no cache flushes, no flap. Our [alt_dns1, alt_dns2] pair on the tunnel link is what turns a blip into strand→re-pin→flush→flap (#166), and when the primary degrades persistently (#118) the pair makes it strictly worse than having no fallback at all.
Proposal: when alt_dns1 is a private/LAN address and a tunnel is up, set it alone on the tunnel link — drop alt_dns2 from that link. Accepted trade-off: local resolver down means host DNS down until it recovers, instead of silent public answers for split-horizon names — the noisier failure is the correct one here. The #95 watchdog becomes unnecessary on that link; #166's damping still applies wherever a pair remains.
🤖 Generated with Claude Code