So can you elaborate more on how the issue looks for you? Because @Geln said above that it is working well for them with Conditional forwarding.
Have you installed Spotify on that device? Try uninstalling the app. That caused the behavior on my device. Pihole was not the problem at all.
Sorry, i didn't catch, that conditional forwarding did resolve his issue. Mine is looking like this:
The device is working fine as far as i can tell but it would be nice if it does not throw this 'error'. As i said before it's only one device with that issue, all other apple device are fine.
Thanks for that hint but i don't have spotify installed on any device in my home network.
Concerning Pi-hole, everything is fine in this screenshot. You iPhone is making the query to
lb_dns-sd._udp.fritz.box. Pi-hole doesn't know the answer and forwards to to the Fritzbox. This replies with
NXDOMAIN and requests Pi-hole should not cache this
Blocked (extern, NXRA).
Next time the same query is made, the same happens again.
Concerning Pi-hole, everything seems to work as expected. These queries would also be there without the Pi-hole (and also they'd be replied to the same way by the Fritzbox), Pi-hole just unveils this behavior.
You should contact Apple support about this. In the end you payed a premium price for the device. You would hope this means they have an excellent (technical) service as well that can answer what you can do.
Thanks for the clarification / summary of the case. I thought pihole redirects the query kind of wrong.
Who said anything is ignored anywhere?
$ dig PTR lb_dns-sd._udp.fritz.box @192.168.2.2 ; <<>> DiG 9.16.1-Ubuntu <<>> PTR lb_dns-sd._udp.fritz.box @192.168.2.2 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 56980 ;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;lb_dns-sd._udp.fritz.box. IN PTR ;; Query time: 7 msec ;; SERVER: 192.168.2.2#53(192.168.2.2) ;; WHEN: Sa Feb 06 22:57:41 CET 2021 ;; MSG SIZE rcvd: 42
192.168.2.2 is a Fritzbox).
I have the same behavior: DNS-SD request for your local network are forwarded to fritz.box because of conditional forwarding and you still get status Blocked. But other DNS-SD requests are forwarded to upstream DNS server. This mixed behavior seems to be OK for my Apple Devices. I do not the problems I had before where Fritz!Box was my upstream DNS.
@anon55913113 I see what lead to the misunderstanding. Yes, it is the Fritzbox that requests the no-caching by not providing a TTL at all.
My assumption would be that it may be requests ending in
fritz.box go to the Fritzbox (which replies with: I don't know hat you want) and others manage go out (because conditional forwarding isn't triggered for them)? Looking at your screenshot above:
they seem to result in
N/A meaning the upstream never replied with any answer. Silence is of course different than NXDOMAIN.
No. 1 still doesn't make much sense as, when I directly query the Fritzbox, I do seen this issue. However, I guess with Conditional Forwarding you won't see a difference between 1 and the solution including CF ?
Unfortunately, this happens more often. I have tried the FritzLabor version and the phones are now able to show a weather screen. This worked for the first day, since then they display "Der Server ist nicht erreichbar." Nothing is blocked in Pi-hole and I don't see why this is happening. I wrote them feedback and on the second try I received quite a soggy reply like: "Fakt ist Ihre 7590 funktioniert einwandfrei. Mehr gibt es da nicht zu sagen." sigh...
You may want to reconsider this. Check out Will DoH & Pi-Hole Still Work With A Recursive DNS Server Setup - #4 by yubiuser
in my case I also see lb entries from many Apple devices under the top blocked domains but if I take a look into the logs directly I cannot see that they are blocked. Looks for me that a "retried" entry will be categorized as "blocked"... is that possible (bug)?
No, everything works as expected.
Looking at your screenshot everything looks fine:
iPhone-12-Prorequests the domain.
- It is forwarded to
unifinever reponds to the request (reply
not applicable = N/A)
- Your iPhone isn't satisfied with not getting a response and tries again
- Pi-hole detects this a try for the same domain as before and categorizes it as
unifidoesn't respond further, hence the shown reply is still
The difference between what you are seeing (green, retried) to what others describe here (red, externally blocked) is how the routers behaved:
- Fritzbox: Blocks this query
- Unifi: Just drops the query, seemingly not considering worth a reply at all
Thanks for the explanation Coro...
But from where are my registered blocks coming? I cannot see it in my logs... Any ideas?
Can you click on the link on the dashboard? This should redirect you to the Query Log with properly set up filtering for these domains.
I can’t because I only can see it in the long-term data stats and there is no possibility to click on it.
Not under "long-term data / top lists". Only on the dashboard directly, but there I cannot see this entries because they are not under the top 10.
If I filter out the "lb*" entries in the long-term view I only can find "OK (forwarded), OK (cached) and Retried entries, but no blocks.
I am a little bit confused why the stats are showing me blocked domain entries for the lb.* addresses.
Judging by your two screenshots, your iPhone-12-Pro is responsible.
At least, it nicely matches all service discovery domains listed under Top Blocked Domains.
To confirm that, runnning the following command will give you a list of your top 10 requesting clients for a domain from your database:
sqlite3 "/etc/pihole/pihole-FTL.db" \ "SELECT count(client), domain, client FROM queries \ WHERE domain LIKE 'lb._dns-sd.%' AND status NOT IN(2,3) \ GROUP BY client, domain ORDER BY 1 DESC LIMIT 10;"
LIKE pattern as required.
If you want to exclude UNKNOWN query results as well, add 0 to status
Refer to Query database - Pi-hole documentation for status details.
Yes, this is indeed a bug as the database API considers them as blocked because it doesn't know that retried isn't a blocked query - the new query types were never added. We need to fix this.
@jostrasser don't worry, it is a displaying bug. If they do not show up on the dashboard (where the bug does not exist), they are mere false positives.
Thanks to all for the support and for confirming the UI bug!
Will be fixed by