Unbound wird nach Debian 11 Update nicht mehr genutzt

[jfb]

Bitte lade ein Debug Log hoch und poste hier anschließend nur die Token-URL.
Das Token generierst Du über

pihole -d

wobei Du die Frage nach dem Upload bejahst, oder Du machst das über die Weboberfläche:
Tools > Generate Debug Log

[THG]

@jfb Anbei der Token

https://tricorder.pi-hole.net/gpS5L8p4/

[Bucking_Horn]

@THG

nslookup arbeitet richtig und es wird der Pi-hole genutzt. Die Anzeige im Pi-hole sagt aber etwas anderes.

Ich kann hier keine Abweichung erkennen.
Dein Screenshot zeigt, dass Dein Pi-hole die Anfrage für heise.de erhalten, nicht geblockt und an unifi#53 weitergeleitet und mit der von dort erhaltenen IP-Adresse beantwortet hat.

@THG

Das bedeutet doch, dass Pi-hole unbound nicht nutzt und als Rückfall mein Hauptgateway genutzt wird aber warum?

Weil Du in 42-my-vlan-forwarding.conf zusätzlich zu unbound sieben weitere Upstream-DNS-Server konfiguriert hast, z.B.:

   server=192.168.178.1

Das instruiert pihole-FTL/dnsmasq, 192.168.178.1 als zusätzlichen Upstream zu verwenden.

Ich nehme an, dass Du hier etwas ähnliches wie Pi-hole's Conditional Forwarding pro VLAN beabsichtigt hast.

Dann müsstest Du aber üblicherweise die Verwendung des Upstreams auf Deine lokale Domäne beschränken, also z.B. für fritz.box als lokale Domäne:

   server=/fritz.box/192.168.178.1

Prinzipiell wäre hier wahrscheinlich auch genau eine solche server-Zeile ausreichend, sofern Du in Deinem Netz nicht mit mehreren lokalen Domänen arbeitest.

[THG]

Hallo @Bucking_Horn,

zu deiner letzten Anmerkung hatte ich dich doch extra gefragt aber leider keine Antwort im nachfolgenden Beitrag erhalten.

Conditional Forwarding mit mehreren DHCP Servern?

Hallo, ich nutze eine UniFi DM-SE. Dort sind mehrere IP Netze eingetragen und in jedem dieser Netze läuft ein eigener DHCP Server von der DM-SE. Alle Netze greifen bei DNS aber auf meine beiden Pi-hole unbound Geräte zu. Kann ich nun bei Conditional Forwarding die ganzen einzelnen DHCP Server eintragen? Genau das was unter dem nachfolgenden Link zu sehen ist brauche ich. /etc/dnsmasq.d/

Ich nutze keine lokalen Domänname in meinen Netzen.

Bisher lief es ja ohne Probleme aber seit dem letzten Update nicht mehr.

Ich habe 42-my-vlan-forwarding.conf gelöscht.
Alles neu gestartet und habe nun überhaupt keinen Zugang mehr über den Pi-hole. Musste meinen Rechner nun mit einer festen DNS Adresse versehen.

Sie sieht es jetzt in Massen im Pi-hole aus den anderen Netzen aus.

[THG]

Unbound deinstalliert und neu installiert ohne Änderungen.

Pi-hole auf DNS Anbieter umgestellt und damit geht es dann wieder.

Ich weiß nicht mehr weiter. Der zweite Pi-hole verhält sich genauso so.

[Bucking_Horn]

@THG

aber leider keine Antwort im nachfolgenden Beitrag erhalten.

Das stimmt - diese nachgesetzte Frage hab ich damals übersehen oder vielleicht fälschlich der Diskussion mit ZeeKay zugeordnet, sorry.
Deine ursprüngliche Frage in dem Topic hatte ich ja ausführlich beantwortet (inklusive Deiner Rückmeldung, dass alles geklappt hat).
Deine Nachfrage kam erst Wochen später (und unmittelbar im Anschluss an Deine Diskussion mit jemanden, der seinerseits Dein Topic zu kapern versucht hat).
Im Zweifel ist es besser, für eine neue Fragestellung ein neues Topic aufzumachen.

@THG

Bisher lief es ja ohne Probleme aber seit dem letzten Update nicht mehr.

Das lässt sich anhand Deiner Angaben so nicht nachvollziehen.
Prinzipiell hat Pi-hole auch nach dem Update ordnungsgemäß gefiltert, auch wenn Du unbeabsichtigt viele Upstream-Server konfiguriert hattest und nicht der Upstream verwendet wurde, den Du erwartet hast.

Aber mit Deiner unbound-Konfiguration scheint etwas nicht zu stimmen (was wohl auch dazu geführt hat, das Pi-hole einen der anderen sieben Upstreams verwendet hat). Das bringen die massiven Fehlermeldungen nach Rücknahme der alternativen Upstreams jetzt deutlich zum Vorschein.

Stimmen Zeit und Zeitzone auf den Rechnern, auf denen unbound bei Dir läuft?

Und sofern Du zwischenzeitlich auf ein Debian-Bullseye-Betriebssystem umgestiegen sein solltest, solltest Du außerdem nach DNS-Schleifen Ausschau halten, die möglicherweise durch eine unglückliche Kombination der Paketvorgaben von unbound und openresolv verursacht werden können.
Was gibt folgendes Kommando zurück:

sudo grep -v '#\|^$' -R /etc/unbound/unbound.conf*

[THG]

@Bucking_Horn

sudo grep -v '#\|^ -R /etc/unbound/unbound.conf*`

pi@rpi-pihole-4:~ $ sudo grep -v '#\|^$' -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: 192.168.20.1
/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:    interface: 127.0.0.1
/etc/unbound/unbound.conf.d/pi-hole.conf:    port: 5335
/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: no
/etc/unbound/unbound.conf.d/pi-hole.conf:    prefer-ip6: no
/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: 1232
/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:    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

pi@rpi-pihole-4:~ $ sudo timedatectl status
               Local time: Thu 2023-02-16 22:52:50 CET
           Universal time: Thu 2023-02-16 21:52:50 UTC
                 RTC time: n/a
                Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

[jfb]

@THG

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: 192.168.20.1

This is your problem.

1. Edit file /etc/resolvconf.conf and comment out the last line which should then read:

#unbound_conf=/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf

2. Delete the unwanted unbound configuration file:

sudo rm /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf

3. Restart unbound:

sudo service unbound restart

[THG]

@jfb

/etc/resolvconf.conf

Die Datei ist bei mir leer

[Bucking_Horn]

@THG

/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: 192.168.20.1

Das ist sehr wahrscheinlich das Problem.

Bitte probier folgendes:

a) /etc/resolvconf.conf bearbeiten und (letzte) Zeile auskommentieren, die anschliessend so lauten sollte:
#unbound_conf=/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf

b) Unerwünschte unbound-Konfigurationsdatei löschen:

sudo rm /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf

c) unbound neu starten:

sudo service unbound restart

[THG]

@Bucking_Horn @jfb

Also soll ich das jetzt #unbound_conf=/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf in meine leere Datei reinsetzten, dann speichern und dann löschen?

Im /etc Verzeichnis gibt es diese Datei nicht.

Es gibt nur:

resolv.conf
resolvconf
resolv.conf.bak

Sollte denn in dieser conf Datei etwas stehen?

[Bucking_Horn]

Wenn auf Deinem System die Datei /etc/resolvconf.conf fehlt oder leer ist, kannst Du Schritt 1 weglassen.
Das sollte Dein unmittelbares unbound-Problem erst einmal beheben.

Es ist dann allerdings unklar, wodurch /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf bei Dir angelegt worden ist.

Du solltest im Auge behalten, ob diese Datei ggf. erneut auftaucht, z.B. nach einem Reboot.

[THG]

@Bucking_Horn @jfb

Nach dem Löschen dieser Datei läuft alles wieder.

Ich verstehe es nicht. Ich habe genau zwei Dinge gemacht. Debian Update auf 11 und Pi-hole Update.

Eines von beiden muss ja dieses Problem verursacht haben.

Danke für eure Hilfe

[Bucking_Horn]

@Bucking_Horn

Und sofern Du zwischenzeitlich auf ein Debian-Bullseye-Betriebssystem umgestiegen sein solltest,

@THG

Debian Update auf 11

Das wird's wahrscheinlich gewesen sein.

Genaueres dazu findet sich in WARNING: Raspbian October 2021 release bullseye + unbound.

Und bezüglich Deiner 42-my-vlan-forwarding.conf.
Wenn Du keine lokale Domäne benutzt, musst Du nur Anfragen für unqualifizierte Domänen an den Router schicken (s.a. dnsmasq-Doku zu server).
Also z.B.

server=//192.168.178.1

Als Randnotiz: Manche Windows-Versionen haben u.U. ohne lokale Domäne Schwierigkeiten mit der Auflösung solcher unqualifizierter Namen. Entsprechende Namen werden dann von Windows gar nicht erst zur Auflösung an einen DNS-Server geschickt.
Wenn dies der Fall sein sollte, lässt sich dies jedoch in der Regel durch Nachstellen eines Punktes im Namen erzwingen (also z.B. laptop. statt nur laptop)

[THG]

Hallo @Bucking_Horn

nun habe ich die angepasste FW Liste wieder mit deiner Anpassung eingetragen und das Chaos geht wieder los.

Kannst du bitte schauen was dort nun passiert? Danke

https://tricorder.pi-hole.net/IEhBuOSK/

## Conditional Forwarding mit mehreren DHCP Servern##

rev-server=192.168.1.0/24, 192.168.1.1
server=//192.168.1.1

rev-server=192.168.10.0/24, 192.168.10.1
server=//192.168.10.1

rev-server=192.168.20.0/24, 192.168.20.1
server=//192.168.20.1

rev-server=192.168.30.0/24, 192.168.30.1
server=//192.168.30.1

rev-server=192.168.40.0/24, 192.168.40.1
server=//192.168.40.1

rev-server=192.168.50.0/24, 192.168.50.1
server=//192.168.50.1

rev-server=192.168.60.0/24, 192.168.60.1
server=//192.168.60.1

rev-server=192.168.178.0/24, 192.168.178.1
server=//192.168.178.1

2023-02-17 10:03:31	RATE_LIMIT	Client 192.168.20.1 has been rate-limited (current config allows up to 1000 queries in 60 seconds)

[Bucking_Horn]

@THG

RATE_LIMIT Client 192.168.20.1

Diese Meldung hatten wir bislang noch nicht.
Sie könnte aber möglcherweise auch auf eine DNS-Schleife hindeuten, zumal ja wieder dieselbe IP auftaucht:

@THG

resolvconf_resolvers.conf: forward-addr: 192.168.20.1

Ist resolvconf_resolvers.conf vielleicht wieder neu erzeugt worden?

Falls nicht, sollten wir uns 42-my-vlan-forwarding.conf nochmal ansehen, insbesondere im Hinblick auf Deine Netzwerk-Topologie und auf meinen Hinweis:

@Bucking_Horn

Prinzipiell wäre hier wahrscheinlich auch genau eine solche server-Zeile ausreichend, sofern Du in Deinem Netz nicht mit mehreren lokalen Domänen arbeitest.

in Verbindung mit:

@Bucking_Horn

Wenn Du keine lokale Domäne benutzt, musst Du nur Anfragen für unqualifizierte Domänen an den Router schicken

Wieso definierst Du hier wiederum sieben spezifische Upstream-Server für //?
Ist das nicht alles derselbe Router und damit derselbe router-interne DNS-Server?
Oder hast Du tatsächlich sieben verschiedene Router im Einsatz?

[THG]

Die Netze sind vollständig getrennt und habe alle ihr eigenes logische Gateway. Gateway ist eine Unifi UDM-SE

Alle DNS Anfragen aus allen IP-Netzen (wird über eine Firewall Regel geregelt) gehen in ein eigenes DNS Netz, wo dann zwei Pi-hole RPI4 im Cluster stehen.

Ich habe die FW Liste wieder gelöscht und damit geht es wieder.

Ich denke ich werde damit leben und ohne FW Liste arbeiten.

[Bucking_Horn]

Wenn ich das richtig verstehe, ist also bei Dir nur ein Router vorhanden?

Ob und wie eine server=-Option in Deiner 42-my-vlan-forwarding.conf funktionieren kann, würde dann davon abhängen, ob Dein Router in jedem VLAN einen eigenen internen DNS-Server laufen hat, oder ob lediglich eine interne DNS-Server-Instanz für alle VLANs zuständig ist.

In letzterem Fall würde es ausreichen, wenn Du nur genau eine server-Zeile in Deiner Konfiguration stehen hast.
Wenn es pro VLAN einen DNS-Server gibt, wird die Auflösung nicht zuverlässig funktionieren, da dann ja nicht eindeutig ist, an welchen der sieben VLAN-DNS-Server ein nicht vollqualifizierter Name wie laptop geschickt werden müsste. Das würde nur mit eindeutigen lokalen Domänen funktionieren.

Außerdem dürfte der interne Router-DNS-Server dann keinesfalls seinerseits Anfragen an Pi-hole schicken, da sonst eine partielle DNS-Schleife geschlossen wird, insbesondere für unbekannte Domänen.

Bei mehreren Routern würde sich der Konfigurationsaufwand entsprechend erhöhen.

Alternativ lässt Du Conditional Forwarding abgeschaltet und legst einfach die entsprechenden Local DNS Records in Pi-hole an, zumoindest für die IPv4-Adressen, die Dir wichtig sind.

[THG]

@Bucking_Horn

Alternativ lässt Du Conditional Forwarding abgeschaltet und legst einfach die entsprechenden Local DNS Records in Pi-hole an, zumoindest für die IPv4-Adressen, die Dir wichtig sind.

Genau so werde ich es nun machen.

Danke