On Thu, 2019-04-25 at 22:19 +0200, Olaf Hering wrote:
Am Thu, 25 Apr 2019 20:01:39 +0000 schrieb Wayne Patton
: I would suggest: "systemctl disable systemd-resolved" That is working fine for me.
That was the obvious second step, once "rpm -e systemd-resolved" failed. But this fails because something else starts it on demand.
I can understand that after what you went through, you had a desire to
kill systemd-resolved slowly and painfully. But if you care mostly
about port 53, AFAICS the right way to disable it listening on that
port would be setting
DNSStubListener=no
in /etc/systemd/resolved.conf. I admit I have some trouble
understanding the practical purpose of this stub listener. What client
program would ever use 127.0.0.53:53?
Remains the question for what purpose systemd-resolved might be useful,
IOW whether running it provides an actual benefit to users.
Ordinary name resolution doesn't use systemd-resolved unless the nss-
resolve package is installed and activated. But the systemd-resolved
documentation tells me that systemd-resolved provides a new DBUS API
which is much better and more powerful than getaddrinfo() (what else
did you expect? :-). If on your system systemd-resolved was started on
demand, some program must have tried to use this API, perhaps systemd
itself or some other program from the systemd package. So, the question
arises whether you risk loosing certain functionality if you disable
the service completely. By just disabling the DNSStubListener, you'd be
on the safe side.
Martin
PS: How many different packages do we have now that allow resolver configuration?
There's netconfig, NetworkManager, wicked, systemd-resolved, avahi, ..., not
to mention libvirtd and friends. Has anyone figured out how all these are supposed
to work together?
--
Dr. Martin Wilck