systemd's developers have formed a habit of deciding to implement something like an NTP client or DNS resolver, bringing a healthy dose of ignorance of how those services actually work, and then doubling down on their poor design decisions when problems are brought to their attention.
Those components become my problem when the distributions I choose to use choose to adopt them, and then I have to work around them.
Everything is a tradeoff.
Otherwise I could avoid Linux entirely if I so chose, and make the systemd consideration irrelevant.
Ultimately distros decide what software is on their distro and users decide what distros to use. So the solution here is to find a distro that meets your needs.
The systemd monorepo also provides systemd-resolvd which does, but this is optional and last I checked not included or at least started by default on Debian, for example.
If you really don't want it, it's super easy to disable:
systemctl disable systemd-resolvedFor previous versions I had to `chattr +x` as well because systemd stuff of course will not let me have my resolver.
`nameserver 1.1.1.1` is insane. Hope you don't ever have to use link-specific resolver.
Congratulation to breaking your system.
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.
`systemctl status ssh` shows, that it is socket-activated:
TriggeredBy: ● ssh.socket
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.
Why am I forced into nothing but link specific resolvers?
Why cant I have a global default resolver anymore, with link specific as needed?
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.
Can you tell me how to have a default global resolver with resolvd and network manager?
Should be pretty straightforward right?
It's a pretty basic task.
I looked all through the Man pages and couldn't find a way to do it with network manager.
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.
I was struggling with it while trying to troubleshoot a VPN connection because resolvd automates resolve.conf into a generated file from several other files and will overwrite any other functionality trying to add resolvers to resolve.conf, like an internal VPN company resolver for example.
Why is systemd even touching DNS?
Seems a little outside of it's scope.
This is kinda crazy to me personally when I found out resolvd was doing this.
https://www.man7.org/linux/man-pages/man8/systemd-resolved.s...
resolvd != systemd. It seems like you are mad that Ubuntu changed DNS resolver, but isn't that the actual job of a Linux distro?
1> in the systemd repo
2> if it's written and maintained by the same people who write systemd
3> if systemd is in the NAME
I don't really know what more is needed to say it a is part of systemd
Then you configure your DNS using NetworkManager, on respective connections. I.e. on your VPN, you configure the DNS on the other side of the connection, and (optionally) which zones it is supposed to resolve. (NetworkManager then configures systemd-resolved accordingly). The usage of this DNS then goes up and down together with your VPN connection. That's it.
Providing DNS services on 127.0.0.1:53 has nothing to do with systemd. It's a convention used by NetworkManager, and associated network services. The very good reason being that network interfaces that are being brought up and down can choose to forward their DNS requests to 127.0.0.1, and allow a completely separate unit (resolved?) to deal with the details of where DNS requests get forwarded from there. (Or not, if they so choose).
Was there some OTHER burning compelling use-case that makes you want to use 127.0.0.1:53 for some other purpose?
"Additionally, systemd-resolved provides a local DNS stub listener on the IP addresses 127.0.0.53 and 127.0.0.54 on the local loopback interface"
https://www.man7.org/linux/man-pages/man8/systemd-resolved.s...
> Was there some OTHER burning compelling use-case that makes you want to use 127.0.0.1:53 for some other purpose?
The problem is... by default... resolvd routes ALL DNS REQUESTS to this stub by over writing resolv.conf with ONLY that socket and forcing you to configure resolvers elsewhere. And you have to manually reconfigure this if you want to change it and it forces you to get in the weeds way to much when all you want to do is add a DNS resolver.
https://www.man7.org/linux/man-pages/man8/systemd-resolved.s...
The confusing thing is why the heck is SYSTEMD an init system writing DNS resolvers? Seems out of it's scope in my opinion.
I was surprised resolvd existed when I was trying to troubleshoot a DNS error caused by it.
unless you want to use Arch at some point it will be the default for most Linux.