# Merkwürdiges Verhalten von PiHole **URL:** \ **Category:** Deutschsprachige Hilfe\ **Created:** [June 14, 2021, 10:40am UTC](https://discourse.pi-hole.net/t/merkwurdiges-verhalten-von-pihole/47636 "2021-06-14T10:40:54Z")\ **Posts on this page:** 1\ **Showing post:** 6

**Author:** ![Bucking\_Horn](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/bucking_horn/32/18719_2.png) [@Bucking\_Horn](https://discourse.pi-hole.net/u/Bucking_Horn)\ **Post date:** [June 17, 2021, 8:29am UTC](https://discourse.pi-hole.net/t/merkwurdiges-verhalten-von-pihole/47636/6 "2021-06-17T08:29:25Z")

> [@R0cc0Naut](#): > > Dann habe ich auf Proxmox diverse Container laufen, die auch, ebenfalls ohne erkennbares Muster, hinter die DNS Abfrage ein .local hängen und dann natürlich vor die Wand laufen. > [@R0cc0Naut](#): > > das .local hatte ich nur zu Testzwecken dort eingetragen. > Ursprünglich war es .fritzbox, hat aber das gleiche Verhalten ausgelöst. Das Verhalten in Bezug auf die Suchdomäne ist ja auch normal, nur handelst Du Dir mit `.local` ggf. Schwierigkeiten ein, da... > [@Bucking\_Horn](#): > > (...) die Verwendung von `.local` für das [mDNS-Protokoll](https://en.wikipedia.org/wiki/Multicast_DNS) reserviert ist. * * * > [@R0cc0Naut](#): > > hier der Token. Dein _Debug Log_ sieht soweit unauffällig aus, bis auf die folgenden Meldungen: ```auto *** [DIAGNOSING]: contents of /var/log -rw-r--r-- 1 pihole pihole 2196 Jun 16 06:03 /var/log/pihole-FTL.log -----head of pihole-FTL.log------ [2021-06-16 03:50:04.951 20956M] FATAL: Trying to access query ID -1, but maximum is 61440 [2021-06-16 03:50:04.951 20956M] found in FTL_query_in_progress() (/root/project/src/dnsmasq_interface.c:2181) [2021-06-16 03:50:04.951 20956M] Failed to unlock SHM lock: Operation not permitted ``` Diese Fehlermeldung ist in [FATAL: Trying to access query ID -1 errors in pihole-FTL.log - #13 by DL6ER](https://discourse.pi-hole.net/t/fatal-trying-to-access-query-id-1-errors-in-pihole-ftl-log/46846/13) bereits untersucht worden und eigentlich in dem Zusammenhang auch behoben. Nach der dortigen Beschreibung hat dieser Fehler allerdings auch ohne Behebung lediglich zu zusätzlichen Log-Einträgen ohne negative Seiteneffekte geführt. Ich werde dazu eine Frage an das Entwickler-Team stellen. * * * > [@R0cc0Naut](#): > > was ist mit einem "dig" gemeint ? _`dig`_ ist ein Kommandozeilen-Tool, das DNS-Anfragen auslösen und Antworten anzeigen kann, ähnlich wie _`nslookup`_. Im Unterschied zu diesem kann _`dig`_ aber detailiertere Informationen ausgeben. _Retried_ bedeutet, dass ein Client eine identische DNS-Anfrage an Pi-hole stellt, die Pi-hole bereits zuvor an einen seiner Upstream-DNS-Server weitergeleitet hat. Dessen Antwort steht allerdings noch aus. Deshalb zeigt Pi-holes _Query Log_ hier als Antwort auch _N/A_, was bei _Retried_ eben soviel bedeutet wie "Antwort steht noch aus". Entweder wiederholt ein ungeduldiges Stück Software auf dem Client die Anfrage zu häufig, oder der Upstream-DNS-Server lässt sich einfach besonders lange Zeit mit seiner Antwort. Wenn Du testweise möglichst nur einen Upstream-DNS-Server in Pi-hole konfigurieren würdest, könnte das helfen, das besser eingrenzen zu können. Eine Ausgabe von _`dig`_ zum Zeitpunkt der _Retried_-Einträge würde im Vergleich mit einer weiteren Anfrage an den verwendeten öffentlichen DNS-Server ggf. weitere Rückschlüsse ermöglichen. Dazu solltest Du die folgenden Kommandos ausführen, wenn das nächste Mal eine Serie von _Retried_ -Anfragen auftritt. ```auto dig @192.168.2.14 ``` ```auto dig @208.67.222.222 ``` `` ist dabei durch die konkret wiederholt angefragte Domain zu ersetzen (also für Deine obigen Bildschirmfotos z.B. auf `dig updates2.signal.org @192.168.2.14`). Im zweiten Kommando ist `208.67.222.222` ggf. durch den aktuell verwendeten Upstream-DNS-Server zu ersetzen. --- _[View the full topic](https://discourse.pi-hole.net/t/merkwurdiges-verhalten-von-pihole/47636)._