> These two statements contradict each other, and you said them one after the other.

OK, thanks, I understand the technical disagreement now. I don't believe they contradict. (And I'd appreciate your help in understanding this, since I apparently am causing people to think I'm being disingenuous!)

If you use systemd the pid 1 binary by itself, with the usual glibc stub resolver, you get a pretty good init system.

If you use systemd pid 1 along with systemd-networkd and systemd-resolved, you get some particularly fancy features relating to tying service management to network state (for instance, I think this combination is required to let you reliably implement the feature where VPN DNS queries are sent to the VPN only, by correlating the DNS server config, the VPN interface, and the VPN process).

However, if you don't want these features, you can totally use systemd pid 1 by itself. And in fact my understanding is Debian/Ubuntu-based distros configure systemd, maybe halfheartedly configure networkd but use ifupdown and /etc/network/interfaces, and don't configure resolved.

Therefore, I said that there is no need (obligation) for systemd, the init system, to use systemd-resolved, nor is there any desire, in the sense that it works better as an init system. It gives you new features related to DNS resolution, but if you're not interested in tying your init to DNS resolution, it doesn't work any worse. (This is different from how, e.g., systemd works slightly worse without libnss-myhostname if your current hostname doesn't resolve, or systemd works I think a good bit worse without udev, or systemd doesn't work at all without cgroups, which is a design decision that I really dislike.)

> The concern is inappropriate coupling via these "nice things" that gives systemd inappropriate sway over what non-init portions of the system are

I am somewhat sympathetic to this argument, in that it seems to be not super straightforward to write an API-compatible drop-in replacement for systemd components, if you happen to like systemd's design but not its implementation (as I do).

However, the alternative is that these "nice things" simply cannot exist at all. I don't think these are inappropriately coupled; if you want to reliably correlate long-running processes and virtual network devices, your service management tool has to keep track of them together. (Admittedly, this tool doesn't need to be pid 1, which is another point of disagreement I currently have, and one I've changed my mind on a few times. It can easily be pid 2.) And given that the nice thing is, in my understanding, the exact thing that was requested at the top of this thread (reliably preventing VPN DNS leakage), it seems like it would be making an incomplete analysis to completely disregard this tradeoff.

(Also, I think that systemd's APIs are actually documented enough that you can write the drop-in replacement if you really wanted to, and that systemd upstream is open to documenting these APIs where they're undocumented.)

Furthermore, while I might be wrong that this is the only way for the "nice things" to exist, I don't think that I am so wrong that this argument is in bad faith / trolling. (Maybe I am, maybe there's something obvious I'm missing?)