Internet Unterbrechnungen DNS resolver

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.

sebden

@nocling Unbound läuft. Aber niemand am LAN bekommt noch etwas aufgelöst. Nach einem Neustart dient Unbound dann auch wieder den Klienten.

Edit.: Das Problem habe ich auch nur an einer Box, andere mit identischem Setup laufen ebenso.

NOCling

DNS Resolver Log sagt dann was?
Auf welchen Interfaces lauscht er?
Ein Mitschnitt auf LAN/WAN zeigt was?

sebden

Da seit dem Cron-Job schon einige Wochen rum sind, reichen die Logs nicht weit genug zurück (es fehlen 3 Tage -.-). Für mein ungeschultes Auge stand dort lediglich periodisch die Aktion vom pfBlocker drin, gefolgt von 1-2 Einträgen die nicht aufzulösen sind (in der Regel tel.t-online.de und anydesk.com).

Gesetzt war als lauschendes Interface nur LAN. Hatte ich nebenher auf ALLE geändert.

Mitschnitt ist aktuell nicht möglich, da müsste ich schauen wann ich die Box sehenden Auges nochmal in das Problem laufen lassen kann.

thiasaef

@sebden said in Internet Unterbrechnungen DNS resolver:

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

Der Patch hat nur dann einen Effekt, wenn bei dir gewollt oder ungewollt rc.newwanip Events stattfinden.

@sebden said in Internet Unterbrechnungen DNS resolver:

da müsste ich schauen wann ich die Box sehenden Auges nochmal in das Problem laufen lassen kann.

Um auszuschließen, dass es an obigen Bug liegt, sollte es genügen, das LAN Kabel kurz abzuziehen und wieder einzustecken und zu schauen, ob DNS Anfragen aus dem LAN danach noch beantwortet werden.

@nocling said in Internet Unterbrechnungen DNS resolver:

Gerade in den erweiterten Einstellungen bei Unbound sollte man aufpassen, hier kann man sich auch die komplette DNS Funktionalität untergraben.

Der Witz ist doch, dass DNS-Abfragen unter Diagnostics / DNS Lookup offenbar trotzdem noch klappen, was fast alle klassischen Konfigurationsfehler ausschließen dürfte.

sebden

Stimmt, dachte aber (da der Patch aktiv ist), dass es eher nicht dieser Bug ist.

Edit: Teste es dann trotzdem nach Möglichkeit nochmal!