[l]b._dns-sd._udp.* werden zahlreich geblockt

Hallo,

ich bin schon lange auf der Suche nach der Ursache, warum in der Liste der geblockten Seiten im Betreff genannte Einträge anführen. Ich habe diverse Beiträge gelesen und Einstellungen probiert -ohne Erfolg. Zuletzt hatte ich den Verdacht, dass es daran liegt, dass ich Pi-Hole in einen Docker Container auf der Diskstation betreibe. Also habe ich einen Raspberry Pi aufgesetzt. Jedoch gleiches Ergebnis. Mein Setting (stark vereinfacht; Details kann ich nach Bedarf nachliefern):

  • Fritz!Box 7590 (Firmware 7.21) ist DHCP Server, DNS Eintrag verweist auf Pi-Hole
  • Pi-Hole (5.2.2 bzw. FTL 5.3.4) verwendet als Upstream DNS Server die Fritz!Box, damit lokale Namen aufgelöst werden
  • "Never forward reverse lookups for private IP ranges" ist deaktiviert
  • IP4 und IP6 ist konfiguriert und ich verwende für IP6 ULA (fd00...)
  • Fritz!Box Upstream DNS Server ist aktuell Cloudflare ohne DoT

Sicherlich könnte ich die Anzeige der geblockten Aufrufe filtern. Ich bin mir aber nicht sicher, ob die Konfiguration sauber ist und zu Problemen führt.

Viele Grüße,
Glen

Please provide some lines from /var/log/pihole.log that show the queries, forwards and replies.

Here some queries:

Dec 30 16:02:23 dnsmasq[566]: query[PTR] lb._dns-sd._udp.254.254.254.10.in-addr.arpa from 192.168.168.71
Dec 30 16:02:23 dnsmasq[566]: forwarded lb._dns-sd._udp.254.254.254.10.in-addr.arpa to 192.168.168.1
Dec 30 16:02:23 dnsmasq[566]: query[PTR] lb._dns-sd._udp.0.168.168.192.in-addr.arpa from 192.168.168.71
Dec 30 16:02:23 dnsmasq[566]: forwarded lb._dns-sd._udp.0.168.168.192.in-addr.arpa to 192.168.168.1
Dec 30 16:02:23 dnsmasq[566]: query[PTR] lb._dns-sd._udp.fritz.box from 192.168.168.71
Dec 30 16:02:23 dnsmasq[566]: forwarded lb._dns-sd._udp.fritz.box to 192.168.168.1
Dec 30 16:02:23 dnsmasq[566]: query[PTR] lb._dns-sd._udp.76.70.157.10.in-addr.arpa from 192.168.168.71
Dec 30 16:02:23 dnsmasq[566]: forwarded lb._dns-sd._udp.76.70.157.10.in-addr.arpa to 192.168.168.1

There are no replies.
192.168.168.1 is Fritz!Box and 71is my iPhone. It does most queries at the moment but is not the only one.

These are DNS Discovery Service requests, normal traffic with Apple devices.

I already read something about bonjour and I also assumed that is normal traffic. But why does Pi-Hole block it? Should I add requests to whitelist? E.g. using regular expression?

Pi-hole is not blocking them. The queries are being forwarded to the upstream resolver.

Dec 30 16:02:23 dnsmasq[566]: query[PTR] lb._dns-sd._udp.254.254.254.10.in-addr.arpa from 192.168.168.71
Dec 30 16:02:23 dnsmasq[566]: forwarded lb._dns-sd._udp.254.254.254.10.in-addr.arpa to 192.168.168.1

Agree according to log file. But there are no replies. And according to query log they are blocked. See screenshots

Bildschirmfoto 2020-12-30 um 18.49.48

These are being blocked by your upstream DNS resolver (or cannot be resolved by your upstream resolver), not by Pi-hole. That's the (eternal, NXRA) status.

Yes, you are right. Makes sense.

So it is not a configuration problem. The Fritz!Box reacts the same way when Pi-Hole is not in between?! The only difference is that I can see it now in the logs. Maybe I ask AVM why it's blocked or do you know the reason?

I wonder if there is a negative side effect or why is there not a side effect. Bonjour seems to work. A discovery tool found 20 Bonjour services. But Apple devices flood the network with these DNS requests. And according to the Apple article you previously posted DNS SD should be known and considered if you setup a DNS server.

Fritz!Box and Apple devices is a common setup, especially in Germany. I would expect much more people wondering what happens here. I'm the only one you needs an explanation or do people not check their logs or do not care?

I added the lb._dns-sd._udp.* in the exclusion list under API settings. Unfortunately wildcards are not possible. So I had to add each of the most common domains. At the moment there are 6 domains in the top list. Under Dashboard > Top Blocked Domains and Tools > Audit log these 6 domains are not visible anymore. But still under Long-term data > Top Lists. Maybe a bug?

Happy new year!

Long term data shows all the data. The filters are for the query log.

AVM has no explanation for the blocked requests until now. I provided several informations. I also told that I have often SERVFAIL. A problem also discussed in a Heise forum (https://www.heise.de/forum/heise-online/Kommentare/Werbeblocker-Pi-hole-Raspi-als-DNS-Server-mit-integriertem-Ad-Blocker-nutzen/Re-PiHole-Fritzbox-7590-massive-Probleme-mit-DNS/posting-37704847/show/). I am curious to see what AVM finds out. I will keep you up to date.

They confirmed problems mit DoT which will be fixed in next version. There is no direct connection to the DNS SD topic. For me it has the side effect that two problems have overlapped and I have had problems analyzing them as a result.

At the moment DoT and Pi-Hole are deactivated and everything works fine. But I have no filter.

BTW. FRITZ!Box has an IP filter. This is more effective because you can not bypass by using IP adresses. Only problem is that FRITZ!Box filter has no features like adding filter lists and no analysis tools.

Meanwhile AVM service person changed and for the third time I had to deliver logs and screenshots ...

While testing I found out that blocked lb._dns* request are the root cause for serval problems with Apple services (iCloud sync, App Store, Safari search, ...). If I change upstream DNS server in pi-hole to Cloudflare, lb._dns* requests are not blocked anymore and Apple services work as aspected. It took a long time, but now I'm able to reproduce it.

In future I want to use DoT. First step is a stable setup without.

Even it is a naming problem I have a problem with Apple service. If routing is PiHole -> FritzBox -> Cloudflare, many services don't work. If routing is PiHole -> Cloudflare, everything is fine. Cloudflare does not block ld._dns* requests. Here a screenshot showing situation switching between routing 1 to 2.

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?

Die Blacklist Lösung von der FB ist in der aktuellen Fassung in vielerlei Hinsicht nicht praktikabel und daher keine Lösung für mich. Wenn man ähnliche Features wie bei Pi-Hole einbauen würde (einfache Verwaltung von Listen, Tools zur Fehleranalyse), dann hätte der IP-Filter der den Vorteil, dass er nicht umgangen werden kann.

Den BPjM Filter habe ich momentan auch deaktiviert. Ich vermute, er hat zu Problemen bei der PS4 meines Sohnes geführt. Muss ich aber noch mal explizit testen.

Über die DNS-Port-Sperre habe ich noch garnicht nachgedacht. Muss ich mal ausprobieren.

Mit den Apple Spezialitäten kenne ich mich nicht aus. Mich haben die Adressen wie 10.254.254.254 auch irritiert. Ein Ping dahin funktioniert nicht.

Wenn ich das Log richtig lese, kommen bei den ld._dns* Anfragen auch keine IPs zurück. So hat es msatter auch vermutet.

Irgendwie scheint was im Zusammenspiel FB und Pi-Hole schiefzugehen:

  1. FB als DNS Server funktioniert
  2. Pi-Hole als DNS Server und externer DNS Server als Upstream funktioniert
  3. Pi-Hole als DNS Server und FB als Upstream führt zu diversen Problemen bei Apple Geräten. Mich wundert, warum dann Szenario 1 funktioniert.

Meinst Du mit vierten Szenario Conditional Forwarding? Habe ich gerade mal eingerichtet. Wie Bucking_Horn schon vorhergesagt hat, gehen dann die DNS-SD-Anfragen vom Subnetz an die Fritz!Box:

Um zu schauen, ob die Apple Services noch gehen, muss ich etwas warten. Meistens ist das Problem erst zeitverzögert aufgetreten und auch nicht so einfach zu testen. Ich probiere es einfach mal.

Zuvor hatte ich probiert die Fritz!Box als sekundären Upstream einzurichten. Das hat leider nicht funktioniert. Wahrscheinlich wird der sekundäre DNS-Server nicht dazu genutzt, ein erfolglose Anfrage zu wiederholen. Bin kein DNS Experte.

Screenshot was taken right after switching configuration. If there is something strange it could be the reason.

I deleted short time ago FTL db to have logs and statistics for my actual configuration. In current long-term data there are no noticeable entries and no IPv6 entries. I will check next days again.

Thanks for explanation for secondary DNS.

Diese drei PTR Queries konnte ich erfolgreich auf die Spotify App zurückführen. Abmelden (in der App) und anschließendes löschen der App hat das Verhalten beendet. Auch nach einer Neuinstallation der App trat es nicht mehr auf.
Ggf. hilft das hier jemandem.

So far, I have tried to deploy Pi-Hole with little effort and changes to the overall infrastructure. I already had enough network failures and could at least undo everything with small interventions. That's why I have so far refrained from switching DHCP.

And honestly, I can't imagine that I'm the only Apple user with Fritz!Box and Pi-Hole. I'm surprised no one else is having problems, at least I haven't found anything. I don't think that everyone has switched DHCP.

The solution with the conditional forwarding works moment well. If there is no other solution, I might stick with that. But first I'll test a bit more to see if everything really works.

I've got the same 'issue' as Glen with one apple device. i have got multiple apple devices in the network but only one is behaving like this. i'm using DHCP on my fritzbox 7490, conditional forwarding on the pi-hole and unbound as an upstream DNS server in pi-hole (upstream DNS server in the fritzbox is my pi-hole).