Leider funktioniert das aber eben nicht so wie man sich das denkt. Dadurch hättest du den Effekt, dass sporadisch eben doch Werbung durchkommt, weil ein DNS-Client sehr kurze Timeouts für den primären DNS hat und danach sofort den sekundären fragt - parallel zu einem zweiten Request beim primären DNS mit längerem Timeout. So schaukelt sich das hoch und beide werden quasi-parallel benutzt. Anders geht das auch gar nicht, weil sonst bei einem fehlerhaften primären DNS die Wartezeiten extrem spürbar wären, weil es ja keine "Umschaltung" im Falle eines Ausfalls gibt, sondern der grob beschriebene Prozess bei jedem DNS-Query auf's neue beginnt - immer erst primär fragen, warten, dann sekundär fragen, warten. Stattdessen wird der sekundäre ziemlich schnell gefragt, wenn der primäre auch nur eine Mikrosekunde zu lange braucht.
Deswegen ist es essentiell wichtig, dass primärer und sekundärer DNS quasi-identisch sind. Das wären zB 8.8.8.8 + 8.8.4.4 oder eben zB zwei pihole-Instanzen im lokalen Netz. Bei gemischten DNS kann ansonsten nicht sichergestellt werden, dass jeder DNS-Query auf Werbung/Tracker hin untersucht wird oder zB lokale DNS-Queries auch wirklich lokal bleiben (mal die Fritzbox als forwarder für die DHCP-Clients außen vor gelassen).
[...]
Da bei dir also kein 8.8.8.8/1.1.1.1 im Spiel ist und pihole im Fehlerfall auch keine eingehenden Queries anzeigt, bleiben nur zwei Fehlerquellen übrig: Der Client-PC, der ggfs gar keinen DNS-Query abschickt, oder die Fritzbox, die ihrerseits den Query vom Client empfängt, aber nicht weiterleitet.
Der nächste Schritt könnte nun also WireShark bzw. tcpdump sein, mit denen man am PC bzw. in der Fritzbox den DNS-Traffic (Port 53) mitliest.
