If only it was that easy. Unfortunately, systemd-resolved is a sticky piece. You have to `apt-get uninstall` it, then `rm /etc/resolv.conf` and replace it with a sane file (`nameserver 1.1.1.1` or whatever).
For previous versions I had to `chattr +x` as well because systemd stuff of course will not let me have my resolver.
Indeed. It has to be completely removed from the system and even then there is no guarantee it won't be brought back by some minor update in a couple of days. This is why I had to chattr +x in Ubuntu 22 and older. Not anymore in 24, but we'll see.
Wrong and wrong. It just needs to be stopped. And you can mask it to make sure it never ever ever is started by anyone again. C'mon man, 0 for 0 so far on your grumbles.
Do you know how to use netstat to see who is holding the port open? This seems like a major Problem Exists Between Keyboard And Chair issue. But also Ubuntu can be a special place. But if you stop the service & the port is still open... It's probably not that service, it's something else, and so throwing shade at systemd is again not accurate.
Ah. It might be a systemd-resolved.socket (or similarly named), allow socket activation. Systemd would warn you when you disable the service that it wouldn't be giving up the socket, that it could still be restarted. Because it's a great monorepo that's smart & courteous.
I think we're confusing two things here. ssh via socket activation is of course a brain damage done solely by Ubuntu. But systemd goes a long way to make sure it hurts, because `ps ax | grep sshd` will definitely show you that /usr/bin/sshd is running. Except it's not it. But maybe that's Ubuntu thing as well, not sure here.
You would know to run netstat or lsof if you have expected something like that to happen. It certainly wouldn't ever cross my mind to have sshd socket-activated and systemd actively trying to hide the fact. This change by Canonical was out of the blue, totally unexpected.
You can have default one. Chances are, if you have only one configured, it will be default. How are you forced? Who did that? How?
Oth, with resolv.conf syntax, link-specific resolvers are impossible. Even the apple-like extension in /etc/resolver, they cannot respond to link doing up and down.
In NetworkManager, you set your DNS servers using `ipv{4,6}.dns`. Similarly, you set `ipv{4,6}.dns-search` with zones that you want to be looked up via DNS over this link. By default, the default DNS is the link with with default route. If you want to designate the default DNS via different link, set up the search for `~.`
Then `resolvectl status` will show you each link, what DNS is configured for it, what domains it will resolve and which one is the default.
