Roku DNS storm is impacting OPNsense

[newsense]

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

[Patrick M. Hausen]

Shouldn't the cache TTL of any DNS record be set by the authoritative server for the zone in question?

[newsense]

Shouldn'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

[nero355]

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

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...

[lmoore]

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...

The man page for unbound.conf(5) lists this option, is it what you are thinking of?

Code Select Expand

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;

[nero355]

The man page for unbound.conf(5) lists this option, is it what you are thinking of?

Code Select Expand

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

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 :)

[OPNenthu]

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:

You cannot view this attachment.

Code Select Expand

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.

[OPNenthu]

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?

[0x]

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

[OPNenthu]

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).

You cannot view this attachment.

2) Using only the DNSBL policy with NXDOMAIN and the cache TTL in the DNSBL policy set to 72000:

You cannot view this attachment.

3) Using only the DBSNL policy with 0.0.0.0 (default) and the cache TTL in the DNSBL policy set to 72000:

You cannot view this attachment.

4) Reverting to Host Override but this time with host TTL set to 3600 in the override:

You cannot view this attachment.

---

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) - 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 block ads & telemetry, so TTL seems like the wrong thing to chase.  I could be wrong about this (let me know).  Roku software doesn't seem to care in any case; it's relentless. 

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.