DNS-Resolver funktioniert nur pfSense-intern (von localhost)
-
@n300
Die Probleme mit dem DHCP Registrierungen (nicht "static DHCP" Registrierungen) haben etwas mit dem Python Modul zu tun. Wenn du dieses nicht nutzt, dann sollte es auch keine Probleme machen.
Allerdings solltest du noch mal lesen, was der Unterschied zwischen dem Forwarding und Resolving Modus ist.
https://docs.netgate.com/pfsense/en/latest/services/dns/resolver-modes.html
Das gesetzte Häkchen ist also nicht unbedingt die Lösung!
Hast du probiert, testweise pfBlocker zu deaktivieren? -
OK, nein die Python (Methode) hab ich derzeit nicht in Verwendung.
Mittlerweile geht ja alles. Seitdem das Forwarder-Häkchen sitzt. Läuft es wie es soll und ich hab den Großteil auch schon vom piHole übersiedeln können. Jetzt muss ich den den pfBlockerNG noch "feinschleifen". Bin mir der Doku noch lange nicht durch. Mächtiges Teil :)
-
@m0nji said in DNS-Resolver funktioniert nur pfSense-intern (von localhost):
Das gesetzte Häkchen ist also nicht unbedingt die Lösung!
Es ist jedenfalls eine. Und manchen reicht das offensichtlich schon.
-
Also ich verwende schon den "DNS Resolver". Der "DNS Forwarder" ist nicht aktiviert.
Besagt das Häkchen nicht nur, dass für DNS-Queries außerhalb seines eigenen Dunstkreises die Upstream-Server bemüht werden sollen?EDIT:
Ach ich verstehe schon. Hab jetzt das Manual noch etwas bemüht.
Ja nach außen hin scheint das wirklich im forwarder-modus zu laufen. Möglicherweise werden derartige Queries wirklich durch meinen ISP geblockt. Gute Frage wie man das feststellt, außer durch die Feststellung, dass es wohl nicht funktioniert.
Bin in Österreich bei A1. Vielleicht weiß da wer was dazu. -
@n300
Ich habe doch oben erklärt, was der Haken bewirkt.
Standardmäßig verwendet der Resolver Rootserver für die Auflösung, die man nicht selbst einstellen kann.
Mit DNS Forwarding gesetzt wird er quasi zum Forwarder und leitet die Anfragen in die Server weiter, die man in der pfSense eingestellt. Ist ja da auch schön beschrieben. -
@viragomann
Du hast recht. Hab es falsch verstanden. Muss gestehen, bislang hatte ich noch nie etwas im privaten Umfeld, was etwas anderes Unterstützt als forwarden.siehe auch meinen Edit oben ;)
-
@n300 said in DNS-Resolver funktioniert nur pfSense-intern (von localhost):
Bin in Österreich bei A1. Vielleicht weiß da wer was dazu.
Ich auch. Das dürfte wohl nicht das Problem sein.
Habe dann ehrlich gesagt keine Idee, warum es nicht funktioniert. Hätte auch mal empfohlen, den DNSBL und pfBlockerNG zu deaktivieren, aber das hast du ja schon, wie ich es verstanden habe.
Wenn du es lösen möchtest, musst du dich wohl mit Logs abmühen, System und DNS Resolver, oder uns die hier bereitstellen.
Läuft der Resolver überhaupt, wenn er nicht im Forwarder-Modus ist? -
@viragomann
Ich muss da leider morgen weiter machen. Wenn ich meiner besseren Hälfte heute schon wieder das Internet abdrehe gibt's Stunk
Aber vielen vielen Dank schon mal für die wirklich kompetente Unterstützung!
-
Liegen die Netze an der pfSense an, musst du die Access Lists im Resolver nicht pflegen, da die Sense diese ja kennt und deren Gateway ist.
Erst wenn du Netze zur pfSense routest, die sie selber nicht kennt, da sie hier kein Interface drin hat, dann musst dieses Netz in der Access List aufgenommen sein, sonst funktioniert hier kein DNS.
Dazu brauchst du aber eine Routing Instanz hinter der pfSense, sprich z.B. einen Core Switch der dann über L3 weitere Netze versorgt und über die Default Route zur pfSense weiter leitet.
Der Resolver in der pfSense ist ein sehr mächtiges Tool, hier kannst du sehr viel Einstellen und das einen oder andere hat massive Auswirkungen ob es dann noch funktioniert oder auch nicht.
Bietest du deinen Clients z.B. nur noch DNSSEC an, hast aber keine gültigen Zertifikate, hast du ein Problem.
Genauso wenn du Features wie "Strict Query Name Minimization" aktivierst, das mögen nicht alle DNS Server da draußen im Internet.Ob dein Provider DNS ausgehend blocked, kannst du doch über einen Paktmitschnitt leicht rausfinden.
Einfach DNSSEC abschalten für ausgehende Anfragen, dann versuchen was auf zu lösen wenn du auf dem WAN Port 53 mitschneidest.Der Dienst läuft bei dir aber auch oder, nicht das bei dir einfach Unbound nicht gestartet ist, dann kannst du Einstellen was du willst, es wird kein DNS für die Clients funktionieren.
-
Guten Morgen zusammen,
also ich hab grade noch mal etwas getestet und nen Capture angeworfen. Ich sehe die ausgehenden Anfragen zum Root-DNS. Aber Antwort kommt keine zurück. Pingen kann ich den aber wohl. Scheint mir dann wirklich gesperrt zu sein.
Ach ja, hier noch der Service Status:
Das mit der Access List hab ich mir schon gedacht. Um es komplett auszuschließen, dass es daran liegt, hab ich da zum Testen die lokalen 192.168.0.0/16 eingetragen. Werde ich dann wieder rausnehmen.
Was mir auch noch auffällt.
Ist das bei euch auch so, dass der Unbound ewigst braucht neue Konfigs zu übernehmen? Dauert bei mir sicher ne Minute zum Saven und noch mal eine um es dann zu übernehmen. Zuerst dachte ich es liegt an der schwachen CPU der netgate. Aber lt. top tut sich da gar nix. 90% idle beim speichern. -
Der Unbound braucht bei mir 6s zum Speichern und 5s für das "Anwenden".
Bei mir läuft er inkl. Python Modul für den pfBlockerNG-Devel.
Ohne Python aber inkl. pfBlocker war das aber (glaube ich) ähnlich lange, aber das ist länger her ^^
Maschine ist ein 2-Kern Celeron.
-
@n300 Die Frage wurde dir zwar schon mehrfach gestellt aber eine Antwort konnte ich nicht finden: Hast du testweise den pfBlocker mal deaktiviert und Unbound neugestartet?
-
@n300
Die DNS-Abfragen gehen an deinem WAN mit der WAN IP als Quelle an den DNS-Server, doch es kommen keine Antworten zurück.
Mir fällt da nichts ein, was auf deiner Seite falsch laufen sollte. Das wird entweder außerhalb geblockt oder fehl-geroutet.Letzteres kannst du mit Traceroute aus dem Diagnostic Menü feststellen. Wenn ich ein Trace auf die Server IP 199.7.91.13 mache, habe ich gerade mal 5 Hops.
Wie ist das bei dir? -
Lasse mal Testweise die Fritz per PPPoE Einwählen.
Dann hänge die pfSense als exposed Host dahinter. -
Ich hab jetzt nochmal das folgende versucht:
- pfBlockerNG abgedreht u. Ubound restarted -> geht nicht
- testweise das Python-Modul geladen -> geht nicht
Nmap auf UDP 53 sowie TCP 53 von der pfsense aus auf den Root-DNS versucht. Die Ports sind beide offen.
Es scheint einfach so, also wolle der Root-DNS mit mir nicht sprechen.hier auch der traceroute:
[22.01-RELEASE][admin@pfSense-HW.fritz.box]/root: traceroute 199.7.91.13
traceroute to 199.7.91.13 (199.7.91.13), 64 hops max, 40 byte packets
1 188-23-119-254.adsl.highway.telekom.at (188.23.119.254) 6.195 ms 6.576 ms 5.954 ms
2 lg85-9076-3219.as8447.a1.net (195.3.93.1) 9.464 ms 9.623 ms 9.850 ms
3 * * *
4 * * *
5 as42-vie.pch.net (193.203.0.33) 12.125 ms 11.371 ms 11.469 ms
6 d.root-servers.net (199.7.91.13) 10.774 ms !Z 11.163 ms !Z 10.964 ms !Z
[22.01-RELEASE][admin@pfSense-HW.fritz.box]/root:
Fritzbox wieder als Router möchte ich eigentlich nicht. Sollte es das wirklich sein, dann hab ich doch lieber DNS-Forward anstatt nem doppelten NAT ;)
-
Das war nur für einen Test gedacht, aber deine Entscheidung.
-
@nocling
Ich werde das bei Zeiten mal versuchen. Ist nicht immer ganz einfach hier nen Timeslot zu finden, wo sich keiner über nicht funktionierendes Internet beschwert. ;) -
Der Weiterleitungsmodus bzw. Forward ist mMn doch ein völlig normales Einsatzszenario. Warum wird auf Biegen und Brechen versucht das inaktiv zu bekommen?
Alle Anfragen, die der lokale DNS nicht kennt, werden zu den angegebenen Servern geleitet und danach lokal im Cache gehalten oder nicht? Genau das soll doch auch so passieren. Nebenher habe ich die freie Wahl welchen Server ich eintrage und ob/wie ich die Anfragen auf den Weg dahin verschlüssle (DoT, DNSSEC usw. usf.)
-
Ich bin jetzt im DNS-Thema auch nicht ganz so tief drinnen. Dachte daher auch, dass dies eigentlich "DAS" Standard-Szenario wäre und war daher ganz verwirrt, als mir gesagt wurde, dem wäre eigentlich nicht so. Was ich mir vorstellen könnte ist, dass man im Resolver-Modus eben noch etwas Anonymer unterwegs ist und zusätzlich nicht von etwaiger Zensure öffentlicher DNS-Server unterworfen wird.
Vermutlich ist es global jetzt nicht angedacht, dass jeder zu den Root-Servern fragen geht. Könnte mir schon vorstellen, dass das dann ein Kapazitätsproblem werden könnte.
@viragomann
Hast du einen Business-Anschluss, oder Privat? Ich bin hier privat unterwegs, vielleicht ist das der Unterschied. -
Laut Dokumentation unter netgate ist dem ja auch so. Nur habe ich das persönlich nie genutzt.
Ich hielt das eher für einen Notbehelf und setze grundsätzlich selbst gewählte Server ein. Wer Wert auf Privatsphäre legt, fährt sicher nicht gänzlich verkehrt mit quad9 (Schweiz?) oder Cloudflare (geben zumindest an nicht zu Speichern). OpenDNS wäre auch eine Möglichkeit.
Alle 3 unterstützen meines Wissens DNS-over-TLS (zumindest aber quad9 und Cloudflare).
