[opensuse-factory] DNS resolution broken in last TW snapshot

newer
Re: [opensuse-factory] New Package...

Olaf Hering

25 Apr 2019 25 Apr '19

07:37

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

Attachments:

attachment.sig (application/pgp-signature — 195 bytes)

Show replies by date

Andrei Borzenkov

25 Apr 25 Apr

17:49

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

Jan Engelhardt

19:28

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

Wayne Patton

19:27

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

Olaf Hering

19:57

Am Thu, 25 Apr 2019 19:27:17 +0000 schrieb Wayne Patton :

...

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

Wayne Patton

20:01

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��Ǩ�

Olaf Hering

20:19

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. Olaf

Christian Boltz

26 Apr 26 Apr

09:33

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 :

...
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

Carlos E. R.

2 May 2 May

20:59

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 :

...
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

Martin Wilck

19:34

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 , 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

Carlos E. R.

20:54

On 25/04/2019 22.19, 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.

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

1827

Age (days ago)

1834

Last active (days ago)

List overview

Download

10 comments

7 participants

participants (7)

Andrei Borzenkov
Carlos E. R.
Christian Boltz
Jan Engelhardt
Martin Wilck
Olaf Hering
Wayne Patton

[opensuse-factory] DNS resolution broken in last TW snapshot

tags

participants (7)