debian bookworm bind9 vs. libuv

2023-12-05 Diskussionsfäden ronny
Guten Morgen,

meine Nikolausüberraschung ist ne doofe.

Linux-Gateway wegen Kernelaktualisierung (baue selber) neu gebootet und
plötzlich geht der bind nicht mehr. Ein dig @127.0.0.1 liefert nun SERVFAIL
und folgende Logeinträge:

06-Dec-2023 07:21:32.145 general: error:
netmgr/uverr2result.c:98:isc___nm_uverr2result(): unexpected error:
06-Dec-2023 07:21:32.145 general: error: unable to convert libuv error code
in udp_send_cb (netmgr/udp.c:802) to isc_result: -89: destination address
required
06-Dec-2023 07:21:32.145 resolver: info: resolver priming query complete:
unexpected error

Was liegt nahe? Änderungen rückgängig machen. Also reboot zum vorherigen
Kern - Fehler bleibt.
Blick ins dpkg.log, was sich in letzter Zeit noch so änderte - nix
auffälliges auch nur in der Nähe von bind9 oder libuv.
Jetzt wird’s hilflos, weil auch google nix weiß. Remove und purge (mit
manueller Kontrolle) von bind9* und libuv -> reinstall - Fehler (auch ohne
meine config und zonen) wieder da.

Auch ein "rndc trace 9" scheint um den Fehler rum kein Indiz zu liefern:

06-Dec-2023 07:55:19.881 database: debug 5: dns_adb_destroyfind on find
0x7f53a10c2300
06-Dec-2023 07:55:19.881 database: debug 5: dns_adb_destroyfind on find
0x7f53a10c2500
06-Dec-2023 07:55:19.881 general: error:
netmgr/uverr2result.c:98:isc___nm_uverr2result(): unexpected error:
06-Dec-2023 07:55:19.881 general: error: unable to convert libuv error code
in udp_send_cb (netmgr/udp.c:802) to isc_result: -89: destination address
required
06-Dec-2023 07:55:19.881 resolver: debug 5: QNAME minimization -  minimized,
qmintype 2 qminname google.com
06-Dec-2023 07:55:19.881 resolver: debug 1: fetch: google.com/NS
06-Dec-2023 07:55:19.881 database: debug 5: dns_adb_destroyfind on find
0x7f53a1473600
06-Dec-2023 07:55:19.881 database: debug 5: dns_adb_destroyfind on find
0x7f53a1473700
06-Dec-2023 07:55:19.881 resolver: debug 3: fctx
0x7f53a14d3400(google.com/NS): createfind for  - success
06-Dec-2023 07:55:19.881 resolver: debug 3: fctx
0x7f53a14d3400(google.com/NS): createfind for  - success


Leider ists dringend, weil dahinter ein Netz auf Funktion wartet. Und ich
möchte das ungern zum Anlass nehmen mich in dnsmasq, unbound oder so
einzuarbeiten.

Ideen?


Mit freundlichen Grüßen / Kind regards
     Ronny Seffner



Re: Smart-Spam-Bot

2023-12-05 Diskussionsfäden Rico Koerner

Hallo,

ich kann mit beiden Varianten leben, aber vermutlich wird das mit den 
Bots wohl zunehmen. Dann wäre "Hold" doch besser.


Gruß
Rico

Am 05.12.23 um 12:05 schrieb Konrad Rosenbaum:

Hi,


ich habe wahrscheinlich eine Möglichkeit gefunden diese smarten 
Spam-Bots zu blockieren:


Wenn die Listen-Policy auf "Hold" (Moderation) gesetzt wird, aber alle 
"Altmitglieder" auf "Default Processing" (durchlassen), dann wird der 
erste Post von neuen Mitgliedern zurückgehalten und ich muss drauf 
schauen ob es Spam oder legitime Mail ist. Ich setze dann legitime 
Mitglieder explizit auf "Default Processing", was bedeutet dass die 
zweite Mail normal durch geht. Spambots werden (wie bisher auch) 
explizit rausgeworfen und verbannt (kann nicht mehr subscriben).



Wäre das für die Gruppe akzeptabel, oder wollen wir lieber den 
gelegentlichen Spam akzeptieren?




     Konrad



OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: Smart-Spam-Bot

2023-12-05 Diskussionsfäden bb

Am 05.12.23 um 12:05 schrieb Konrad Rosenbaum:

Hallo Konrad,


Hi,


ich habe wahrscheinlich eine Möglichkeit gefunden diese smarten
Spam-Bots zu blockieren:

Wenn die Listen-Policy auf "Hold" (Moderation) gesetzt wird, aber alle
"Altmitglieder" auf "Default Processing" (durchlassen), dann wird der
erste Post von neuen Mitgliedern zurückgehalten und ich muss drauf
schauen ob es Spam oder legitime Mail ist. Ich setze dann legitime
Mitglieder explizit auf "Default Processing", was bedeutet dass die
zweite Mail normal durch geht. Spambots werden (wie bisher auch)
explizit rausgeworfen und verbannt (kann nicht mehr subscriben).


Wäre das für die Gruppe akzeptabel, oder wollen wir lieber den
gelegentlichen Spam akzeptieren?


aus meiner Sicht eine sehr gute Lösung (meine Toleranz für SPAM ist
'völlig intolerant').

Falls Du beim Freischalten von legitimen Neumitgliedern an
Belastungs-Grenzen stoßen solltest (wenn z.b. urplötzlich eine
'alle-wollen-Linux'-und LUG-Beitritts-Welle aufträte ;-), wäre zu
schauen, inwieweit Du den Admin-Job (ver)teilen kannst bzw. generell die
Vertretungsfrage zu stellen, falls Du mal nicht verfügbar bist.

Danke für Deinen Einsatz & Grüße,

Bernhard


Re: Smart-Spam-Bot

2023-12-05 Diskussionsfäden Christian Perle
Hi Konrad,

On Tue, Dec 05, 2023 at 12:05:20 +0100, Konrad Rosenbaum wrote:

> ich habe wahrscheinlich eine Möglichkeit gefunden diese smarten
> Spam-Bots zu blockieren:

Mir war gar nicht aufgefallen, dass der warez-Schrott ueber die lug-dd
reinkam. Da die Liste eher low traffic ist, schlagen die Mails direkt
in meiner Inbox auf und werden nicht in eine andere Mailbox verschoben.
Hatte die Messages direkt nach lesen des Subjects geloescht.

> Wäre das für die Gruppe akzeptabel, oder wollen wir lieber den
> gelegentlichen Spam akzeptieren?

Ist von mir aus okay.

Danke fuers Kuemmern,
  Christian
-- 
Christian Perlechris AT linuxinfotag.de
010111  http://chris.silmor.de/
101010  LinuxGuitarKitesBicyclesBeerPizzaRaytracing


Re: Smart-Spam-Bot

2023-12-05 Diskussionsfäden Uwe Koloska

Hallo,

Am 05.12.23 um 12:05 schrieb Konrad Rosenbaum:
Wäre das für die Gruppe akzeptabel, oder wollen wir lieber den 
gelegentlichen Spam akzeptieren?


Ich find's OK. Und Danke für deine Mühe, Konrad!

Gruß
Uwe



Re: Smart-Spam-Bot

2023-12-05 Diskussionsfäden Konrad Rosenbaum

Hi,


ich habe wahrscheinlich eine Möglichkeit gefunden diese smarten 
Spam-Bots zu blockieren:


Wenn die Listen-Policy auf "Hold" (Moderation) gesetzt wird, aber alle 
"Altmitglieder" auf "Default Processing" (durchlassen), dann wird der 
erste Post von neuen Mitgliedern zurückgehalten und ich muss drauf 
schauen ob es Spam oder legitime Mail ist. Ich setze dann legitime 
Mitglieder explizit auf "Default Processing", was bedeutet dass die 
zweite Mail normal durch geht. Spambots werden (wie bisher auch) 
explizit rausgeworfen und verbannt (kann nicht mehr subscriben).



Wäre das für die Gruppe akzeptabel, oder wollen wir lieber den 
gelegentlichen Spam akzeptieren?




    Konrad



OpenPGP_0xBE96A6EE776FE5D0.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: Smart-Spam-Bot

2023-12-05 Diskussionsfäden Konrad Rosenbaum

Hi,

On 04/12/2023 17:39, Carsten Weber wrote:

Nein, aber eigentlich ist das nicht sonderlich schwer - warum passiert
das nicht viel häufiger?


Kaum gesagt, schon ist es wieder passiert. Inzwischen habe ich das auch 
auf der Mailliste von Qt beobachtet.



Konrad



OpenPGP_0xBE96A6EE776FE5D0.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature