Lokale Namensauflösung funktioniert nicht richtig

Hallo,

Aufgrund zu vieler Probleme habe ich kürzlich Raspbian neu installiert und Pi-Hole mit Unbound eingerichtet. Anschließend habe ich über den Teleporter meine Daten importiert.
Die Auflösung funktioniert nun wirklich sehr gut, jedoch habe ich noch immer das Problem, dass fast alle lokalen Hostnamen nicht aufgelöst werden.
Außerdem fragt localhost sehr oft nach seiner eigenen Adresse??
Da Pi-Hole als DHCP Server eingestellt ist, verstehe ich nicht warum es so ein Problem ist die lokalen Hostnamen aufzulösen.
Ich habe diesbezüglich schon sehr viel gelesen, aber nichts davon scheint zu klappen und oftmals sind es irgendwelche manuelle Bastellösungen. Ich möchte keine Hosts manuell eintragen müssen, das sollte Pi-Hole schon selbst schaffen.
Hat jemand eine Idee was ich hier übersehe?

https://tricorder.pi-hole.net/b2joheohvz

Danke & Grüße,
Hyper

Kannst Du hier Beispiele für eine gescheiterte Auflösung lokaler Namen nennen?

Die Clients werden angezeigt mit *dip0.t-ipconnect.de. oder auch mal die IP.
Es betrifft sowohl A als auch AAAA Anfragen.

Nachdem ich nun neu gestarte habe war bei Unbound mal der Anchor defekt.
Den habe ich nun repariert und das Ergebnis ist nun wieder anders.
IPs werden nun nicht mehr angezeit, jedoch wird vom selben Client einmal eine Anfrage mit dem Hostnamen angezeigt und direkt danach die gleiche Anfrage wieder mit *dip0.t-ipconnect.de.
Was läuft da schief?

Selbst wenn der Client über Pi-hole eine statische IP Adresse bekommt wird es nicht richtig angezeigt.

Auch wenn da vermutlich eine IPv6-Adresse anstelle des * steht, ist das keine IPv6-Adresse:
Es handelt sich um den generischen öffentlichen Hostnamen für die öffentliche IPv6-Adresse des Geräts, das die Anfrage stellt. Dieser wird durch Deinen ISP vergeben.

Ja das weiss ich. Das ist ja das Problem, er zeit diese Adresse an, statt dem eigentlichen Hostnamen des Clients. Mal zeigt er diese nun richtig an mal nicht.
Nach dem ersten Neustart nach der Unbound Einrichtung funktioniert Unbound nun auch nicht mehr richtig.
Es wird nur ein Teil der Anfragen bearbeitet, der Rest ist SERVFAIL oder N/A. Nach einer Weile reagiert dann der Dienst nicht mehr auf Anfragen. Vor dem Booten hat zumindest Unbound einwandfrei funktioniert.

Nochmals: Es wird korrekt der Hostname (z.B. p200300de...2468.dip0.t-ipconnect.de) für die öffentliche IPv6-Adresse angezeigt, nicht die Adresse selbst (z.B. 2003:00de:...:2468).
Es handelt sich dabei also auch nicht um eine lokale Namensauflösung.

Zum Verständnis ist auch folgendes noch wichtig:
Pi-hole (bzw. DNS) identifiziert einen Eintrag im Query Log durch die Client-IP-Adresse.
Ein Gerät mit mehreren IP-Adressen kann dementsprechend mit jeder seiner IP-Adressen im Query Log auftauchen.

Soll für eine Client-IP-Adresse ein Name angezeigt werden, so muss für diese IP auch ein entsprechender Name definiert sein.

Für öffentliche IPv6-Adressen wird ein Name durch Deinen ISP vergeben, und dieser verwaltet auch den zugehörigen öffentlichen DNS-Eintrag.
Wenn Du einen eigenen Namen für die öffentliche IP-Adresse sehen möchtest, kannst Du versuchen, für diesen auch einen lokalen DNS-Datensatz anzulegen, z.B. über Local DNS Records.
Für öffentliche IPv6-Adressen macht dies allerdings selten Sinn, da diese Adressen sich zu oft ändern können.

Da Pi-hole nicht beeinflussen kann, mit welcher IP-Adresse ein Client anfragt, müsstest Du alternativ ggf. also entsprechend das Verhalten Deiner Clients anpassen, z.B. indem Du die IPv6 Prefix Policies auf dem Client anpasst.
Oder Du deaktivierst IPv6 in Deinem Netzwerk komplett, sofern Dein Router das unterstützt und Du nicht zwingend darauf angewiesen bist.

Um die Menge der in Pi-hole beobachteten IPv6-Adressen zu reduzieren, kann Dir möglicherweise auch folgende, nicht ganz saubere Konfiguration helfen: Du kannst versuchen, Pi-holes link-lokale IPv6-Adresse (aus dem Bereich fe80::/10) in der FB einzutragen. Dadurch zwingst Du Clients, ebenfalls nur link-lokal anzufragen.

In segmentierten Netzwerken wird dies allerdings nicht mehr sauber funktionieren: Geräte, die in unterschiedlichen VLANs liegen oder über zusätzliche Netzwerkgeräte wie z.B. einen weiteren Router, AP oder L3-Switch verbunden sind, können Pi-hole über die link-lokale IPv6-Adresse nicht erreichen.

Danke für die ausführliche Antwort.
Ich dachte genau hierfür wären unter anderem die ULA Adressen da.

Außerdem sind im Pi-Hole unter Network alle IPs zum jeweiligen Client, welcher einen"*dip0.t-ipconnect.de" Hostnamen hat, ordentlich zugeordnet, weshalb er in der Lage sein müsste diese dennoch zuzuordnen. Spätestens wenn ich z.B. der IPv4 Adresse, die da ebenfalls mit aufgeführt ist über Local Host Records einen zuweise.

Wofür?

Pi-holes *Network overview" basiert auf der Analyse der ARP- bzw. NDP-Caches. Diese Protokolle können lediglich für im selben Netzwerksegment vorhandene Geräte eine einwandfreie Namenszuordnung ermöglichen.
Die Einträge in Pi-holes Query Log basieren dagegen auf dem DNS-Protokoll, d.h. es setzt (wie bereits erläutert) einen vorhandenen DNS-Eintrag (PTR) für eine IP-Adresse voraus.

Pi-holes Entwickler experimentieren derzeit mit der Möglichkeit, Informationen aus der ersten für die letztere Sicht zu verwenden.
Möglicherweise wird dies in einer der nächsten Versionen kommen, eine Garantie dafür gibt es allerdings nicht.
Wenn Du das experimentell nutzen möchtest, wirf einen Blick auf Adding alias-clients to Pi-hole FTL.

Also kann es Pi-Hole gerade schlichtweg noch nicht. Ich schau mir das an. Vielen Dank!

Pi-holes lokale Namensauflösung funktioniert korrekt.

Bei Deiner Beobachtung geht es aber um öffentliche Namensauflösung, die ebenfalls korrekt funktioniert, nur gefallen Dir die korrekten öffentlichen Namen nicht besonders (mir übrigens auch nicht). An dieser Stelle sei noch einmal wiederholt, dass der DNS-Server Deines ISPs für die Vergabe öffentlicher Namen für öffentliche IP-Adressen aus seinem Adressbereich zuständig ist.

Eine mögliche Abhilfe wäre, die öffentliche Namensauflösung lokal zu übersteuern. Das könntest Du wie erwähnt auch in Pi-hole konfigurieren, nur wäre das ziemlich aufwändig, wenn sich die öffentliche IP-Adresse ständig ändert.

Die erwähnten "super-clients" verfolgen mit der Gruppierung von mehreren zusammengehörigen IP-Adressen im Query Log eigentlich ein etwas anderes Ziel, würden aber als Seiteneffekt u.U. dafür sorgen, dass auch Dein Wunsch nach Anzeige eines alternativen Namens statt des durchaus korrekten öffentlichen Namens erfüllt werden könnte.

A post was split to a new topic: Hostname 'unkown' in Network overview

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