Hallo,
unbound wirf im Log folgende Fehlermeldungen im Log aus:
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!
Bitte mal den Patch probieren...
https://github.com/opnsense/core/commit/845fbd384fe
# opnsense-patch 845fbd384fe
Besser oder gleich?
Grüsse
Franco
Unbound restart tut nicht. Hängt nach dem Patch und reagiert nicht. Ich probiere später mal einen Reboot.
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
Zumindest die Fehlermeldung ist weg nach einem Reboot.
Die Aussage ist schwierig. Unbound startet zumindest? ;)
Grüsse
Franco
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.
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
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.
Du kannst das Logging aktivieren und es dir anschauen.
Services: Unbound DNS: Advanced
- Log Queries
- Log Replies
etc
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?
Quote from: meschmesch on October 13, 2023, 03:44:25 PM
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
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.
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)
Quote from: Patrick M. Hausen on October 13, 2023, 03:57:28 PM
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
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
Quote from: Patrick M. Hausen on October 13, 2023, 06:06:22 PM
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.
Irgentwo holt der die her, die wird beim Start von unbound neu angelegt, auch wenn man die löscht ( den Spass hab ich mir mal gemacht )
Du hast recht - ist in der OPNsense tatsächlich so konfiguriert:
# file to read root hints from.
# get one from https://www.internic.net/domain/named.cache
# root-hints: ""
Wie findet er den Server, wenn man die Datei löscht? Es muss zusätzlich einkompilierte Defaults geben ;)
Die sind anscheinend auch in den Source Code mit reinkompiliert. Hier ist die C Datei
https://github.com/NLnetLabs/unbound/blob/master/iterator/iter_hints.c
Genau das meine ich ja. Es gibt eine statische Cache Priming Liste für die Root-Zone.
Wenn darin mal ein oder zwei Adressen nicht mehr stimmen, dann stört das ja auch noch nicht weiter. Beim Start holt sich der Dienst dann eine aktuelle Liste.
BIND hat die Defaults nicht rein kompiliert, aber einfach in jeder Release eine statische Datei. Der Name "named.cache" kommt von BIND. Er benutzt dann beim Start DNS, um irgendeinen der Server nach der aktuellen Liste zu fragen. Sollte eine Adresse "kaputt" sein, nimmt er halt die nächste.
Dass Unbound das per HTTPS statt per DNS macht, war mir bisher entgangen. Moderne Zeiten ;)
Caveat: es ist durchaus möglich, dass auch BIND sich inzwischen anderes benimmt als von mir geschildert. Mein tiefes BIND-Wissen ist "BIND 4/BIND 8" Jahre alt ...
Solange sich an den operativen Aspekten nichts ändert, hört man nach 20 Jahren mit dem Produkt irgendwann mal auf, jedes Mal die Release Notes etc. pp. zu studieren, so lange alles funktioniert. Und konzentriert sich dann auf die Aufgabe, die gerade ansteht, wie z.B. Einführung von DNSSEC für die authoritativen Nameserver.
Aber ich schwiff ab ...
Historisch ist das einfach eine statische Liste, die muss immer präsent sein, entweder durch Doku + Konfiguration oder einkompiliert. Beim Start kann der Dienst dann alles Mögliche tun, um seinen Cache zu aktualisieren.
Quote from: Patrick M. Hausen on October 13, 2023, 06:24:17 PM
Wie findet er den Server, wenn man die Datei löscht? Es muss zusätzlich einkompilierte Defaults geben ;)
Das steht im Code drin, hol dir erst mal ne aktuelle Liste.
Der Unbound auf meinen Piholes machte das genauso, der hat erst mal die root-liste geholt.