# Merkwürdiges Verhalten von PiHole

**URL:** <https://discourse.pi-hole.net/t/merkwurdiges-verhalten-von-pihole/47636>\
**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:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![R0cc0Naut](https://discourse-cdn.pi-hole.net/letter_avatar_proxy/v4/letter/r/a9adbd/32.png) [@R0cc0Naut](https://discourse.pi-hole.net/u/R0cc0Naut)\
**Post date:** [June 14, 2021, 10:40am UTC](https://discourse.pi-hole.net/t/merkwurdiges-verhalten-von-pihole/47636/1 "2021-06-14T10:40:54Z")

</div>

Hallo zusammen,

ich habe PiHole letzte Woche in Proxmox in einem LXC installiert.  
Von beginn an, verhält sich das PiHole sehr merkwürdig und ich kann den Grund nicht finden.

Ich bekomme sporadisch bei den DNS Abfragen N/A zurück. Das Verhalten ist vollkommen zufällig, zumindest konnte ich kein Muster erkennen. Die gleiche Abfrage geht Sekunden später sauber durch.

 ![NA](https://discourse.pi-hole.net/uploads/default/original/3X/c/d/cd1e199f3834b723345008805ed5a6a619aaeb3b.png)

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.  
Wo das .local her kommt habe ich inzwischen rausgefunden, aber nicht warum das kommt. Es erscheint nämlich nicht bei jeder Abfrage.

 ![dwd](https://discourse.pi-hole.net/uploads/default/original/3X/a/2/a2b5b7060b172b6a184021b3281bd3b05cf33c00.png)

Ich habe verschiedene DNS Server versucht (google, Quad9, etc) auch in Kombination. Gleiches ergebnis.  
DNS Anfragen vom Client direkt, oder über den Router, gleiches Ergebnis.

---

<div class="post-metadata">

**Author:** ![jfb](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/jfb/32/4332_2.png) [@jfb](https://discourse.pi-hole.net/u/jfb)\
**Post date:** [June 14, 2021, 12:34pm UTC](https://discourse.pi-hole.net/t/merkwurdiges-verhalten-von-pihole/47636/2 "2021-06-14T12:34:23Z")

</div>

Bitte lade ein _Debug Log_ hoch und poste hier anschliessend **nur das Token**.  
Das Token generierst Du über

```auto
pihole -d

```

wobei Du die Frage nach dem Upload bejahst, oder Du machst das über die Weboberfläche:  
_ **Tools \> Generate Debug Log** _

---

<div class="post-metadata">

**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 14, 2021, 1:10pm UTC](https://discourse.pi-hole.net/t/merkwurdiges-verhalten-von-pihole/47636/3 "2021-06-14T13:10:42Z")

</div>

> [@R0cc0Naut](#):
>
> Dann habe ich auf Proxmox diverse Container laufen, die auch, ebenfalls ohne erkennbares Muster, hinter die DNS Abfrage ein .local hängen

Dass Clients eine Suchabfrage um die lokale Domäne/Suchdomäne/_search suffix_ ergänzen, ist nicht ungewöhnlich. Allerdings sollte `.local` als lokaler Domänenname vermieden werden, da die Verwendung von `.local` für das [mDNS-Protokoll](https://en.wikipedia.org/wiki/Multicast_DNS) reserviert ist.  
Du solltest Dein Netzwerk auf eine andere lokale Domäne konfigurieren.

Das hat höchstwahrscheinlich keine Auswirkung auf Deine erste Beobachtung.  
Neben dem _Debug Log_ wäre hier auch interessant, wie die Ausgabe für ein _`dig`_ auf eine der Domänen während des _Retried_-Zeitraums aussieht.

---

<div class="post-metadata">

**Author:** ![R0cc0Naut](https://discourse-cdn.pi-hole.net/letter_avatar_proxy/v4/letter/r/a9adbd/32.png) [@R0cc0Naut](https://discourse.pi-hole.net/u/R0cc0Naut)\
**Post date:** [June 16, 2021, 8:13am UTC](https://discourse.pi-hole.net/t/merkwurdiges-verhalten-von-pihole/47636/4 "2021-06-16T08:13:31Z")

</div>

Hi,

hier der Token.

[https://tricorder.pi-hole.net/69oi7kdz8i](https://tricorder.pi-hole.net/69oi7kdz8i)

---

<div class="post-metadata">

**Author:** ![R0cc0Naut](https://discourse-cdn.pi-hole.net/letter_avatar_proxy/v4/letter/r/a9adbd/32.png) [@R0cc0Naut](https://discourse.pi-hole.net/u/R0cc0Naut)\
**Post date:** [June 16, 2021, 8:15am UTC](https://discourse.pi-hole.net/t/merkwurdiges-verhalten-von-pihole/47636/5 "2021-06-16T08:15:20Z")

</div>

das .local hatte ich nur zu Testzwecken dort eingetragen.  
Ursprünglich war es .fritzbox, hat aber das gleiche Verhalten ausgelöst.

was ist mit einem "dig" gemeint ?

Edit: War gerade 20min auf Amazon am surfen und plötzlich ging nichts mehr. Alle DNS Abfragen zu Amazon und sogar hier das Forum, kamen mit N/A zurück.

So ist das PiHole nicht nutzbar.  
DIe Ausfälle sind komplett zufällig. Beschränkt sich nicht auf bestimmte Sites oder Uhrzeiten.

---

<div class="post-metadata">

**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")

</div>

> [@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 <auffällige.domain> @192.168.2.14

```

```auto
dig <auffällige.domain> @208.67.222.222

```

`<auffällige.domain>` 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.

---

<div class="post-metadata">

**Author:** ![DL6ER](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/dl6er/32/281_2.png) [@DL6ER](https://discourse.pi-hole.net/u/DL6ER)\
**Post date:** [June 19, 2021, 8:25am UTC](https://discourse.pi-hole.net/t/merkwurdiges-verhalten-von-pihole/47636/9 "2021-06-19T08:25:11Z")

</div>

> [@R0cc0Naut](#):
>
> War gerade 20min auf Amazon am surfen und plötzlich ging nichts mehr. Alle DNS Abfragen zu Amazon und sogar hier das Forum, kamen mit N/A zurück.

N/A steht in diesem Kontext für "Not available" und heißt, dass es bislang _keine_ Antwort vom DNS Server gegeben hat. Wenn das passiert wären die Zeilen in der Datei `/var/log/pihole.log` zu diesem Zeitpunkt interessant. Hier kann man vermutlich sehen, dass nichts von Deinem gewählten DNS Server zurück kam.

- Kann es sein, dass es temporäre Internetprobleme gab?
- Könntest Du wenn es wieder auftritt einen `ping` zu dem von Dir gewählten DNS Server probieren?
- Könntest Du temporär einen anderen DNS Server probieren?

Ich hatte ähnliche Probleme mit der Fritzbox 7590 wo zeitweise das DSL abhanden kam ohne dass die Fritzbox es in der grafischen Oberfläche vermeldet hat. Ich habe dann ein geschirmtes Kabel statt des normalen Telefonkabels verlegt und meine Probleme waren behoben. (das nur als Randnotiz)

---

<div class="post-metadata">

**Author:** ![system](https://discourse.pi-hole.net/uploads/default/original/3X/7/c/7c8792f649eeb921c5d2b4c41564ffa873d9a2b8.png) [@system](https://discourse.pi-hole.net/u/system)\
**Post date:** [July 10, 2021, 8:25am UTC](https://discourse.pi-hole.net/t/merkwurdiges-verhalten-von-pihole/47636/10 "2021-07-10T08:25:15Z")

</div>

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