I'm seeing this exact issue: https://github.com/FreshTomato-Project/freshtomato-arm/issues/268
My parents have a Roku box that just started flooding DNS to its telemetry endpoints which are blocked by DNSBL policy. I'm seeing millions of requests in the reporting period (I think OPNsense keeps last 24 hrs). The only issue is that it's causing log buildup which is overwhelming the system. Memory use went from ~20% (baseline) to over 60%, mostly due to Unbound's logger (attached). The Unbound reporting is taking half a minute to load. Also seeing slowdowns in the live view and Firewall widget loading.
top-blocked.webp
What I did remotely was to force the WiFi client to reconnect via the UniFi console. Unfortunately it immediately started spamming DNS again once it reconnected. For the moment I've blocked the device from internet access.
The recommendation in the GH link is to redirect the telemetry endpoint to some blackhole IP instead of 0.0.0.0. I think that could end up being a maintenance issue if the hostnames change, so I'm wondering if I can instead rate limit the DNS requests just from this device? A quick forum search seems to indicate there's no way to do that, but I'm not sure. Appreciate tips on how to best proceed (short of throwing the Roku in the trash).
Why not redirect the Roku to 127.0.0.1, letting it spam itself?
It was tried (4th comment in the ticket) and apparently only worked initially.
Worth a shot, though.
(EDIT): I think the problem is that I would have to set up an alias with the specific telemetry endpoints to use as the destination in the DNAT rule. Roku apparently has many such endpoints. I can't keep such a list manually updated and reliable.
For example, in my logs it's spamming "brewster.logs.roku.com" but in the logs in the linked ticket it's spamming "bayside.logs.roku.com".
You might be able to use a firewall overload table combined with a block rule.
If your DNS rule matches and too many requests are sent then the client will be added to the defined overload table.
Then with a block rule before the dns allow rule, that client will then be blocked for some time.
But that would block all DNS traffic of that client. So kinda moot if it should still be allowed "something" and only telemetry should be blackholed.
If the telemetry endpoints are all under some certain wildcard domains you could also use a dnsmasq ipset alias to banish them to the shadow realm.
https://docs.opnsense.org/manual/dnsmasq.html#firewall-alias-ipset
In AdGuard Home you could do something like this:
'rewrites':
- 'domain': *.logs.roku.com
'answer': 127.0.0.1
And in Unbound:
(https://forum.opnsense.org/index.php?action=dlattach;attach=55695;image)
Thank you, I added the host override in DNS but it looks like the Roku doesn't want to shut up. I tried both 127.0.0.1 and 192.168.254.254. The log spam continues.
Quote from: Monviech (Cedrik) on June 09, 2026, 12:50:08 PMBut that would block all DNS traffic of that client. So kinda moot if it should still be allowed "something" and only telemetry should be blackholed.
If the telemetry endpoints are all under some certain wildcard domains you could also use a dnsmasq ipset alias to banish them to the shadow realm.
https://docs.opnsense.org/manual/dnsmasq.html#firewall-alias-ipset
Yeah, I need for it to stay connected so they can watch TV and only the DNS spam should be controlled. A firewall rule for all *.logs.roku.com would let me disable logging so that could possibly do the trick, as long as they don't change it. Thanks, will look into this.
Long term, it would be nice for OPNsense to have a rate limiting function :)
Well opnsense does have a rate limiting function, its the PF overload tables and/or request limiters. But it can only limit by source and destination and other layer 3 identifiers.
Since your destination is semi dynamic, it could only rate limit a source, and that would then block the whole source, or drop requests that you might want.
A rate-limiter would do the same, it couldn't identify which traffic you want, and which you don't, because there is no metadata to use here (other than source and destination...)
If you want to rate limit on a higher OSI Layer (e.g. on the application layer by checking DNS packet contents itself) the firewall would already have to process more again which is the same as simply allowing the processing to hit the DNS daemon anway since it can handle that load if the hardware itself can handle the load.
And then we get into CDN territory, since you need beefier hardware to filter out requests that should be rate limited before it hits your own smaller hardware. Push expensive filtering/classification away from the smaller origin system. On a home firewall, that extra layer usually does not exist, so the resolver still has to receive and inspect the request before it can decide what to do with it.
Quote from: OPNenthu on June 09, 2026, 11:44:12 AMAppreciate tips on how to best proceed (short of throwing the Roku in the trash).
IMHO that's the best thing to do after reading this : https://discourse.pi-hole.net/t/what-domain-to-whitelist-to-unblock-roku-tv-schedule/86284
And now your topic too... :'(
Quote from: OPNenthu on June 09, 2026, 01:39:55 PMLong term, it would be nice for OPNsense to have a rate limiting function :)
Pi-Hole has the limit DNSmasqd has too :
Quote-0, --dns-forward-max=<queries>
Set the maximum number of concurrent DNS queries. The default value is 150, which should be fine for most setups. The only known situation where this needs to be increased is when using web-server log file resolvers, which can generate large numbers of concurrent queries.
So in theory the one in OPNsense should behave the same :)
Quote from: Monviech (Cedrik) on June 09, 2026, 02:21:18 PMSince your destination is semi dynamic, it could only rate limit a source, and that would then block the whole source, or drop requests that you might want.
Got it. I was thinking to allow certain sources to talk to Unbound at a set rate (ray 1 req/sec) rather than blocking them after some quota, but I don't know how that would be implemented except maybe in pf itself.
Here's a different idea but it might be a dumb one...
OPNsense is already handling the blocklist policy for Unbound via python hooks. Those policies could be enhanced to, say, have an option to silence blocked requests only from specific problematic sources rather than letting the log fill up. Right now logging is all or none, but it needn't be. The DNSBL is otherwise doing its job. It's just a resource problem.
Quote from: nero355 on June 09, 2026, 02:24:19 PMIMHO that's the best thing to do after reading this : https://discourse.pi-hole.net/t/what-domain-to-whitelist-to-unblock-roku-tv-schedule/86284
You won't find one in my home, but my parents subscribe to a streaming app on that platform for international programming. So I try to contain it for them.
The thing that really lights my candle is recent revelations that many smart TVs have been caught capturing frequent screenshots of owners' screens and there's speculation about microphones doing the same kind of thing.
I'm perfectly happy with a "dumb" TV that I can plug what I want into, thank you very much.
BTW r/e the antenna TV EPG issue that person in your thread mentions- I don't know if my parents' Roku has the issue but I anyway set it up so that they switch to the antenna input and use the TV's own remote for channel tuning when they want to watch OTA channels. The TV was designed to do one thing well, so might as well use it :) However, if you have a fully integrated RokuTV I guess that limits your options.
Quote from: nero355 on June 09, 2026, 02:24:19 PMSo in theory the one in OPNsense should behave the same :)
That could be helpful if I were using Dnsmasq for DNS, but anyway that to me looks like a global limiter rather than from a specific source. Nice that they include it.
Annoying isn't it. These roku boxes are infuriating from a networking POV but are a big favourite with older people for easy access to streamed TV because the interface is a masterclass in UX. Sadly I have one here :-( and I resorted to putting it on a smart plug to keep it off most of the day. I put it on its own SSID which is also on a schedule. A bit extreme but at least I no longer see 24hr DNS storms. Whilst they are known to be chatty, something updated a couple of months ago that resulted in much higher rates of queries for those same few hostnames. I have the roku querying a pihole so these requests fortunately don't hit opnsense.
Quote from: keeka on June 09, 2026, 06:17:00 PMWhilst they are known to be chatty, something updated a couple of months ago that resulted in much higher rates of queries for those same few hostnames.
That jives. It's always been the chattiest in the DNS logs, but never like
this.
Maybe some middle manager vibe coded something... lol.
Quote from: keeka on June 09, 2026, 06:17:00 PMI have the roku querying a pihole so these requests fortunately don't hit opnsense.
That's also an option. I've been resisting moving DNS off of the firewall because it's one more thing to host and maintain.
You could use NAT to forward just the Roku requests directly to 8.8.8.8 for example. Or give it a dhcp reservation with an external dns server right away.
Or to dnsmasq on port 53053, you can run multiple dns servers at the same time.
I don't know about the OP but IME the Roku DNS storm is a hissy fit in response to DNSBL. I only forward DNS to the pihole for select clients. Everything else, inclusing the pihole, queries opnsense unbound directly, which is not using any DNSBL.
Quote from: keeka on June 09, 2026, 06:51:26 PMI only forward DNS to the pihole for select clients. Everything else, inclusing the pihole, queries opnsense unbound directly, which is not using any DNSBL.
That's effectively what the source-based Unbound policies allow you to do, since the OPNsense devs brought that into the community edition from the business edition some months ago. It was a game changer for reducing the need for external DNS, IMO.
Quote from: Monviech (Cedrik) on June 09, 2026, 06:39:09 PMYou could use NAT to forward just the Roku requests directly to 8.8.8.8 for example. Or give it a dhcp reservation with an external dns server right away.
Well, the desire is to actually block that telemetry, just in a way that doesn't also kill the OPNsense resources. I feel like this is a design problem because any misbehaved actor on the network could similarly do this, no? Just happy that this one happens to be benign.
BTW, the firewall in question has 8G of RAM. The CPU is relatively weak (J4125) but still doesn't break a sweat as a pure firewall+router for gigabit.
Denial of Service can take many shapes, one of them is harddrive space exhaustion. Any service that logs can be susceptible to it, thats why logs rotate and can have upper size limits etc... but rogue clients are always an issue, its one of the main reasons CDNs have so many customers xD
I have a TCL TV that has Roku OS on it. It's constantly very chatty. I use ControlD for DNS so I have it blocked. I tried disconnecting the TV from the network, but then there is a bright white light on the front of the TV that constantly flashes with the intensity of a thousand suns.
I looked for a new "dumb" TV with no smart features. I quickly found out unless you want to buy a professional display costing almost as much as a car you are stuck with this scheiße.
</rant>
Quote from: RobertoZ on June 09, 2026, 07:23:51 PMI looked for a new "dumb" TV with no smart features. I quickly found out unless you want to buy a professional display costing almost as much as a car you are stuck with this scheiße.
</rant>
It almost seems like the market is rigged so the rentiers and data brokers always win...
Quote from: RobertoZ on June 09, 2026, 07:23:51 PMI have a TCL TV that has Roku OS on it. It's constantly very chatty. I use ControlD for DNS so I have it blocked. I tried disconnecting the TV from the network, but then there is a bright white light on the front of the TV that constantly flashes with the intensity of a thousand suns.
I looked for a new "dumb" TV with no smart features. I quickly found out unless you want to buy a professional display costing almost as much as a car you are stuck with this scheiße.
</rant>
You can stop by your local friendly hardware store if you do not have a black electrical tape and cut a tiny piece and place it on the bright LED. :)
No smartTV should be on anyone's network, even the world's BEST SONY Android TV's.
Quote from: lilsense on June 10, 2026, 12:13:36 PMNo smartTV should be on anyone's network
MWAHAHAHA!!!!!
"It's funny because it's true!" :P
Quick update-
The DNS storm seems to have stopped overnight but I'm not sure why. All I had done was add a host override in Unbound with the black-hole IP, but I had removed it since it wasn't helping to calm the log spam. Now it's back to just the DNSBL policy blocking the telemetry and it's acting normally.
I guess either there's some trigger for the storm that hasn't been hit yet, or something's been fixed (hopefully).
Quote from: OPNenthu on June 10, 2026, 10:30:58 PMQuick update-
The DNS storm seems to have stopped overnight but I'm not sure why.
I wouldn't bet on it. When I first noticed the increase in DNS queries, I left the roku powered down for a short period. After restarting, DNS queries remained low for some time, but eventually returned to once per second for each of various hosts in logs.roku.com. I don't see any performance hits at that level but it is rather irritating and does put me off buying more such devices.
I had almost two months of relief from this but now I got a Monit alert email that the CPU was pegged.
It's Roku again.
# top
last pid: 94206; load averages: 12.54, 12.19, 7.00 up 1+00:26:27 15:38:35
75 processes: 3 running, 72 sleeping
CPU: 97.8% user, 0.0% nice, 2.3% system, 0.0% interrupt, 0.0% idle
Mem: 937M Active, 1712M Inact, 2074M Laundry, 1646M Wired, 1151M Free
ARC: 705M Total, 221M MFU, 403M MRU, 532K Anon, 14M Header, 63M Other
566M Compressed, 6726M Uncompressed, 11.89:1 Ratio
Swap: 8192M Total, 2265M Used, 5926M Free, 27% Inuse
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
4737 root 11 113 0 470M 371M CPU1 1 2:41 191.32% python3.13
4013 root 11 111 0 514M 396M RUN 3 2:43 180.62% python3.13
48625 unbound 4 3 0 802M 376M kqread 1 191:11 19.53% unbound
17859 root 3 0 0 81M 36M kqread 1 14:54 1.34% syslog-ng
87088 root 1 0 0 14M 1748K bpf 3 13:56 1.33% filterlog
...
Screenshot from 2026-08-04 15-43-19.png
I went back to post #4 and re-added the host override in Unbound.
I see from the query logs that the override is in effect (it's using "Source=Local-data"), but the client is still spamming so much that it's keeping the OPNsense CPU busy and the system temps elevated.
# top
last pid: 43681; load averages: 6.45, 2.66, 2.83 up 1+00:52:34 16:04:42
77 processes: 3 running, 74 sleeping
CPU: 97.9% user, 0.0% nice, 2.0% system, 0.1% interrupt, 0.0% idle
Mem: 1176M Active, 1138M Inact, 1838M Laundry, 1680M Wired, 1689M Free
ARC: 724M Total, 243M MFU, 402M MRU, 1668K Anon, 14M Header, 64M Other
583M Compressed, 6817M Uncompressed, 11.69:1 Ratio
Swap: 8192M Total, 2147M Used, 6045M Free, 26% Inuse
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
750 root 11 111 0 443M 342M RUN 2 1:59 193.59% python3.13
23 root 11 114 0 464M 367M CPU3 3 2:03 191.15% python3.13
9890 unbound 4 0 0 617M 501M kqread 3 0:57 9.36% unbound
17859 root 3 0 0 85M 39M kqread 1 15:06 0.70% syslog-ng
87088 root 1 0 0 14M 1748K bpf 2 14:08 0.70% filterlog
...
Hopefully it calms down in some time but I may need to break down and install a standalone DNS there to get this load off of OPNsense. As a last resort I'll consider disabling the telemetry blocks :(
Sorry to hear it's had a relapse. Mine has been furiously querying the same hosts in logs.roku.com ever since your OP. Consequently it spends 21 hours a day turned off via smart plug! From the hostnames concerned, it would seem associated with the Roku OS itself rather than some errant app. Idiotic behaviour.
Quote from: OPNenthu on August 04, 2026, 10:20:24 PMI may need to break down and install a standalone DNS there to get this load off of OPNsense.
You could ofcourse give it a small dedicated DNS Server running on a Raspberry Pi 2B/3B or perhaps even a Pi Zero and keep everything else as is :)
What a horrible device by the way...
Has anyone ever complained about this via Roku Support or something like that ?!
That amount of DNS Requests from such a small shitty device is just
INSANE!!! :(
You could try the new rate limits of pf out to limit how many pakets the Roku could send the opnsense dns port.
https://github.com/opnsense/core/commit/80f4affed7074a1095a3ffabe98419af2d4498af
Quote from: Monviech (Cedrik) on August 05, 2026, 03:55:43 PMYou could try the new rate limits of pf out to limit how many pakets the Roku could send the opnsense dns port.
https://github.com/opnsense/core/commit/80f4affed7074a1095a3ffabe98419af2d4498af
This brought the load averages down a lot and restored the system responsiveness. Thank you for adding it!
Implementation notes below.
last pid: 73963; load averages: 0.26, 0.18, 0.17 up 0+02:01:28 15:14:13
71 processes: 1 running, 70 sleeping
CPU: 0.3% user, 0.0% nice, 0.3% system, 0.0% interrupt, 99.4% idle
Mem: 265M Active, 1307M Inact, 1194M Wired, 4745M Free
ARC: 382M Total, 154M MFU, 177M MRU, 9639K Anon, 2886K Header, 39M Other
273M Compressed, 730M Uncompressed, 2.67:1 Ratio
Swap: 8192M Total, 8192M Free
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
17210 unbound 4 0 0 603M 500M kqread 2 1:55 0.55% unbound
50439 root 1 0 0 100M 56M nanslp 1 0:33 0.55% php
22734 root 8 5 0 411M 335M kqread 1 8:34 0.12% python3.13
73963 root 1 0 0 15M 3884K CPU0 0 0:00 0.06% top
33976 hostd 12 0 0 77M 16M uwait 2 0:04 0.04% hostwatch
54035 root 3 0 0 51M 17M kqread 0 0:24 0.03% syslog-ng
73373 root 1 0 0 14M 2524K select 3 0:01 0.03% powerd
69073 root 1 0 0 14M 3364K bpf 0 0:00 0.02% filterlog
...
I applied with "$ opnsense-patch https://github.com/opnsense/core/commit/80f4aff" on top of 26.7.1_1.
There was a trick to making it work correctly with my ruleset. I ended up with 4 new rules in Floating (plot twist: there are actually multiple Rokus on the network so I made an alias):
dns-limiters.png
pass in quick inet proto {tcp udp} from $HOSTS_ROKU to {127.0.0.1} port {domain} keep state max-pkt-rate 50/10
pass in quick inet6 proto {tcp udp} from $HOSTS_ROKU to {fdff::1} port {domain} keep state max-pkt-rate 50/10
pass in quick inet proto {tcp udp} from $HOSTS_ROKU to {(self)} port {domain} keep state max-pkt-rate 50/10
pass in quick inet6 proto {tcp udp} from $HOSTS_ROKU to {(self)} port {domain} keep state max-pkt-rate 50/10
block return in quick inet proto {tcp udp} from $HOSTS_ROKU to {any} port {domain}
block return in quick inet6 proto {tcp udp} from $HOSTS_ROKU to {any} port {domain}
The first two catch any redirected requests from NAT rules.
The third catches normal queries to the Unbound listener on the interface.
The fourth (important!) catches and rejects any that were not matched by the rate limiter. I found in testing that once the rate limiter is exceeded the queries would simply go on to match the default DNS rule at group/interface level, so they need to be explicitly dealt with.
Made all of them non-logging rules.
Now, I need to confirm any effects on Roku usability. I'll give it a day or two to see if my parents notice any service disruptions.
Quote from: OPNenthu on August 05, 2026, 09:34:41 PMblock return in quick inet proto {tcp udp} from $HOSTS_ROKU to {any} port {domain}
block return in quick inet6 proto {tcp udp} from $HOSTS_ROKU to {any} port {domain}
If you were to change the
Action in these rules to
Block, by how much would the rate of queries drop?
block drop in quick inet proto {tcp udp} from $HOSTS_ROKU to {any} port {domain}
block drop in quick inet6 proto {tcp udp} from $HOSTS_ROKU to {any} port {domain}
The Reject action plays a critical role here. These rules are throttling all of the DNS queries from the Roku group, not just the undesirable ones. I need them to fail fast with feedback so that the streamer doesn't hang and has the best chance of retrying quickly when one of the necessary queries gets dropped.
Quote from: OPNenthu on August 06, 2026, 07:23:47 AMThe Reject action plays a critical role here. These rules are throttling all of the DNS queries from the Roku group, not just the undesirable ones. I need them to fail fast with feedback so that the streamer doesn't hang and has the best chance of retrying quickly when one of the necessary queries gets dropped.
I see now, thanks
I unhooked my Samsung tv (from iot vlan) and moved to a Apple TV because of this noise
Still has some noise but not as much as a tizen os
Appreciate the reminder on why I'll never own a Roku
The proper fix for this can be manually applied in the unbound or dnsmasq configuration file-until the functionality has been added to the GUI.
The ticket is already opened for a while...
https://github.com/opnsense/core/issues/10032
Shouldn't the cache TTL of any DNS record be set by the authoritative server for the zone in question?
Quote from: Patrick M. Hausen on August 06, 2026, 02:05:01 PMShouldn't the cache TTL of any DNS record be set by the authoritative server for the zone in question?
This and similar threads don't exist because of what should or shouldn't, they do because of poor programming, or malicious sometimes, or simply idiotic if you want to get philosophical (how many queries each minute for the same servers is done by YouTube apps as round trips on the Internet ?).
For all of the reasons above you need these controls
Quote from: newsense on August 06, 2026, 12:33:55 PMThe proper fix for this can be manually applied in the unbound or dnsmasq configuration file-until the functionality has been added to the GUI.
The ticket is already opened for a while...
https://github.com/opnsense/core/issues/10032
IIRC my Pi-Hole + Unbound setup has this feature already :)
There was also some additional piece of software for Unbound that can cache frequently requested stuff for you for longer periods based on your personal preferences, but I can't remember the exact name...
Quote from: nero355 on August 06, 2026, 07:45:05 PMThere was also some additional piece of software for Unbound that can cache frequently requested stuff for you for longer periods based on your personal preferences, but I can't remember the exact name...
The man page for unbound.conf(5) lists this option, is it what you are thinking of?
cache-min-ttl: <seconds>
Time to live minimum for RRsets and messages in the cache. If the
minimum kicks in, the data is cached for longer than the domain
owner intended, and thus less queries are made to look up the
data. Zero makes sure the data in the cache is as the domain
owner intended, higher values, especially more than an hour or so,
can lead to trouble as the data in the cache does not match up
with the actual data any more.
Default: 0 (disabled)
The setting in Services -> Unbound DNS -> Advanced is;
(https://forum.opnsense.org/index.php?action=dlattach;attach=57351;image)
Quote from: lmoore on August 06, 2026, 08:18:18 PMThe man page for unbound.conf(5) lists this option, is it what you are thinking of?
cache-min-ttl: <seconds>
Time to live minimum for RRsets and messages in the cache. If the
minimum kicks in, the data is cached for longer than the domain
owner intended, and thus less queries are made to look up the
data. Zero makes sure the data in the cache is as the domain
owner intended, higher values, especially more than an hour or so,
can lead to trouble as the data in the cache does not match up
with the actual data any more.
Default: 0 (disabled)
The setting in Services -> Unbound DNS -> Advanced is;
https://forum.opnsense.org/index.php?action=dlattach;attach=57351;image (https://forum.opnsense.org/index.php?action=dlattach;attach=57351;image)
I am aware of that option, but it was something that would basically run as an extension of Unbound.
However maybe that option made that piece of software obsolete now...
Haven't read anything about it for a long time :)
I think I haven't had enough coffee yet today because I'm confused by the Git ticket that @newsense posted. Don't those cache settings already exist in the Unbound GUI?
I have them set to custom values on this firewall since long go:
custom-ttl.png
root@firewall:~ # cat /var/unbound/advanced.conf | grep cache
msg-cache-size: 128m
rrset-cache-size: 256m
cache-max-ttl: 86400
cache-min-ttl: 300
I agree that the Host Override I used has TTL 0, so that should probably be removed now.
The question then is: do DNSBL hits honor TTL settings? Or do those also have TTL 0? And for that matter, does forcing NXDOMAIN on DNSBL hits instead of 0.0.0.0 have a negative impact here as well because I use that.
Another observation I had is that the python process is exercised heavily even when I'm using the Host Override for these domains. I know that python is used for DNSBL processing in the OPNsense implementation of Unbound but I'm not sure why that would come into play when a host override is used. Could there be a python hook somewhere that is adding to the overhead?
I tried creating unbound overrides for the 2 URLs mine is spamming to unreachable addresses with TTLs of 86399
Didnt work
See some creative stuff in here, but I think im just going to explode this little plastic box with a 106lb kettlebell and call it a day
Kettlebell drop is arguably the most therapeutic solution ;)
---
I did a few quick tests and spot checked the results in Unbound reporting. In order:
1) Using a Host Override with 127.0.0.1 as the IP and default host TTL (0).
host-override-ttl0.png
2) Using only the DNSBL policy with NXDOMAIN and the cache TTL in the DNSBL policy set to 72000:
DNSBL-NXDOMAIN.png
3) Using only the DBSNL policy with 0.0.0.0 (default) and the cache TTL in the DNSBL policy set to 72000:
DNSBL-default.png
4) Reverting to Host Override but this time with host TTL set to 3600 in the override:
host-override-ttl3600.png
---
I won't pretend to understand some of the things I'm seeing. The only case where the query showed any non-zero TTL in the reporting was with the default DNSBL return value (not using NXDOMAIN) in case #3. I don't know the source of that value though because it doesn't match anything I have configured in Unbound during that test.
Overall however, I can say that none of these has any observed effect on quieting down the Rokus. I'm not sure that chasing TTL tweaks is going to solve this. Remember also, I'm not trying to reduce the number of upstream resolutions. I'm trying to limit ads & trackers, but Roku software seems relentless and uncaring about TTLs in any case I tried so far.
The pf rate limiters remain effective for keeping the CPU under control, but I have yet to confirm if the Rokus behave well enough with this rate limiting. I plan to visit my parents this week and will see for myself how it's working then.
If you want to shut down more of its telemetry, shut down access to Oracle related networks.
Do a lookup with a tool like
https://hackertarget.com/as-ip-lookup/
search for oracle
and load them into an alias, and make a Floating rule using the alias as destination.
You'll see a little more getting blocked than you think. It breaks WebEx, but I don't trust Oracle at all.
A few comments on the latest posts.
The GH ticket is not about caching for RRsets.
The Rokus won't be silenced internally, that's not the goal. They can only be silenced by the devs - and clearly the every second telemetry is more important than anything for them.
If the Rokus work without sending logs then dropping the traffic is fine. Caching would only be useful if you still want that traffic to go through but instead of doing dns queries over the internet every second you'd get the replies from the cache and then unbound would refresh the dns information to serve from cache once the cached information is about to expire.
Also there's no need to have cached values for dropped traffic, it's not like those clients obey anything.
Back with an update.
While using the actual devices for a bit, we could maybe tell there was a little bit of random delay in app and video stream startup but it was quite acceptable. We could have just as well imagined it due to expectation bias.
The Unbound reports are overgrown now and taking long to load due to the tens of millions of accumulated queries, but this includes metrics from before the limiter was added. I also noticed the 'syslog-ng' service had stopped and needed a restart, which is concerning.
So... partially solved. I'll manually clear the reporting data if it doesn't rotate out soon and hopefully that will remain at manageable levels going forward. We'll see.
Appreciate all the tips so far.
---
@yourfriendarmando: thanks for that. Did you suggest it because there's a link between these two companies? I wouldn't be surprised but I don't know.
@newsense: that clears it up, thank you. As for your observation about the constant telemetry, I did notice something interesting when I was going through the Roku privacy settings that I don't recall seeing earlier (must have been added in an update?).
There were two entries in privacy settings: "Automatic Content Recognition (ACR)" and "Content Viewing Disclosure," both which can be unchecked but were enabled. This allows visual screen scraping and sending off information to 3rd parties and advertisers. Unfortunately, disabling them did not stop the DNS storm.
Hi , yes great question, the Roku devices try to connect to IPs belonging to Oracle ASNs for telemetry services. The bonus is by blocking these, it also blocks telemetry attempted to be sent by an app or two on my and/or partner's phones.
I'm going to call this a win. Been following the issue for some days now and the pf rate limiter is reliably capping the queries from the Roku group to just around 300/min, which corresponds perfectly to the 50 / 10s rate that I set in the rules.
last-hour-queries.png
The millions of queries that were bogging down the Unbound reports have also now dropped off naturally and are capped:
blocked-stats.png
One of the Rokus has recently stopped its spamming but another one remains 'active'. It's no longer making the firewall unresponsive though and now the reporting also loads normally.
I think pf rate limiting is a nice one to have in the toolbox. Good feature update :)
@OPNenthu Dealing with the problem before the queries hit a DNS server is the favourite solution IMO. Thanks for posting (post #25).
Quote from: OPNenthu on August 14, 2026, 01:23:26 AMI'm going to call this a win. Been following the issue for some days now and the pf rate limiter is reliably capping the queries from the Roku group to just around 300/min, which corresponds perfectly to the 50 / 10s rate that I set in the rules.
That "50 per 10s" you set, is this per individual device (e.g. per source ip) or is this across all matches for that rule (so the matches for Roku1 would also count towards the rate limiting of Roku2 and vice versa)?
Quote from: tangofan on August 18, 2026, 09:48:43 AMThat "50 per 10s" you set, is this per individual device (e.g. per source ip) or is this across all matches for that rule (so the matches for Roku1 would also count towards the rate limiting of Roku2 and vice versa)?
Going off of the man page (https://man.freebsd.org/cgi/man.cgi?pf.conf(5)) description for 'max-pkt-rate', I think it should count for all the clients in the source alias I used. The manual says it measures "packets matching the rule and states created by it," which I interpret this way.
I can say that the earlier Unbound reports corroborated this. While both of the Rokus were actively spamming, the total rate of queries between them was capped at the set rate.
Maybe a dev can confirm this.
Oh, but I think there might be a wrinkle with how the floating rules expand. One rule in OPNsense could really be several rules in pf, so best to check the ruleset on the backend.