Pihole + unbound -- Konfiguration fehlerhaft

Boombastic

Lt. Commander
Registriert
Feb. 2004
Beiträge
1.253
Habe auf dem Pi2 pihole installiert das peoblemlos lief.
Nun habe ich bereits mehrfach versucht unbound nach dieser Anleitung dazu zu installieren.
Danach wird im Webinterface von pihole immer FTL Offline angezeigt und nichts geht mehr.

Da das ganze für mich Neuland ist, bräuchte ich da mal eure Hilfe.

Pi-hole Version v4.3.2 Web Interface Version v4.3.2 FTL Version v4.3.1
 
Tritt während der Einrichtung irgendeine Fehlermeldung oder Warnung auf?
Was liefert der Abschnitt "Test Validation" aus der Anleitung?
Betreibst du bei dir im LAN ein reines IPv4 oder dual-stack mit IPv6?
Funktioniert grundlegend der pi-hole bevor du unbound installierst?
 
Bis zu welchem Schritt hast du die Anleitung abgearbeitet?

Was haben die beiden digs gegen verteiltesysteme.net ergeben?

Was versprichst du dir von der Kombination aus unbound und Pi-hole? Wenn es dir bloß um DNSSEC geht, kannst du im Web-GUI unter Settings → DNS auch eigene Upstream-DNS definieren, z. B. den von digitalcourage und vom CCC:

piholeupstreamdns.png


Gefallen dir die beiden nicht, such dir andere z. B. aus dieser Liste raus.
 
Die Anleitung wurde komplett abgearbeitet. Die beiden digs lieferten ein Ergebnis wie in der Anleitung beschrieben. Nach einem Neustart des Pi2 lif dann nichts mehr, mit besagten Fehler.
Ich wollte halt einen eigenen DNS-Server aufsetzen, den Pi-Hole zuerst anfragt und der erst wenn er keine Antwort kennt, externe DNS-Server abfragt.
 
Das geht mit DNS nicht. Pihole braucht den Forwarder. Zwingend. DNS kann ggfs auch einfach rootserver fragen, aber das macht pihole mW nicht mit.
 
Läuft der Unbound Serverdienst denn nach dem Neustart?

@RalphS Ich verstehe es so, dass der pihole natürlich forwarder spielt nur als upstream Server nicht irgendwelche Drittanbieter fragt sondern den lokal installierten Unbound und was der unbound nicht kennt, holt sich unbound von den root-servern bzw. fragt sich dort zu den authoritativen Servern durch. Dadurch werden nur diese Server abgeklappert und nicht Dritte wie cloudflare, google, $DNS-Server-vom-ISP, etc.
 
  • Gefällt mir
Reaktionen: DeusoftheWired und omavoss
@snaxilian Ja, so soll es mal laufen. Deine Frage kann ich im Moment nicht beantworten, da ich pihole ohne unbound am Laufen habe. Bin etwas frustiert und ohne den Fehler zu kennen würde ich unbound nicht nocmal (3 Versuche) erneut installieren. Kann das mit den Versionen die ich oben aufgeführt habe zusammenhängen, Stichwort Unverträglichkeiten?
 
Die Versionen sollten nicht das Problem sein. Das Webinterface des Pi-hole, den ich auf einem Raspi1 unter Debian Buster Lite laufen habe, sagt jedenfalls, daß es die gleichen Versionen verwendet. Der läuft hier allerdings ohne unbound (unbound hatte ich davor ohne Pi-hole laufen nach dieser Anleitung der c’t).

Gehen wir mal durch, was noch nicht stimmen kann:

Am Ende der /etc/unbound/unbound.conf.d/pi-hole.conf aus deiner Anleitung sind sechs Netze mit entsprechender Subnetzmaske angegeben, für die unbound gelten darf. Die in der Anleitung benutzte 192.168.0.0 wird allerdings als /16-Netz konfiguriert und nicht wie in deutschen Privatverbraucherroutern üblich 192.168.1.0 /24 bzw. 192.168.178.0 /24 bei einer FRITZ!Box. Stelle sicher, daß die Angabe des Netzes und der Subnetzmaske zu deinem LAN passen.

Prüf die Dateirechte der heruntergeladenen root.hints, die in /var/lib/unbound/ liegt. Gib ihr mit sudo chmod 777 /var/lib/unbound/root.hints probehalber Lese- und Schreibrechte für jedermann, starte sämtliche Dienste neu und versuche dann noch mal, das Web-GUI von Pi-hole zu erreichen.

Du hast im Eingangsbeitrag ja geschrieben, daß Pi-hole vor einer unbound-Installation grundsätzlich funktioniert. Tritt der Fehler denn erst auf, wenn du 127.0.0.1#5353 als ersten und einzigen Custom-IPv4-DNS einträgst?

Sprichst du Pi-holes Web-GUI via Hostname oder IP an? Standardmäßig ist es unter http://IP.deines.Raspi2./admin/index.php zu erreichen.
 
Werde ich nochmal testen.
Aus dem Gedächtnis würde ich sagen der Fehler trat nach Änderung auf 127.0.0.1#5353 als ersten und einzigen Custom-IPv4-DNS auf
 
Da du bisher nur stückchenweise auf Fragen antwortest zitiere ich mich mal selbst:
snaxilian schrieb:
Betreibst du bei dir im LAN ein reines IPv4 oder dual-stack mit IPv6?
Was denn du intern über IPv6 eine Anfrage zum pihole schickst und dieser will es per v6 weiter geben, hat aber keinen upstream DNS zu dem er es weiter leiten kann und der pihole macht in dem Fall ggf. keine 6to4 Übersetzung?
 
  • Gefällt mir
Reaktionen: DeusoftheWired
snaxilians Frage ist gut. Hab wegen genau dieser Späße IPv6 in Debian und Pi-hole deaktiviert.
 
@snaxilian @Boombastic
Okay, dann hab ich das mißverstanden... allerdings, zu meiner Verteidigung, der Post über meinem war dann dahingehend tatsächlich mißverständlich dahingehend, daß zu viele DNS-"Neulinge" der Meinung sind, wenn Server A nicht die gewünschte Antwort liefert, dann frag ich eben Server B, und exakt das kann man mit DNS nicht machen.

Ich bin da konservativ. Mein Pihole hängt ganz oben in meiner Infrastruktur, "niemand" fragt den, außer dieser Jemand will eine externe Domain haben und dann fungiert er als Forwarder für den DC. Direkt von Clients wird er nicht befragt.
Aber ich frag lieber meinen ISP als irgendwelche Drittanbieter. Die kriegen sowieso alles, was ich im Netz so treibe, und wenn ich meinem ISP nicht trauen würde, dann müßte ich kündigen.
Root fragen, mh, hatte ich seinerzeit auch überlegt. Ich bin aber der Ansicht, daß rootserver nicht für Endanwender da sind. Klar, muß man nicht so sehen und man hat ja auch als "Normalo" Zugriff drauf, aber.... roots sollen imo das Wichtige tun, nämlich letzte Instanz spielen für fremde TLD, nicht als pauschaler Ansprechpartner für jeden Scheiß.

Aber das ist wohl Ansichtssache.

Wie's dem TO geht weiß ich nicht, aber bei mir läuft auf 5353/tcp eine zeroconf-Instanz (hier: avahi). Evtl wäre es eine Idee erstmal zu gucken ob dort überhaupt der "richtige" Service lauscht.

--- Ha. Natürlich vertan 😊 zeroconf ist natürlich UDP, nicht tcp, kommt also nicht in die Quere. Sorry. Dennoch, sicherheitshalber gucken ob der richtige Service am konfigurierten Port lauscht und nicht irgendwer/-was anderes.
 
RalphS schrieb:
Die kriegen sowieso alles, was ich im Netz so treibe, und wenn ich meinem ISP nicht trauen würde, dann müßte ich kündigen.

Wenn ein einziger Server unter einer IP läuft, dann ja. Ist heutzutage aber nur noch in Ausnahmen der Fall. Beim Rest schützt dich TLS, wenn alles ordentlich konfiguriert ist. Genau deshalb sind ja z. B. die britischen Provider Sturm gelaufen, als Mozilla DoH ab Werk ankündigte.
 
Sagen wir so. Als Sysadmin kotzt mich DoH auch massivst an. Die sollen was ordentliches auf die Beine stellen, nicht so nen unbrauchbaren (aber zugegeben öffentlichkeitswirksamen) Hack.

Aber das ist wohl die Zeit. Die Unixphilosophie -- ja, die greift hier auch --- von wegen Eine Sache für Ein Problem und das Hierarchiemodell sind eindeutig tot. Normale Menschen würden niemals auf die Idee kommen, einen abhängigen Service nochmal herumzuschieben, bis ein Zirkelbezug da ist. Jetzt haben wir DoH, der bootstrapping benötigt, weil er sonst nicht funktioniert, und als ob das nicht genug wäre, kann man damit konzeptbedingt keinen eigenen DNS mehr betreiben. Oder danach filtern, was das angeht.

Daß DNS zu alt ist für aktuelle Ansprüche, geschenkt. Es war nie für Integrität oder Verschlüsselung gedacht, es stammt noch aus einer Zeit, als das ganze System als Vertrauenswürdig eingestuft wurde, lange bevor die Öffentlichkeit Zugriff bekam.
Daß man da was tun muß, daß man Namenszuordnung betreiben können muß, ohne aktuelle End-to-End Verschlüsselung faktisch albern zu machen, weil die Metadaten dafür weiterhin im Klartext vorliegen, auch geschenkt.

Aber nicht mit DNS-over-HTTPS. Da könnten wir auch mit Ethernet over HTTPS kommen. Dann lieber einen encryption layer im OSI Modell einfügen zwischen L1 und L2 (ich nenn es ganz bewußt nicht Verschlüsselungsschicht).
 
RalphS schrieb:
ich nenn es ganz bewußt nicht
Und doch hast du ganz genau das gerade gemacht...
RalphS schrieb:
Root fragen, mh, hatte ich seinerzeit auch überlegt. Ich bin aber der Ansicht, daß rootserver nicht für Endanwender da sind
Genau so funktioniert aber DNS auf Serverseite. Der Client hat einen (oder mehrere) Nameserver konfiguriert und fragt diesen nach einer Domain (www.example.tld). Wenn dein konfigurierter Nameserver den Eintrag nicht im Cache hat, fragt er die root-DNS-Server nach dem RR für die tld-Zone, die authoritativen Server dieser Zone fragt dein Nameserver dann nach dem RR für die Zone example und diese dann nach dem Host www.

Also... zumindest im einfachsten Fall. Wenn der DNS-Server für deine Clients erst den Nameserver deines ISPs fragt schaut dieser in seinen Cache und falls da nix ist dann die root-DNS-Server sofern diese eingetragen sind oder wiederum seinen upstream DNS Server, der wieder in seinen Cache schaut usw usf.
Die "Großen" Anbieter von DNS-Servern wie google, cloudflare, größere ISPs etc haben dementsprechend einfach einen großen Cache und antworten daher so schön schnell.
 
Mir fällt auf, daß er noch den Nutzer unbound und die Gruppe unbound zum Besitzer der root.hints macht: sudo chown unbound:unbound root.hints
 
snaxilian schrieb:
Und doch hast du ganz genau das gerade gemacht...
Okay, ich hab nochmal genauer geschaut. Wollte vorsichtig sein, weil die DE Übersetzung der OSI Layer so unbrauchbar ist... aber der Data Link (L2) nennt sich "Sicherungsschicht", nicht wie ich halb im Hinterkopf hatte "Verschlüsselungsschicht".
Mea culpa. Die Übersetzung ist halt komplett unbrauchbar und bringt - wie man sieht ;-) -- mehr Unklarheiten, als sie löst.

snaxilian schrieb:
Genau so funktioniert aber DNS auf Serverseite.

Ich weiß wie DNS funktioniert :daumen: allerdings funktioniert DNS hierarchisch, das scheint von den allermeisten verkannt zu werden. Gerade im Netz der Netze würden einige wenige Server komplett zusammenbrechen, wenn die pauschal mit der Auflösung für alles und jeden betraut werden würden.

Dafür gibt es die Forwarder. DNS ist auf- und abwärts rekursiv, einmal per Delegation, einmal per Rekursion.

Endgerät => fragt DNS auf dem Heimrouter.
Heimrouter => fragt DNS des ISP.
ISP => fragt Provider des ISP. Der fragt den nächst höheren und wieder den höheren, bis es keinen mehr gibt und daher kein Forwarder mehr gesetzt werden kann.
Erst dieser fragt die Rootserver.
JEDER dieser Unterwegs-DNS hat einen Cache. Die Abfragekette wird sofort unterbrochen, sobald der nächste Server in der Kette einen passenden Eintrag gefunden hat. Die Rootserver werden NUR behelligt, wenn KEINER der Unterwegs-DNS einen Cacheeintrag hat, was üblicherweise nur für "seltene" Ziele der Fall ist. Sagen wir japantimes.jp oder sonst irgendeine Domain im asiatischen Raum, die aus Europa eher weniger angesprochen werden.

In den seltenen Fällen, wo die Rootserver gefragt werden müssen, fragen dann wieder herunter, über die Halter der TLD, die die Provider der Second-level Domain, die den zuständigen NS und ggfs weitere, je nachdem ob es noch 3rd oder tiefere Levels gibt. Also genau wie Du sagst die rekursive Abfrage des DNS. So wird ganz gezielt dafür gesorgt, daß möglichst schnell und möglichst zuverlässig ein Ergebnis bei rumkommt.

Wenn ich natürlich DNS gänzlich in Frage stellen würde, wenn ich niemandem vertraue, mir die richtige Antwort zu geben, dann muß ich wohl den Rootserver fragen. Aber im "Normalfall" werf ich eher die Roothints aus meiner Konfiguration raus und habe dann damit für gesorgt, daß mein DNS-Zugriff (seitens meiner Clients) klar nachvollziehbare Wege geht und daß ich an der Stelle bedarfsweise filtern kann.

Wenn jetzt jeder einzelne Anwender seinen DNS-Forwarder leer lassen würde und zur Auflösung ab Heim(edge)Router direkt die Roots anspricht, dann wäre die Frage nicht, ob diese unter der Last zusammenbrechen, sondern wann.
Ich denke, ein paar Sekunden würden mehr als ausreichen.
 
  • Gefällt mir
Reaktionen: snaxilian
DeusoftheWired schrieb:
[...] Die in der Anleitung benutzte 192.168.0.0 wird allerdings als /16-Netz konfiguriert und nicht wie in deutschen Privatverbraucherroutern üblich 192.168.1.0 /24 bzw. 192.168.178.0 /24 bei einer FRITZ!Box. Stelle sicher, daß die Angabe des Netzes und der Subnetzmaske zu deinem LAN passen. [...]
Daran könnte es gelegen haben. Alles neu eingerichtet und jetzt läuft es.
 
  • Gefällt mir
Reaktionen: DeusoftheWired
Falls es darum geht (private-address: 192.168.0.0/16), dann lag es sicher nicht daran, denn 192.168.0.0/16 beinhaltet auch alle 192.168.x.0/24er Netze.

Ich könnte mir viel eher vorstellen, dass du beim ersten Anlauf vergessen hast, unbound auf Port 5353 zu konfigurieren und er dir deshalb mit dem DNS des Pi-Hole kollidiert ist. 🙂
 
Zurück
Oben