v2.2.0 — resolver flush on the remaining WARP paths
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.