Unbound funktioniert nicht

[meschmesch]

Hallo,
unbound wirf im Log folgende Fehlermeldungen im Log aus:

Code Select Expand


2023-10-13T11:45:04 Error unbound [72203:0] error: worker send cmd 0 failed
2023-10-13T11:45:04 Error unbound [72203:0] error: cannot fcntl F_SETFL: Bad file descriptor
2023-10-13T11:45:04 Error unbound [72203:0] error: cannot fcntl F_GETFL: Bad file descriptor
2023-10-13T11:42:54 Critical unbound [72203:1] fatal error: Could not initialize thread
2023-10-13T11:42:54 Error unbound [72203:1] error: Could not set root or stub hints
2023-10-13T11:42:54 Error unbound [72203:1] error: reading root hints /root.hints 2:11: Syntax error, could not parse the RR's type


Ich habe bei Unbound eigentlich nichts außer der Reihe eingestellt. DoT, QueryForwarding, Blocklist, Accesslists ist alles leer. Kann man unbound auf default zurücksetzen?

Danke!

[franco]

Bitte mal den Patch probieren...

https://github.com/opnsense/core/commit/845fbd384fe

# opnsense-patch 845fbd384fe

Besser oder gleich?


Grüsse
Franco

[meschmesch]

Unbound restart tut nicht. Hängt nach dem Patch und reagiert nicht. Ich probiere später mal einen Reboot.

[franco]

Habs getestet hier. Ich nehme immer noch an irgendwas verklemmt sich auf dem System wenn der Fehler auftritt (mit dem Standard Code).


Grüsse
Franco

[meschmesch]

Zumindest die Fehlermeldung ist weg nach einem Reboot.

[franco]

Die Aussage ist schwierig. Unbound startet zumindest? ;)


Grüsse
Franco

[meschmesch]

Also, nach dem Reboot scheint alles zu laufen, keine Fehlermeldung im Log. Mehr kann ich nicht sagen.

Andere Frage, wie finde ich denn heraus, ob unbound die Root-Server rekursiv abfrägt bzw. wo lege ich das fest? Wie bereits oben geschrieben ist alles leer bei DoT, QueryForwarding, Blocklist, Accesslists.

[Monviech (Cedrik)]

Nach der Doc von Unbound ist es wohl default, dass die Root Server gefragt werden, wenn keine Weiterleitung zu einem anderen Resolver eingetragen ist.

https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.html#description

[meschmesch]

Hi Monviech,
danke, aber die Frage ist, was tut unbound tatsächlich? Lässt sich das mit irgendwelchen Tools nachvollziehen? Auf der Firewall sehe ich Anfragen vom WAN Interface an eine Vielzahl unterschiedlicher Server auf Port 53. azure-dns.com, edgecastdns.net usw.

[Monviech (Cedrik)]

Du kannst das Logging aktivieren und es dir anschauen.
Services: Unbound DNS: Advanced
- Log Queries
- Log Replies
etc

[meschmesch]

Hmm, bringt mich nur halb weiter. Ich würde bei Abfrage der Root-Server erwarten, dass irgend eine initale Query nach xx.root-servers.net rausgeht. Tut es aber nicht. Also mal ganz praktisch, DNS-Lookup auf eine bisher nicht aufgerufene Domain in einem weitegehend unbekannten Land auf der Erde sollte doch irgendwie die root-Server ins Spiel bringen. Und das müsste man im Log sehen? Oder habe ich einen Denkfehler?

[Patrick M. Hausen]

Hmm, bringt mich nur halb weiter. Ich würde bei Abfrage der Root-Server erwarten, dass irgend eine initale Query nach xx.root-servers.net rausgeht.

Die Liste der Root-Server ist in einen rekursiven Nameserver eingebaut - entweder einkompiliert oder per Konfiguration. Irgendwo muss er ja anfangen und deren IP-Adressen ändern sich alle paar Jahre mal.

Der erste Requests eines frisch gestarteten rekursiven Nameservers mit leerem Cache geht an einen der Root-Nameserver.

Beispiel: ich suche forum.opnsense.net

Hab ich nicht im Cache. Ich würfel mir einen der Server für "." und frag den nach der Nameserver-Liste für "net."
Dann frag ich einen von denen nach der Nameserver-Liste für "opnsense.net."
Und dann einen von denen nach dem A-Record für "forum.opnsense.net."

Gruß
Patrick

[Monviech (Cedrik)]

Ich hab mal nen tcpdump gemacht (Auf meinem Pihole mit Unbound) um zu schauen ob Unbound wirklich zu root Servern geht:

Ich hab dazu katzen.de aufgerufen. Hier wird rekursiv vom root server bis zum authoritiven DNS Server der ganze Weg durchgegangen.

Code Select Expand


tcpdump -i eth0 dst port 53 | grep -i katzen
16:13:39.816547 IP6 xxxx:x:xxxx:xxxx:f690:eaff:fe00:d9f4.21929 > pi.hole.domain: 52729+ [1au] A? katzen.de. (38)
16:13:39.816698 IP 10.1.1.1.48657 > raspi03.domain: 37038+ [1au] AAAA? katzen.de. (38)
16:13:39.819139 IP raspi03.31154 > a.nic.de.domain: 61391% [1au] A? katzen.de. (38)
16:13:39.820317 IP raspi03.54677 > z.nic.de.domain: 45172% [1au] A? katzen.de. (38)
16:13:39.834288 IP raspi03.32139 > ns-cloud-a2.googledomains.com.domain: 42208% [1au] AAAA? katzen.de. (38)
16:13:39.838713 IP raspi03.33883 > ns-cloud-a2.googledomains.com.domain: 1325% [1au] A? katzen.de. (38)
16:13:40.484264 IP6 xxxx:x:xxxx:xxxx:f690:eaff:fe00:d9f4.26842 > pi.hole.domain: 17994+ [1au] A? www.katzen.de. (42)
16:13:40.484367 IP 10.1.1.1.49836 > raspi03.domain: 42041+ [1au] AAAA? www.katzen.de. (42)
16:13:40.489155 IP raspi03.10181 > ns-cloud-a3.googledomains.com.domain: 15469% [1au] A? www.katzen.de. (42)
16:13:40.489373 IP raspi03.62046 > ns-cloud-a4.googledomains.com.domain: 6402% [1au] A? www.katzen.de. (42)
16:13:40.513185 IP raspi03.19598 > ns-cloud-a4.googledomains.com.domain: 32835% [1au] AAAA? www.katzen.de. (42)


[Tuxtom007]

Die Liste der Root-Server ist in einen rekursiven Nameserver eingebaut - entweder einkompiliert oder per Konfiguration. Irgendwo muss er ja anfangen und deren IP-Adressen ändern sich alle paar Jahre mal.

Ich bin nicht sicher, aber ich meine der holt sich die Liste der Root-Server beim Start einmal vom FTP.INTERNIC.NET und legt die lokal ab, die stehen nämlich in der /var/unbound/root.hints.

Das sind ja keine root-server sondern Server-Pools hinter denen ( kenne die aktuellen Zahlen nicht mehr ) rund 1300 DNS-Server stecken

[Patrick M. Hausen]

Genau in der Datei stehen die drin. 13 A- und 13 AAAA-Records im Moment. Das meinte ich mit "durch Konfiguration", ich bezog mich jetzt nicht nur auf Unbound sondern auf rekursive Server generell.

Die Datei wird von Unbound nicht automatisch aktualisiert, neue Versionen kommen entweder mit einer neuen Unbound-Release oder per Cronjob oder von Hand von dem von dir ebenfalls richtig genannten FTP-Server.

Natürlich sind das nicht nur 13 Maschinen. Aber nur 13 IPv4- und 13 IPv6-Adressen. Stichwort: anycast.

Zum Nachgucken mit einem Klick per HTTPS: https://www.internic.net/domain/named.cache

Gruß
Patrick