Systemd is known to but in into areas that are not / should not be of concern for it. Also known to do stuff half baked or changing things because you can.
So I'd very much love to see systemd fingers completely outside of dns resolver, that way we wouldn't have this conversation at all.
Correct, which is why it's not part of /bin/systemd or any other init/pid 1 process.
Having one monolith executable or ten executables that increasingly demand each other is the same thing. Oh wait its name also suggests it is part of the package, being named Systemd-resolved.
There is number of reality distortions like this one that systemd people tried to perform, during the several past years.
Having a "technical conversation" would require you engaged with the person you were replying to, not engaging in what can only be described as "technical trolling".
For the record, the vocal "technical trolls" are why I don't like systemd, despite having little opinion on the technical merits.
I think it is relevant that the current state of affairs (with glibc) isn't actually better at preventing DNS leakage, and that systemd-networkd has relevant functionality specifically to address the underlying use case in a way that reliably blocks DNS leakage.
I also think it is relevant that the functionality is not in pid 1 and (although I didn't say it, and maybe I should have) there is no particular obligation or desire on the part of systemd's pid 1 binary to use systemd-resolved. They're developed in the same project, and there are some nice things you get by using them together, but you don't have to, and you experience no loss of functionality as compared to the status quo ante systemd if you choose to use systemd as init plus the glibc stub resolver. (In particular, I think that's the standard way most distros configure systemd.)
I was probably rude in my reply about how this functionality is not in pid 1, and for that I apologize, but I don't think I was irrelevant. Maybe I don't understand the objection to having systemd-resolved developed alongside an init system? (Developing everything together and using common routines where possible is the traditional UNIX approach, epitomized by the current BSDs.)
> there are some nice things you get by using them together
These two statements contradict each other, and you said them one after the other.
The accusation of trolling stems from this behavior: if you're not even being consistent for the span of two sentences, why should I believe you're advancing a thoughtful, genuine argument? The evidence you present (by so flippantly contradicting yourself) is against that.
> I was probably rude in my reply about how this functionality is not in pid 1, and for that I apologize, but I don't think I was irrelevant.
I believe you misunderstood the objection to the two pieces of software being coupled in your rush to correct a technical point -- it's completely irrelevant if the two processes both run under the same pid as long as it's the case that "there are some nice things you get by using them together".
The concern is that a process which shouldn't be coupled to the process of DNS resolution at all is injecting these "nice things" through coupling, and that systemd is making a whole suite of such software around their init system. Your reply, well, doesn't address that concern, and doesn't seem to even be aware that is the concern.
> Maybe I don't understand the objection to having systemd-resolved developed alongside an init system? (Developing everything together and using common routines where possible is the traditional UNIX approach, epitomized by the current BSDs.)
The concern is inappropriate coupling via these "nice things" that gives systemd inappropriate sway over what non-init portions of the system are, while degrading the overall resilience and versatility of components, and that over time, the process to replace systemd will require replacing substantial portions of the OS, rather than just the init system.
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?)