Verliere ständig erst Upstream und dann Internet bei Video-Calls (Vodafone, Fritz-Box, Pihole)

Expected Behaviour:

Ich benutze:

  • Vodafone Kabel Internet
  • AVM FRITZ!Box 6591 Cable
  • Pi-hole** [v5.18.2]
  • FTL [v5.25.2]

Actual Behaviour:

  • In unregelmäßigen Abständen, aber manchmal im 20 Minuten-Takt, manchmal erst nach einigen Tagen
  • Hauptsächlich bei Teams Video Calls
  • Verliere erst den Upstream
  • Nach einiger Zeit oft auch den Downstream
  • Sehr viele PiHole Queries enden mit NODATA:

dns_queries_all_types 75812
reply_UNKNOWN 15805
reply_NODATA 7498
reply_NXDOMAIN 472
reply_CNAME 21878
reply_IP 22627
reply_DOMAIN 162
reply_RRNAME 1
reply_SERVFAIL 1567
reply_REFUSED 5606
reply_NOTIMP 0
reply_OTHER 0
reply_DNSSEC 0
reply_NONE 0
reply_BLOB 196

Debug Token:

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

Dein Pi-hole läuft auf einem Rechner mit der IP 192.168.178.33.
Laut Debug Log hast Du diese IP-Adresse als Upstream für Pi-hole konfiguriert.

Damit würde Pi-hole sich selbst befragen, weshalb die Nutzung dieser IP verworfen wird:

*** [ DIAGNOSING ]: Pi-hole diagnosis messages
 count  last timestamp       type          message
 -----  -------------------  ------------  ----------------------------------------------------
 1      2024-06-10 13:05:54  DNSMASQ_WARN  ignoring nameserver 192.168.178.33 - local interface  

Pi-hole sollte niemals sein eigener Upstream sein.
Du solltest diese IP aus Pi-holes Upstreams entfernen.

Die ebenfalls als Upstream konfigurierte IPv6-ULA gehört zu Deinem Fritzbox-Router.
Da Du die Fritzbox als Pi-holes Upstream verwendest, kannst Du Pi-holes Conditional Forwarding deaktivieren - in dieser Konstellation bekommt ja die Fritzbox ohnehin alle DNS-Anfragen. Never forward non-FQDN A and AAAA queries unter Settings | DNS sollte dann deaktiviert sein, damit auch einfache Hostnamen (wie z.B. smartphone) an die FB weitergeleitet werden.

Dieser liefert also alle Antworten für von Pi-hole nicht geblockte Domänen und befragt dafür seinerseits seine Upstream-DNS-Server - bei Fritzboxen konfiguriert unter Internet > Zugangsdaten > DNS-Server.

Welche Server hast Du da eingetragen?

NODATA ist eine normale DNS-Antwort - sie bedeutet, dass für den angefragten Datensatz schlicht keine Daten im DNS hinterlegt sind (z.B. gibt es derzeit für imap.1und1.de keinen AAAA-Datensatz).

Auffällig sind eher folgende Antworten:

UNKNOWN bedeutet, dass Pi-hole eine Anfrage an einen Upstream weitergeleitet, aber nie eine Antwort erhalten hat (in Deinem Fall also von der Fritzbox).

Das passiert in der Regel, wenn der befragte Upstream überlastet war, was wahrscheinlich wiederum auf einen der Fritzbox-Upstreams zurückzuführen ist (z.B. antworten die DNS-Server von Digital Courage leider öfters nur eingeschränkt oder langsam).

REFUSED bedeutet in der Regel, dass ein Upstream überhaupt nicht erreichbar ist oder die Anfrage ablehnt. Das könnte z.B, passieren, wenn die Fritzbox Pi-hole als einen ihrer Upstreams verwendet.

1 Like

Erstmal danke für die ausführliche Antwort.
Ich bin hier einem Tutorial gefolgt, fand das mit der IP vom PI als upstream auch seltsam, aber da es ja (meist) funktioniert hab ich es mal gelassen. Aber es macht wenig sinn.

Bei der Fritzbox unter Internet > Zugangsdaten > DNS
habe ichVom Internetanbieter zugewiesene DNSv4/6-Server verwenden (empfohlen)

gewählt.

Dann ist es wahrscheinlich, dass die DNS-Server Deines Internetanbieters bisweilen überlastet sind.

Versuch's mal mit öffentlichen DNS-Servern.

Ich habe jetzt folgendes gemacht:

Bevorzugter DNSv4-Server 94.140.14.140
Alternativer DNSv4-Server 176.9.93.198

Bevorzugter DNSv6-Server 2a10:50c0::1:ff
Alternativer DNSv6-Server 2a01:4f8:151:34aa::198

Dennoch tritt das Problem auf und immer noch verstärkt bei Video-Sharing
Gleichzeitig zu den Momenten sehe ich im Pihole einen ziemlichen spike an Requests.

Laut Fritzbox bin ich allerdings mit guter Geschwindigkeit verbunden.
Stichprobenartig habe ich dann Pihole aus dem Netz genommen und die Probleme waren weg.

Es scheint für mich so, als ob Pihole in Intervallen überlastet wird und dann die Requests nicht mehr verarbeitet und festhängt. Aber das kann auch ein komplett falscher Eindruck sein.

Hier nochmal ein Debug token: https://tricorder.pi-hole.net/14y9fIEf/

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