DNS-Resolver funktioniert nur pfSense-intern (von localhost)
-
@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).
-
@n300 said in [DNS-Resolver funktioniert nur pfSense-intern (von localhost)](/post/1032223
@viragomann
Hast du einen Business-Anschluss, oder Privat? Ich bin hier privat unterwegs, vielleicht ist das der Unterschied.Nein, ist auch privater DSL mit PPPoE.
Ich möchte aber nicht gänzlich ausschließen, dass sich der Anschluss in Salzburg anders verhalten kann als hier in NÖ.Ich bekomme hier vom selben Server eine Antwort. Im Resolver habe ich DNSSEC übrigens eingeschaltet. Denke aber nicht, dass das einen Unterschied macht.
Jedenfalls kommst du ja auch mit Traceroute auf den DNS Server. Ein Fehl-Routing wäre da noch denkbar gewesen, das tritt oft nur lokal auf. Das ist es aber nicht.
Hab dann auch keine Idee mehr. -
Ja das Witzige ist ja, ich bekomme auch über nmap auf udp und sogar tcp 53 ne Antwort. Es scheint fast so, als wolle der Root-DNS mit meinem Unbound einfach kein "DNS" sprechen.
-
@n300
Ja, sieht so aus. Es würde aber ebenfalls so aussehen, wenn die Anfragen außerhalb deines Netzes blockiert würden.
Allerdings verwendet die pfSense nicht nur einen Root DNS-Server, sondern einen Pool mit etwa ein Dutzend, soweit ich weiß. Und wenn der eine nicht antwortet, sollte sie den nächsten anfragen. Daher würde ich meinen, du müsstest weitere Server-IPs im Capture sehen.Die pfSense Docs weisen auch darauf hin, dass die Root DNS-Server blockiert werden könnten: DNS Resolver Mode.
A1 "macht so etwas allerdings nicht gerne". Jedenfalls nicht, wenn man nachfragt.
Könntest du vielleicht versuchen, wenn du den Resolver Mode verwenden möchtest. -
Ja A1 "macht so manche Dinge nicht gerne". War gar nicht so einfach den alten Router in den Modem Modus versetzen zu lassen. Das war auch nur mit Murren und sehr widerwillig.
-
@sebden said in DNS-Resolver funktioniert nur pfSense-intern (von localhost):
Der Weiterleitungsmodus bzw. Forward ist mMn doch ein völlig normales Einsatzszenario. Warum wird auf Biegen und Brechen versucht das inaktiv zu bekommen?
Es mag normal sein, aber genauso ist DNS Resolution völlig normal und wenn das am Anschluß nicht geht, dass ich selbst mit einem DNS Root Server sprechen kann/darf, dann ist da was faul und das möchte man ggf. doch wissen, oder?
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.)
Eigentlich sollte genau das nicht passieren - also dass ein zwei angegebene Server gefragt werden. Das ist einfach nur ein Faulheits- und Abhängigkeitskonstrukt aus der Neuzeit. Geplant war DNS so nicht, sonst gäbe es keine Root Server, sondern die Roots wären heute das, zu was sich 8.8.8.8, 9.9.9.9 oder 1.1.1.1 entwickelt haben. Und gerade jetzt wo wir im Kriegsfall sehen können, wie schnell man mit der Keule kommt irgendwas "zentralistisch" abzuschalten, blocken, zensieren oder entfernen, sollte man bemerken warum "Zentralismus" nichts Sinnvolles ist, was man im Internet haben möchte.
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.)
Genau. So lange bis dann - bspw. der Provider - eben nicht nur den Zugriff auf die Roots sperrt, sondern auf alles und einfach schlicht jeden DNS Query umlenkt auf seinen eigenen DNS. Und dort dann zensiert, egal was du woanders einstellst. DNSSEC funktioniert BTW genau mit DNS Forwarding gar nicht, denn DU bekommst keine Antwort vom DNS Server, nur ein Ergebnis. Der Forwarder den du eingetragen hast ist der einzige, der valides DNSSEC machen kann.
Und genau um solche unnötige und auf Dauer eher schädliche Zentralisierung nicht zu fördern ist es hilfreich den "normalen" Weg via DNS Roots wesentlich häufiger zu nutzen, weswegen beide Sensen bspw. inzwischen eben auf Unbound und DNS Resolution als Standard gewechselt haben.
Ja für das Problem ist Forwarding vielleicht ein Workaround der völlig genügen kann. Mich würde es aber persönlich durchaus interessieren, warum ich bspw. keine DNS Roots befragen darf. Und wenn es tatsächlich nicht an Konfiguration oder Problem beim Provider liegt (bspw. sein IP Range geblockt von Upstream oder Roots weil mißbraucht) - warum mein ISP den ich für (freies) Internet bezahle mir das verbietet?
Aber da es um A1 und Österreich geht, weiß ja vielleicht @noplan als Landsmann was.
Cheers
-
Sorry für die Leichenschänderei. Aber ich habe nun endlich eine recht findige Lösung gefunden zum Problem -> "Resolver-Mode funktioniert über meinen ISP A1.net nicht!"
Wir haben festgestellt, dass A1 offenbar keine grundsätzliche Drop-Rule für UDP/TCP 53 Richtung Root-DNS Server hat. Jedoch Root-DNS-Queries irgendwie unterbindet... Allerdings nur über UDP. TCP ist nicht blockiert.
Im Chat von -> https://chat.dns-oarc.net/ wurde mir dann geholfen. Wir haben Unbound mit folgender Stub-Zone in den Advanced Settings nun dazu gezwungen alle Root-Anfragen immer über TCP zu schicken. Und siehe da. Es geht :)
stub-zone: name: "." stub-tcp-upstream: yes stub-addr: 170.247.170.2 #b.root-servers.net stub-addr: 192.33.4.12 #c.root-servers.net stub-addr: 199.7.91.13 #d.root-servers.net stub-addr: 192.5.5.241 #f.root-servers.net stub-addr: 192.112.36.4 #g.root-servers.net stub-addr: 193.0.14.129 #k.root-servers.netunbound log Auszug:
Sep 10 13:14:59 unbound 78401 [78401:1] info: validator operate: query orf.at. AAAA IN Sep 10 13:14:59 unbound 78401 [78401:1] info: finishing processing for orf.at. AAAA IN Sep 10 13:14:59 unbound 78401 [78401:1] info: reply from <orf.at.> 192.174.68.100#53 Sep 10 13:14:59 unbound 78401 [78401:1] info: response for orf.at. AAAA IN Sep 10 13:14:59 unbound 78401 [78401:1] info: iterator operate: query orf.at. AAAA IN Sep 10 13:14:59 unbound 78401 [78401:1] info: processQueryTargets: orf.at. AAAA IN Sep 10 13:14:59 unbound 78401 [78401:1] info: iterator operate: query orf.at. AAAA IN Sep 10 13:14:59 unbound 78401 [78401:1] info: processQueryTargets: orf.at. AAAA IN Sep 10 13:14:59 unbound 78401 [78401:1] info: iterator operate: query orf.at. AAAA IN Sep 10 13:14:59 unbound 78401 [78401:1] debug: sending to target: <orf.at.> 192.174.68.100#53 Sep 10 13:14:59 unbound 78401 [78401:1] info: sending query: orf.at. AAAA IN Sep 10 13:14:59 unbound 78401 [78401:1] info: processQueryTargets: orf.at. AAAA IN Sep 10 13:14:59 unbound 78401 [78401:1] info: iterator operate: query orf.at. AAAA IN Sep 10 13:14:59 unbound 78401 [78401:1] info: processQueryTargets: orf.at. AAAA IN Sep 10 13:14:59 unbound 78401 [78401:1] info: response for orf.at. AAAA IN Sep 10 13:14:59 unbound 78401 [78401:1] info: iterator operate: query orf.at. AAAA IN Sep 10 13:14:59 unbound 78401 [78401:1] info: sending query: orf.at. A IN -
@n300 Das ist tatsächlich mal ein vorbildliches Ergebnis von "Leichenfledderei" ;) Also nach all der Zeit tatsächlich einen Workaround zu haben, macht hier auf jeden Fall Sinn - da braucht es dann auch kein Sorry :)
Finde ich aber sehr interessant, dass hier wohl UDP versagt. Das klingt eher so, als würde A1 da vllt unterwegs DNS/UDP mit zu großer Payload vllt wegfiltern(?) um ggf. irgendwelche DNS countermeasures umzusetzen o.ä. oder es ist tatsächlich irgendwelche MTU oder sonstiger Kram - der bei TCP dann nicht zu Tragen kommt, weil es da frisch ausgehandelt werden kann. Spannend. Und durchaus wichtig zu wissen um das ggf. als Debug/Diagnose mal nutzen zu können!
Danke dafür!
