Just disable the parts you don't like on your system. I disable resolved everywhere I can and don't feel the need to go complaining about it. Where are you being labeled a systemd hater? Possibly it's more tone of voice than what you're complaining about.

I do, where I can. But with our clients It's often impossible (due to politics) to control all of the clients on the network, so I can't disable parts I don't like.

So I have to find workarounds, like intercepting DNS queries on network level, to fix what used to work before.

And if dnssec ever gets implemented, that wont work either.

Why do you need to intercept DNS queries on the network level? Can't you configure systemd-resolved to do what you need it to do?

Also, dnssec is implemented, and it works.

Sure if I have access to the host, which I often don't[1].

I wrote whole wall of text but at the end of the day, its not that big of a deal, It's more annoying explaing to customers that they have to talk to their other vendors to fix their configs, so sometimes just network level hack is easier.

[1] In enterprise environment and even some SMB environment its somewhat common (at least here in South EU) that big vendors just drop black boxes to you (usually in a form of vmware image, lately sometimes Docker containers). A lot of them are just stock RH, or Ubuntu with their software. ANd that comes with default fallback to goolge or cloudfalre DNS's

What has systemd-resolved got to do with the fact that you have to use black-boxes? If they had used no DNS management at all and instead just dumped entries in /etc/resolv.conf, you'd be just as SoL as you are now with systemd-resolved. If you can write to /etc/systemd, you can set whatever DNS config you want in the config file for systemd-resolved. I fail to see how our woes with bad software products have anything to do with systemd-resolved.

Most black boxes are just default linux distro with their vendor software on top.

Before systemd, you just needed to set correct DHCP config and it would all just work.

But nowdays distros come with systemd-resolved which usualy has (by deafult) fallback public DNS servers.

That means that boxes suddenly can switch from your DHCP network provided DNS servers (or even static DNS servers) to goolge (or cloudflare,) public DNS server.

Bottom line is, it used to be enough to set DNS server through DHCP (or static ones) that is no longer enough in some situations.

I'm not entirely certain that it is systemd-resolved's fault that the distro maintainers are setting default servers in the config. I'm not disputing that RHEL might, but debian certainly does not, nor any of the distros I've used recently, but I probably have a completely different perspective as I have to deal with more end-user focused distros. I do feel your pain though, DNS config management seems to be incredibly hard. And this fuckery where a OS default setting overrides the DHCP config you're pushing would be incredibly painful.

"more and more like children" earlier in this very discussion, perhaps.

> I like the init part, i could do without everything else.

Then, do exactly that? None of the components you're complaining about are mandatory (except for journald, but you can easily forward log messages to a regular syslog daemon).

I can only do that on devices/clients I control [1].

Often that's not an option and have to create workarounds on network level (for DNS).

Because I might not have a say on what device is running, but if it can't resolve internal systems its my problem.

DNSSEC is going to make my life even more interesting.

I actually thought that systemd is the init part.. Regarding DNS, is the systemd resolver just not advanced/flexible enough? I.e as a desktop user I can't complain about anything, but I don't configure it much either.