DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 17657
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
Es gibt einen Grund, der nennt sich Einfachheit.
Hat man ein System, was immer den gleichen Resolver nutzen soll, macht es keinen Sinn, diese Datei verwalten zu lassen.
Dann kann man die Verwaltung wirklich abstellen und dann manuell editieren. Es wäre auch eine kurze Erklärung hilfreich, warum überhaupt ein Stub-Resolver genutzt wird.
ok
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
DJKUhpisse schrieb: Es gibt einen Grund, der nennt sich Einfachheit.
Hm, kann es sein, dass Du hier "Einfachheit" mit "Gewohnheit" verwechselst? Wenn ich z.B. lieber über GUI verwalte, warum ist dann das Deaktivieren von systemd-resolved "einfacher". Wenn ich in einer größeren Umgebung die DNS-Server Organisations-weit über Netplan ausrollen möchte, warum wäre dann das Deaktivieren von systemd-resolved einfacher anstatt die DNS-Server in einer *.yaml festzulegen, die ich dann gleichermaßen für Server und Clients verwenden könnte? Damit will ich nicht sagen, dass es nicht auch Situationen gibt, in denen das Deaktivieren von systemd-resolved angebracht sein kann. Aber IMO muss man erst mal die Struktur verstehen, um diesbezüglich zu einer validen Einschätzung zu kommen, oder? Und im Moment mangelt es IMO noch an Erklärung, warum denn überhaupt dieser Weg des Managen der /etc/resolv.conf über die verschiedenen Manager beschritten wird. Das Argument der "Einfachheit" für den umgekehrten Fall des Nicht-managen-lassens greift diesbezüglich IMO zu kurz. LG,
Newubunti
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 17657
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
Einfachheit deshalb, weil dann nur der Inhalt der Datei zählt und sonst nichts anderes im Spiel ist.
Wie würdest du das gerne formulieren?
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
DJKUhpisse schrieb: Wie würdest du das gerne formulieren?
Ja, berechtigte Frage! Ich bin offen gesagt noch unentschlossen, weil ich das Thema selbst nicht vollends überblicke. Was ich aber am jetzigen Aufbau für ungünstig halte ist, dass im Übersichtsartikel zur DNS-Konfiguration quasi nun exponiert steht, wie man das Managen der /etc/resolv.conf über die (von Ubuntu) gegebenen Mechanismen deaktiviert, während man für NetworkManager und systemd-networkd bzw. Netplan verlinkt. IMO sollte doch zunächst erklärt werden, wie man dem Mechanismus folgend konfiguriert und erst dann unter ferner liefen, wie man es im Fall der Fälle vollständig deaktiviert.
Einfachheit deshalb, weil dann nur der Inhalt der Datei zählt und sonst nichts anderes im Spiel ist.
Naja, das klingt jetzt so - auch wenn es von Dir wahrscheinlich so nicht gewollt ist - dass mit den Ubuntu Standardvorgaben keine stabile DNS-Konfiguration möglich sei. Ich finde es - mal davon abgesehen, dass alles um systemd herum noch relativ neu ist - eigentlich ganz gut, dass ich DNS entweder über /etc/NetworkManager/system-connections/... bzw. über /etc/systemd/network/... bzw. über /etc/netplan/... alles bezüglich des Netzwerks konfigurieren kann. Man muss hier natürlich nicht meiner Meinung sein, darum geht es nicht! Aber diese Auffassung orientiert sich an der von Ubuntu gegebenen Struktur. Und die in erster Linie zu beschreiben, sollte erstes Ziel auch dieses Artikels sein. Deaktivieren von systemd-resolved kann gerne auch Thema sein, aber IMO sollte es das nicht so vordergründig sein, wie es sich jetzt darstellt. LG,
Newubunti
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29066
Wohnort: WW
|
Hallo,
Aber diese Auffassung orientiert sich an der von Ubuntu gegebenen Struktur. Und die in erster Linie zu beschreiben, sollte erstes Ziel auch dieses Artikels sein.
+1. Den Ist-Zustand darstellen als erster und dann darauf aufbauend was man ändern könnte. Was IMHO für einen großen Teil der Desktop-Nutzer von *buntu nicht relevant ist, weil IMHO der größere Teil keine Notwendigkeit hat, für ein Desktopsystem den DNS-Server zu ändern. Bei Servern kann ich das nicht beurteilen. Gruß, noisefloor
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 17657
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
noisefloor schrieb: Hallo,
Aber diese Auffassung orientiert sich an der von Ubuntu gegebenen Struktur. Und die in erster Linie zu beschreiben, sollte erstes Ziel auch dieses Artikels sein.
+1. Den Ist-Zustand darstellen als erster und dann darauf aufbauend was man ändern könnte. Was IMHO für einen großen Teil der Desktop-Nutzer von *buntu nicht relevant ist, weil IMHO der größere Teil keine Notwendigkeit hat, für ein Desktopsystem den DNS-Server zu ändern. Bei Servern kann ich das nicht beurteilen.
Bei Servern werden oft die IP-Adressen und damit auch die DNS-Server manuell festgelegt, damit man kein DHCP braucht. Daher ist da schon Relevanz da.
Da mittlerweile in Deutschland DNS-Zensur (bitte nicht hier, sondern im Hinterzimmer diskutieren) stattfindet, wird es auch Desktop-User ein Interesse geben, den DNS-Server anzupassen.
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
Damit wir nicht in eine falsche Richtung diskutieren: Es ist natürlich schon richtig und wichtig zu beschreiben, wie man den DNS Server in Ubuntu ändert. Aber wenn man mal über den Tellerrand blickt, dann wird das z.B. für Ubuntu 20.04 (Desktop) so beschrieben: https://phoenixnap.com/kb/ubuntu-dns-nameservers oder für Server z.B. https://askubuntu.com/questions/1280277/how-to-change-dns-server-permanently-on-ubuntu-20-04 oder auch: https://netplan.io/examples/ Und genau darum geht es mir. Erst mal den Ubuntu-gerechten - ich werte hier nicht in besser oder schlechter - Weg beschreiben. Und dann könnte man auch zusätzlich noch auf systemctl disable systemd-resolved eingehen, sollte dann aber IMO auch dazu schreiben, warum und wann diese Methode - eventuell - vorzuziehen wäre. Im Artikel hier derzeit, steht diese IMO eher letzte Methode zu stark im Vordergrund. Zumal wenn man den Links zu NetworkManager und systemd-networkd folgt, dann steht da explizit zur DNS-Konfiguration nichts (NetworkManager) oder es steht da verwirrendes (systemd-networkd) - könnte und sollte man natürlich noch ändern. Da ist die Gefahr derzeit ziemlich groß, dass da beim Leser der Eindruck entsteht, man könne den DNS-Server nur sicher ändern, indem man systemd-resolved deaktiviert und den DNS manuell in die /etc/resolv.conf einträgt. LG,
Newubunti
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8627
Wohnort: Münster
|
Newubunti schrieb: […] Es wäre auch eine kurze Erklärung hilfreich, warum überhaupt ein Stub-Resolver genutzt wird.
"Stub-Resolver" ist die vom systemd-Projekt gewählte Bezeichnung für einen lokalen DNS-Cache. Dies ist eine der von systemd-resolved realisierten Funktionen. Ein lokaler DNS-Cache ist technisch ein DNS-Server, der aber keine eigenen DNS-Records oder -Zonen kennt, sondern nur andere DNS-Server als Forwarder und der die von diesen erhaltenen Antworten zwecks erneuter Verwendung temporär zwischenspeichert. Bei Desktop-Rechnern will jeder beim Surfen im Internet eine solche Funktion benutzen, selbst wenn man nicht weiß, das es so etwas überhaupt gibt, weil damit das Antwortzeitverhalten drastisch verbessert wird. Bei Servern ist die Funktion dagegen entbehrlich. Eine Alternative zu systemd-resolved, welches zur Zeit bei Ubuntu-Desktops dafür verwendet wird, ist dnsmasq, welches bei Ubuntu früher diese Aufgabe erfüllt hat. Eine logische Konsequenz beim Einsatz eines DNS-Cache ist natürlich, dass man nun erstens der libc über ihre Datei /etc/resolv.conf sagen muss, dass sie für die Namensauflösung den DNS-Cache benutzen soll, und man zweitens dem DNS-Cache sagen muss, welche DNS-Server dieser als Forwarder befragen soll. Dummerweise missbraucht systemd-resolved die Datei /etc/resolv.conf auch selbst für die zweite Aufgabe.
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
kB schrieb: "Stub-Resolver" ist die vom systemd-Projekt gewählte Bezeichnung
Danke, für die Erklärung! 👍
Eine logische Konsequenz beim Einsatz eines DNS-Cache ist natürlich, dass man nun erstens der libc über ihre Datei /etc/resolv.conf sagen muss, dass sie für die Namensauflösung den DNS-Cache benutzen soll, und man zweitens dem DNS-Cache sagen muss, welche DNS-Server dieser als Forwarder befragen soll. Dummerweise missbraucht systemd-resolved die Datei /etc/resolv.conf auch selbst für die zweite Aufgabe.
Das verstehe ich noch nicht ganz. Warum "dummerweise missbraucht..."? Wie wurde denn der Forwarder der libc dann vor systemd-resolved mitgeteilt? Danke! LG,
Newubunti EDIT: Noch eine Frage nachgeschoben: Stub-Resolver und Stub-Listener meint exakt das selbe?
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 17657
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
Dummerweise missbraucht systemd-resolved die Datei /etc/resolv.conf auch selbst für die zweite Aufgabe.
Nein, denn da steht nur 127.0.0.53 drin.
Bei dnsmasq war es anders, da standen alle drin.
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
Ok, ich versuche mal bis hierhin zu rekapitulieren: Bei einem Standard Ubuntu Desktop erfolgt die DNS-Konfiguration wie folgt - Netplan lasse ich erst mal außen vor, weil "nur" Netzwerkkonfigurations-Abstraktionsschicht: NetworkManager konfiguriert, dass Schnittstelle(n) DNS-Server per DHCP bezieht oder Nutzer setzt mittels NetworkManager den DNS manuell * systemd-resolved holt sich den DNS von NetworkManager Konfiguration bzw. über DHCP, verwendet diesen intern, trägt in die /etc/resolv.conf sich selbst als DNS ein, weil es auch gleichzeitig Cache-Funktionalität bereitstellt. Client-Programme verwenden über libc den in der /etc/resolv.conf eingetragenen DNS-Server und damit systemd-resolved.
Soweit so richtig? Wenn ich nun über die /etc/systemd/resolved.conf den Stub-Listener deaktiviere, dann managed systemd-resolved eigentlich "nur noch" den Inhalt der /etc/resolv.conf oder? NetworkManager böte diese Funktionalität grundsätzlich auch selbst, oder? Bei einem Server verhält es sich, wenn man in obiger Aufzählung systemd-netword für NetworkManager einsetzt ähnlich, allerdings kann systemd-networkd die /etc/resolv.conf nicht selbst verwalten, richtig? Danke! LG,
Newubunti EDIT: Was ich hier noch nicht ganz verstehe: Managed nun NetworkManager die /etc/resolv.conf oder systemd-resolved? In der /etc/resolv.conf steht ja, dass sie von systemd-resolved verwaltet wird. Auf der anderen Seite muss man, wenn man die Verwaltung ganz abschalten will, in der etc/NetworkManager/NetworkManager.conf DNS=none setzen. Das hieße doch im Umkehrschluss, dass systemd-resolved und NetworkManager die Datei gleichzeitig verwalten oder ist NetworkManager so umprogrammiert, dass es nur verwaltet, falls systemd-resolved nicht läuft? EDIT2: Ok, die Antwort auf meine Fragen steht eigentlich - zumindest teilweise - in systemd/systemd-resolved. Demnach konfiguriert NetworkManager systemd-resolved. Das macht eigentlich in der Logik von NetworkManager auch Sinn. Noch nicht ganz klar ist mir dabei, ob nun NetworkManager die Konfiguration von systemd-resolved konfiguriert oder direkt die /etc/resolv.conf. Ich schätze mal, dass NetworkManager systemd-resolved konfiguriert, dann würde auch der Kommentar in der /etc/resolv.conf grundsätzlich weiterhin Sinn ergeben. Ist das so richtig? EDIT3: So nach Studie weitere Dokumentationen komme ich (vorläufig) zu folgendem Ubuntu-Desktop-Standard-DNS-Strang: Datei /etc/nsswitch.conf wird aufgerufen, um DNS-Abfrage-Reihenfolge zu ermitteln Statische Einträge aus /etc/hosts werden ermittelt/berücksichtigt mDNS-Abfrage DNS NetworkManager konfiguriert die /etc/resolv.conf NICHT, weil aufgrund des aktiven systemd-resolved der Symlink /etc/resolv.conf ⇒ /run/systemd/resolve/stub-resolv.conf existiert, weswegen NetworkManager entgegen des eigentlichen Standards von der direkten Konfiguration/Verwaltung der /etc/resolv.conf absieht Deshalb reicht NetworkManager etwaige eigene DNS-Konfiguration an systemd-resolved weiter systemd-resolved trägt 127.0.0.53 als einzigen DNS-Server /run/systemd/resolve/stub-resolv.conf, was einer von vier möglichen Konfigurationsmöglichkeiten der /etc/resolv.conf entspricht. DNS-Angaben die über NetworkManager konfiguriert werden, verdrängen DNS-Angaben, die in /etc/systemd/resolved.conf getätigt wurden.
Einwände? LG,
Newubunti
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
Hallo, das von mir weiter oben vorgeschlagene Kommando, systemd-resolve --status --no-pager |grep Server ist nicht so gut geeignet, um die DNS-Server anzuzeigen, weil unter Umständen die Zuordnung der DNS-Server zu den entsprechenden Links nicht ersichtlich wird. Es gibt bei resolvectl dafür extra die Option dns , also besser wäre (ab 20.04):
Listet dann z.B.:
Global:
Link 1 (enp2s0): 192.168.0.1 Allerdings funktioniert diese Variante nicht mit systemd-resolve . Davon abgesehen würde ich den Artikel wie folgt aufbauen, wobei die Inhalte auch verlinkt werden können: Was ist DNS? ⇒ Kurze Erklärung. Im Prinzip das, was jetzt schon in der Einleitung steht. DNS Server anzeigen resolvectl Prüfen ob Stub-Resolver aktiv/inaktiv
DNS Server festlegen/konfigurieren NetworkManager (Desktop) GUI nmcli
systemd-networkd (Server als DNS-Client) Netplan resolvectl Manuelle Konfiguration der /etc/resolv.conf
(Reihenfolge gegebenenfalls anpassen) Wenn hier nur Übersichtsseite - wie bis jetzt einhellige Meinung - dann entsprechend alle Themen gleichermaßen verlinken. Jedenfalls finde ich es ungeschickt das Thema um die Datei /etc/resolv.conf aufzubauen. Die Datei ist zwar im Hintergrund nach wie vor wichtig, aber für die DNS-Konfiguration an sich spielt sie für den Anwender und auch Admin in der Regel erst mal eine untergeordnete Rolle. Wichtiger wäre dann IMO die Relation der unterschiedlichen Konfigurations-Werkzeuge zu einander zu beleuchten. Damit meine ich die Frage, welche Konfiguration sich im Zweifel durchsetzt. LG,
Newubunti
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8627
Wohnort: Münster
|
Newubunti schrieb: […] Ich schätze mal, dass NetworkManager systemd-resolved konfiguriert
NetworkManager benutzt systemd-resolved, ohne Zweifel, jedenfalls manchmal. Es ist mindestens abhängig von der Version, von der Betriebsweise und von der Konfiguration von NetworkManager. NetworkManager kann auch selbst in der Datei /etc/resolv.conf herum pfuschen und hat das jedenfalls in früheren Versionen auch getan. Ob er es aktuell noch kann oder tut – keine Ahnung, was bedeutet „aktuell“? systemd-resolved hat mindestens 4 verschiedene Betriebsweisen, es gibt bei Ubuntu mindestens 3 verschiedene Manager für /etc/resolv.conf, ich kenne 2 Programme, die bei Ubuntu als DNS-Cache werkeln und Ubuntu-Server sind anders als Ubuntu-Desktops. Das ergibt schon 48 verschiedene gute und ca. 144 (?) kranke Situationen, wobei ich sicher bin, es zu optimistisch zu betrachten, weil ich garantiert noch etwas übersehen habe. Die konkrete Ausgestaltung dieses Chaos war für 16.04 anders als für 18.04 und 18.04 war anders als 20.02 und wie es für 22.04 sein mag, weiß ich noch gar nicht. Und Netplan als neu modischer, für Ubuntu spezieller Oberguru macht das Chaos zwar nicht perfekt, leistet aber auch nichts zu seiner Beseitigung. In diesem Spiel sehe ich nur wenige Konstanten:
Es hat in der von der Distribution als Standard verkauften Version immer funktioniert. Wenn jemand mit auf dem Wissensstand einer früheren Version etwas an der Struktur dieses von der Version abhängigen „Standards“ verändert hat, hat es nicht mehr funktioniert. Alles bleibt anders.
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5106
|
kB schrieb: ...
Also in man NetworkManager.conf steht: dns
...
systemd-resolved: NetworkManager will push the DNS configuration to systemd-resolved
... Mich würde jetzt konkret interessieren, wie dieser "push" genau abläuft? Über irgend eine /run Datei vielleicht? Um das ganze mal gegenüber meinem gestrigen Monolog zu konkretisieren. LG,
Newubunti
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29066
Wohnort: WW
|
Hallo, kB schrieb: Es hat in der von der Distribution als Standard verkauften Version immer funktioniert.
IMHO sind das aber für den Artikel ein wichtiger Punkt. Der erste besagt ja, dass ein Standard *buntu-Desktop ootb funktioniert und man daran normalerweise nichts ändern muss. Was ja dem primären Fokus des Wikis entspricht. Wie das bei Servern ist kann ich nicht beurteilen. Gruß, noisefloor
|