I've noticed that my Apple TV 4k oftentimes makes a huge amount of queries (that get blocked) when it's sleeping. It doesn't happen all the time though (I have no idea what triggers it).
Here's a screenshot of Pi-hole's activity view:
As you can see, the following two blocked domains stick out:
xp.apple.com
_dns.resolver.arpa
I presume that those get blocked for a reason and it's better not to whitelist them. However, does anyone know what exactly causes the Apple TV to make such a massive amount of queries when it should be sleeping? Is there a solution for it?
Both of your example domains are perfectly reasonable for your apple tv to be contacting.
_dns.resolver.arpa is a domain that devices are able to query to determine what DNS services are available on the connected network in a standardised way.
Pi-hole follows this same standard and blocks access to this domain to prevent your devices from sending queries to a resolver provided by your upstream DNS providers (such as google, cloudflare or quad9) without Pi-hole acting as the intermediary.
xp.apple.com is one of Apple's domains that they use for software updates. Your apple tv is clearly set up that it will keep trying if it doesn't connect to the update server.
As it's an apple update domain (rather than activity from some third-party app), I'd be inclined to whitelist it myself.
You may want to check why it was added to the blocklist(s) that you use with their maintainers, as software updates can form an important element of maintaining security on your network.
Is there a solution for it?
I'm not sure what type of solution you are seeking.
The device is making sure it is connecting to the network correctly, and seeking its software updates. It attempts the update in the background while it is 'sleeping' presumably because nobody wants to have their tv reboot for updates while they are using it.
You can always power it down when it is not in use.
xp.apple.com isn't blocked by the Pihole default lists, FYI -- using "out of the box" block lists.
Not sure if this would be it, but is your Apple TV connected via ethernet cable? If yes, they tend to be chatty while asleep for some reason. I, and others, have experienced this in the past. Pulling the ethernet cable and going wifi stopped the chatty device.
Thanks for replying!
Yes, they're both reasonable for Apple TV to be contacting. I'd rather not whitelist _dns.resolver.arpa, in case it might help Apple TV circumvent pihole's blocking.
xp.apple.com is an interesting one: it's used for some software updates, but allegedly also for some telemetry. I guess that is why it has been included on some blocklists. Also, I forgot to clarify that I'm using various Hagezi's blocklists for pihole. Personally, I've never had any problems updating my device when that domain was blocked.
I tried whitelisting xp.apple.com, but that doesn't solve the issue because _dns.resolver.arpa will still go ballistic at times with thousands and thousands of queries. As I said earlier, I'd rather not whitelist the latter.
What could be the solution? bluzfanmr1 pointed out that this happens when Apple TV is connected to the network using an ethernet cable. And that seems to be the cause for me as well. When I was using wifi that didn't happen. At first I didn't make the connection and thought that perhaps it started happening right after I updated to pihole 6 -- I did the update and started using the ethernet cable right around the same time. So, a potential solution could be to find out what exactly causes Apple TV to make so many queries through ethernet, but not wifi. Perhaps there's a specific setting for it.
Correct. I forgot to mention which blocklists I'm using:
Yes, I'm using ethernet. Come to think of it, the problem started right after I opted for using a cabled connection for it. I stream mostly from my PC to my Apple TV using jellyfin/swiftfin, so I'd rather have an ethernet connection for it -- it feels way smoother.
I wonder whether there's a specific setting when using ethernet that has an effect.
I asked ChatGPT about that behaviour and it gave a very insightful answer. In general, Apple devices seem to be more chatty via ethernet when they're idle.
I would say Apple devices are always more "chatty" than others. Apple has leaned heavily into multicast traffic and mDNS. Things like Bonjour, AirPlay, and AirPrint all rely on broadcast & multicast traffic. They also like to use DNS to discover network services. (warning, giant wall of text)
This is perfectly normal. Apple tries to encrypt it's DNS constantly to improve their user's privacy. The problem is that we are already doing that with pi-hole (and probably a better job at it). Apple has not programmed any logic to pause these upgrade requests when it sees that the upstream server doesn't support DoH.
Edit: You used to be able to adjust the blocked query TTL in pi-hole v5. If you can still do that with v6, that may help with the number of queries you are seeing.
They do. I'm in no possible way a fan of Apple, but I'm more than happy to give them credit for actually following standards here. They will (aggressively) try to find out if there is another way that they can connect, but if the answer is no, they abide by it. I've never seen an apple device trying to do a run-around of the defined DNS. Dodgy third party apps might, but Apple's software just doesn't, unlike android for example.
You can. But whether it's worth it or not is another matter.
If you increase the block TTL then you can run into problems if you need to whitelist anything. You need to wait for the device's cached copy with the long TTL to expire before you'd be able to access the domain.
It's in All Settings -> DNS Server -> dns.blockTTL in the web UI (blockTTL in pihole.toml).
I have added below dnsmasq directive via the webGUI:
$ sudo pihole-FTL --config misc.dnsmasq_lines
[ local-ttl=2 ]
That covers the TTL for both local records and the blocked ones:
$ dig +noall +answer @localhost pi.hole
pi.hole. 2 IN A 127.0.0.1
$ dig +noall +answer @localhost flurry.com
flurry.com. 2 IN A 0.0.0.0
See the "default":
$ man dnsmasq
[..]
-T, --local-ttl=<time>
When replying with information from /etc/hosts or configura‐
tion or the DHCP leases file dnsmasq by default sets the
time-to-live field to zero, meaning that the requester
should not itself cache the information. This is the correct
thing to do in almost all situations. This option allows a
time-to-live (in seconds) to be given for these replies.
This will reduce the load on the server at the expense of
clients using stale data under some circumstances.
I have a NAS and when accessing it via the webGUI, the amount of queries goes bananas without.
And two seconds shouldnt be an issue when white listing or when disabling blocking.
