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 wirds 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 <unknown> - success 06-Dec-2023 07:55:19.881 resolver: debug 3: fctx 0x7f53a14d3400(google.com/NS): createfind for <unknown> - 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
Hallo Ronny,
sowas in der Richtung evtl.? https://gitlab.isc.org/isc-projects/bind9/-/issues/2466
Das Stichwort Zeit / DNSSEC fiel hier schon. * Zeit checken (sieht ja offenbar "gut" aus?) * mal testweise dnssec ausmachen * was sagt strace * ggf. anderen Bind installieren / selber bauen o.Ä.
Hast schon was rausgefunden(bzw. bitte mal rückmelden wenn dus rausgekriegt hast)? Sieht interessant / wüst aus, vielleicht hast ja auch nen Bug gefunden ^^
Grüße von der T2,
Falk
On Wed, 2023-12-06 at 08:01 +0100, ronny@seffner.de wrote:
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 <unknown> - success 06-Dec-2023 07:55:19.881 resolver: debug 3: fctx 0x7f53a14d3400(google.com/NS): createfind for <unknown> - 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
Grüße von der T2,
Wer oder was ist "T2"?
Hatte ich schon vor Augen. Matcht nicht wirklich.
Das Stichwort Zeit / DNSSEC fiel hier schon.
- Zeit checken (sieht ja offenbar "gut" aus?)
Da läuft ntp - Zeitstempel passt. (Ronnys "IT-Regeln" sagen auf Platz 3 "DNS-Prüfungen sind billig, DNS ist fast immer Schuld" und Platz 4 "Zeit prüfen ist billig. Zeitabweichungen sind oft Schuld" ;-)
- mal testweise dnssec ausmachen
Im pdns-recursor eben mal deaktiviert: keine Besserung.
- was sagt strace
Der "ich" kennt das tool im Grunde nicht.
- ggf. anderen Bind installieren / selber bauen o.Ä.
Das habe ich mit einem 32-bittigen bind im chroot und ersatzweise einem pdns-recursor getan. Beide gleiches Verhalten - aber der/die/das pihole tut wunderbar (auf ner anderen IP).
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Habe eben den apt cache geleert und ALLE installierten Pakete mit apt install --reinstall neu überinstalliert. Hilft nicht. Ein Bitfehler irgendwo scheidet also vermutlich auch aus.
Rechte? Kernel? Ging ja aber schon mit dem Kern, der gerade läuft. Hardware?
Ich habe noch eine i386 schroot-Umgebung auf der amd64-Kiste, bekomme dort zwar einen bind installiert - auch der verhält sich so.
Mit freundlichen Grüßen / Kind regards Ronny Seffner
In meiner Not, DNS an den Start zu bekommen, habe ich mal schnell pdns-recursor installiert. - auf der betroffenen Kiste : SERVFAIL - auf einer beliebigen anderen Debian 12 Kiste : geht
= es liegt nicht am bind, ob sich was eingenistet hat und an meinen Paketen rumpopelt?
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Moin,
ich vermelde einen Teilerfolg.
Es war ja so, dass ich von bind9 und einem testweise installierten powerdns-recursor schlicht ein SERVFAIL bekam, wenn ich etwas (nicht lokal bekanntes, wie ich jetzt weiß) auflösen wollte. Ein parallel auf anderer IP lauschendes pihole/dnsmasq funktionierte aber tadellos. Der Unterschied liegt in den Konfigurationen: pihole hat einen forwarder, die anderen nicht.
Kaum einen forwarder (8.8.8.8) in bind9 gesetzt, geht wieder alles.
Ich vermute: mit dem reboot, der scheinbar alles auslöste, erfolgte auch eine neue Einwahl beim Provider (ENSO) der mir eine veränderte "config" überhalf, mit der ich jetzt nicht mehr selber auflösen kann.
Hat hier einer eine Idee, was die Provider da so anstellen könnten? Ist dazu schon etwas bekannt?
Mit freundlichen Grüßen / Kind regards Ronny Seffner
lug-dd@mailman.schlittermann.de
-
Falk Herzog -
ronny＠seffner.de