7
Lokale Domains an Linux Desktop
Hej zusammen,
ich habe zuhause einen DNS Server auf Basis von Bind9 laufen. Das funktioniert auch an allen Heim PCs, egal ob Raspi oder Windows. Jetzt habe ich mein DesktopOS zu LinuxMint gewechselt und da funktioniert nicht alles.
Wenn ich externe Domains auflöse, ist alles in Ordnung.
Mir ist klar, dass das der lokale Cache ist, der mit Version irgendwas für Ubuntu eingeführt wurde, aber ich habe auch in den letzten Wochen keine Lösung gefunden, wie ich systemd-resolved beibringe, auch die .gbx über den DNS meines Heimnetzes abzufragen. Ich habe mal, die Domain auf meinem Heim DNS geändert, von*.gbx auf *.local und *.netz - das hatte aber auch keinen Erfolg gebracht.
Kennt sich jemand von euch damit aus und hat einen Tipp?
Allen zusammen eine schöne Restwoche und vorab schon mal danke fürs Lesen und den einen oder anderen Tipp.
Viele Grüße,
Boris
ich habe zuhause einen DNS Server auf Basis von Bind9 laufen. Das funktioniert auch an allen Heim PCs, egal ob Raspi oder Windows. Jetzt habe ich mein DesktopOS zu LinuxMint gewechselt und da funktioniert nicht alles.
Wenn ich externe Domains auflöse, ist alles in Ordnung.
user@notebook:~$ nslookup www.google.de
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: www.google.de
Address: 142.250.185.131
Name: www.google.de
Address: 2a00:1450:4001:829::2003//
Nutze ich aber "meine" interne Domain *.local bekomme ich einen Fehler:
//user@notebook:~$ nslookup octoprint.domain.gbx
Server: 127.0.0.53
Address: 127.0.0.53#53
** server can't find octoprint.tobo.local: SERVFAIL Mir ist klar, dass das der lokale Cache ist, der mit Version irgendwas für Ubuntu eingeführt wurde, aber ich habe auch in den letzten Wochen keine Lösung gefunden, wie ich systemd-resolved beibringe, auch die .gbx über den DNS meines Heimnetzes abzufragen. Ich habe mal, die Domain auf meinem Heim DNS geändert, von*.gbx auf *.local und *.netz - das hatte aber auch keinen Erfolg gebracht.
Kennt sich jemand von euch damit aus und hat einen Tipp?
Allen zusammen eine schöne Restwoche und vorab schon mal danke fürs Lesen und den einen oder anderen Tipp.
Viele Grüße,
Boris
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 4006192889
Url: https://administrator.de/contentid/4006192889
Ausgedruckt am: 22.11.2024 um 01:11 Uhr
7 Kommentare
Neuester Kommentar
nun - du hast eben den Forwarder im DNS falsch drin. Ggf. z.B. via DHCP das du einen öffentlichen DNS bekommst und damit natürlich die .local-Domain unbekannt ist...
Ich würde mal die /etc/resolv angucken -> was da so als DNS drin steht... ansonsten (da wird vermutlich die 127.0.0.1 sein) gucken was in deinem lokalen DNS auf deinem Rechner konfiguriert ist (dnsmasq oder was auch immer da genutzt wurde).
Ich würde mal die /etc/resolv angucken -> was da so als DNS drin steht... ansonsten (da wird vermutlich die 127.0.0.1 sein) gucken was in deinem lokalen DNS auf deinem Rechner konfiguriert ist (dnsmasq oder was auch immer da genutzt wurde).
Zitat von @maretz:
Ich würde mal die /etc/resolv angucken -> was da so als DNS drin steht... ansonsten (da wird vermutlich die 127.0.0.1 sein) gucken was in deinem lokalen DNS auf deinem Rechner konfiguriert ist (dnsmasq oder was auch immer da genutzt wurde).
Ich würde mal die /etc/resolv angucken -> was da so als DNS drin steht... ansonsten (da wird vermutlich die 127.0.0.1 sein) gucken was in deinem lokalen DNS auf deinem Rechner konfiguriert ist (dnsmasq oder was auch immer da genutzt wurde).
Die Adresse 127.0.0.53, die bei nslookup erwähnt wird, ist die Standardadresse vom systemd-resolved.
Das ist also erstmal korrekt und in der resolv.conf sollte nicht herumgespielt werden, wenn der resolved genutzt wird.
Ich kann nicht für Mint sprechen, weil ich damit keine Erfahrung habe, auf anderen Distributionen wird der resolved durch den verwendeten Network-Manager konfiguriert, der das in der Regel auch korrekt macht.
Die Frage ist, wie der DNS-Server im Netzwerk mitgeteilt wird und wie die DNS-Auflösung der internen Namen darüber funktioniert.
Meine losen Vermutungen: IPv6-Router-Advertisements die den Router als DNS-Server mitteilen, daher wird ein bisher IPv4-only betriebener interner DNS-Server übersteuert, weil ja IPv6 bevorzugt wird.
Lösung in dem Fall: Den Router konfigurieren, dass per IPv6 die Link-Local-Adresse des internen DNS-Servers mitgegeben wird.
Ist aber nur eine Vermutung, der TO müsste zu dem Punkt mit Details kommen, wie denn genau normalerweise die DNS-Auflösung der internen Namen funktioniert.
Btw: Der TO sollte von .local weggehen, denn das ist exklusiv für mDNS reserviert und wird nicht über reguläres DNS aufgelöst. Zumindest nicht unter Linux und MacOS.
Du solltest also zu einer anderen "internen TLD" wechseln.
Dass in vielen Anleitungen weiterhin ".local" empfohlen wird liegt meist daran, dass das von reinen Windows-Nutzern geschrieben wird, die selten in dieses Problem rennen, aber nichtsdestotrotz bleibt es falsch.
Moin,
Dein nsllokup fragt lokalhist und nicht Deinen eigenen DNS-Server. Den must Du natürlich in der Resolv.conf eintragen ( oder in den Netzwerkeinstellungen des NICs).
lks
Dein nsllokup fragt lokalhist und nicht Deinen eigenen DNS-Server. Den must Du natürlich in der Resolv.conf eintragen ( oder in den Netzwerkeinstellungen des NICs).
lks
Zitat von @Lochkartenstanzer:
Dein nsllokup fragt lokalhist und nicht Deinen eigenen DNS-Server. Den must Du natürlich in der Resolv.conf eintragen ( oder in den Netzwerkeinstellungen des NICs).
Dein nsllokup fragt lokalhist und nicht Deinen eigenen DNS-Server. Den must Du natürlich in der Resolv.conf eintragen ( oder in den Netzwerkeinstellungen des NICs).
Aaah!! Hört auf das zu empfehlen. Da wird der systemd-resolved gefragt! Das hat seine Richtigkeit! Nicht an der resolv.conf herumbasteln!
1
Stimmt - die Welt wird untergehen wenn man es da ändert oder auch nur auf die Idee kommt .local zu verwenden...
Vielen Dank für die Rückmeldung,
Es scheint daher wirklich daran zu liegen, das der interne systemd-resolved den DHCP nicht abfragt (aber welchen dann?).
Zitat von @LordGurke:
Die Adresse 127.0.0.53, die bei nslookup erwähnt wird, ist die Standardadresse vom systemd-resolved.
Das ist also erstmal korrekt und in der resolv.conf sollte nicht herumgespielt werden, wenn der resolved genutzt wird.
Das Prinzip von systemd-resolved finde ich eigentlich prima, oftmals heißt es bei Treffern in der Suchmaschine aber "umgehen" oder "abschalten". Das möchte ich aber nicht.Die Adresse 127.0.0.53, die bei nslookup erwähnt wird, ist die Standardadresse vom systemd-resolved.
Das ist also erstmal korrekt und in der resolv.conf sollte nicht herumgespielt werden, wenn der resolved genutzt wird.
Ich kann nicht für Mint sprechen, weil ich damit keine Erfahrung habe, auf anderen Distributionen wird der resolved durch den verwendeten Network-Manager konfiguriert, der das in der Regel auch korrekt macht.
Die Frage ist, wie der DNS-Server im Netzwerk mitgeteilt wird und wie die DNS-Auflösung der internen Namen darüber funktioniert.
Der Netzinterne DNS (Bind9) wird per DHCP mitgeteilt, die internen Adressen sind dort direkt in die entsprechenden DB-Files eingetragen.Die Frage ist, wie der DNS-Server im Netzwerk mitgeteilt wird und wie die DNS-Auflösung der internen Namen darüber funktioniert.
Meine losen Vermutungen: IPv6-Router-Advertisements die den Router als DNS-Server mitteilen, daher wird ein bisher IPv4-only betriebener interner DNS-Server übersteuert, weil ja IPv6 bevorzugt wird.
Lösung in dem Fall: Den Router konfigurieren, dass per IPv6 die Link-Local-Adresse des internen DNS-Servers mitgegeben wird.
Ist aber nur eine Vermutung, der TO müsste zu dem Punkt mit Details kommen, wie denn genau normalerweise die DNS-Auflösung der internen Namen funktioniert.
In dem Netzwerk ist IPv6 am Router deaktiviert und es gibt auch keine entsprechenden Policys. Die IPv6 die der Client daher hat, hat er im Netz selbst ausgehandelt. Schaue ich mir den Networkmanager an, scheint das soweit auch erstmal zu passen (siehe Screenshot anbei, ja - der DHCP ist in einem anderen Netzwerk, dazwischen ist aber ein Router, unter Windows und MacOs funktioniert soweit auch alles). Der erste DNS ist der Linux PC mit Bind9, der zweite DNS ist meine Fritzbox (als Fallback). Frage von Linux PC aus direkt den DNS an, funktioniert die Auflösung ebenfalls:Lösung in dem Fall: Den Router konfigurieren, dass per IPv6 die Link-Local-Adresse des internen DNS-Servers mitgegeben wird.
Ist aber nur eine Vermutung, der TO müsste zu dem Punkt mit Details kommen, wie denn genau normalerweise die DNS-Auflösung der internen Namen funktioniert.
user@notebook:~$ nslookup octoprint.comwo.gbx 192.168.50.24
Server: 192.168.50.24
Address: 192.168.50.24#53
Name: octoprint.comwo.gbx
Address: 192.168.50.27Es scheint daher wirklich daran zu liegen, das der interne systemd-resolved den DHCP nicht abfragt (aber welchen dann?).
Btw: Der TO sollte von .local weggehen, denn das ist exklusiv für mDNS reserviert und wird nicht über reguläres DNS aufgelöst. Zumindest nicht unter Linux und MacOS.
Du solltest also zu einer anderen "internen TLD" wechseln.
Dass in vielen Anleitungen weiterhin ".local" empfohlen wird liegt meist daran, dass das von reinen Windows-Nutzern geschrieben wird, die selten in dieses Problem rennen, aber nichtsdestotrotz bleibt es falsch.
Ich nutze tatsächlich eine andere interne TLD (gbx). local und net waren nur die Versuche, ob es damit vielleicht funktioniert ;)Du solltest also zu einer anderen "internen TLD" wechseln.
Dass in vielen Anleitungen weiterhin ".local" empfohlen wird liegt meist daran, dass das von reinen Windows-Nutzern geschrieben wird, die selten in dieses Problem rennen, aber nichtsdestotrotz bleibt es falsch.
Ich habe ewig nicht mehr mit Debian auf der GUI zu tun gehabt - ich meine mich zu erinnern, dass dort explizit eingestellt werden musste, dass auch DNS, nicht nur IP per DHCP bezogen werden soll, aber da kann ich mich täuschen.
Das kannst du ja einmal in den Einstellungen nachprüfen, ggf. auch einmal den DNS-Server manuell festlegen und zur Sicherheit den resolved neustarten.
Wenn du es da ohne Sinn und Verstand änderst, wird es entweder automatisch wieder überschrieben oder - schlechtestenfalls - funktioniert danach die DNS-Auflösung überhaupt nicht mehr. Das steht normalerweise auch ganz oben in der resolv.conf. Ich propagiere also keinen Weltuntergang sondern gebe wieder, was der Softwarehersteller dringend anrät.
Was ".local" angeht: Das Problem ist eines, was in der Microsoft-Welt zum jetzigen Zeitpunkt (noch) nicht in der Form auftritt. Das kann sich mit der weiteren Verbreitung von mDNS aber auch eines Tages ändern. Aber es trifft andere Betriebssysteme, die mDNS nativ unterstützen und auch benutzen. Kollege Venator ist nicht der erste, der dieses Problem hatte
Und anstatt in der nsswitch herumzukramen und ein Nicht-Standard-Verhalten zu erzwingen, kann man - wenn man sowieso noch flexibel ist - auch "local" als TLD vermeiden.
Das kannst du ja einmal in den Einstellungen nachprüfen, ggf. auch einmal den DNS-Server manuell festlegen und zur Sicherheit den resolved neustarten.
Zitat von @maretz:
Stimmt - die Welt wird untergehen wenn man es da ändert oder auch nur auf die Idee kommt .local zu verwenden...
Stimmt - die Welt wird untergehen wenn man es da ändert oder auch nur auf die Idee kommt .local zu verwenden...
Wenn du es da ohne Sinn und Verstand änderst, wird es entweder automatisch wieder überschrieben oder - schlechtestenfalls - funktioniert danach die DNS-Auflösung überhaupt nicht mehr. Das steht normalerweise auch ganz oben in der resolv.conf. Ich propagiere also keinen Weltuntergang sondern gebe wieder, was der Softwarehersteller dringend anrät.
Was ".local" angeht: Das Problem ist eines, was in der Microsoft-Welt zum jetzigen Zeitpunkt (noch) nicht in der Form auftritt. Das kann sich mit der weiteren Verbreitung von mDNS aber auch eines Tages ändern. Aber es trifft andere Betriebssysteme, die mDNS nativ unterstützen und auch benutzen. Kollege Venator ist nicht der erste, der dieses Problem hatte
Und anstatt in der nsswitch herumzukramen und ein Nicht-Standard-Verhalten zu erzwingen, kann man - wenn man sowieso noch flexibel ist - auch "local" als TLD vermeiden.
