Hallo,
unter meinen "Top Permitted Domains" stehen, in meinen Augen, mehrere merkwürdige Einträge. Aufgrund seiner hohen Anzahl von Hits sticht aber "_ta-4f66-9728" hervor.
Eine Google suche zeigte mir, dass es wohl etwas mit Unbound zu tun hat, der bei mir auch läuft. Mehr habe ich aber nicht verstanden.
Wie kann ich herausfinden, wer oder was "_ta-4f66-9728" ist und warum es so viele Abfragen erzeugt?
Mein Debug token lautet: https://tricorder.pi-hole.net/RUJv0nKd/
Danke und Gruß Eggi
Von welchen Client-IPs kommen denn die Anfragen für _ta-4f66-9728 an?
Hallo,
wenn ich das richtig interpretiere, von meiner FRITZ!Box (192.168.1.1). Die FRITZ!Box fungiert bei mir auch als DHCP Server.
Wenn ich mich recht erinnere, hatte ich dieses verhalten vor dem update auf Version 6 von Pi-hole nicht.
Vielleicht hilft die "Pi-hole diagnosis"?
Danke und Gruß Eggi
Zu den Fehlermeldungen:
1 2025-03-02 20:20:02 CONNECTION_ERROR ::1#5353
Du solltest ::1#5353 aus Pi-holes Upstream DNS Server entfernen.
Maximum number of concurrent DNS queries reached (max: 150)
Das hängt wahrscheinlich mit dem Fehler zusammen.
Ausgeführt auf Deinem Pi-hole-Rechner, was gibt folgendes Kommando zurück:
sudo grep -v '^\s*#\|^$' -R /etc/unbound/unbound.conf*
Hallo,
ich habe ::1#5353 aus dem Upstream DNS Server entfernt. Bild vorher und nachher:
Nach der Eingabe von "sudo grep -v '^\s*#|^$' -R /etc/unbound/unbound.conf*" im Terminal kommt folgende Ausgabe:
KE@Raspberry-Pi-3-Model-B-Plus:~ $ sudo grep -v '^\s*#\|^$' -R /etc/unbound/unbound.conf*
/etc/unbound/unbound.conf:include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"
/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf:forward-zone:
/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf: name: "."
/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf: forward-addr: 1.1.1.1
/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf: forward-addr: fd26:d00b:a9f5:0:f184:c79:954e:e111
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf:server:
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf: auto-trust-anchor-file: "/var/lib/unbound/root.key"
/etc/unbound/unbound.conf.d/pi-hole.conf:server:
/etc/unbound/unbound.conf.d/pi-hole.conf:verbosity: 0
/etc/unbound/unbound.conf.d/pi-hole.conf:port: 5353
/etc/unbound/unbound.conf.d/pi-hole.conf:do-ip4: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:do-udp: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:do-tcp: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:do-ip6: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:root-hints: "/var/lib/unbound/root.hints"
/etc/unbound/unbound.conf.d/pi-hole.conf:harden-glue: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:harden-dnssec-stripped: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:use-caps-for-id: no
/etc/unbound/unbound.conf.d/pi-hole.conf:edns-buffer-size: 1472
/etc/unbound/unbound.conf.d/pi-hole.conf:cache-min-ttl: 3600
/etc/unbound/unbound.conf.d/pi-hole.conf:cache-max-ttl: 86400
/etc/unbound/unbound.conf.d/pi-hole.conf:prefetch: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:num-threads: 1
/etc/unbound/unbound.conf.d/pi-hole.conf:msg-cache-size: 50m
/etc/unbound/unbound.conf.d/pi-hole.conf:rrset-cache-size: 100m
/etc/unbound/unbound.conf.d/pi-hole.conf:so-reuseport: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:so-rcvbuf: 1m
/etc/unbound/unbound.conf.d/pi-hole.conf:private-address: 192.168.0.0/16
/etc/unbound/unbound.conf.d/pi-hole.conf:private-address: 169.254.0.0/16
/etc/unbound/unbound.conf.d/pi-hole.conf:private-address: 172.16.0.0/12
/etc/unbound/unbound.conf.d/pi-hole.conf:private-address: 10.0.0.0/8
/etc/unbound/unbound.conf.d/pi-hole.conf:private-address: fd00::/8
/etc/unbound/unbound.conf.d/pi-hole.conf:private-address: fe80::/10
Danke und Gruß Eggi
Du hast vermutlich im Zuge des Updates auf Pi-hole v6 auch Dein Betriebssystem von Buster auf Bullseye gebracht(?) und dabei einen bummelig 4 Jahre alten Fehler des Paketmanagers für unbound aktiviert.
Du solltest Pi-holes Empfehlungen für unbound noch einmal durchlesen und umsetzen, insbesondere Disable resolvconf.conf entry for unbound (Required for Debian Bullseye+ releases).
Hallo Bucking_Horn,
Raspberry Pi OS 11 (Debian bullseye) ist die original Installation. Darauf wurde Pi-hole Version 5 installiert und dann mit einigen Problemen auf Version 6 upgedated.
Ich habe mit der Eingabe "KE@Raspberry-Pi-3-Model-B-Plus:~ $ nano /etc/unbound/unbound.conf.d/pi-hole.conf" folgendes Ergebnis erhalten:
Es unterscheidet sich in einigen Punkten von der Vorgaben aus der Pi-hole documentation. Muss/ soll ich die Text Datei der Pi-hole documentation anpassen?
Ich habe mit der Eingabe "systemctl is-active unbound-resolvconf.service" folgendes Ergebnis erhalten:
KE@Raspberry-Pi-3-Model-B-Plus:~ $ systemctl is-active unbound-resolvconf.service
active
Soll ich jetzt die folgende vier Eingaben nacheinander ausführen?
sudo systemctl disable --now unbound-resolvconf.service
sudo sed -Ei 's/^unbound_conf=/#unbound_conf=/' /etc/resolvconf.conf
sudo rm /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf
sudo service unbound restart
Entschuldige bitte die Nachfragen, aber ich habe keine Ahnung von Linux und Angst, etwas kaputt zu machen. Meine komplette Installation beruht auf Schritt für Schritt Anleitung, die ich mir ergoogelt habe.
Danke und Gruß Eggi
Hallo Bucking_Horn,
ich habe Pi-hole upgedated: Core v6.0.5, FTL v6.0.4, Web interface v6.0.2
Ich habe einen neuen Debug token erzeugt: https://tricorder.pi-hole.net/1nvzu9rW/
Danke und Gruß Eggi
Hallo,
um eine Änderung des Verhaltens zu beobachten, oder auch nicht, habe ich die "DNS Settings" geändert. Der "Upstream DNS Servers" wurde vom installierten Unbound auf die hinterlegten von "Quad9" umgestellt.
Ein erneuter Blick auf die "Recent Queries" zeigt, dass die letzte Abfrage zu "_ta-4f66-9728" vor der Umstellung des "Upstream DNS Servers" erfolgte. Die Umstellung hat die Abfrage zu "_ta-4f66-9728" beendet, scheint somit im Zusammenhang mit Unbound zu stehen.
Leider ist mir noch immer nicht klar, was ich in Unbound anpassen oder ändern muss, um dieses Verhalten zu beenden. Vielleicht kann mir noch mal jemand einen Tipp geben.
In der "Pi-hole diagnosis" werden noch immer zwei Fehler Angezeigt. Um die werde ich mich wohl auch noch irgendwie kümmern müssen.
Ich habe einen neuen Debug token erzeugt: https://tricorder.pi-hole.net/ErXdt6zE/
Über hilfe freuend, Danke und Gruß Eggi
Ja, sofern das genau die Kommandos aus der von mir verlinkten Doku sind:
Hallo Bucking_Horn,
ich habe den "Upstream DNS Servers" wieder auf "127.0.0.1#5353" in Pi-hole eingestellt.
Danach habe ich folgende Eingaben immTerminal gemacht:
KE@Raspberry-Pi-3-Model-B-Plus:~ $ sudo systemctl disable --now unbound-resolvconf.service
KE@Raspberry-Pi-3-Model-B-Plus:~ $ systemctl is-active unbound-resolvconf.service
inactive
KE@Raspberry-Pi-3-Model-B-Plus:~ $ sudo sed -Ei 's/^unbound_conf=/#unbound_conf=/' /etc/resolvconf.conf
KE@Raspberry-Pi-3-Model-B-Plus:~ $ sudo rm /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf
KE@Raspberry-Pi-3-Model-B-Plus:~ $ sudo service unbound restart
KE@Raspberry-Pi-3-Model-B-Plus:~ $ sudo systemctl status unbound.service
● unbound.service - Unbound DNS server
Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2025-03-07 14:54:02 CET; 7s ago
Docs: man:unbound(8)
Process: 23030 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code=exited, status=0/SUCCESS)
Process: 23033 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_update (code=exited, status=0/SUCCESS)
Main PID: 23036 (unbound)
Tasks: 1 (limit: 2057)
CPU: 158ms
CGroup: /system.slice/unbound.service
└─23036 /usr/sbin/unbound -d -p
Mär 07 14:54:02 Raspberry-Pi-3-Model-B-Plus systemd[1]: Starting Unbound DNS server...
Mär 07 14:54:02 Raspberry-Pi-3-Model-B-Plus unbound[23036]: [23036:0] info: start of service (unbound 1.13.1).
Mär 07 14:54:02 Raspberry-Pi-3-Model-B-Plus systemd[1]: Started Unbound DNS server.
Die Antworten machten für mich den Eindruck, als wenn es wie erwartet gelaufen ist.
Ein erneuter Blick auf die "Recent Queries" zeigt, dass keine neuen Abfragen zu "_ta-4f66-9728" aufgetaucht sind.
Ich werde das ganze weiter beobachten, den Raspberry Pi noch einmal neu starten und mich noch einmal melden.
Danke und Gruß Eggi
Hallo Bucking_Horn,
vorweg möchte ich mich für die ganz große Unterstützung bedanken 
Ohne Dich hätte ich wohl, "irgendwann mal", den Raspberry Pi neu aufsetzen müssen.
Das "_ta-4f66-9728" scheint behoben zu sein, in den "Recent Queries" sind keine neuen Einträge aufgetaucht.
Ich habe nun noch zwei Einträge in der "Pi-hole diagnosis" die wohl aber nicht zu dem "_ta-4f66-9728" Problem gehören. Ich frag aber einfach mal, was ich da machen kann:
Danke und ein schönes Wochenende Eggi
Sofern diese Fehler auch heute noch bestehen, stell bitte dafür ein neues Topic ein- dieses hier hat ja bereits eine Lösung.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.
