Folgende Fehlermeldung seit über einem Jahr, eigentlich fast täglich einmal.
Connection error (9.9.9.10#53): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
Auch mit anderen DNS Servern:
Connection error (149.112.112.10#53): TCP connection failed while receiving payload length from upstream (Connection prematurely closed by remote server)
Auf Netzwerk Ebene scheint mir alles sauber zu sein, kein Packet Loss oder ähnliches zu sehen, wo sowas dann mit untergehen könnte. Ich bin auf ipv4 only unterwegs intern.
Wenn man danach sucht heißt es das wäre ja nur eine Notiz, die seit einiger Zeit jetzt im Log landet und nicht mehr stillschweigend verworfen wird.
Aber ...
Seit grob einem Jahr habe ich 1-2-3 mal am Tag mit dem DNS Probleme.
Große Seiten(Faz.net, Golem.de, Heise.de), die ich mehrfach täglich aufrufe. Nach einiger Wartezeit Timout Faz.net nicht erreichbar. Eigentlich merkt man es inzwischen schon wenn im Browser mal ne Seite nicht direkt da ist.
Ich vermute da geht die Antwort auf eine DNS Anfrage verloren. Dann muss erst irgendwas in ein Timeout von mutmaßlich größer 30 sek laufen. Dann kommt die Meldung das die Domain nicht aufgelöst werden kann. Dann drückt man F5 im Browser, die nächste DNS Abfrage ist erfolgreich und die Seite ist da.
Genau heute konnte ich eine korrelation herstellen das diese Logeinträge wohl immer genau dann kommen, wenn mal wieder eine Seite erst beim zweiten Versuch laden wollte. Da kann ich dann auch wieder die Vodafone DNS Server nehmen die früher einfach zuoft ausgestiegen sind, weswegen ich mir ein Pi Hole angeschafft habe.
Die Forensoftware sagt mir es gibt zu dem Thema bereits Beiträge, deswegen hatte ich hier einen Account erstellt, weil ich auf einen davon Antworten wollte. Als ich dann einen Account hatte gab es keinen Antworten Button mehr, also ein neuer Thread.
Ich hätte Interesse daran das Problem zu lösen und liefer auch gerne noch weitere Infos.
Der von Pi-hole kontaktierte DNS-Server (in Deinem Fall einer von verschiedenen Quad9-DNS-Servern) hat die Verbindung vorzeitig aktiv beendet, also bevor Daten vollständig übertragen wurden.
In der Regel ist anzunehmen, dass der DNS-Server temporär teilweise überlastet war, oder dass die maximal zulässige Zahl von Anfragen von Deiner öffentlichen IP-Adresse überschritten wurde.
Pi-hole kann diesen Fehler nur feststellen - warum Quad9 die Übertragung tatsächlich beendet, wäre nur durch Quad9 ermittelbar.
Ist das denn bei Quad 9 üblich das die DNS Server täglich überlastet sind?
Ich denke eher nicht?
Ich nahm die eigentlich auch bewusst, statt z.b. welche vom CCC, weil Quad 9 dann doch etwas größer ist und es eher unüblich ist das deren Server überlastet sind.
Das würde ja auch bei anderen Pi Hole Usern die Quad 9 nutzen auftreten. Da find ich jetzt aber eher weniger Beiträge zu solchen Themen.
Die maximal zulässige Anzahl von Anfragen klingt interessant, denn ein rate limit mit 150 Anfragen die Sekunde tauchte auch gelegentlich im Logs auf, mein Eindruck nach dem deaktivieren des Limits auf dem Pi Hole war auch nicht das es besser wurde.
Ich kann mir einfach nicht vorstellen das ich in nem Single Nerd Haushalt mit 2-3 VMs und 3-4 Docker Services intern, auf derart viele DNS Anfragen komme das ich da mal auf Quad 9 Seite in ein limit renne. Da fand ich jetzt spontan was von mehr als 5000 Anfragen die sekunde, ab denen sich Firmen gedanken machen sollten das intern nochmal zu chachen.
Die höchten Peaks bei mir im Pihole sehe ich bei 1400 Anfragen in einem 10minuten Zeitraum.
das klingt für mich jetzt auch nicht nach extrem viel.
(Sorry for answer in English)
Yes.
This error always happened in the background, but older Pi-hole versions never warned about it.
Since Pi-hole v6 these messages are showed to users.
This also happens with every other upstream server, including local Unbound, when installed.
It can happens if the upstream server is overloaded, but it can also happen if the connection fails for any other reason.
Please note that Pi-hole is not causing this error in any way.
Pi-hole is only reporting that a request was sent to the upstream server (Quad9, in your case), but no answer was received. Pi-hole never received anything back. Without an answer, error or any other information, Pi-hole assumed it was a timeout and the connection was closed... and this message was logged.
These are mostly harmless messages.
If you prefer, you can disable them.
Just enable this option:
Eine Deaktivierung von Pi-holes clientbezogenem Rate Limit würde sehr wahrscheinlich die QPS-Rate bei den Upstream-DNS-Servern erhöhen und könnte damit potentiell zu Deiner Beobachtung beitragen.
Allerdings forciert Pi-hole eine Begrenzung von 150 standardmäßig nicht für ein Rate Limit, sondern für die maximal mögliche Anzahl an gleichzeitigen DNS-Anfragen.
Die entsprechende Meldung 'Maximum number of concurrent DNS queries reached' kann einerseits durch eine DNS-Schleife ausgelöst werden.
Andererseits können (temporär) nicht erreichbare oder nicht antwortende DNS-Server genauso zu dieser Meldung führen.
Zusammen mit einem bereits vorher beobachteten TCP connection-Fehler wäre dies also eher ein weiteres Indiz dafür, dass ein Upstream vorübergehend nicht erreichbar war oder nur stark verzögert geantwortet hat.
Eine DNS-Schleife könnte zwar zu einem temporären Ausfall von Pi-holes DNS-Funktion führen, weil Pi-hole dann keine neuen DNS-Anfragen mehr annehmen könnte. Allerdings wäre in diesem Zusammenhang erst einmal nicht mit den beobachteten TCP connection-Fehlern zu rechnen (höchstens zufällig im Nachgang).
Aus welcher Quelle hast Du den Wert von 5.000 QPS?
Mir ist nur Quad9s Empfehlung auf DNS Forwarder Best Practices - Quad9 Documentation bekannt, in der eine individuelle Kontaktaufnahme bereits ab 500 QPS angeraten wird.
Im Umfeld von HomeAssistant ist es anscheinend durchaus schon zu Auffälligkeiten wie temporärer Sperrung der IPdurch Quad9 (siehe z.B. Home Assistant gets me banned from quad9 · Issue #147152 · home-assistant/core · GitHub).
In diesem Kontext ist vielleicht relevant, dass DNS-Anfragen primär per UDP übertragen werden. Auf das aufwändigere TCP (auf das sich die von Dir beobachtete Meldung direkt bezieht) wird nur zurückgegriffen, wenn eine Antwort zu groß für ein UDP-Paket sein sollte.
Es wäre daher durchaus plausibel, dass ein DNS-Server unterschiedliche Limits für UDP- und TCP-Verbindungen verfolgt.
Diese Details wären aber nur über den Betreiber ermittelbar.
Die 5000 QPS hab ich mir dann wohl zusammengeschielt, du hast recht 500 QPS und 5000 User steht da, das hab ich vermutlich durcheinander gebracht...
Ich danke euch allen für eure Hinweise und Tipps, grade das mit TCP und UDP klingt als ob ich da mal weiter forschen sollte, am Ende hab ich UDP nicht in der Firewall freigegeben oder so ...
Das das Problem nicht unbedingt am Pi Hole liegt ist mir durchaus bewusst...
Ich werde mal tiefer forschen ob evtl irgendwo UDP geblockt wird in meinem Netz.
Wenn das alles über TCP läuft, was eher ungewöhnlich ist, kann man ja durchaus mal in eine Art rate limit auf Quad 9 Seite rennen
Das ist unwahrscheinlich - wenn 53/UDP geblockt wäre, wäre keine DNS-Auflösung mehr möglich.
Setzt Du ebenfalls HomeAssistant ein?
Du könntest versuchen, die Deaktivierung von Pi-holes Rate Limit rückgängig zu machen. Wenn Pi-hole -wie in der Standardkonfiguration- bereits die Anzahl an DNS-Anfragen begrenzt, dann würde das eine Upstream-Begrenzung zumindest unwahrscheinlicher machen.
Sofern dann wieder Rate Limit- oder Max concurrency-Warnungen auftreten, wäre es empfehlenswert, die Ursache dafür herauszufinden und wenn möglich zu beheben - unabhängig davon, ob dies einen Einfluss auf die beobachteten TCP connection-Fehler haben sollte.
Nein kein Homeassistent im Einsatz bei mir.
Und falls die Stats auf dem Dashboard vom Pihole korrekt sind habe ich da max. 1400 -1500 Anfragen in einem 10min Zeitraum. Davon werden vielleicht 200 nicht geblockt, oder aus dem cache beantwortet.
da würde ich sagen das rate limit ist nicht wirklich ein problem.
da bleibt nur nochmal den router checken ob mir da was auffällt und ob es bei den fehlern dabei bleibt das da versucht wird DNS über TCP zu treiben
