ubuntuusers.de

systemd/systemd-resolved

Status: Ungelöst | Ubuntu-Version: Nicht spezifiziert
Antworten |
Dieses Thema ist die Diskussion des Artikels systemd/systemd-resolved.

kB Team-Icon

Supporter, Wikiteam
(Themenstarter)
Avatar von kB

Anmeldungsdatum:
4. Oktober 2007

Beiträge: 9387

Wohnort: Münster

Neue Version hochgeladen. Inhalt unverändert, aber Links wunschgemäß reduziert.

Kann aus meiner Sicht von der Baustelle ins Wiki verschoben werden.

noisefloor Team-Icon

Anmeldungsdatum:
6. Juni 2006

Beiträge: 29567

Hallo,

der Artikel ist im Wiki, Danke für's Erstellen ☺

Verlinkt ist er bis jetzt nur auf der systemd Seite. Weitere Verlinkungen auf anderen Seiten bei Bedarf bei noch vornehmen.

Gruß, noisefloor

Kevin_Kofler

Anmeldungsdatum:
15. Februar 2022

Beiträge: Zähle...

Warum heißt es im Artikel, man solle nicht gleichzeitig Methode A und B verwenden? Methode A und B können problemlos kombiniert werden, und das ist auch die Standardkonfiguration z.B. in Fedora.

Die Idee dahinter ist (wie auch in obigem Link erklärt), daß Applikationen, die den DNS-Resolver der glibc verwenden, direkt mit systemd-resolved kommunizieren und nicht über den Stub-DNS-Server (Methode B), während Applikationen, die das DNS-Protokoll selbst implementieren, also den DNS-Resolver der glibc umgehen (z.B. nslookup) den Stub-DNS-Server in /etc/resolv.conf finden (Methode A). Gegenüber nur Methode A hat es den Vorteil, daß die meisten Applikationen effizienter sind, weil sie den Stub-DNS-Server nicht brauchen, gegenüber nur Methode B, daß die restlichen Applikationen auch systemd-resolved verwenden.

Ich würde also (entgegen dem derzeitigen Wiki-Text) auf jeden Fall die kombinierte Methode A+B empfehlen. Ich kann auch bestätigen, daß das auf Ubuntu auch funktioniert, zumindest auf 20.04 LTS "Focal Fossa" (aber ich wüßte nicht, warum es auf anderen Versionen nicht funktionieren sollte).

kB Team-Icon

Supporter, Wikiteam
(Themenstarter)
Avatar von kB

Anmeldungsdatum:
4. Oktober 2007

Beiträge: 9387

Wohnort: Münster

Es macht keinen Sinn, gleichzeitig beide Methoden zu aktivieren, weil – selbst wenn es dann funktionieren sollte – man dann die Arbeit doppelt tun lässt.

Davon abgesehen, kann es auch nicht zuverlässig funktionieren, weil die Aktivierung von Methode A oder B eben auf der unterschiedlichen Natur der Datei /etc/resolv.conf beruht: Sie ist entweder ein symbolischer Link oder nicht und kann nicht beides gleichzeitig sein. Die Art der Datei ist in diesem Falle funktionsrelevant!

Ob übrigens die Datei /etc/resolv.conf ein symbolischer Link ist oder nicht, ist auch für den NetworkManager relevant, der beim Mischen der Methoden A und B Probleme bekommt.

Wenn Fedora das anders macht, hat dies keinerlei Relevanz für das UbuntuUsers.de-Wiki. Hier wird beschrieben, wie es bei Ubuntu funktioniert oder auch nicht funktioniert.

Die schließlich und am wichtigsten: Die Warnhinweise stehen da, weil es beim ausführlichen Test zu funktionalen Problemen gekommen ist. Und weil es diese Beobachtungen gibt, die durchaus nicht in allen denkbaren Konstellationen zwangsläufig auftreten müssen, aber eben manchmal aufgetreten sind, kann ich die Kombination beider Methoden keinesfalls empfehlen. Gerade, weil die Probleme nur manchmal auftreten, muss man seriöser Weise davor warnen.

Aber jeder Leser darf Warnungen ignorieren.

Kevin_Kofler

Anmeldungsdatum:
15. Februar 2022

Beiträge: 6

kB schrieb:

Es macht keinen Sinn, gleichzeitig beide Methoden zu aktivieren, weil – selbst wenn es dann funktionieren sollte – man dann die Arbeit doppelt tun lässt.

Ich habe doch gerade erklärt, warum ich beides brauche! Nicht jede Applikation geht für das DNS-Resolving über den Resolver der glibc, deshalb funktioniert nsswitch.conf nicht für alle Applikationen. Für die restlichen muß resolv.conf auf den Stub-Resolver umgestellt werden.

Probiere mal, mit einer Split-DNS-Konfiguration (nur) Methode B anzuwenden und dann mit nslookup ein paar Domains innerhalb und außerhalb der Zuständigkeit des VPNs aufzulösen, du wirst überrascht sein!

Davon abgesehen, kann es auch nicht zuverlässig funktionieren, weil die Aktivierung von Methode A oder B eben auf der unterschiedlichen Natur der Datei /etc/resolv.conf beruht: Sie ist entweder ein symbolischer Link oder nicht und kann nicht beides gleichzeitig sein. Die Art der Datei ist in diesem Falle funktionsrelevant!

Die Datei /etc/resolv.conf wird unter Methode B vom glibc-DNS-Resolver komplett ignoriert (!), daher ist es für Applikationen, die den verwenden, völlig irrelevant, ob die Datei eine einfache Datei oder ein symbolischer Link ist oder sogar überhaupt nicht existiert. Der symbolische Link auf die stub-resolv.conf wird nur für die Applikationen benötigt, die den Resolver der glibc umgehen.

Ob übrigens die Datei /etc/resolv.conf ein symbolischer Link ist oder nicht, ist auch für den NetworkManager relevant, der beim Mischen der Methoden A und B Probleme bekommt.

Was für Probleme?

Der NetworkManager erkennt den symbolischen Link und weiß daher, daß systemd-resolved verwendet wird und er daher seine DNS-Informationen nicht in /etc/resolv.conf hineinschreiben soll, sondern an eine Stelle, wo sie systemd-resolved auch finden kann. Das verhindert keinesfalls, systemd-resolved auch direkt über nsswitch.conf (also ohne den Stub-Resolver, für den der symbolische Link gesetzt wird) aufzurufen. Wie genau mit systemd-resolved kommuniziert wird, dafür ist der NetworkManager ja gar nicht zuständig.

Ich sehe also nicht, wo es da zu Problemen kommen könnte. Bei mir hat es jedenfalls keine gegeben.

Wenn Fedora das anders macht, hat dies keinerlei Relevanz für das UbuntuUsers.de-Wiki. Hier wird beschrieben, wie es bei Ubuntu funktioniert oder auch nicht funktioniert.

Wie gesagt, ich habe die kombinierte Methode A+B auf einem Ubuntu Focal Server getestet und sie funktioniert einwandfrei.

Die schließlich und am wichtigsten: Die Warnhinweise stehen da, weil es beim ausführlichen Test zu funktionalen Problemen gekommen ist. Und weil es diese Beobachtungen gibt, die durchaus nicht in allen denkbaren Konstellationen zwangsläufig auftreten müssen, aber eben manchmal aufgetreten sind, kann ich die Kombination beider Methoden keinesfalls empfehlen. Gerade, weil die Probleme nur manchmal auftreten, muss man seriöser Weise davor warnen.

Und was waren diese Probleme? Könnte es sich um längst behobene Bugs in alten Versionen handeln? Das riecht für mich stark nach "cargo culting", das die optimale Lösung aufgrund längst obsoleter schlechter Erfahrungen verhindert.

Aber jeder Leser darf Warnungen ignorieren.

Ich möchte diese unsinnigen Warnungen aber aus dem Wiki entfernt sehen, weil sie Benutzern von der optimalen, von systemd-Entwicklern empfohlenen (die von mir verlinkte Fedora-Change-Seite wurde von Zbigniew Jędrzejewski-Szmek mitgeschrieben, der auf https://github.com/systemd/systemd gleich an zweiter Stelle nach Lennart Poettering steht, letzterer kommt übrigens auch von Fedora / Red Hat) Methode abraten.

kB Team-Icon

Supporter, Wikiteam
(Themenstarter)
Avatar von kB

Anmeldungsdatum:
4. Oktober 2007

Beiträge: 9387

Wohnort: Münster

Kevin_Kofler schrieb:

[…] Wie gesagt, ich habe die kombinierte Methode A+B auf einem Ubuntu Focal Server getestet und sie funktioniert einwandfrei.

Ubuntu Server 20.04 alleine ist nicht repräsentativ für die die Gesamtheit aller aktuellen Ubuntu-Systeme.

Ich habe es seinerzeit unter Ubuntu 18.04 Desktop und Server sowie 20.04 Desktop und Server getestet und Probleme mit der DNS-Auflösung und der Netzwerk-Konfiguration durch NetworkManager beobachtet, wenn gleichzeitig beide Methoden angewendet wurden.

Beim Server gab es weniger Probleme, weil hier eben kein NetworkManager eingesetzt wird.

[…] Ich möchte diese unsinnigen Warnungen aber aus dem Wiki entfernt sehen

Was Du im Trotz als unsinnig ansiehst, sehen andere (auch ich) anders. Fedora und Ubuntu sind unterschiedliche Betriebssysteme und was bei dem einen gut funktioniert kann beim anderen Ärger verursachen. Wie gesagt: Bei Ubuntu ist generell eine gleichzeitige Anwendung nicht sinnvoll, weil für aktuelle Systeme negative Erfahrungen vorliegen. Vielleicht ist es für 22.04 anders, das bleibt abzuwarten und zu testen.

Und wenn es für einen speziellen Anwendungsfall gut funktioniert, gilt es noch lange nicht generell.

Und wenn Du es für einen sehr speziellen Anwendungsfall sogar benötigst, ist das auch kein Anlass für eine generelle Empfehlung.

Im Übrigen weist sogar die von Dir verlinkte Seite im Fedora-Wiki darauf hin, dass es zu Wechselwirkungen mit NetworkManager kommen kann!

Kevin_Kofler

Anmeldungsdatum:
15. Februar 2022

Beiträge: 6

Beim Server gab es weniger Probleme, weil hier eben kein NetworkManager eingesetzt wird.

Fedora verwendet jedenfalls auch NetworkManager, also daran alleine kann es nicht liegen.

Wie gesagt: Bei Ubuntu ist generell eine gleichzeitige Anwendung nicht sinnvoll, weil für aktuelle Systeme negative Erfahrungen vorliegen. Vielleicht ist es für 22.04 anders, das bleibt abzuwarten und zu testen.

Gibt es zu den nicht-LTS-Zwischenversionen keine Erfahrungswerte?

Im Übrigen weist sogar die von Dir verlinkte Seite im Fedora-Wiki darauf hin, dass es zu Wechselwirkungen mit NetworkManager kommen kann!

Eine Interaktion ist noch nicht automatisch ein Konflikt.

Es ist schade, denn diese sonst sehr übersichtliche Wikiseite wird durch die für mich nicht nachvollziehbaren Warnungen so weit unbrauchbar gemacht, daß ich sie nicht guten Gewissens verlinken kann.

Es lesen übrigens auch Nutzer*innen anderer Distributionen eure Wikiseiten, der Cargo-Cult könnte sich also auch noch deutlich weiter verbreiten, als du es vermuten würdest.

Kevin_Kofler

Anmeldungsdatum:
15. Februar 2022

Beiträge: 6

Was ich jedenfalls sicher sagen kann, ist, daß die "doppelte" Konfiguration auf Ubuntu 20.04 LTS Focal Fossa (Server), Fedora 33 (KDE Plasma) und Fedora 35 (KDE Plasma) mit einem split-DNS-VPN (das auf dem erwähnten Ubuntu-Focal-Server läuft, mittels dnsmasq) problemlos funktioniert.

Übrigens: dnsmasq und systemd-resolved kommen sich nicht in die Quere, wenn dnsmasq mit interface=vpns* und bind-dynamic konfiguriert wird. Dann hört dnsmasq nur auf die VPN-Interfaces (und zwar dynamisch, wenn sie kommen und gehen, das macht bind-dynamic, das leider in der mit Focal mitgelieferten dnsmasq.conf nicht nur nicht standardmäßig aktiviert, sondern überhaupt nicht dokumentiert ist, obwohl es von der Version von dnsmasq unterstützt wird), während systemd-resolved von Haus aus nur auf localhost hört, somit kommt es nicht zu einem Konflikt. Und zwar schickt dnsmasq dann sogar die Anfragen, die es nicht selbst beantworten kann, an den systemd-resolved weiter, der es dann an die Upstream-DNS-Server schickt.

Kevin_Kofler

Anmeldungsdatum:
15. Februar 2022

Beiträge: 6

Wobei die systemd-resolved-Konfiguration auf dem Server keine Split-DNS-Konfiguration ist, weil der Server ja kein VPN-Client, sondern "nur" ein VPN-Server ist, und dnsmasq Abfragen an systemd-resolved schickt und nicht umgekehrt. Nur auf den (Fedora-)Clients wird Split-DNS verwendet. Der Server verwendet eigentlich nur deshalb systemd-resolved, weil es in Ubuntu Focal Standard ist.

noisefloor Team-Icon

Anmeldungsdatum:
6. Juni 2006

Beiträge: 29567

Hallo,

Es lesen übrigens auch Nutzer*innen anderer Distributionen eure Wikiseiten, ...

Es ist schon klar, dass sich das Wiki auch bei Nutzern anderer Distribution, sich einer gewissen Beliebtheit erfreut. Und sicherlich ist auch viele ohne größere Probleme auf andere Distros übertragbar. Nichts desto trotz ist das Wiki nur (und nur) relevant, was auf einem *buntu getestet wurde und läuft. Ob etwas auf Mint oder Debian oder ... läuft und darum auch auf Ubuntu laufen müsste hat keine Relevanz. Es ist halt ein Ubuntu-Wiki (=Ubuntu und offizielle Derivate) und es gibt auch z.Zt. null Bestrebungen, daran was zu ändern.

Gibt es zu den nicht-LTS-Zwischenversionen keine Erfahrungswerte?

In Bezug auf den Wikiartikel hier: scheinbar nicht. Die Erfahrung ist her auch eher so, dass je "tiefer" ("low level") das Thema ist - was IMHO bei systemd-resolvd gegeben ist - desto weniger testen das bzw. interessieren sich für die STS Releases von *buntu. Was nicht heißt, dass das nicht alles 1:1 übertragbar ist. Hat halt nur entweder keiner wirklich getestet oder der, der es getestet hat, hat es nicht im Wiki manifestiert.

Zum Ausgangspunkt: wenn es ein (reproduzierbares) Problem gibt, dann darf und soll das im Wikiartikel erwähnt werden. Normalerweise am Ende im Abschnitt "Problembehebung". Im gegebenen Fall macht es aber schon Sinn, dass nach vorne zu packen, weil das ja quasi den ganzen Artikel betrifft. In wie fern das ganze alle *buntus betrifft oder ggf. nur ein Problem für einen (kleinen) Teil der *buntus ist kann ich nicht beurteilen, weil ich systemd-resolvd selber nicht nutzen. Dass sich darüber bisher noch keiner beschert hat kann halt zwei Gründe haben: a) ist es ein reales Problem und alles ist 1:1 richtig, wie es im Wiki steht oder b) das Thema interessiert eigentlich niemanden, deswegen fallen auch mögliche Fehler im Artikel nicht auf.

Gruß, noisefloor

Kevin_Kofler

Anmeldungsdatum:
15. Februar 2022

Beiträge: 6

Das entweder-oder verursacht auch Probleme, z.B. https://github.com/calamares/calamares/issues/1942.

karzer Team-Icon

Wikiteam
Avatar von karzer

Anmeldungsdatum:
10. April 2022

Beiträge: 1480

Wohnort: Bad Oeynhausen

Ich habe diesen Artikel getestet und auf meinem Noble funktioniert Methode B nicht, sondern es wird verlangt, dass /etc/resolv.conf ein symbolischer Link auf /run/systemd/resolve/stub-resolv.conf ist, wie mittlerweile auch bereits bei Systeminstallation eingerichtet (eine leere Datei funktioniert auch nicht); andernfalls funktioniert die Namensauflösung überhaupt nicht mehr. Es brachte auch nichts, den Namen des Moduls nss-resolve wie in der Manpage beschrieben zu resolve zu ändern. Kann das jemand bestätigen?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
$ ls /etc/resolv.conf 
lrwxrwxrwx 1 root root 37 Nov 10 14:28 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf
$ sudo rm /etc/resolv.conf; sudo touch /etc/resolv.conf 
$ dig ubuntuusers.de
;; communications error to ::1#53: connection refused
;; communications error to ::1#53: connection refused
;; communications error to ::1#53: connection refused
;; communications error to 127.0.0.1#53: connection refused

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> ubuntuusers.de
;; global options: +cmd
;; no servers could be reached
$ sudo vim /etc/nsswitch.conf
$ dig @127.0.0.53 ubuntuusers.de

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> @127.0.0.53 ubuntuusers.de
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60134
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;ubuntuusers.de.			IN	A

;; ANSWER SECTION:
ubuntuusers.de.		6647	IN	A	87.79.26.37

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Sun Nov 10 14:38:17 CET 2024
;; MSG SIZE  rcvd: 59

$ sudo rm /etc/resolv.conf; sudo ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf 
$ sudo vim /etc/nsswitch.conf 
$ dig ubuntuusers.de

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> ubuntuusers.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25371
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;ubuntuusers.de.			IN	A

;; ANSWER SECTION:
ubuntuusers.de.		6517	IN	A	87.79.26.37

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Sun Nov 10 14:40:27 CET 2024
;; MSG SIZE  rcvd: 59
1
2
# in /etc/nsswitch.conf
hosts:          files mdns4_minimal [NOTFOUND=return] nss-resolve

kB Team-Icon

Supporter, Wikiteam
(Themenstarter)
Avatar von kB

Anmeldungsdatum:
4. Oktober 2007

Beiträge: 9387

Wohnort: Münster

Methode B ist aus heutiger Sicht zu knapp beschrieben.

Wenn man die Datei /etc/resolv.conf selbst verwalten möchte, muss man die Verwaltung vorher sowohl systemd-resolved als auch NetworkManager entziehen. Die Methoden dazu (leere Dateien, Symlinks) sind wohl versionsabhängig.

Das Abhängigkeitsgestrüpp zwischen den Konfigurationsprogrammen (und zusätzlich Netplan) ist unerfreulich unübersichtlich (jedenfalls für mich) und variabel.

Ich schlage vor, Methode B als fehlerhaft ab noble zu markieren.

karzer Team-Icon

Wikiteam
Avatar von karzer

Anmeldungsdatum:
10. April 2022

Beiträge: 1480

Wohnort: Bad Oeynhausen

kB schrieb:

[...] Ich schlage vor, Methode B als fehlerhaft ab noble zu markieren.

Einverstanden. Ich währe Dir sehr verbunden, wenn Du das nach bestem Wissen und Gewissen vornehmen könntest.

Antworten |