[opensuse-factory] DNS resolution broken in last TW snapshot
Thankfully I have this other system to "get online". One of the snapshots did unconditional start systemd-resolved. As a result dnsmasq can not claim port 53. As a result no name resolution can work. Nothing like that was mentioned in the weekly review mails. There is no preset for 'systemd-resolvd', so one would expect that thing to remain disabled after 'zypper dup'. The man page lacks info about how to not run it per default. It is not possible to get rid of it at the rpm level. Are we still in control of the base system? Is it time to drop dnsmasq, bind and whatever else would offer DNS services? Thanks. (really...) Olaf
25.04.2019 10:37, Olaf Hering пишет:
Thankfully I have this other system to "get online".
I have no problems with running systemd-resolved. DNS resolution works. It is not broken.
One of the snapshots did unconditional start systemd-resolved. As a result dnsmasq can not claim port 53. As a result no name resolution can work. Nothing like that was mentioned in the weekly review mails.
You are not a newbie who is incapable of distinguishing between "no internet" and "systemd-resolved conflicts with dnsmasq". systemd-resolved listens on single address 127.0.0.53. I have no idea what dnsmasq does or why it conflicts with systemd-resolved - you are capable of debugging it yourself.
There is no preset for 'systemd-resolvd', so one would expect that thing to remain disabled after 'zypper dup'. The man page lacks info about how to not run it per default. It is not possible to get rid of it at the rpm level.
It is likely started via D-Bus auto-start. systemctl mask systemd-resolved.service - or - man resolved.conf /DNSStubListener
Are we still in control of the base system?
Is it time to drop dnsmasq, bind and whatever else would offer DNS services?
Thanks. (really...)
Olaf
On Thursday 2019-04-25 19:49, Andrei Borzenkov wrote:
25.04.2019 10:37, Olaf Hering пишет:
Thankfully I have this other system to "get online".
I have no problems with running systemd-resolved. DNS resolution works. It is not broken.
One of the snapshots did unconditional start systemd-resolved. As a result dnsmasq can not claim port 53. As a result no name resolution can work. Nothing like that was mentioned in the weekly review mails.
You are not a newbie who is incapable of distinguishing between "no internet" and "systemd-resolved conflicts with dnsmasq".
systemd-resolved listens on single address 127.0.0.53. I have no idea what dnsmasq does or why it conflicts with systemd-resolved - you are capable of debugging it yourself.
Well that's easy: Binding to the wildcard address, *:53, requires that there is _not a single socket_ of the same protocol in the network namespace that is already listening on 53 on any address. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I run dnsmasq and had no issue like you describe from yesterday's TW snapshot update. I have systemd-resolved disabled and the recent updates did not re-enable it on my system. Wayne On Thu, 2019-04-25 at 09:37 +0200, Olaf Hering wrote:
Thankfully I have this other system to "get online".
One of the snapshots did unconditional start systemd-resolved. As a result dnsmasq can not claim port 53. As a result no name resolution can work. Nothing like that was mentioned in the weekly review mails.
There is no preset for 'systemd-resolvd', so one would expect that thing to remain disabled after 'zypper dup'. The man page lacks info about how to not run it per default. It is not possible to get rid of it at the rpm level.
Are we still in control of the base system?
Is it time to drop dnsmasq, bind and whatever else would offer DNS services?
Thanks. (really...)
Olaf
Am Thu, 25 Apr 2019 19:27:17 +0000 schrieb Wayne Patton <wayne.patton@suse.com>:
I have systemd-resolved disabled and the recent updates did not re-enable it on my system.
Glad to hear it works for you. I also have it disabled now. Because it is still UNIX: "chmod a-x /usr/sbin/systemd-resolved" Looks like NetworkManager triggers it. Someone else will figure it out at some point. Olaf
Caution: This email originated from outside the organization. Do not click links or open attachments unless you have verified this email is legitimate. I would suggest: "systemctl disable systemd-resolved" That is working fine for me. Wayne On Thu, 2019-04-25 at 21:57 +0200, Olaf Hering wrote:
Caution: This email originated from outside the organization. Do not click links or open attachments unless you have verified this email is legitimate.
N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
Am Thu, 25 Apr 2019 20:01:39 +0000 schrieb Wayne Patton <wayne.patton@suse.com>:
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. Olaf
Hello, Am Donnerstag, 25. April 2019, 22:19:15 CEST schrieb Olaf Hering:
Am Thu, 25 Apr 2019 20:01:39 +0000 schrieb Wayne Patton <wayne.patton@suse.com>:
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.
It's even more interesting than that - something *enabled* it :-/ On my system, I have lrwxrwxrwx 1 root root 48 15. Apr 14:13 /etc/systemd/system/dbus-org.freedesktop.resolve1.service -> /usr/lib/systemd/system/systemd-resolved.service I checked /var/log/zypp/history, and it only has entries for 2019-04-14 and 2019-04-16 (both zypper dup), which means something[tm] must have enabled systemd-resolved in a non-default way :-( To make things even more interesting - the next boot after the 2019-04-14 zypper dup was 2019-04-15 at 12:07, so systemd-resolved was enabled _two hours after booting_, and I have no idea why. For completeness: systemctl status systemd-resolved.service ● systemd-resolved.service - Network Name Resolution Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: disabled) so there's indeed no preset to enable it, which IMHO also means it shouldn't get enabled. Is there already a bugreport for this, or should I open one? Regards, Christian Boltz --
which camera is this? Marcus, this is my bug :) [Marcus Meissner and Stephan Kulow in https://bugzilla.novell.com/show_bug.cgi?id=217731]
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 26/04/2019 11.33, Christian Boltz wrote:
Hello,
Am Donnerstag, 25. April 2019, 22:19:15 CEST schrieb Olaf Hering:
Am Thu, 25 Apr 2019 20:01:39 +0000 schrieb Wayne Patton <wayne.patton@suse.com>:
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.
It's even more interesting than that - something *enabled* it :-/
On my system, I have
lrwxrwxrwx 1 root root 48 15. Apr 14:13 /etc/systemd/system/dbus-org.freedesktop.resolve1.service -> /usr/lib/systemd/system/systemd-resolved.service
I checked /var/log/zypp/history, and it only has entries for 2019-04-14 and 2019-04-16 (both zypper dup), which means something[tm] must have enabled systemd-resolved in a non-default way :-(
To make things even more interesting - the next boot after the 2019-04-14 zypper dup was 2019-04-15 at 12:07, so systemd-resolved was enabled _two hours after booting_, and I have no idea why.
Try systemctl mask systemd-resolved.service as Andrei suggested. -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.1 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 2019-04-25 at 22:19 +0200, Olaf Hering wrote:
Am Thu, 25 Apr 2019 20:01:39 +0000 schrieb Wayne Patton <wayne.patton@suse.com>:
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 <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 25/04/2019 22.19, Olaf Hering wrote:
Am Thu, 25 Apr 2019 20:01:39 +0000 schrieb Wayne Patton <wayne.patton@suse.com>:
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.
Why, what did it say? -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.1 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (7)
-
Andrei Borzenkov -
Carlos E. R. -
Christian Boltz -
Jan Engelhardt -
Martin Wilck -
Olaf Hering -
Wayne Patton