nslookup arbeitet richtig und es wird der Pi-hole genutzt. Die Anzeige im Pi-hole sagt aber etwas anderes.
Was bedeutet diese Anzeige? Unifi ist mein Management Netzwerk für die Unifi Produkte.
Stutzig mach mich ein anderer Test.
Feb 15 23:58:23: query[A] ssl.gstatic.com from 192.168.50.29
Feb 15 23:58:23: forwarded ssl.gstatic.com to 192.168.1.1
Feb 15 23:58:23: query[HTTPS] ssl.gstatic.com from 192.168.50.29
Feb 15 23:58:23: forwarded ssl.gstatic.com to 192.168.1.1
Feb 15 23:58:23: validation result is INSECURE
Feb 15 23:58:23: reply ssl.gstatic.com is 142.250.185.131
Feb 15 23:58:23: validation result is INSECURE
Feb 15 23:58:23: reply ssl.gstatic.com is NODATA
Feb 15 23:58:23: query[HTTPS] clients6.google.com from 192.168.50.29
Feb 15 23:58:23: forwarded clients6.google.com to 192.168.1.1
Das bedeutet doch, dass Pi-hole unbound nicht nutzt und als Rückfall mein Hauptgateway genutzt wird aber warum?
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.
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.
zu deiner letzten Anmerkung hatte ich dich doch extra gefragt aber leider keine Antwort im nachfolgenden Beitrag erhalten.
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.
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.
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:
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
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:
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?
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.
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)
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:
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:
in Verbindung mit:
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?
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.
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.
