Die Fritzbox kann neben der BPjM-Filterung auch eine DNS-Filter-Liste verwalten. Allerdings ist diese Fritzbox-Blacklist auf maximal 500 Einträge begrenzt.
Die Verwendung der Filter muss bei Bedarf im jeweiligen Zugangsprofil aktiviert werden.
Zusätzlich lässt sich der DNS-Port sperren (noch besser wäre eine Umleitung des DNS-Ports auf Pi-hole, aber das unterstützt die FB leider nicht). Wie das geht, habe ich vor einiger Zeit in Smarthome Steckdosen im pihole - #8 by Bucking_Horn beschrieben.
Im Ergebnis könnten die Profile dann in der Übersicht so aussehen (klicken für Bildschirmfoto)
Die Konfiguration der Fritzbox als Pi-holes einziger Upstream-Server ist durchaus valide.
Sie ist gegenüber der Konfiguration von Conditional Forwarding sogar im Vorteil, weil IPv6-Rückwärtsauflösungen für lokale Adressen so ebenfalls so weit möglich funktionieren und außerdem alle Eigen-Adressen der FB aufgelöst werden (die FB verwendet auch Namen außerhalb der von ihr definierten fritz.box-Domäne).
In Bezug auf die Wide-Area-DNS-SD-Anfragen würde es dabei ebenfalls nicht zu einer Veränderung kommen:
Die entsprechenden Anfragen für Deinen privaten IP-Adressbereich 192.168.168.0/24 würden nach wie vor an die FB gehen.
(Klicken für ein paar Erläuterungen zu diesem Typ von Anfragen)
Im aktuellen Netzwerksegment können Geräte über mDNS (ein von DNS völlig unabhängiges Protokoll) und die zugehörige mDNS-Domäne .local direkt miteinander kommunizieren, sofern die jeweiligen Geräte die entsprechenden Protokolle unterstützen.
So können z.B. Apple-Geräte sofort einen Netzwerkdrucker mit AirPrint-Unterstützung finden.
Befinden sich Geräte in verschiedenen Netzwerksegmenten, funktioniert dieser Weg nicht mehr.
Mit Wide-Area-DNS-SD können Geräte im gesamten Netzwerk nach vorhandenen Adressen für bestimmte Anwendungen fragen (z.B. nach verfügbaren Netzwerk-Druckern).
Eine solche Suche wird von einem Client durch die Ermittlung der für DNS-SD zu verwendenden Domäne eingeleitet. Die Anfrage geht an den lokalen DNS-Server und erfolgt mit der vom DHCP-Server an den Client verteilten lokalen Domäne, in Deinem Fall also mit fritz.box.
Die entsprechende DNS-Anfrage in Deinem Query Log ist PTR lb._dns-sd._udp.fritz.box.
Wird hier NXDOMAIN zurückgeliefert, sollte ein Client wissen, dass Wide-Area-DNS-SD in Deinem Netz nicht konfiguriert ist, und weitere DNS-SD-Anfragen einstellen. Die Servicesuche bleibt dann auf dasselbe Netzwerksegment beschränkt (wo sie ganz ohne DNS über mDNS/.local erfolgt).
Eine manuelle DNS-SD-Anfrage über dig zeigt nun, dass die Fritzbox (zumindest meine) hier offensichtlich eine andere Rückgabe liefert als ein öffentlicher DNS-Server:
~ $ dig ptr lb._dns-sd._udp.fritz.box @fritz.box
; <<>> DiG 9.11.5-P4-5.1+deb10u2-Raspbian <<>> ptr lb._dns-sd._udp.fritz.box @fritz.box
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8525
;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; WARNING: Message has 23 extra bytes at end
Öffentliche DNS-Server liefern ebenfalls NXDOMAIN, aber ohne die Warnungen.
In beiden Fällen sieht der Client allerdings status: NXDOMAIN und sollte daher die weitere Suche einstellen.
Es könnte sich bei Deiner Beobachtung also sowohl um einen Fehler in der FB als auch um ein fehlerhaftes Verhalten eines Clients handeln.
Bei den DNS-SD-Anfragen in Deinem Query Log ist außerdem die Verwendung einer IP-Adresse aus einem Bereich außerhalb Deines Subnetzes auffällig, nämlich 10.254.254.254 (aus lb._dns-sd._udp.254.254.254.10.in-addr.arpa).
(Vielleicht handelt es sich dabei aber auch bloss um eine Apple-Spezialität - ich habe keine Apple-Geräte und kann das daher nicht nachvollziehen.)
Lässt sich diese IP-Adresse in Deinem Netzwerk über ping erreichen?
Welches Gerät würde dann dahinter stecken?
