PiHole with Unbound (recursive DNS) Step-by-Step Tutorial | The internet is broken!

Zitat aus einem Post von davebastard

welche server hast du bei Settings -> DNS eingetragen ?

kanns sein dass du als primary einen eingetragen hast der nicht zuverlässig ist und dann fragt er immer erst nach dem fail den secondary ? (cloudflare 1.1.1.1)

Cloudflare einfach aus Geschwindigkeitsgründen, aber ich hab das auch mit Google DNS etc. Alles schon versucht - Keine Veränderung.

Smut ich hab deinen Vorschlag jetzt versucht mit GMX. Da kann ich das Verhalten regelmäßig provozieren.
Beispiel - Aufruf des GMX Posteingangs - Da möchte er die Adresse 3c.gmx.net aufrufen.

Im Browser kommt die Timeout-Meldung
Hinterher gleich ein Lookup von der Pi-Console aus (linke Seite) und von meinen Rechner aus (rechtes Fenster).
Beide bekommen Antwort. Danach einmal das Browserfenster refreshed und tada - Seite ist ganz normal da.



Ich tu mir schwer das wirklich in "Echtzeit" zu prüfen, da es eben in einem Moment nicht geht und 2 Sekunden später funktioniert.
Das ganze ist auch nicht beider jeder Seite - eher bei 5-10% aller Anfragen, aber dennoch unerträglich.

Ich würde auf jeden Fall mal UniFi IPS/IDS ausschalten testweise, selbiges für lokale Virenscanner und deren Browser-Plugins um solche Probleme mal auszuschließen.

Auch mal testen im Privacy Mode bzw. mit allen Browser Plugins deaktiviert (insbesondere für sowas wie HTTPS Everywhere, Decentraleyes etc.).

Hat dein Netzwerk die Möglichkeit eine andere Route zu gehen (innerhalb von deinem Netzwerk) als raus gegangen ist?
Manchmal blockieren Firewalls/Router (UniFi?) Pakete die nicht am selben Weg zurückkommen wie dessen Anfrage raus gegangen sind und werden dann eingehend blockiert (resultiert dann eben in Timeout weil nichts ankommt), Assymetric Routing?

Als Browser würde ich auch mal z.B. Firefox verwenden, falls das da oben Chrome ist - Chrome macht da mittlerweile gerne seine eigenen Shenanigans was DNS Anfragen angeht um Blocker zu umgehen ...

Zitat aus einem Post von COLOSSUS

[...]https://coloss.us.to/chrome_truth.png[...]

Zuerst mal Danke für die Antworten.

Ich hab am USG sämtliche Sachen bis auf DPI auf OFF, hab testweise DPI auch ausgeschalten - keine Veränderung.

Getestet und aufgetaucht sind die Probleme auf Chrome mit und ohne Extensions, Safari, Handybrowser von Android und Apple, aber auch Geräte wie eine Shield oder Echos bekamen die "retried" Probleme zu spüren.
Also kein Device blieb verschont.

Ich hab jetzt mal folgendes gemacht.
Im USG habe ich den zu kommunizierenden DNS auf Cloudflare geändert und die Änderung ans USG provisioniert = Alle Geräte bekommen den neuen DNS. Ergebnis - alles funktioniert, logischerweise habe ich jetzt die Pi-Hole Funktionalität verloren.

Dann habe ich meinem Rechner manuell Pi-Hole als DNS eingetragen und geschaut was passiert.
Info: Am Pi-Hole ist ebenso Cloudflare als DNS Upstream hinterlegt.

Jetzt habe ich keine Probleme mehr beim Surfen auf diesem Gerät.
Ich habe zwar noch den ein oder anderen "Retried" Status, aber alle Seiten werden zügig so geladen wie es sein soll. Würde ich nicht ins Log schauen, es würde mir nicht auffallen.

Also was bitteschön ist der Unterschied zwischen IP des DNS manuell eintragen und DNS Server über das USG verteilen lassen?

Kann es dann wirklich die Anzahl an Geräten sein? (ca. 30)
Die Hardware schnarcht eigentlich vor sich hin.

Füge noch ein Bild an von den wenigen "Retried" Antworten als Pi-Hole manuell bei mir eingetragen war. Wie gesagt ich sehe es zwar im Log, aber in der Praxis fällt es nicht auf.
Die erste Anfrage war ein Pi-Hole Forumsbeitrag, die zweite vermutlich die Signal Desktop App.

Hab bei mir die Adressen alle in die hosts eingetragen - geht auch.

Nochmal zu meinem Setting - Ich verfüge leider nicht über die Expertise das selbst zu lösen :/

Router (WAN) <--> (LAN) Ubiquiti USG [DHCP] --> Clients

Im USG hab ich den Pi als DNS Server eingetragen und die Clients greifen auch schön brav darauf zu. Alles funktioniert perfekt.
Aber nach ~ 4 Tagen beginnen dann die Probleme und DNS Anfragen (zumindest viele) werden nicht mehr beantwortet und vom Pi mit einem "retried" beantwortet.

Selbst wenn ich dann alles vom Router über USG, bis zum Pi neu starte macht es keinen Unterschied.

Im USG trage ich als Gegenprobe einen anderen DNS Server statt des Pi-Holes ein (zb Cloudflare), warte bis sich die Clients die Settings holen und alles funktioniert.
Cloudflare ist auch im Pi eingetragen, daher denke ich nicht, dasss es am DNS Upstream an sich liegt.

Um dann weiter zu testen habe ich dann nur meinem Desktop die DNS des Pi-Servers eingetragen und kann auch ganz normal surfen.

Also habe ich 2 Vermutungen:

1) Anzahl der Geräte: Obwohl das Pi-Hole kaum ausgelastet ist wäre es denkbar, dass es zu viele Geräte sind!?

2) Es gibt irgendein "Log-File" oder sonst irgendeine "Table" die befüllt wird und nach X - Einträgen voll läuft.
(Das würde auch die 4 Tage perfektes funktionieren zu Beginn erklären)

Zitat aus einem Post von TOM

Ich würd an deiner Stelle im Pihole einen anderen Upstream DNS hinterlegen und testen.

Alles schon versucht :/

Unbound werd ich mir anschauen.

ja same here, verwende auch den router (openwrt) als dhcp. für sowas essentielles will ich nicht ein service das in einem docker container rennt...

Zitat aus einem Post von __Luki__

Ich wuerde empfehlen, statt Cloudflare oder Google direkt mit den DNS Root Servern zu sprechen => sonst schickst du ja deine kompletten DNS Daten wieder zu einem Provider...


LG

irgendwelche nachteile hat das aber auch, ich kann mich jetzt nicht mehr erinnern was aber ich hab das damals auch recherchiert....