DNS-Resolver funktioniert nur pfSense-intern (von localhost)
-
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!
