DNS Loop?

Hallo,

ich benutzte Pi.Hole schon länger, aber erst seit kurzem fiel mir auf, dass nachts, etwa 3:40, immer eine Spitze in der Zahl der DNS-Anfragen auftritt. Heute habe ich dann auch eine größere Anzahl von Warnungen "Maximum number of concurrent DNS queries reached (max: 150)" gesehen. In den Logs scheinen die Abfragen alle von der IPv6 des Pi.Hole-Systems zu kommen (also ein Loop).

Vermutlich wegen Fehlern auf der SD-Karte musste ich das System jetzt mehrfach neu aufsetzen, habe aber eigentlich ( :grin:) nie etwas wirklich anders als bei den vorherigen Malen gemacht.

Zum Setup: Pi.Hole mit Unbound auf RaspberryPi hinter Fritz!Box mit IPv4 und IPv6 - FB ist DHCP Server und verteilt DNS (IPv4/IPv6) an alle Clients. Dabei benutze ich für IPv6 einen eigene zufällige ULA, die per Router Advertisment (zurzeit) ohne DHCPv6 (mit scheint nicht anders zu sein) verteilt wird. Eingerichtet habe ich das entsprechend Anleitung, insbesondere Unbound nach unbound - Pi-hole documentation inkl. Deaktivierung des unbound-resolvconf Dienstes.

Nun steht in /etc/resolv.conf (nur) die IPv6 des Pi.Hole. resolvconf -l meldet als Grund eth0.ra und (falls aktiviert in der FB) eth0.dhcp6

Nun könnte ich zwar in /etc/dhcpcd.conf den Wert von static domain_name_servers auf IPv4/IPv6 der FB setzen, aber ich bin einerseits verwundert, dass diese nicht über DHCP bzw. RouterAssignment gesetzt werden, andererseits habe ich auch bisher keine Anleitung gesehen, dass das überhaupt notwendig sein sollte.

Irgendeine Idee was hier falsch sein könnte?

Danke!
Jeff

Da das nur nachts passiert: schau mal im Log deiner FB nach, ob das die Zeit ist, zu der die Zwangstrennung stattfindet.

Nein, das ist (immer) eine ganz andere Zeit.

Vielleicht hängt die Abfrage mit GitHub - jacklul/pihole-updatelists: Update Pi-hole's lists from remote sources easily zusammen - hab noch nicht gefunden, wann deren Aktualisierung läuft. Die zu dieser Zeit abgefragten Domains scheinen mir allerdings weniger Domains auf Ad-Listen zu sein, als real verwendete (so ähnlich wie eine Cache-Aktualisierung nach Ablauf der TTL stelle ich mir vor) - weiß aber nicht woher das kommen könnte.

Gerade habe ich noch die Forward-Zone von Unbound entdeckt - hatte ein ähnliches Problem wie hier: Unbound servfail Hab wohl noch nicht 100% verstanden, wie das alles miteinander verzahnt ist, aber auch dieses Problem tritt nur auf, wenn "static domain_name_servers" nicht gesetzt ist. Dann steht nur die eigene IPv6 in der forward_zone.

By default, the script runs at random time (between 03:00 and 04:00) on Saturday
GitHub - jacklul/pihole-updatelists: Update Pi-hole's lists from remote sources easily

Wie ist denn die Antwort auf diese Anfragen? Werden die korrekt beantwortet?

Interessanterweise war der Peak am Sonntag viel höher, am Montag nicht ganz so, aber doch auch deutlich mehr.

"Query Log" zeigt am Sonntag ~7300 erlaubte und 85 geblockte, am Montag ~2100 erlaubte und 102 geblockte. Welche Folge das Überschreiten des Maximums hatte, kann ich aus dem bisherigen Log leider nicht entnehmen.

Ich habe jetzt doch wieder IPv4 und IPv6 der FB in "static domain_name_servers" (dhcpcd.conf) eingetragen, dann gibt es auch keinen Peak mehr. Außerdem das "resolvconf_resolvers.conf" deaktiviert und gelöscht. Das scheint jetzt auch wirklich gut zu laufen (dnsleaktest zur Kontrolle hat bis dahin immer den DNS der FB angezeigt!) - nur frage ich mich, ob es "richtig" ist, dass das manuell zu machen ist, oder ob ich ingesamt noch einen Fehler habe.

Auf jeden Fall schon mal Danke für die hilfreichen Denkanstöße!

Verwendest Du unbound auf einem Debian/RPiOS Bullseye?

Dann könnte die folgenden Schritte helfen:
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

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.