PI Hole DNS Resolution von Statischen IP's

Hallo! Ich glaub ich bin zu blöd für Pi Hole! :slight_smile:

Ich will meinen alten internen DNS Server mit dem Pi Hole ablösen, und das funkioniert auch - für alle Clients, welche eine dynamische IP haben, oder eine DNS Reservierung bezogen haben. Aber es ist nicht möglich, Clients aufzulösen, welche einen statische IP haben, oder / und eine DNS Reservierung eingetragen haben, welche aber nicht bezogen wurde. Da gibts einfach keine Auflösung von dem jeweiligen Namen. Auch nicht wenn der Pi Hole als primary DNS konfiguriert ist. Warum ist das so? Praktisch jeder interne DNS Server kann das.

Du kannst für diese Client einen "Local DNS Record" anlegen

1 Like

Ja das kann ich machen, aber das muss ich manuell machen. Ich vermisse ein automatische Registrierung.

Ist Pi-hole auch dein DHCP Server?

Grundsätzlich ja, aber ich habe Testserver, die brauchen eine fixe IP.

Auflösung der Clients, welche eine DHCP Lease beziehen, oder eine AKTIVE Reservierung haben, funktioniert. Aber eben nicht von statischen Clients oder INAKTIVER Lease.

Da muss man zwei Sachen unterscheiden:

Clients mit statischen Konfigurationen melden sich ja nirgendwo an, oder signalisieren, dass sie da sind. Entsprechend weiß auch niemand, wie die Hostnamen sind, bzw. Pi-hole nicht, wie die DNS -> IP Assoziation ist. Da musst du also immer händisch im DNS server hinterlegen, welcher Hostname zu den statischen Clients gehört.

Über INAKTIVER Lease wurde hier im Forum/Github letztens auch diskutiert. Ich finde den Beitrag leider nicht mehr, denke aber, dass das Fazit war, dass das auf dnsmasq (zentraler Bestandteil von Pi-hole) zurückzuführen ist. Ob nun Bug oder per design weiß ich leider nicht mehr.

Ok danke.

Aber das verstehe ich nicht. Mein Linksys Router kann mit dnsmasq Leases auflösen, welche inaktiv sind.

Das ist per design. Statische Reservierungen existieren nur innerhalb der Datei solange sie kein Gerät benutzt. Erst wenn ein Gerät mit gegebener MAC Adresse nach einem Lease fragt, schaut dnsmasq in der Datei nach, ob dort bereits ein Einrag vorhanden ist und nutzt diesen dann ggfs.

Im Linksys werden dann zwei Listen angelegt, eine mit IP <-> Hostname und eine mit den statischen Reservierungen. Das ist so in Pi-hole nicht vorgesehen, auch wenn man sicher darüber diskutieren könnte ob dies das normale Verhalten sein sollte.

Die Frage ist eben, was passieren sollte, wenn man die Liste ändert. Dann muss der gesamte DNS-Cache invalidiert werden. Das wird auf dem Linksys so funktionieren, da man da die volle Kontrolle hat (Steuerung nur per Weboberfläche möglich). Pi-hole erlaubt ja aber auch einen Betrieb komplett ohne Weboberfläche mit manuellem Editieren von Dateien.

Wenn wir etwas implementieren, dann sollte es auch grundsätzlich (und nicht nur über bestimmte Wege) funktionieren. Das stelle ich mir schwierig vor.

Ich verstehe den Ansatz, aber stimme nicht zu. Wenn man einen DNS hat, sollte er auch die gleiche Funktionalität haben.

Ehrlich, diese Aussage bringt mich zum überlegen, ob ich nicht Pi Hole einfach wieder als vorgeschalteren DNS weiter benutze, und beim Windows DNS Server bleibe. Das soll jetzt kein Troll Kommentar sein, ist aber für mich ein KO Kriterium.

Cache invalidieren wär mir so egal, wie der Reis Sack in China. Das würde ich in Kauf nehmen. Wie auch immer, muss überlegen wie ich hier weitermache. Bevor ich diese Bürde auf mich nehme, zahle ich lieber die Stromkosten von meinen Server weiter.

73 de OE3GWU :wink:

Wie viele Geräte betrifft dass denn bei dir? Wie oft änderst sich da der DNS Eintrag?


Was ist denn dein genaues Nutzungsscenario? Wofür brauchst du eine DNS Auflösung für Geräte, die gerade ehe nicht erreichbar sind (inaktiver lease)?

Dieses Verhalten ist beabsichtigt, denn so können mehrere DHCP-Host-Einträge für dieselbe MAC-Adresse in verschiedenen Subnetzen (mit unterschiedlichen Adressen) existieren. Nur die Adresse, die zu dem Subnetz übereinstimmt, in dem der Host zuletzt ein DHCP-Lease erhalten (oder erneuert) hat, ist aktiv. Dies ist z. B. bei einem Laptop, der in verschiedenen drahtlosen Netzwerken auftaucht
nützlich und anderweitige Konfliktlösung nicht unbedingt einfach zu realisieren.

Alles in allem würde ich sagen, dass statische DHCP-Leases für Geräte die niemals DHCP nutzen eine gewisse Dehnung der Möglichkeiten sind. Man kann komplett (!) auf statische Adressen verzichten, wenn sich alle Geräte per DHCP diese Informationen abholen. Typischerweise verwendet man statische Adressen dennoch für Router (bzw. Gateways im Allgemeinen) und DNS-Server um die Übersicht zu behalten. Statische Adressen darüber hinaus müssen aber eigentlich nicht sein - denn dafür gibt es ja den lokalen DNS Server.

Wenn man unbedingt statische Geräte haben möchte, dann würde ich die in einem separaten Segment platzieren. Zum Beispiel den Router auf .1, den DNS-Server auf .2 und sämtliche weiteren statischen Geräte fortfolgend. Der dynamische DHCP-Pool kann dahinter anschließen, also z.B. .20 - .200

Am Ende kann es jeder so machen wie er es für sich am besten empfindet und man lernt erst mit der Zeit was wirklich praktikabel ist und was vielleicht einfach ein bisschen unnötige Arbeit macht. Pi-hole erlaubt dies alles. Und aufgrund eben jeder generischen Verwendbarkeit (und dem hier im ersten Absatz genannten Grund) ist es sinnvoll nicht genutzte DHCP Leases nicht per DNS anzubieten. Hierfür sollte entweder Local DNS Records oder manuelle Einträge in der /etc/hosts auf dem Pi-hole verwendet werden.

Ich habe einen Windows Failovercluster laufen als Test virtuell. Sag ihm das mal, dass er per DHCP beziehen soll. Der lacht dich aus. Und 2 Kyocera Router können absolut nicht mit Leases arbeiten. Die holen sich trotz lease irgendeine IP ab, weisl zur MAC hinten eine dynamische Kennung hinzufügen.

Detto Raspberry Pi's. Die fügen auch eine dynamische Kennung zur MAC hinzu, damit kann ein Windows DHCP umgehen, aber ein Pi Hole nicht. Und der Workaround den ich damals nutzte im Pi, um diese Kennung zu deaktivieren geht nichtmehr.

Ich hab damit knapp 15 Geräte, welche ich so nicht bedienen kann. Deswegen bleibe ich beim Windows DHCP und DNS Server. Da habe ich weniger kopfweh. Wenn das Pi Hole nicht kann, kann ich es nicht einsetzen.

Ich bin an Details interessiert um das zu verbessern. Ich habe hier auch mehrere RPis im Einsatz (viele andere auch) und überhaupt keine Probleme mit DHCP für alles.

Na gut, wenn das aufgrund fehlender Konfigurationseigenschaften oder mangels Support oder Fehlern in Geräten nicht geht, dann steht das dem entgegen. Obwohl ich dann ja argumentieren würde die auch fehlerhaft verhaltenden Geräte zu ersetzen. Aber ich sehe natürlich, dass das nicht immer eine Lösung sein kann. Insofern geht mein Ansatz natürlich von einer heilen Welt mit kooperativen Geräten aus.