Das Verhalten in Bezug auf die Suchdomäne ist ja auch normal, nur handelst Du Dir mit .local ggf. Schwierigkeiten ein, da...
Dein Debug Log sieht soweit unauffällig aus, bis auf die folgenden Meldungen:
*** [ 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 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.
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.
dig <auffällige.domain> @192.168.2.14
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.