Skip to content

v2.2.0 — resolver flush on the remaining WARP paths

Choose a tag to compare

@doug445 doug445 released this 23 Aug 12:07
· 9 commits to main since this release

2.1.0 fixed the resolver flush in warp-tray and stopped there. Auditing every path in the suite that changes WARP state turned up three more that needed it.

Fixed

netmaster warp off, warp on and warp reset now flush the resolver.

off and on each have two branches: one delegating to warp-killswitch, and a fallback for when the killswitch isn't installed. The killswitch branches were already covered — warp-killswitch restarts systemd-resolved, and a restart drops the cache and the learned per-server feature grades together. The fallback branches, and the whole of reset, brought the tunnel up or down and left the cache untouched — which is exactly the failure 2.1.0 set out to fix.

Verified in dry-run that all three emit the flush, and that every warp-cli connect in the file is now followed by either flush_resolver or a systemd-resolved restart.

Audited and already correct

Recorded so nobody re-checks them:

Path Why it was already fine
warp-killswitch down / up restarts systemd-resolved directly
netmaster fix (S5/S6 ladder) restarts systemd-resolved at S6
dns-toggle restarts the resolver and resets server features (2.1.0)
checkdns read-only
netcheck its resolvectl flush-caches is unrelated — it provokes a real upstream round-trip so the DoT probe isn't answered from cache

Background

Bringing the WARP tunnel up or down kills every DNS lookup in flight over it. Those fail DNSSEC validation with failed-auxiliary — the transport carrying the DS/DNSKEY chain vanished mid-lookup — and systemd-resolved caches the failure. Routing is fine immediately afterwards; only the cache is stale, and it reads as "no internet" until something clears it.