Hello,
while investigating unexpected multicast traffic in my home network, I isolated what appears to be a reproducible networking issue originating from an Amazon Fire TV Stick 4K Max.
The issue does not only affect the Fire TV itself. In my environment, it generated approximately 2,600 mDNS multicast packets per second and significantly affected the stability of the entire local network.
Several older embedded and low-performance devices became overloaded by the sustained multicast traffic and were partially or completely unable to operate normally until the traffic stopped.
I would like to know whether this behavior is already known to the Fire OS engineering team and whether additional diagnostic information would be helpful.
Device
Device:
Amazon Fire TV Stick 4K Max
Fire OS:
7.7.1.3 (PS7713/5443)
Fire TV Home Version:
7280112.1
Network connection
The Fire TV is normally connected via Ethernet using the official Amazon Ethernet Adapter for Fire TV.
However, the behavior is not specific to Ethernet or to the Ethernet adapter.
I explicitly reproduced the same issue while the Fire TV was connected directly via Wi-Fi. The observed mDNS behavior and its impact on the local network were the same with both connection types.
Tested connection types:
- Ethernet via the official Amazon Ethernet Adapter for Fire TV
- Direct Wi-Fi connection
Gateway / DNS:
192.168.0.1
The Fire TV is the only device on my network exhibiting this specific behavior.
Observed behavior
The Fire TV continuously transmits mDNS (Multicast DNS) AAAA queries for hostnames within the *.fritz.box domain.
Examples observed include:
- fritz-box.fritz.box.
- fritzbox-ug.fritz.box.
When no device responds to these AAAA queries, the Fire TV continues sending them repeatedly.
During my measurements, the resulting multicast traffic reached approximately 2,600 mDNS packets per second on the local network.
Because mDNS is multicast traffic, the packets are distributed throughout the relevant local broadcast domain rather than affecting only the Fire TV itself.
The sustained traffic significantly affected the entire local network. Several older embedded and low-performance devices became overloaded, partially or completely unresponsive, and were unable to maintain normal operation until the multicast traffic stopped.
Investigation
To better understand and isolate the behavior, I implemented a minimal mDNS responder that answers only the relevant AAAA queries from the Fire TV.
The responder returns a single valid IPv6 link-local address for the requested hostname.
Immediately after the Fire TV receives a valid AAAA response:
- the repeated AAAA mDNS queries stop immediately
- multicast traffic returns to normal
- affected devices recover and resume normal operation
- the Fire TV itself continues operating normally
When the responder is disabled and the cached response expires, the repeated AAAA queries begin again.
This behavior is fully reproducible.
The test was successfully reproduced with both:
- Ethernet via the official Amazon Ethernet Adapter for Fire TV
- Wi-Fi without the Ethernet adapter
This makes an issue limited to the Ethernet adapter or its connection unlikely.
Technical conclusion
Based on these experiments, the Fire TV appears to correctly accept and cache a valid mDNS AAAA response.
However, when no AAAA response is available, the device appears to retransmit the queries continuously or at an excessive rate without a reasonable retry backoff.
The fact that a single valid AAAA response immediately terminates the repeated traffic strongly suggests that the behavior is triggered by the absence of an mDNS AAAA response rather than by general network instability.
From my perspective, this is not merely a cosmetic networking issue. The resulting multicast rate is capable of significantly degrading the stability of an otherwise normally operating local network and can overload older or lower-performance network devices.
Diagnostics available
I have collected the following diagnostic material:
- packet captures showing the mDNS traffic
- packet captures before and after enabling the workaround
- measured traffic statistics
- responder statistics
- Fire TV device and software information
- network topology
- source code of the minimal mDNS responder used during testing
I would be happy to provide this material or perform additional tests if it would help the Fire OS engineering team reproduce and diagnose the issue.
Questions for the Fire OS engineering team
-
Is this mDNS retry behavior expected?
-
Is there a known Fire OS issue involving repeated mDNS AAAA queries when no responder is available?
-
Would packet captures and the minimal reproduction setup be useful for further investigation?
-
Is there an official channel through which I should submit the complete diagnostic package?
Thank you for your time.