Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
the piholes logs were my starting point.. seeing it being flooded with huge amounts of requests from my iPhone and iPads, asking for "Wohnzimmer.openthread.thread.home.arpa" (my AppleTV4k2ndGen is named 'Wohnzimmer') made me curious/nervous in the first place.. dont know exactly, what Apple is doing here, to be honest =/ And my pihole forwarded these requests to upstream resolvers, and this is not a good idea imho.
In my case it was the HP mini that everyone was asking for, not the ATV 4K 2G. The ATV had registered it's "openthread" name with my router automatically. I wonder whether this is because the HomePod was the second thread boarder router? The mini also took over as the Thread Boarder Router (and "leader"? not sure), so that could be the issue too.

In any case, creating a static-mapping of homepodname.openthread.thread.home.arpa pointing to my HP mini's IPV4 address reduced the DNS traffic from Apple devices AND ended the requests being forwarded to upstream DNS servers. Everything seems to be working as expected.

I now suspect an OS bug that has to do with registering the second (or subsequent) Thread boarder router (which only applies to HomePod mini and ATV 4K 2G).
 
I think that neither Apple nor the users have given it the importance that this topic deserves. I have been doing tests and looking for information about it. specifically it is about the “Thread” protocol. the only 2 devices that currently include or support it is the HomePod Mini and Apple TV 4K 2G 2021. my internet provider works with ipv4 and ipv6, and I started noticing strange behavior, especially in devices that turn off and on only when they will use, for example PS4 and PS5, although these devices do NOT require ipv6 to play online, a bad ipv6 configuration does affect them. The problem in my case was resolved by disconnecting the Apple TV 4K 2021 from the network. I have already reported it to Apple and they give very absurd excuses that the behavior is normal. however after using the wireshark tool, messages are seen coming from the Apple TV 2021, these messages are Router Advertisment. There are 2 threads in the apple forums since the Apple TV practically came out and it has not been resolved, at least they should put an option to be able to turn off the Thread protocol, I hope my comment can be useful to more people, since in an ipv4 network and ipv6 + Apple TV 4K 2021 + PS5 will cause problems
 
... however after using the wireshark tool, messages are seen coming from the Apple TV 2021, these messages are Router Advertisment. There are 2 threads in the apple forums since the Apple TV practically came out and it has not been resolved, at least they should put an option to be able to turn off the Thread protocol, I hope my comment can be useful to more people, since in an ipv4 network and ipv6 + Apple TV 4K 2021 + PS5 will cause problems
Interesting. Can you provide a link to these Apple communities discussions?

The router advertisements are not unexpected, since both these devices ARE acting as routers between the normal IPV4/IPV6 network and the Thread network. However, soemthing seems to be amiss with the implementation of Thread routing.
 
apple support have no idea what i am talking about or trying to explain
thanks for those links. You might do better to send feedback to apple with info about th problem you’re experiencing. Support cannot do anything about how iOS works. This is either a broken function or it’s working as intended. Either way, support can’t help with that.
 
again the same problem is appearing with tvOS 16, they had already solved it with iOS 15.3 or 15.4 I'm not sure. 🤬 Apple
 
Interesting: On OS 16, Apple TV (4K Gen2) and HomePod mini are running a DNS server on port 53. HomePod does not do this, so perhaps this is related to Thread. In fact Thread uses IPV6, so the Apple discussion in your previous post about ATV acting as a router may be seeing this. These IPV6 addresses might be leaking or being offered on the standard wifi/eth network by mistake.
 

Attachments

  • Image.jpg
    Image.jpg
    156.9 KB · Views: 169
The problem is that I have 4 Netatmo cameras and PS5 and PS4, and the cameras have random disconnections, in the case of PS5 and PS4 they only have problems in the playstation network friend lists. This problem was fixed in tvOS 15.4 and it didn't happen again until I upgraded to tvOS 16. It's very annoying having to unplug the Apple TV from the network so it doesn't cause problems and plug it back in when I need to use it.
 
Adding a data point to the discussion, I have noticed that Apple TV (4K Gen2, tvOS 16) is acting as a fallback DNS server for Macbooks and possibly other devices. When my PiHole stopped responding I saw a LittleSnitch firewall alert asking if I want to allow mDNSResponder to connect to dns-tls port 853 of my ATV. So this is in addition to open DNS resolver running on port 53.
 
I see that Port 853 is open as well (both Apple TV and HomePod mini), so I wonder whether Thread/Matter uses 853. dif

What I noticed for port 53 at least, is that the DNS seems to checking with the the local network's DNS server. i'd be curious to see what happens when the up-stream local DNS is not available.
 
Hi there, I made an account today just so I could be helpful to anyone who’s wondering why there’s open resolvers running on Apple TVs & HomePods (yes, they’re on HomePods too) as I stumbled upon this myself since I just bought new Apple gear recently, and having a cybersecurity background, this definitely concerned me & so I started digging.

The good news is that it’s a feature, not a bug. What you’re seeing here is that Apple is finally experimenting with zeroconf networking again after it stalled in recent years. Probably as a result of them working on the new smart home industry standard, Matter. I’ll explain further.

Sadly there’s not a whole lot of documentation on this yet, at least not for those inexperienced with networking technologies & DNS server administration. As such, the following is nothing but speculation & educated guesses on my part, so I could be completely wrong & probably at least will be on a few things. The closest you’ll get to official documentation are the possibly relevant IETF standards, and Apple’s official GitHub repo of mDNSResponder, (especially in the Documents folder).

To begin, what I suspect these open DNS resolvers are is likely Apple’s reference implementation of their fairly recent IETF standard, RFC 8766. To put it simply, it’s probably a unicast to multicast DNS proxy. It’s also more than that, it’s a stub resolver like dnsmasq and an authoritative DNS server wide area Bonjour/DNS-SD. That’s the simplest explanation I can give. Read that RFC for more specifics.

The reason this would be useful for home users is that devices can do DNS based discovery via unicast DNS rather than multicast DNS, which is inefficient, especially on WiFi. It’s multicast traffic so it gets broadcast throughout the whole network, rather than just to one device (with some exceptions like IGMP/MLD snooping, but I don’t want to open that can of worms). However, it seems that unless you have a SOHO router that will automatically add the correct local DNS delegations pointing to your Apple TVs and HomePods as authoritative for the relevant zones specified in RFC 8766, it’s likely not configured correctly. You’ll probably have to manually do it. Which I’m working on figuring out all through trial & error in my network haha.

All in all, there’s a lot of cool stuff that Apple is working on as we speak in regards to DNS standards, and they’re collaborating with Cloudflare on a lot of this. One of those standards is currently in draft status, Discovery of Designated Resolvers (IETF Draft Standard / Cloudflare blog). It’s basically standardized auto-upgrade encrypted DNS, and all of Apple’s devices on the latest OS version supports it, including Ventura & iOS 16, tvOS 16, audioOS 16, etc.

The one that I’m most excited to see in action is the new Service Registration Protocol that Apple currently has as a draft standard at the IETF also, but I digress.

Hopefully all of this helps someone out there relax a bit, you likely didn’t get owned by a hacker. 😂
 
This is a lot of info; thanks. I think most here are aware that the DNS services running on ATV/HomePods are related to Matter. It would be nice if this was documented by Apple.
 
There is a lot of info in this thread and some of it is too technical. Is there any way to stop the AppleTV G4 from doing this? I see thousands of connections in my pi-hole from my AppleTV G4 to urls like:
lb._dns-sd._udp.0.7.9.10.in-addr.arpa _dns.resolver.arpa lb._dns-sd._udp.lan

This happens when the device is sleeping. I would like to disable this behavior.
 
There is a lot of info in this thread and some of it is too technical. Is there any way to stop the AppleTV G4 from doing this? I see thousands of connections in my pi-hole from my AppleTV G4 to urls like:
lb._dns-sd._udp.0.7.9.10.in-addr.arpa _dns.resolver.arpa lb._dns-sd._udp.lan

This happens when the device is sleeping. I would like to disable this behavior.
Hello @opensky. Can I ask what negative effects you're feeling that you need to do something about this? I'm not certain about this, but these almost certainly consequences of the Thread networking capabilities of ATV and HPM. Aside from the annoyance of seeing these in logs, I'm not aware of any problems related to this.

The "too technical" aspects here might be an indicator that it's better to just ignore these. Best regards!
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.