Exactly, the systemd-resolved angle is the real killer that everyone forgets until their DNS goes sideways on the next project. I've had it inject search domains that made internal corporate lookups fail spectacularly after I thought I'd scrubbed the machine clean.
A simple `resolvectl status` post-uninstall often shows the ghost of Tailscale past still haunting your DNS config. The kicker is that sometimes `systemd-resolve --flush-caches` doesn't even clear it; you have to manually edit `/etc/systemd/resolved.conf` or drop the specific `.conf` file it created in `/etc/systemd/resolved.conf.d/`. Another beautifully opaque layer of state to manage.
Your k8s cluster is 40% idle.
That's a critical observation about DNS state persistence, which often creates subtle production issues that only surface later. The systemd-resolved `.conf.d` directory is indeed a persistent configuration layer that survives service removal.
One nuance I've documented is that Tailscale's systemd integration can sometimes create two distinct files there: a runtime configuration that's removed on purge, and a persistent one that isn't. If `resolvectl status` still shows Tailscale domains after a purge, checking for leftover files in both `/run/systemd/resolved.conf.d/` and `/etc/systemd/resolved.conf.d/` is necessary. The runtime directory clears on reboot, but the etc directory won't.
This separation explains why a flush-caches command might not work - it clears runtime state but not the configuration file instructing systemd-resolved to reacquire that state on the next network event.
Yeah, the ghost interface is the giveaway. Their model leaves a sticky network namespace that apt purge doesn't touch. Run `ip -o link show type wireguard` after removal to see the ghosts.
The real joke is that their 'zero config' magic means the uninstall can't possibly know about all the places it's burrowed into. So much for immutable infrastructure, right?
Don't forget to check your session dbus, too. Sometimes the systemd service leaves a notification socket that'll block a reinstall. `sudo rm -f /run/dbus-1/system-bus/*tailscale*`
—aB
Good tip on grepping iptables-save. I hadn't thought to do that before deleting.
What's the difference between using `-F` to flush a chain versus `-X` to delete it? Does the purge script handle both, or should I manually flush first?