Internet Unterbrechnungen DNS resolver

JeGr

@viragomann said in Internet Unterbrechnungen DNS resolver:

Im Cron Paket kann man bestehende Jobs editieren oder weitere hinzufügen.

Sollte man für pfBlocker aber tunlichst sein lassen! Denn pfB managed das selbst. Was man in den CRON Settings in pfb einstellt ist lediglich, wann zu welcher Stunde der Cron läuft, also ob es wirklich jede Stunde um :00 Minuten ist und wann er zu zählen anfängt (bei 0 oder eben nicht) wenn Jobs konfiguriert sind mit "alle X Stunden". Der Blocker kann/sollte jede Stunde laufen um seine Jobs zu tun! Nur weil er jede Stunde gestartet wird, heißt das nicht dass er auch jede Stunde was tut. WANN er etwas tut, bestimmt dann wieder alleine die IP oder DNS Liste und das Setting dort.

Wenn es mit dem DNS Resolver hapert: ist denn jetzt der Python mode aktiv? Ist im DNS Resolver auch Python aktiv? Ich habe seit meinem Post jetzt nichts davon gelesen, wie die Settings sind außer dass du mit dem DNS Resolver Probleme hast. Zeig doch bitte mal die Einstellungen des Resolvers und deiner DNSBL Settings und der Listen. Sonst ist das alles herumraten im Nebel. Zudem wäre es auch sinnvoll zu wissen, ob der Resolver überhaupt im Resolver Mode läuft oder ob du irgendwo hin forwardest und dort das Problem liegt. Oder MultiWAN. Oder sonstwas. Mehr Details!

@viragomann Ich hatte auf meiner letzten alten Hardware Appliance anscheinend cron installiert, beim Umzug auf die neue ist der Eintrag unter Services wieder gekommen. Das Paket wurde aber nicht installiert.

Alleine das klingt schon danach, als wäre beim Umzug der Restore nicht vollständig gelaufen, sonst wäre das Paket da. Könnte also auch was mit der Installation zu tun haben.

Cheers

viragomann

@jegr said in Internet Unterbrechnungen DNS resolver:

@viragomann said in Internet Unterbrechnungen DNS resolver:

Im Cron Paket kann man bestehende Jobs editieren oder weitere hinzufügen.

Sollte man für pfBlocker aber tunlichst sein lassen! Denn pfB managed das selbst. Was man in den CRON Settings in pfb einstellt ist lediglich, wann zu welcher Stunde der Cron läuft, also ob es wirklich jede Stunde um :00 Minuten ist und wann er zu zählen anfängt (bei 0 oder eben nicht) wenn Jobs konfiguriert sind mit "alle X Stunden". Der Blocker kann/sollte jede Stunde laufen um seine Jobs zu tun! Nur weil er jede Stunde gestartet wird, heißt das nicht dass er auch jede Stunde was tut. WANN er etwas tut, bestimmt dann wieder alleine die IP oder DNS Liste und das Setting dort.

Ich war damit auf eine Frage bezüglich des Cron Pakets eingegangen, von pfBlocker war da keine Rede.
Ich denke nicht, dass das sonst noch jemand so in Zusammenhang gebracht hat.

JeGr

@viragomann Sorry das war nicht alles an dich adressiert gewesen. Hätte ich anders darstellen sollen..

Da ging es mir mehr um

Ich habe zwar in der Auswahl unter Services glaub ich cron, aber da kommt drauf eine Fehlermeldung beim aufmachen. Wenn ich im pfnblocker und smrt auf Update gehe, bekomme ich bei beiden die selbe Ansicht. Auch beim drücken auf view sehe ich, das er verwendet wird.

denn im Screenshot sieht man ja, dass der Haupt-Cron von pfBNG schon verändert wurde. Das ist im Normalfall nicht nötig und sinnvoll da dann auch die Maintenance Tasks nicht angestoßen werden.

viragomann

@jegr said in Internet Unterbrechnungen DNS resolver:

Da ging es mir mehr um
denn im Screenshot sieht man ja, dass der Haupt-Cron von pfBNG schon verändert wurde. Das ist im Normalfall nicht nötig und sinnvoll da dann auch die Maintenance Tasks nicht angestoßen werden.

Aber nicht im Text.

interessierter

@jegr Nein der Python mode im DNS resolver ist nicht aktiv, was ich gemacht habe:

Einen Script mit Cron verbunden, der die Internet Verbindung checkt und den DNS resolver neu startet
Ein paar IP Listen aus dem pfblocker ausgeräumt
Updates alles auf 1 mal am Tag eingestellt, und diese in die nacht verschoben
im pfblocker die Option Resolver Live Sync aktiviert

Ich habe bisher nur einen Restart des resolvers in der Nacht. Im Moment ist Ruhe im Karton

JeGr

@interessierter said in Internet Unterbrechnungen DNS resolver:

Einen Script mit Cron verbunden, der die Internet Verbindung checkt und den DNS resolver neu startet

Warum Workarounds bauen, anstatt die Ursache zu finden und zu fixen?

Ein paar IP Listen aus dem pfblocker ausgeräumt

Das macht immer Sinn.

@interessierter said in Internet Unterbrechnungen DNS resolver:

Updates alles auf 1 mal am Tag eingestellt, und diese in die nacht verschoben

Das ist ja Unsinn. Wenn sich listen mehrfach am Tag - oder bei einigen der PRI1 oder bspw. Firehol1 <1h aktualisieren mit neuen Daten weil gerade was krassiert und ich date die nur einmal am Tag ab ist der Sinn einer aktuellen Liste ja ziemlich klein.

@jegr Nein der Python mode im DNS resolver ist nicht aktiv, was ich gemacht habe:
...
im pfblocker die Option Resolver Live Sync aktiviert

Und warum nicht? Es steht ja noch dazu explizit im Text:

This option is not required when DNSBL python blocking mode is enabled.

Warum nicht einfach mal mit defaults (was Cron angeht) sauber durchspielen:

Cron wieder auf jede Stunde.

Python an im DNS Resolver und dann testen bzw. ne Stunde abwarten.

Klar kannst dus lassen wie jetzt, nur dann hast du eben den kompletten Sinn von rapid-response IP/DNS Blocklisten versäumt und hängst nen ganzen Tag hinterher. Jede Blocklist ist ja schon per se "hinterher" was die Gefahrenlage jeweils angeht. Darum würde ich per se eigentlich versuchen so nah wie möglich an live updates ranzukommen.

Cheers

interessierter

@jegr said in Internet Unterbrechnungen DNS resolver:

@interessierter said in Internet Unterbrechnungen DNS resolver:

Einen Script mit Cron verbunden, der die Internet Verbindung checkt und den DNS resolver neu startet

Warum Workarounds bauen, anstatt die Ursache zu finden und zu fixen?

Um beides zu haben. Der Schmerz wegen der dauernden Untebrechungen war schon groß. Der Workaround soll aber nicht die Dauerlösung sein

Ein paar IP Listen aus dem pfblocker ausgeräumt

Das macht immer Sinn.

@interessierter said in Internet Unterbrechnungen DNS resolver:

Updates alles auf 1 mal am Tag eingestellt, und diese in die nacht verschoben

Das ist ja Unsinn. Wenn sich listen mehrfach am Tag - oder bei einigen der PRI1 oder bspw. Firehol1 <1h aktualisieren mit neuen Daten weil gerade was krassiert und ich date die nur einmal am Tag ab ist der Sinn einer aktuellen Liste ja ziemlich klein.

Das mag sein, sinnlos ist es trotzdem nicht. Wenn sich das ganze stabilisiert hat (und dsa scheint es), kann ich wieder mehr dazu schalten

@jegr Nein der Python mode im DNS resolver ist nicht aktiv, was ich gemacht habe:
...
im pfblocker die Option Resolver Live Sync aktiviert

Und warum nicht? Es steht ja noch dazu explizit im Text:
This option is not required when DNSBL python blocking mode is enabled.

Ich wollte nicht zuviel auf einmal ändern, ich hab ihn jetzt eingeschaltet

Warum nicht einfach mal mit defaults (was Cron angeht) sauber durchspielen:

Cron wieder auf jede Stunde.

Python an im DNS Resolver und dann testen bzw. ne Stunde abwarten.

Klar kannst dus lassen wie jetzt, nur dann hast du eben den kompletten Sinn von rapid-response IP/DNS Blocklisten versäumt und hängst nen ganzen Tag hinterher. Jede Blocklist ist ja schon per se "hinterher" was die Gefahrenlage jeweils angeht. Darum würde ich per se eigentlich versuchen so nah wie möglich an live updates ranzukommen.

Cheers

JeGr

@interessierter said in Internet Unterbrechnungen DNS resolver:

Das mag sein, sinnlos ist es trotzdem nicht. Wenn sich das ganze stabilisiert hat (und dsa scheint es), kann ich wieder mehr dazu schalten

Nein sinnlos ist es nicht, aber unsinnig(er). Darum sag ich auch nicht "das ist doof" weil das falsch wäre - und unfreundlich Was gemeint war, ist klar, es entgeht einem dann der Vorteil der wirklich häufig gepflegten Listen. Aber ja - siehe unten - erstmal einen stabilen Zustand zu haben, ist natürlich wünschenswert.

OK also war Ziel erstmal eine Lösung zu haben die irgendwie funktioniert ohne Dauerabbruch. Kann ich nachvollziehen :)
Wenn das erreicht ist damit, ist das natürlich erstmal gut. Das sollte dann nicht falsch rüberkommen. Wenn du das jetzt auf das Python Module umgestellt hast, bin ich gespannt wie es arbeitet, ich habe da auf der Lab-HW-Box eigentlich keine Aussetzer gehabt im Test trotz voller Latte an Listen. Hatten da zum Test einfach mal alles angehakt auch wenn es explizit genannt wird, dass man das bitte nicht tun sollte ;) War RAM-seitig im Python mode sehr unspektakulär, nach switch auf normal ist die Kiste mit Swap voll abgekratzt ;)
Der Unterschied ist da wirklich enorm :)

interessierter

@jegr Kein Problem!
Stabil war sie dann vorher auch schon, wenn ich noch was improven kann dann gerne. Das Ding muss einfach laufen.

Wie ist den eure Erfahrung mit zuviel Listen, bzw was ist eigentlich zu viel? Meine HW ist neu und auch nicht schwach auf der Brust. Trotzdem habe ich nach dem entfernen von ein paar Listen einen massiven Unterschied im Speed von MS Teams gemerkt. Ich verwende die Office 365 Proxy Liste, und schalte alle IPs und Namen mit einem ALLOW total durch. Irgendwie ist es blöd, es geht jetzt voll super. Welche Liste das aber genau war und warum, kann ich nicht sagen. Ich hab keine Blocks in der Richtung gesehen.

Wie viele Listen habt ihr da aktiv?

JeGr

@interessierter Meinst du jetzt DNS Listings oder eher IP Listings? Die Office 365 Liste ist ja IMHO eine IP Liste oder?

Ansonsten schwer zu sagen was das war, dass es Teams gebremst hat. Das passt nicht wirklich in das Prozedere. Es geht oder nicht wenn es um IPs geht. Oder bei DNS gibt es ggf. Timeouts. Aber langsam klingt komisch.
Eventuell geht das in Richtung "zu viele DNS Einträge" (o.ä.) zu blocken und daher war der Resolver ggf. überfordert und hat einfach langsam geantwortet? Das wäre zumindest ungefähr dann erklärbar. Gerade da sollte aber der Python Mode Abhilfe/Besserung schaffen, da er wesentlich weniger RAM braucht. Also wenns daran hing, dann könnte es sein, dass das Problem jetzt generell besser/weg ist auch wenn du wieder DNSBLs mit dazu nimmst.

Was Listen angeht kann ich jetzt nur IP mäßig sprechen: Da haben wir meist die PRI1 mit Anpassungen drin und inzwischen oft noch die firehol1 und 2. Manchmal auch 3, allerdings haben sich inzwischen auf der firehol_level3 leider durch einige "Spaßvögel" (eher Kackvögel) und deren Doofheit auch IPs von Discord Servern und GitHub FRA mit eingeschlichen. Das kann man durch die Suppression in pfB ganz leicht wieder fixen und allow-listen, aber trotzdem sitzt man im blöden Fall dann erstmal davor und wundert sich, warum was nicht geht. Daher jetzt nur noch 1+2 und 3 mit Ausnahmen wenn überhaupt mit drin. PRI1+Firehol1/2 sind schon so viel große Bereiche, da fällt schon ordentlich was weg - und das natürlich dann von außen wie von innen filtern.

sebden

Ich habe mittlerweile eine Box mit dem gleichen Problem. Vormals die letzte 2.5er Version, aktuell 2.6.0.

Aufgefallen ist es dadurch, dass:

Webseite A lädt auf dem Klienten. Webseite B nicht.

NSLookup auf Webseite B am Klient brachte o.g. Meldung, Server nicht erreichbar o.ä.

DNS Lookup auf der pf ging allerdings.

Neustart -> Unbound und auch der Klient konnte auflösen und die Webseite B laden.

Meine Konfig ist recht nah am Standard würde ich meinen. Ich hänge ein paar Bilder an.

Die Maschine ist die einzige mit diesem HW-Typ, das unterscheidet sie zu einigen anderen mit den identischen Einstellungen. Ist so ein China, All in One PC mit Celeron Prozessor. Zwischenzeitlich wurde ein Cron-Job eingebaut, der die Kiste jeden Tag früh neu startet, dennoch tritt das Problem häufig auf. Und statt meiner Lieblings-DNS Cloudflare oder quad9 läuft mittlerweile nur Google mit 8.8.8.8 und 8.8.4.4.

thiasaef

@sebden, siehe: https://forum.netgate.com/topic/170235/unbound-massively-broken-pfsense-2-5-2/

ich will gar nicht wissen, wie viele Mannstunden mit dem Bug schon vernichtet wurden ... es ist einfach nur traurig.

sebden

Besten Dank @thiasaef

Ich habe den besagten Patch zur Probe mal aktiviert. Ein Leeren des Caches wäre mir im Vergleich zum bestehenden Problem wirklich egal.

Ich melde mich hier nochmal zurück, falls es Neuigkeiten gibt.

sebden

Leider war der Patch keine Lösung. Das Problem besteht weiterhin, nur scheint es (gefühlt) seltener aufzutreten.

Aktuelle Krücke: Per Cron erfolgt 5min nach dem pfBlocker-Job ein Neustart vom Unbound. Seit einigen Wochen herrscht somit erstmal Ruhe.

NOCling

Warum genau nutzt du den Resolver im Forwarding Mode?
Welche Version vom pfBlocker?
Wie ist die maximale Tabellengröße eingestellt?
Ram Disk aktiv, wenn ja ist die groß genug für das pfBlocker Update oder läuft die dabei über?

Und die GUI auf deutsch zu stellen ist wirklich grausam, kann ich nur von abraten, denn so findest du nix dazu im Handbuch.

sebden

@nocling

Zu 1: Ich bevorzuge die Server von 1.1.1.1 oder auch 9.9.9.9. Zumindest offiziell loggen Sie nicht und sind performant mit Unterstützung von DoT.

Zu 2: pfBlockerNG-devel 3.1.0_1, wobei es mittlerweile ein kleines Update gibt.

Zu 3: Wenn du Maximale Firewall Table Einträge meinst, dann 400000.

Zu 4: Nicht dass ich wüsste. Ich habe SWAP 0% von 4096MiB in Nutzung, sowie / 3% von 111GB ufs und tmpfs 3% von 4.0 MiB.

Ich mag die deutsche GUI Klar wäre die englische jetzt auch kein Problem.

NOCling

Die Funktionsweise von Unbound ist hier gut erklärt:
DNS Resolver Root Server Question

sebden

@NOCling

Ich werde mal testhalber auf meiner privaten Büchse das rooten testen. Aus Sicht der Privatsphäre, ist das dann weniger Anonym? Nur unter der Annahme 1.1.1.1 oder 9.9.9.9 würden tatsächlich nicht loggen - sonst wäre die Frage natürlich sinnfrei.

Konntest du anhand der Angaben im Post vorher eine Fehlkonfiguration entnehmen, die das Problem mit Unbound erklären könnten? Er läuft ja, dient aber keinem Klienten mehr am LAN Port. Ein Lookup aus dem Diagnose-Bereich klappt bei der betroffenen Kiste immer. Ohne Patches und ohne Cron-Job zeigt sich das Problem fast jeden Tag nach einigen Stunden Betrieb.

@thiasaef Hat, genau in dem von dir genannten Thread, ein noch bestehendes Problem mit Unbound angesprochen. So richtig bewegt sich bei dem Thema gefühlt nichts. Ob mich nun genau dieser Bug betrifft kann ich nicht sagen. Aber ein wenig traurig ist es schon

Bob.Dig

Hier gibt es auch im Forwarding Mode keinerlei Probleme.

NOCling

Ich habe hier selber 2 Kisten und keine Probleme, Kollegen haben auch ein paar und auch die haben mit recht ähnlichen Settings keine Probleme.

Es sind halt im pfBlocker und im Unbound unzählige Einstellungen die man setzen kann, eine davon kann dann ggf. Probleme bereiten.
Gerade in den erweiterten Einstellungen bei Unbound sollte man aufpassen, hier kann man sich auch die komplette DNS Funktionalität untergraben.

Das Undound aber nicht mehr startet hatte ich noch auf keiner Kiste.

Ein Kollege hat mit dem "pfb_dnsbl" Dienst zur Zeit ein Problem, hier will der Webserver nicht starten. Merkert scheinbar das der Port verwendet wird, wird er jedoch nicht. Weder laut Config noch laut Sockets Übersicht.