Manche .local Adressen können nicht aufgelöst werden

Help Deutschsprachige Hilfe
1

Hallo liebe Pi-Hole Fans,

nachdem ich hier ein bisschen gelesen habe und mich freue, dass hier scheinbar ein ganz freundliches Miteinander herrscht, traue ich mich auch mal, etwas zu fragen.

Bei mir im Heimnetz läuft Pi-Hole auf einem Pi Zero, der via WLAN im Netz hängt (das will ich schon länger mal verbessern, da ich etwas "fragil" finde, den zentralen DNS nur per WLAN verbunden zu haben, oder?!). Das läuft schon seit über einem Jahr eigentlich ziemlich gut.

Aber in letzter Zeit, seit ein paar Wochen, habe ich immer wieder mal (manchmal täglich) Probleme mit lokalen Namensauflösungen. Hier im Netz gibt es allerlei Apple HomePods und andere Raspberrys und Macs und die haben ja alle einen .local Namen. Manche dieser Rechner sind bisweilen nicht erreichbar über den Namen, über die IP-Adresse sind sie aber problemlos erreichbar. Merkwürdigerweise gilt das aber nicht pauschal für alle *.local Rechner: andere sind einwandfrei erreichbar.

Ein Beispiel:

╰─ nslookup hoobs.local
Server:		192.168.0.142
Address:	192.168.0.142#53

** server can't find hoobs.local: NXDOMAIN

Der Pi Zero, auch dem Pi Hole läuft, ist bei mir zentral auf meiner Fritz!Box 7590 konfiguriert und hat die IP 192.168.0.142. Die Fritz!Box listet in der Netzwerkübersicht das Gerät mit dem Namen hoobs und der IP 192.168.0.137 auf und darüber ist im Browser auch (auf Port 8080) der Hoobs Dienst erreichbar. Aber nicht über den Namen hoobs.local.

Ein bisschen anders ist es bei einem anderen Raspberry Pi, auf dem Octoprint läuft. Auch da versagt nslookup:

╰─ nslookup octoprint.local
Server:		192.168.0.142
Address:	192.168.0.142#53

** server can't find octoprint.local: NXDOMAIN

Aber im Browser kann ich über die Adresse octoprint.local den Dienst problemlos erreichen.

Über die Web Developer Tools und das Network tab ist mir dabei aufgefallen, dass der Browser den Namen octoprint.local zu einer 2003er IPv6 Adresse aufgelöst hat, nicht zu einer IPv4 Adresse:

image
image326×113 8.28 KB

Ob ich da ein IPv4/IPv6 Problem bzw. Kuddelmuddel habe? Ich habe mich da ehrlich gesagt nie wirklich ernsthaft damit beschäftigt und weiß nicht, was ich auf der Fritz!Box (die auch DHCP Server ist) und was ich in Pi-Hole bzw. auf dem Pi Zero korrekterweise einstellen sollte. :pensive:

Kann mir jemand ein paar Tipps geben oder einen Link zu einem guten Tutorial? Das wäre toll!

Vielen lieben Dank!

2

Pi-hole hat nichts mit der Auflösung dieser Namen zu tun:
.local ist die für das mDNS-Protokoll reservierte TLD. mDNS ermöglicht die namentliche Ansprache von Clients innerhalb desselben Netzwerksegments, unabhängig von einem zentralen Namensserver wie bei DNS.

Wenn einzelne Clients sich nicht über .local ansprechen lassen, dann unterstützen diese entweder mDNS nicht, oder sie liegen in einem anderen Netzwerksegment.

1 Like
3

Aha! Vielen Dank, das wusste ich nicht. Ich dachte, alle Namensanfragen gehen erstmal an den dem Client bekannten Namensserver (hier also den Raspi Zero mit Pi-Hole) und der antwortet.
Wenn also ein Client im lokalen Netz eine .local Adresse anfragt, wer löst die denn in eine IP Adresse auf? :flushed_face:
Das komische ist ja, dass Antworten auf .local Anfragen manchmal (meistens) funktionieren, aber manchmal nicht. Und es sind auch nicht immer dieselben, die mal funktionieren mal nicht. :man_shrugging:
Das Beispiel hoobs.local führt zu einem Raspi mit aktuellem Raspbian. Könnte man also dann dort mal suchen, ob da etwas (aus welchem Grund auch immer) nicht mehr läuft, was aber laufen sollte?

4

Das sind eigentlich keine Pi-hole-Fragen. :wink:

Damit *.local-Namensanfragen aufgelöst werden können, müssen sowohl der anfragende als auch der angefragte Client mDNS unterstützen, und beide müssen sich im selben Netzwerksegment befinden.

mDNS funktioniert -wie das aufgelöste Akronym schon sagt- über Multicast (und Multicasts wiederum sind auf das lokale Netzwerksegment beschränkt). Vereinfacht gesagt, sendet ein Client eine mDNS-Namensanfrage an alle an dasselbe Netzwerksegment angeschlossenen Geräte, und nur das Gerät mit dem gesuchten Namen antwortet dann.

1 Like
5

Prima, vielen Dank, verstanden. Dann forsche ich mal weiter, warum wohl der Hoobs-Raspi nicht auf seinen .local Namen antwortet.
Auf seinen hoobs.fritz.box Namen antwortet er übrigens.

Sorry, dass das nichts mit Pi-Hole zu tun hat. Ich dachte, dass es evtl. mit dessen „Local DNS“ Einstellungen zu tun haben könnte. Schließlich fällt mein Netzwerk ab und zu auch komplett aus, aber das scheint dann ein anderes Thema zu sein (und ein anderes topic/anderer Post hier; wobei es da ja schon einige ähnliche gibt).

1 Like
6

Das sollte er auch - schließlich ist .fritz.box die lokale DNS-Domäne Deines Heimnetzwerks (und die sollte prinzipiell für jedes Gerät und netzwerksegment-übergreifend funktionieren).

1 Like
7

Schau mal, ob auf dem Rechner avahi installiert ist.

1 Like
8

Hehe, ja, nach den Ausführungen von Bucking_Horn hatte ich direkt nachgeschaut und, ja, der avahi daemon läuft, aber – interessant – der Rechner hatte mittlerweile statt hoobs den Namen hoobs-4 bekommen!! Und darüber war er dann auch normal erreichbar. Nur warum wird der auf magische Weise umbenannt?? Und warum heißt er in der Fritz!Box aber immer noch nur hoobs?
Aber das wird jetzt echt zu off-topic. Ich forsche mal weiter!
Lieben Dank euch allen fürs Mitdenken & Helfen!! :+1::+1:

1 Like
9

Ich würde vermuten, dass das ebenfalls auf mDNS zurückzuführen ist.

Da mDNS-Clients ihre Namen selbst festlegen und bekanntgeben, muss es auch einen Mechanismus geben, um Namenskollisionen aufzulösen (also wenn mehrere Clients denselben Namen verwenden).
Bei mehreren RPis im Netz könnte man eine solche Kollision evtl. unabsichtlich z.B. dadurch provozieren, dass man eine Kopie eines Images von einem RPi in einem anderen RPi verwendet und dann dort den Namen nicht oder erst viel später anpasst.
Aber das ist ein wenig Spekulation meinerseits - zu solchen Fragen findest Du in einem mDNS-Forum wahrscheinlich bessere Antworten. :wink:

1 Like
10

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.