Diese Zeilen bedeuten, dass Pi-hole eine Anfrage von 192.168.178.21 für den A-Record von pi4.fritz.box erhalten hat.
Für diesen Namen existiert allerdings überhaupt kein Eintrag (NXDOMAIN).
Das ist laut Deiner Beschreibung auch das erwartete Ergebnis.
Es ist dabei durchaus normal, dass Clients DNS-Anfragen um die lokale Domäne erweitern (in Deinem Fall fritz.box). Für pi4.fritz.box hat das in Deinem Fall entsprechend zu einer weiteren Anfrage nach pi4.fritz.box.fritz.box geführt.
Z.B. würde ein nslookup pi4.fritz.box auf Windows zu einer Anzahl an vergleichbaren Anfragen an Pi-hole führen.
Du müsstest herausfinden, warum 192.168.178.21 verzweifelt versucht, pi4.fritz.box aufzulösen.
Ich müsste herausfinden, warum mein Pi-hole (das ist die 192.168.178.21) verzweifelt versucht, pi4.fritz.box aufzulösen. Leider habe ich keine Idee, wie. Noch irgendwelche Ideen? Herzlichen Dank nochmals!
Nicht ganz: 192.168.178.21 ist die IP-Adresse des Rechners, auf dem Pi-hole läuft, und andere Software eben auch.
Pi-hole würde von sich aus keine DNS-Anfragen stellen (abgesehen von eventuellen stündlichen Rückwärtsanfragen für IP-Adressen).
Bitte lade ein Debug Log hoch und poste hier anschließend nur die Token-URL.
Das Token generierst Du über
pihole -d
wobei Du die Frage nach dem Upload bejahst, oder Du machst das über die Weboberfläche: Tools > Generate Debug Log
NOTE:
When you Upload the log and post the Token, the log is actually uploaded to a secure server and only a few members of Pi-hole team are able to read the log to help you.
Allerdings weist rdwebdesign korrekt darauf hin, dass ein hochgeladenes Debug Log nur von ausgewählten Mitgliedern des Pi-hole-Teams eingesehen werden kann.
Außerdem werden Debug Logs automatisch nach Ablauf von 48 Stunden vom Server gelöscht.
Ich kann auch vorab weder sicher ausschliessen noch bestätigen, dass die genannten Abschnitte nicht vielleicht zu Deiner Beobachtung beitragen könnten.
Unabhängig davon finden sich in dieser Kategorie (Clients/Groups) bisweilen Konfigurationsfehler, die wir Dir dann auch mitteilen würden - vorausgesetzt natürlich, wir sehen sie überhaupt.
Insofern würde ich eher empfehlen, die Abschnitte zu belassen.
Hallo nochmal! Bevor ich alles hochlade bzw. den Token URL angebe, möchte ich noch mitteilen, dass ich den String pi4.fritz.box mittels sudo grep -rnw '/' -e 'pi4.fritz.box' (als sudoer) auf der virtuellen Maschine (192.168.178.21) finden konnte, auf dem Pi-hole läuft:
grep: /dev/shm/FTL-strings: Übereinstimmungen in Binärdatei
grep: /etc/pihole/pihole-FTL.db: Übereinstimmungen in Binärdatei
Hilft das, das Problem ohne den Token URL einzugrenzen? Wenn in den beiden Dateien pi4.fritz.box enthalten ist, ist das ein Hinweis, dass ein Service diesen Client vergeblich versucht aufzulösen? Ich hatte einmal einen Client pi4 genannt, aber inzwischen umbenannt. Kann es sein, dass da noch irgendwelche Reste übrig sind? Macht es Sinn und ist es möglich, die beiden o.g. Dateien neu erstellen zu lassen?
Nein, das sagt uns nur, dass der gesuchte Text in Pi-holes Langzeitdatenbank auftaucht (pihole-FTL.db), und dass zumindest eine die Anfrage auch in den letzten 24 Stunden aufgetaucht sein kann (FTL-Strings) - also nichts, was wir nicht schon wissen.
Es lässt sich aufgrund dieser Suche auch nicht ausschliessen, dass hier andere Software als Pi-hole beteiligt ist. Eine Software könnte die Anfrage auch aus Hostname (pi4) und lokaler Domäne (fritz.box) dynamisch zusammengebaut haben, oder den Namen nur als Hash oder verschlüsselt speichern, oder überhaupt nicht speichern und stattdessen dynamisch ermitteln (z.B. über eine Rückwärtsanfrage).
Der pi4 Client heißt nun homeassistant und hat die IP 192.168.178.55. Ich denke wie Du, dass auf der VM irgendein Dienst läuft, wo noch pi4 eingetragen ist, was aber eben nicht mehr aufgelöst werden kann, da er nun nicht mehr unter diesem Namen existiert. Ich suche noch in diversen config Dateien auf der VM, konnte aber bisher nichts finden.
Den brauchst Du auch überhaupt nicht, um das obenstehende nslookup abzuschicken - das funkt die Rückwärtsanfrage nach 192.168.178.55 an die IP-Adresse Deiner FB.
EDIT:
Diese Rückwärtsanfrage soll aufzeigen, ob sich die FB ggf. zu der früher verwendeten IP-Adresse den alten Namen gemerkt hat.
Das sieht ok aus, liefert aber auch keine neuen Erkenntnisse.
(Und da 192.168.178.1 als Ziel-DNS-Server angegeben wurde, ist es erst einmal und grundsätzlich egal, von welchem Rechner Du das ausführst.)
Zur Erklärung (falls das hilft): In der VM, auf der Pi-hole läuft, läuft auch Unbound. Und in Pi-hole habe ich das dann auch so im Pi-hole DNS Tab eingetragen: 127.0.0.1#5335
So hat es immer funktioniert, wobei ich mich nun auch wundere, dass dort der Port 5335 lautet (und so hatte ich Unbound m.E. konfiguriert, also weder Port 53, noch Port 5353 wie man es manchmal liest), aber weshalb steht hier im Screenshot #53? Seltsam...
So, jetzt sind die Einträge weg. Es war, wie Du bereits vermutet hattest, ein anderer Dienst auf der VM, auf der auch Pi-hole läuft, und zwar FHEM. Ohne dass ich noch genauer sämtliche FHEM-Einstellungen durchgegangen bin, habe ich es kurzerhand komplett entfernt, und seitdem ist Ruhe im Pi-hole Log. Ich erinnere mich, dass ich Daten von FHEM an meinen Raspberry Pi 4 via MQTT weiterleiten wollte, auf dem Home Assistant lief. Zuerst hieß der RPi 4 Client pi4, später dann homeassistant, was das Problem wohl erklärt.
Es tut mir ehrlich leid, dass ich Deine/Eure Zeit hier für ein Problem in Anspruch genommen habe, das gar nichts mit Pi-hole zu tun hat!
Umso mehr nochmals meinen herzlichen Dank für die vielen Rückmeldungen! Ich habe wieder vieles gelernt.
Es war, wie Du bereits vermutet hattest, ein anderer Dienst auf der VM, auf der auch Pi-hole läuft, und zwar FHEM. Ohne dass ich noch genauer sämtliche FHEM-Einstellungen durchgegangen bin, habe ich es kurzerhand komplett entfernt, und seitdem ist Ruhe im Pi-hole Log. Ich erinnere mich, dass ich Daten von FHEM an meinen Raspberry Pi 4 via MQTT weiterleiten wollte, auf dem Home Assistant lief. Zuerst hieß der RPi 4 Client 
Ich habe wieder vieles gelernt.